Alexander Krapf is president and co-founder of Codemesh. He worked with Hitachi back in the early CORBA days, and since then he has been involved equally in .NET,  C++, and Java. We were glad recently to sit down with Alex and discuss some of the ins and outs of interoperability today. We present these in parts, starting with a discussion of early milestones in .NET-Java. That means a look at early JNI.

At the turn of the century, a healthy number of C++ shops were adding servers built in Java. The question often, said Krapf, was how one could leverage established utilities. There were DLLs that were responsible for logging data access – basically a whole slew of things that one could not leverage from the Java side. Krapf saw benefits on use of CORBA in some instances …

“In CORBA you would  create an interface description in IDL and then have whatever ORB you were using generate bindings for you in C++ or Java. But it was a layer of abstraction at the component level, not the API level,” he said.

Krapf uncovered a solution, but it was not fully optimal.

JNI rises
“I stumbled over JNI,” he said, pointing to the Java Native Interface. “It was totally unusable if you wanted  to create a large scale integration solution. It was too easy to create bugs and too hard to debug them.”

“What was needed was something to make JNI very easy,” he said. He had an idea about code generation.  Of course that meant deeply understanding JNI.

JNI is ‘the assembly language of the JVM.’ It is a C interface that lets you call out of Java to C functions. It is part of the Java spec. If you think about it, there has to be something like that. Otherwise, how does Java integrate with native files system services, for example. There has to be some integration layer, and that is essentially what JNI is.

Mosty people avoid it, and correctly so. It is good for them to avoid it. It’s very reliable because it has to be. It is the core of Java sitting on the operating system; it is the core of how you launch Java. How does a JVM start? When you kick of a java.exe, somehow you have to start a JVM. It’s done through a JNI. It’s a way to load a JVM into a native process. It’s done through JNI.

What we said was ‘there is wealth of Java functionality out there. People are starting to write more and more Java software, yet they are sitting on existing C++ software.’ We bet there were enough people that wanted to Java-enable their existing C++ software.”

For example, you have an existing MFC app on Windows and now you want to have it talk to a EJB server, or you want to have it talk to a Java message queue.

What kind of software architects choose  this type of solution? We asked. Very often, it seems, it is not exactly a choice.

Said Krapf: “Very often people don’t choose to interoperate; they are forced to interoperate.”

Give me rewrite!
Any time an integration is under consideration, the specter of the rewrite arises. When you have a lot of C++, for example, why not rewrite it in Java. Surely someone will suggest it.

Krapf said it is not likely a favorable course. “When you think of the use of resources required for rewriting software in another language, there may be some reasons to do it, but, from a technology point of view, it is a huge waste of resources.”

“Now you shoulder the burden of the rewrite, and, in the case of C++, there are very likely things in the code that you cannot understand,” he said.

Even ‘broken’ elements may need to be recreated. “There may be bugs your software is counting on,” said Krapf. “Usually you can’t do a one-to-one translation.”

The problem is not unlike the Y2K problem, to again hearken back to the turn of the century, because one encounters legacy code dependencies.

“C++ apps are full of unintended side effects. Things like explicit conversions. They make C++ code so hard to read, unless you step through it in the debugger.”

And such projects seldom go far without individuals suggesting the code can be cleaned up. The specter of refactoring also arises.

Says Krapf: “People refactor, and what they thought was a three month project turns into one year, because they’ll end up completely rewriting the app, rather than porting it.” - By Jack Vaughan

Read Part 1 | Read Part 2 | Read Part 3

This entry was posted on Wednesday, July 18th, 2007 at 5:38 pm 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.