Accessing Java Objects from within C#
We often hear back from customers regarding this interesting problem. I am just throwing a perspective on this. Here is what we heard from one of our customers:
I'm trying to get my organization to move to C# as the primary development tool, but I have to work with another group who insists on using Java. This other group already has a number of large objects created with Java and distributed to my group as JAR files. Consequently, I do not have access to the actual Java source code. I only have the executable objects.
What is the best way to use C# to build applications that rely on the Java objects that the other group provides? I see lots of information on converting Java to C#, but I don't see anything on actually using Java within C#.
Can you help with this problem?
A> There are two things I can suggest:
1) J# ships with a tool called JBIMP.EXE which can be used to convert Java .class or .jar files to MSIL. Assuming that the JDK class library functionality used by the Java files you have is implemented in the J# class libraries, this should work great. Roughly speaking, J# provides JDK functionality for most business logic functionality. If that’s what the Java class files are implementing, you should have a pretty good migration percentage. Else, you may need to pass the /USESTUBREFS argument when calling JBIMP and re-implement some of the functionality.
2) You can look at a tool like JNBridge (www.jnbridge.com) which can provide intra-process interoperability between a Java Virtual Machine and the CLR. I highly recommend JNBridge – I’m not 100% sure of the constraints around this type of solution, but check out their Web site.
Comments
- Anonymous
December 22, 2005
There is also IKVM.NET, and it works great! - Anonymous
December 23, 2005
Converting Java .class or .jar files to MSIL is not a reasonable solution in most cases because of the need to fully re-test the generated MSIL, as well as the need to constantly update the MSIL based on changes in the Java code. Therefore, this cannot be considered a serious solution.
Products like JNBridge are the way to go because they use the existing Java implementation directly.