Jack Vaughan posted in his interoperability blog about CodeMesh, and how they try to enable (and succeed to a degree) interoperability between Exiting Java code and external code written in an language like C++ (They also have a product for .NET). Their approach is to use code generation that creates wrappers around the Java code which lets you talk to the java code from the external language, and vice versa ,
Read the interview he did with Alexander Krapf in 3 parts (first, second, third) where he also refers to JuggerNET, one of their products.
On the Codemesh site they have a comparison with other methods of achieving interoperability (JNI, Web Services, hand written code, CORBA).
It’s interesting to note that on some level, both Codemesh and Mainsoft are sharing the same set of problems:
- Keeping up with new versions of the frameworks on both sides
“As people switch compilers, new issues come up, bindings must be updated. Meanwhile, certainly, new versions of .NET have to be studied for elements that it would be useful – or necessary – to update. This was interesting to me – to see platform and framework change from the point of view of an Independent Software Vendor [ISV] who must ensure the fit and finish for customers. Of course, the backdrop is a software landscape now highly influenced by open-source and free software, where end users often must take on the role of Versioning Meister.”
Amen. Mainsoft is coming to grips with the .NET framework 3.0 and 3.5, but it’s a struggle to keep up. The same goes for Java. It’s comforting to know we’re in the same boat..
“Updates in .NET, particularly, have led Krapf to consider how Generics can play in the new interoperability milieu. It is worthwhile to consider, he said, taking Java Generics and translating them into .NET. But, to do it for all APIs, he adds, “is not as trivial as it sounds.”
I spent some time talking with Noam Lampert, Dev lead here, and he explained to me some of the difficulties and challenges involved in making .NET generics to translate nicely to the java platform. For example, in .NET creating a generic type of of some sort (IList<int>) and then creating another one for a different type (IList<string>) actually creates two separate classes at .NET runtime. In Java, Generics play differently and you have to make sure you get it right or stuff just won’t work as expected or not compile at all. I hope to explain this more deeply in a alter post.
“And the other major piece is in the code generator, which knows how to map from Java Type A to the corresponding part in .NET. That’s what many people miss when they do proof of concept on things like this.“
Grasshopper doesn’t actually generate code, but it actually compiles IL code into Java Byte code. That means that you have two main use cases for Grasshopper Compiled code :
-
- Write in .NET but actually run natively in Java - no interop at all. Your code is actually Java code.In this use case you can also migrate existing .NET code to Java.
- Federate, or reuse your existing .NET code from Java or vice versa, via web services or uses remoting. For instance, you can write code in .NET that uses your existing objects through web service or remoting interface. Because you are still writing in .NET, you will not have to modify your existing code to be WS-I compliant when you expose it as a web service. You will still be able to use .NET types like DataSet even when running in Java. This is the interop scenario grasshopper enables.
- They have a bunch of utility classes to help with interop translations issues and such
We also have utility classes that are used when you write code in .NET. stuff like translating BigInteger to .NET integer values and so on. If you are programming only in .NET languages you usually do not need to use these classes directly. If you want to call from your C# code a class that was written in Java, you may need to use these to marshal specific types to the types Java expects (e.g. a DateTime to a java.util.Calendar).
Overall I’d say the main difference between grasshopper and Codemesh JaggerNet are:
- Codemesh enables native cross language interop. it allows in process interop between platforms, but does not try to solve the skill problem (where you need to learn another language to interoperate with it) . It does not support or try to support web service or remoting scenarios. in fact, it is compared against those (either-or) as a different solution.
- Grasshopper enables native code compilation to Java (solving the skill problem - I don’t need to learn java to create code or use code on the java platform . all I know is .NET)
- Grasshopper also allows writing interoperating code using web services and remoting from and to .NET without needing to translate or rewrite parts of your .NET code in Java. It is done for you. The skill barrier is taken care of, but interop at the web service or remoting level between two different platforms is possible.
- The interop solution the you can use with Grasshopper compiled code could be slower than the native calls performed by Codemesh APIs (since Codemesh uses the JNI interface, a low level C interface for the java language which is fast, and runs in process) because we support web service calls and remoting interop between .NET and java - slower than direct calls using JNI.
- Codemesh does not solve the skill problem - if I want to use Java objects from .NET or C++ I need to learn the Java API stack. with Grasshopper you only need to know .NET. the skill barrier is lower.
Your thoughts are welcome.
