Enhance your Java application with Java Native Interface (JNI)

How to compete with native applications without sacrificing cross-platform benefits

1 2 3 Page 3
Page 3 of 3

(This is a very bad application, because it does not offer the same functionality on other platforms. It does, however, fail rather gracefully.)

Suggestions for improvement

The desktop indicator solution is certainly usable as is, but may be extended to offer even more functionality.

  • Many native Windows applications feature a context menu for their taskbar icons. We can use Java to display this menu, but we must know where on the screen to display it. This information can be supplied in the listener's callback method.

  • Currently, the desktop indicator only supports ICO files to render the icons; however, using JPEGs would be more interoperable with other Java packages, and it would be nice to use JPEG files located within JARs. It would not be trivial to support this feature; runtime translation of the desired JPEG to the ICO format used by Win32 would be necessary.

GUI and beyond

JNI does have a serious limitation when it comes to extending Java's GUI: there is no standard way for getting native window handles from AWT components. Each VM may implement its AWT differently, and store the window handle in a different place. Future versions of the VM may handle windows in still different ways, ways that cannot be predicted with any certainty right now. With Java 2 platform VMs just starting to get a foothold (without this feature), I don't expect to see a standard way for doing this anytime soon.

This limitation means that it is quite impossible for your JNI extensions to alter or otherwise work with AWT-created components. You can definitely create your own mini-AWT framework to handle your platform-specific windowing features, but this requires considerable work, never integrates well, and is, of course, nonportable.

While I've focused this article on a GUI extension, there are other platform-specific features that users may expect that are not part of the GUI. One example is the Windows' registry. When running on Windows, Java applications cannot normally write their settings to the registry, and, as such, they will not be saved on the user's profile. A class that uses JNI to write to the registry on Windows, and writes to a file on other platforms, gives you the best of all worlds, without compromising its persistence features. I have supplied a rather primitive solution for this on my JNI site (see Resources).

Support JNI ... carefully

I am firmly convinced that JNI extensions are not merely cool toys for Java, but are a real necessity if Java is to transcend the small world of applets and compete in the desktop-application arena. Java aficionados have hitherto downplayed JNI for an obvious reason: applications which rely on JNI features will no longer be portable, and Java will lose its main edge and become just another VM architecture. On the other hand, with careful design considerations, JNI extensions may save the day.

I am maintaining a small site for supporting public-domain open source JNI extensions similar to the one described in this article. If more people contribute, we can build a useful library of application boosters and make Java a viable platform for real-world, cross-platform applications. See Resources for the URL.

The deployment issue

True native behavior is not the only problem with Java applications. Deployment is another big issue. Of course, you can deploy a Java application just like any other application, and there are several commercial kits for cross-platform installation, many running in Java. But it's still a far cry from deploying Java applets, and millions of miles away from HTML/DHTML Web applications, where all you have to do is turn on your Web server.

Wouldn't it be great if you could just give your users a URL for your applications and have them point their VMs to it? It would be just like using a browser, but with all the benefits of a real application with real windowing. The initiative is under way, and you are welcome to join and help where you can. It's all free software under the GNU General Public License. See Resources for more details.

Tal Liron is currently a senior developer at Goman Research (http://www.goman.co.il) and its spin-off, Distributed Devices (http://www.ddevice.com). He has experience in very diverse fields, such as embedded operating system integration, Web applications, CAD, databases, RAD, distributed logic, and object-oriented infrastructure. Lately, he's become deeply involved with the most caffeinated member of the C family. He's an object enthusiast, has been in the army, and will begin studying anthropology next year. Go figure.

Learn more about this topic

  • JNI resources in JavaWorld:

1 2 3 Page 3
Page 3 of 3