简体   繁体   中英

Java and C# interoperability

I have two programs. One is in C# and another one in Java. Those programs will, most probably, always run on the same machine.

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.

I am author of jni4net , open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.

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.

我听说过有关IKVM的好东西,这是用.NET制作的JVM。

Ice from 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).

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...

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.

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.

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.

Another reason I like it is that your server could be used by other clients, too, as long as they know HTTP and XML.

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.

I am a big fan of Thrift an interoperability stack from Facebook. You said they code will probably run on the same machine so it could be overkill but you can still use it.

It appears a very similar question has been asked before here on stack overflow (I was searching Google for java windows shared memory):

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."

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.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM