Native Java - Technology Information

ENT, Jan 12, 2000 by Eric Binary Anderson

Moving: One of life's most dreaded experiences. The excitement of living in your new neighborhood is dampened by the minutia of packing, lifting, and coordinating. When you arrive at your destination, you quickly learn to appreciate the natives. The natives use shortcuts you would never find, they understand the local weather patterns, and they always know where to eat. Sure, you can get by on your own, but having a native to consult sure smoothes things out.

The Java platform has matured over the past few years, but there are many cases where it can still use the help of a native. Calling native methods -- methods written in natively compiled languages such as C and C++ -- has been supported since the early releases of Java. Consistent, portable, and maintainable native calls are relatively new to Java, however, mostly due to implementations of Java Native Interface (JNI) in most major Java Virtual Machines (JVM).

Imagine moving to a town full of feuding clans. The clans know how to run their respective local businesses efficiently, but the years of bad blood and incompatibility make it difficult for them to cooperate with other clans to scale up to broader solutions. As the new guy, you may be able to mediate effectively because of your impartiality. In the coding world, Java can play the mediator by acting as a glue layer between disparate native systems, providing a consistent specification for interoperability that each clan can follow.

Maybe you are the type of person who naturally draws people to your ideas. After moving to a new town, the natives may decide your ideas are straight from heaven. They may even commit all of their resources to try and follow your lead. Regardless of the high esteem in which the town holds you, things can't change overnight. The switch-board, power grid, and sewer system must continue to function even as new ideas are adopted.

This is similar to the situation in which Java is adopted as the core language for server-side implementations. Regardless of the level of commitment from the company, if the company has a customer base, it is unlikely that all of its existing code can be converted to Java. The source code may be lost, or perhaps the cost to rewrite is too high. In this scenario, small, well-defined chunks of functionality remain implemented in native code, while the core of the system is written in Java. Since the number of platforms for server-side development is usually much smaller than the potential platforms for a Web application, it is reasonable to port the remaining native code to each platform while the lion's share of your business logic remains in platformless Java.

Locals usually get around better than a new arrival. The native's knowledge of the secret ways to navigate a town makes newcomers look like they are standing still. Native methods likewise offer performance improvements that can leave even the much-improved Java compilers eating dust. For example, performance improvements gained by keeping large blocks of memory contiguous and unmoved are difficult in Java but simple in C. Following the 80-20 rule, the 20 percent of your Java solution that takes 80 percent of the execution time can be optimized using native methods.

The result may not be 100 percent Java, but it can be comparable in execution speed to a complete native solution.

Luckily for native Java developers, the courts ruled against Microsoft in its battle with Sun for the right to alter the Java platform. Up until 1999, Microsoft had three overlapping mechanisms for accessing native methods: RNI, COM, and J/Direct.

These mechanisms continue to be viable and are often excellent for creating Windows-specific native calls from Java. None of these techniques, however, conformed to the proposed JNI standard from Sun.

With Microsoft's JVM release #3158, Microsoft bowed to the courts and fully implemented JNI. At the time of the court ruling, the control issue seemed esoteric. Now I am actually thanking the lawyers. If my company had to support two or more separate code lines for each Java native wrapper, we likely wouldn't be using Java at all. With JNI, however, you can freely switch virtual machines and run the same Java native wrapper code.

While not appropriate for Java purists, JNI provides an excellent method for leveraging existing, working, and tested legacy code. Before you decide to rewrite your entire product in Java or give up on Java altogether, consider getting a little help from the natives.

Eric Binary Anderson is a development manager at PeopleSoft's PeopleTools division (Pleasanton, Calif.) and has his own consulting business, Binary Solutions.