Feature

I'm going to share my experience of enabling a graphics-oriented GIS visualization module with a C++ rendering engine for a Java desktop application using JNI technology.

The solution was implemented in the GIS library TerraLib as part of the TerraLib Develoment Toolkit (Tdk), applying a JNI-bridged drawing canvas as part of the Components API used by the rendering engine.

The solution gave the Java desktop application visualization module a native equivalent performance and saved a lot of duplicative effort in natively implemented rendering functionalities that could be accessed by the Java application layer. It also promoted full integration between the GIS visualization module and the application control peer.

First I'll present the architecture and then discuss how JNI can be a great solution for a well-designed native layers integration. I'll also present, throughout the text, some third-party solutions currently available, giving references and links for more information on this still challenging matter.

The Architecture
The TerraLib Development Kit - Tdk - core is entirely written in C++. It consists of a framework to make GIS developers' experience with TerraLib easier. As a proof of usage for Tdk, a visualization tool called VIPE (Visualization, Interaction, Printing, and Editing) was successfully built with the Tdk API. This native version of the application is quite stable and designed over an event-oriented model. As we'll discuss later this was a key factor in the proposed solution. I took advantage of that existing design and had the two mixed language control layers communicating through JNI. The other JNI touching point was restricted to the data layer to provide native data state management directly from the corresponding Java data layer. The latter became a very thin layer since it only holds the state management operators (accessor and mutator methods) and the JNI bridge to access the corresponding native data container effectively holding the data (see Figure 1).

Some Relevant Implementation Details
One very important implementation detail was the need to have the rendering take place on the native visualization layer where the data was formally accessible. But the user experience is actually with a JPanel instance. That made us take the risky strategy of keeping the C++ and Java control layers communicating by sending application state control and visualization UI events and finally applying the Bridge pattern on the Canvas component to enable the native rendering logic control over the Java Graphics2D-based rendering engine.

The Java control layer simply delegates the UI events over to the native layer, which in turn does the response callbacks to the Java Bridge through a jobject proxy. See Listing 1.

We ended up with JVIPE (Java VIPE) having equivalent performance to the C++ version saving development duplication related to rendering the Maps and Cartographic elements - to mention a few. What we do now is implement first in C++ and bridge it to Java. The single data cache was also a major achievement because it wasn't possible with the previous solution using CORBA. We basically succeeded on performance and memory allocation too. The client application inherited JVIPE functionalities through the Tdk Java API and is currently in production.

The drawback is still the unavoidable conversion of the geometry native data types to Java for plotting. I'm currently checking JDK1.4 NIO features for the vector data blocks' native access to the raster data types whose conversion is also very costly.

JNI Analysis
Looking back at the process that resulted in this successful solution I can risk some conclusions to pass on to those willing to embrace JNI or analyze it against some other technologies.

Native Code Access from Java Analysis
The first question that we have to answer before deciding to use JNI is when should we try to access native code in a Java development scenario?

The answer isn't as obvious as you may think. Code reuse is a questionable issue. Moving to a modern programming language will usually be a worthy move it because new language efforts usually gather technological improvements together and get rid of past mistakes. Experience says that old libraries will eventually be migrated to modern languages to be continued and improved. So the question becomes, what kind of native code should we directly access against a rewrite approach?

That question is a little simpler to answer. To answer it I'll risk generalizing two answers taken from a design decision:

1. Integration demands combined with manpower or time frame limitations for rewriting the existing code in Java (legacy case)
2. Java considerations for getting an adequate solution as a whole (scratch time case)

We also mustn't forget that not all that's written in a legacy native code can be accessed by Java. Generally speaking I'd say that the best candidates for being kept or developed in native code beforehand would be modules that implement functionalities that Java has trouble with. I mean mostly time-consuming code where Java performance misses (despite JITs, we're still buying new hardware, folks, and with new hardware the native code will run faster!)

Now that we have some idea of when to bring a tower of Babel to our code, let's analyze some technologies.

The JNI Choice
From my point of view the first analysis to do in deciding to use any technology is its applicability to the situation. It's a good approach considering we'll make serious mistakes using a technology inadequate to our situation. So we could ask ourselves if JNI is really the right technology to access native code from Java.

JNI is a standard Java API. By definition Java demands native resources access. Different technologies could replace JNI however. I've seen some sites analyzing CORBA pros and cons against JNI, and COM has been a choice for Microsoft solution providers. But it's best to analyze the situation you're trying to apply the technology to and then decide if it makes sense.

The first candidate to bridge the two worlds was CORBA since its IDL-based specifications provide language independence and we could take advantage of the client/server technology to create a distributed version of the application. After a couple of weeks of implementing a CORBA middle layer we ended up rewriting the caching model multiple times and wound up with very poor performance and a duplicated cache (the data was loaded first into the native layer and then into the Java visualization layer). All these problems basically stemmed from the separate processes scenario that CORBA - and any other inter-process (IPC) technology - brings in. That recommended JNI as the middle layer.

JNI Considerations
Accessing external modules written in a language different from the main routine isn't new to most readers. Most languages carry that feature along. We declare some known convention for method prototyping and the two modules can start talking at runtime. With JNI it's no different. Sun's decision to use C as the JNI base for prototyping was quite adequate since most languages can integrate with C code. JNI, though, is an API and requires some level of expertise to be programmed, while linking C code to FORTRAN is a link time task and can be done with only slight understanding of your compiler directives. In JNI the glue must be programmed.

JNI, as an API, offers flexibility but requires some education to use though it's not too steep of a learning curve.

There are some products and tools that can be used to help make the JNI experience simpler. One major effort is Noodle Glue - also a Bridge pattern-oriented solution that works as a bridger to the native class to automatically generate a Java wrapper. It's sophisticated and robust, and was being open sourced when last seen. The other is JNIWrapper, the apparent proprietary market leader so far, which follows more of an Adapter pattern model in that it tries to adapt some native types so you can access native resources through direct method calls.