Back to VSLive! San Francisco Show Daily Home

email article printer friendly

Bridging the .NET/Java Gap
SAS speaker Alex Krapf has some advice for companies with legacy code or merger and acquisition incompatibilities.
by Kay Keppler, Editor of Java Pro

VSLive! San Francisco, February 9, 2005

What would you do if somebody gave you a problem you couldn't refuse that started with 23 CORBA and C++ servers and ended with moving everything into Java? Alex Krapf, president of Codemesh and Software Architecture Summit speaker, got this problem, and it kick-started his business.

Because the libraries weren't available on the Java side, he realized that the company could either develop what it needed in Java or not use the libraries. So it didn't use them—and it had a broken application. Searching for alternatives, Krapf wanted to leverage existing code. "I just wanted to solve the problem of calling one language into another language," he said.

He saw quickly that although there are a lot of ways to solve this problem, it becomes prohibitively expensive if the problem is complex, either in terms of performance or cost of ownership. He looked at JNI, which had promise but was complex to use. What we need, he thought, is a tool that can take one side as input and generate bindings for the other side. "So we developed a prototype and got it to work," he said.

As the business grew, Codemesh's most common use situation was a merger and acquisition scenario, especially where one company used C++ and one used Java. This problem set caused the company to look more closely at the integration space. Customers told Krapf that the tool was great but not what they needed. "What customers needed was not a tool, but a solution for a specific problem. They had problems where they couldn't identify our tool as the solution," he said. So the company decided to identify JMS as the problem and build C++ bindings for it.

"That's a selling point," he said. "It was a breakthrough when we identified that as a common integration problem. Many companies use JMS. Then they said, 'If only we could do that for our proprietary Java API', and we said, 'we can.' "

Two years ago, the company branched out into Java/.NET integration, exposing Java to C# and using PInvoke and JNI under the hood. "This kind of integration is computationally relatively expensive, but much cheaper than out-of-process integration," Krapf said. "You can't really look at overhead when you have to integrate and when rewriting code is your option." Overhead on Codemesh's tools is about 25 percent, depending on the characteristics of the application. If the workload on the Java side is heavy, overhead is zero or close to zero. And, Krapf said, "there are ways to minimize overhead. So far we haven't hit a situation where overhead is a show-stopper."

Krapf believes that Codemesh is the highest-performing bridging integration solution. "If you port, you get better performance, but at a higher cost," he said.

The company has also branched into platforms: Besides Java, C++, and Windows, it's added Solaris, Linux, Mac OS, and Irix, Silicon Graphics' platform. "We definitely need to cover popular platforms, but we could probably make more money supporting unusual platforms, because there's no other solution space for customers with that problem," Krapf said. "Many companies find that on modern platforms, they already use pure Java, so they don't need us. It's on old platforms that are all C++ where they need this." The company is adding legacy platforms with its partners.

"Our strategy is to branch out into other languages, like .NET, and add platforms and compilers and solutions where we identify a Java segment that seems to be a popular integration segment. JMX is one enterprise Java segment that seems to be popular, where people have built infrastructures and they want to use them from C++ and .NET platforms. When we create a solution, we have to look for a standalone API that isn't intended to be implemented by the user, and there's only a few that lend themselves to this kind of solution," Krapf said.

Will it ever be possible to solve everybody's integration problems? Will the industry get past Java/C++ integration problems?

"C++ is almost a dead language, practically a niche," Krapf said. "What we have is a massive amount of C++ code, more than Cobol. C++ is going to stay. No way can these firms move this massive amount of C++ code into Java. If you had Java as input and had to port it to C++, that's probably a doable problem. But C++ to Java as an automated conversion is inconceivable, because you'd have to import the bugs. There's no way to analyze what's going on and come up with a Java app that does the same thing. So if you want to move it into the future, a bridging case has to come into it."

One alternative, Krapf said, is support by proxy. Say you have an existing C++ app and you have to keep it in production. Pick a module, write the Java replacement class, proxy it with the Codemesh tool, and integrate it back into the C++ app. If you did it correctly, you could use the existing test framework and make sure the app still works right. But now some parts are in Java while some are still in C++. "This is what Martin Fowler would call extreme refactoring," Krapf said. "That approach is all about how backward integration of code is inexpensive to do," he added. "If you had to do it manually, you'd be declared insane. But this way it becomes feasible, and you can transition over a long time frame."

Krapf sees Codemesh well-entrenched in Java/C++, and he believes that big movement will happen in Java/.NET over the next two to three years. "I would be very surprised if Sun and Microsoft didn't do something along these lines soon," he said. "Now they say the solution is Web services. But many customers who look at Web services come to us for a solution. Computational and maintenance costs are often too high to make Web services practical. Bridging is virtually without cost. It's a good segment to be in right now."

About Alexander Krapf
Alexander Krapf is the president of Codemesh, a bridging solutions software company in Carlisle, Mass. Reach him at alex@codemesh.com.