Java 和 C# 互操作性
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/16689/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Java and C# interoperability
提问by
I have two programs. One is in C# and another one in Java. Those programs will, most probably, always run on the same machine.
我有两个程序。一种是 C#，另一种是 Java。这些程序很可能总是在同一台机器上运行。
What would be the best way to let them talk to each other?
让他们彼此交谈的最佳方式是什么？
So, to clarify the problem:
因此，要澄清问题：
This is a personal project (so professional/costly libraries are a no go). The message volume is low, there will be about 1 to 2 messages per second. The messages are small, a few primitive types should do the trick. I would like to keep the complexity low. The java application is deployed as a single jar as a plugin for another application. So the less external libraries I have to merge, the better. I have total control over the C# application. As said earlier, both application have to run on the same computer. Right now, my solution would be to use sockets with some sort of csv-like format.
这是一个个人项目（所以专业/昂贵的图书馆是不行的）。消息量较低，每秒大约会有 1 到 2 条消息。消息很小，一些原始类型应该可以解决问题。我想保持低复杂性。Java 应用程序作为另一个应用程序的插件部署为单个 jar。所以我必须合并的外部库越少越好。我可以完全控制 C# 应用程序。如前所述，两个应用程序必须在同一台计算机上运行。现在，我的解决方案是使用具有某种类似 csv 格式的套接字。
回答by John Downey
回答by Chris Farmer
I used JNBridge (http://www.jnbridge.com/jnbpro.htm) on a relatively simple project where we had a .NET client app using a relatively significant jar file full of business object logic that we didn't want to port. It worked quite nicely, but I wouldn't say we fully exercised the capabilities of JNBridge.
我在一个相对简单的项目中使用了 JNBridge ( http://www.jnbridge.com/jnbpro.htm)，我们有一个 .NET 客户端应用程序，使用相对重要的 jar 文件，其中包含我们不想移植的业务对象逻辑. 它工作得很好，但我不会说我们完全运用了 JNBridge 的功能。
回答by Mark Cidade
回答by serg10
Icefrom ZeroC is a really high performance "enterprisey" interop layer that supports Java and .net amongst others. I think of it as an updated Corba - it even has its own object oriented interface definition language called Slice(like Corba's IDL, but actually quite readable).
ZeroC 的Ice是一个真正高性能的“企业”互操作层，支持 Java 和 .net 等。我认为它是一个更新的 Corba——它甚至有自己的面向对象的接口定义语言，称为Slice（类似于 Corba 的 IDL，但实际上非常可读）。
The feature set is extensive, with far more on offer than web services, but clearly it isn't an open standard, so not a decision to make lightly. The generated code it spits out is somewhat ugly too...
功能集非常广泛，提供的功能远远超过 Web 服务，但显然它不是一个开放标准，因此不能轻易做出决定。它吐出的生成代码也有点丑......
回答by Cheekysoft
Kyle has the right approach in asking about the interaction. There is no "correct" answer without knowing what the usage patterns are likely to be.
凯尔在询问互动方面有正确的方法。如果不知道可能的使用模式是什么，就没有“正确”的答案。
Any architectural decision -- especially at this level -- is a trade-off.
任何架构决策——尤其是在这个级别——都是一种权衡。
You must ask yourself:
你必须问自己：
- What kind of messages need to be passed between the systems?
- What types of data need to be shared?
- Is there an important requirement to support complex model objects or will primitives + arrays do?
- what is the volume of the data?
- How frequently will the interactions occur?
- What is the acceptable communication latency?
- 系统之间需要传递什么样的消息？
- 哪些类型的数据需要共享？
- 是否有支持复杂模型对象的重要要求，或者原语 + 数组可以吗？
- 数据量是多少？
- 交互发生的频率如何？
- 可接受的通信延迟是多少？
Until you have an understanding of the answers, or potential answers, to those questions, it will be difficult to choose an implementation architecture. Once we know which factors are important, it will be far easier to choose the more suitable implementation candidates that reflect the requirements of the running system.
在您了解这些问题的答案或潜在答案之前，很难选择实现架构。一旦我们知道哪些因素是重要的，那么选择反映运行系统要求的更合适的实现候选就会容易得多。
回答by Josh Brown
I realize you're talking about programs on the same machine, but I've always liked the idea of passing messages in XML over HTTP.
我意识到您在谈论同一台机器上的程序，但我一直喜欢通过 HTTP 以 XML 格式传递消息的想法。
Your server could be a web server that's ready to accept an XML payload. Your client can send HTTP messages with XML in the body, and receive an HTTP response with XML in it.
您的服务器可能是准备接受 XML 负载的 Web 服务器。您的客户端可以发送正文中带有 XML 的 HTTP 消息，并接收带有 XML 的 HTTP 响应。
One reason I like this is that HTTP is such a widely used protocol that it's easy to accept or create HTTP POST or GET requests in any language (in the event that you decide to change either the client or server language in the future). HTTP and XML have been around for a while, so I think they're here to stay.
我喜欢这个的一个原因是 HTTP 是一种广泛使用的协议，它很容易接受或创建任何语言的 HTTP POST 或 GET 请求（如果您决定将来更改客户端或服务器语言）。HTTP 和 XML 已经存在一段时间了，所以我认为它们会继续存在。
Another reason I like it is that your server could be used by other clients, too, as long as they know HTTP and XML.
我喜欢它的另一个原因是您的服务器也可以被其他客户端使用，只要他们知道 HTTP 和 XML。
回答by jatanp
If they are separate programs and running as independent applications,you may use sockets. I know it's bit complex to define communication protocol but it'll be quite straight-forward.
如果它们是单独的程序并作为独立的应用程序运行，则可以使用套接字。我知道定义通信协议有点复杂，但它会非常简单。
However if you have just two separate programs but want to run them as single application, then I guess IKVM is a better approach as suggested by marxidad.
但是，如果您只有两个单独的程序但想将它们作为单个应用程序运行，那么我想 IKVM 是一种更好的方法，正如 marxidad 所建议的那样。
回答by Pavel Savara
回答by Thorbj?rn Ravn Andersen
It appears a very similar question has been asked before here on stack overflow (I was searching Google for java windows shared memory):
似乎在堆栈溢出之前已经问过一个非常相似的问题（我在 Google 上搜索 java windows 共享内存）：
Efficient data transfer from Java to C++ on windows
From the answer I would suggest you to investigate:
从答案中，我建议您进行调查：
"Your fastest solution will be memory mapping a shared segment of memory, and them implementing a ring-buffer or other message passing mechanism. In C++ this is straight forward, and in Java you have the FileChannel.map method which makes it possible."
“你最快的解决方案将是内存映射共享内存段，它们实现环形缓冲区或其他消息传递机制。在 C++ 中，这是直接的，而在 Java 中，你有 FileChannel.map 方法，这使它成为可能。”
