Alexander Krapf is president and co-founder of Codemesh. We were glad recently to sit down with Alex and discuss some of the ins and outs of modern interoperability. We present these in parts, following our initial  discussion of early milestones in .NET-Java, with a look at code generators with ‘knowledge’ about Java and .NET, and a run-time library that can deal with the delicate aspects of interacting in the ‘no-man’s land’ between the major languages.

With Juggernaut as its flagship offering, Codemesh has progressed, adding various elements. Krapf and his crew have faced the continued challenge of updating its software to deal with changes on the various sides of the platform divide. The areas that change may surprise some. Krapf remarks that “C++ changes all the time. The language is fairly static, but the compilers change.”

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.

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

There are two major pieces to CodeMesh technology .. one is a code generator that has built-in heuristics concerning Java and C++ or .NET target languages. And the other piece is “a runtime library that has all the built in smarts about interacting between the two technologies.”

Said Krapf:

So, for example, the runtime library includes a runtime configuration so that people can specify what is the Java class path of their mixed language application, what are the JVM options that should be enforced, and it maps some very basic types to each other, for example, the string type, which is a built in type in both Java and .NET, so we have to do a translation between the two type. And things like that are part of the runtime library. It is essentially a utility API that we have created to talk from one language to another language.  

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.

Type System Issues
When you think about it, among various designer pitfalls looming in interoperability or porting scenarios, the issue of the ‘working proof of concept’ is one of the deepest and darkest. It may work. It may prove the concept. But it may not come close to covering every instance, or even just the most typical instances.

While by no means suggesting this represents every scenario, Alex Krapf can readily describe the general case.

“You say ‘I have a Java type. I will create a matching type for it.’ You spend a week figuring out the pitfalls of JNI. It works. Then you say ‘let’s use it for the API.’ And then you encounter type system issues, such as interfaces and abstract types. You did it for a concrete class, now you want to map the inheritance hierarchy because you want to be able to, for example,  use a string instance, in every place where an object can be passed as an argument to a method,” he said.

“Then,” he continued, “you find you have to worry about the type system – about the relationship between the types. And that’s were it becomes very non-trivial to create a whole  ecosystem of cooperating types - types that work together.”

Advises Krapf, “What is simple for one type is totally non-trivial for some other types. It’s not the 700-types-times-the-effort-for-one-type. It becomes much more difficult.” - By Jack Vaughan

Read Part 1 | Read Part 2 | Read Part 3

This entry was posted on Friday, July 20th, 2007 at 12:08 am and is filed under Interoperability, Distributed objects. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.