在同一过程中执行Java和C＃？

Question

I want to execute a Java VM and a C# application within the same process making it possible to share the same memory region along with the same memory for the same shared libraries.

Does anyone know a way to do that?

I would be able to run Java from C# or C# from Java or even using a C application to start both within the same process.

[Update]

The http://jni4net.com/ project claims to provide the Feature: "Intraprocess - it means that both VMs are in same process. Any call uses same thread and same stack for both environments. It's relatively fast."

This is exactly what I try to do myself in order to use a simple off-heap memory address and use it to both intra-process VMs.

Answer 1

C# is .NET which is compiled to an Intermediary Language (IL), it is possible that Java has a processor for the .NET IL, but it would be need to be included as part of the Java project when built.

You would not be able to run two separate processes that share the same execution thread and memory.

Answer 2

Bottom line is I don't think this is a good idea.

From my personal experience, all the currently available projects which claimed to support both are having various defects and support issues on libraries and even some language features, not to even mention the run-time performance. If you don't prefer a simple socket solution or a memory mapped file stuff and declare them to be non-standard and with pitfalls, then I could only tell you the frameworks you trying to use are with even more pitfalls.

Plus, the idea of sharing memory is a bit puzzling me. What exact data piece are you trying to share? Bear in mind that the C# and Java memory structure are not mutually compatible, you either storing some stuff with 3rd party standard eg audio/video/pictures etc; or you need to write your own serialization layer which essentially disable you from being able to operate on the same object from both sides. If you are already writing your own serialization layer, what blocks you from using a socket solution which seems best supported from both side to me?

If there is any performance concern, I could say that since you are using Java + C# solution, the performance difference between MMF, socket or shared memory is insignificant compared to whatever performance your application can possibly achieve. If your application really requires such a performance, you'd better do it in C++ or even ANSI C.

So I totally agree with all the comments, that the stuff you are trying to achieve seems not in the right direction.

Answer 3

The solution is to embed Java and Mono within the same process. There are resources available for doing so within a C/C++ application but it is not limited to C/C++.

By embedding Java and Mono (C#) together within the same process, all the desired properties can be guaranteed. There is no duplication in the shared memory, memory manipulation is instantaneously and the changes appear in the correct order.

One should take care to pin the threads according to the memory domain in multiple processor setups as always but thats about it.

It is even possible to share the same processor by pinning the threads of C# and Java to the same processor and to profit from second level and even third level caches.

Another important benefit is both VMs profit from sharing the same local shared library instance resulting in code running in either of the VMs interacting with the very same library instance instead of using two distinct versions.

Helpful information:

• For Java
• For Mono

Answer 4

There are ways to host a JVM in a .NET process, or to host a .NET CLR in a Java process, but they are ugly and require familiarity with JNI (Java Native Interface) and/or the CLR's COM-based hosting API.

There are fortunately interoperability tools that encapsulate these mechanisms and allow Java and .NET to run in the same process and freely interoperate. One such tool is JNBridgePro from JNBridge. Please see www.jnbridge.com for more information, and particularly look for "shared memory."

Disclaimer: I am with JNBridge.