Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Use native methods to expand the Java environment

Learn how to interact with libraries and applications written in other languages

  • Print
  • Feedback
The JNI provides a documented and supported specification that allows programs written in other languages to be called from Java. Calling Java from an application written in another language is often referred to as embedding, and the process requires an understanding of the Invocation API. The JNI also provides a way for applications written in other languages to call Java.

Before we get too deep into our discussion, I'd like to provide some background on how native methods worked prior to the release of the JNI. In short, before JDK 1.1 native methods were difficult to use because:

  • The specification did not interface to the Java virtual machine (VM) at runtime for symbol lookup. It was assumed that symbols would be in an include file and compiled in at compile-time. Unfortunately, this is not the way object environments work with dynamic linking. This approach also created an opportunity for out-of-date source files, and prevented dynamic changes to values at runtime.

  • The interface for embedding was vague.

  • There was no support for pinning (preventing garbage collection and movement of Java objects).

  • Java strings were converted to pointers without support for large character sets, making internationalization impossible.

  • The nomenclature was terribly confusing.


With the introduction of the JNI in JDK 1.1, native methods have become much easier to use. To help you better understand the JNI, we'll review portions of the actual JNI spec to explain why you need to use it and what it allows you to do. The italicized items are direct quotes from the JNI specification, and the regular text is the annotation I've supplied for clarity. Once you know the "why" and "what" of using the JNI, we'll focus on the "how." Note that for brevity's sake I make no attempt to fully explain the JNI specification. If you feel you need a primer on the JNI, be sure to review the complete specification (and also the tutorial), which is listed in the Resources section of this article.

Why do I need to use the JNI?

  • The standard Java class libraries do not support the platform-dependent features needed by the application.

    You might need to set some device-specific properties under program control, or access a device-specific API.

  • You already have a library written in another language, and wish to make it accessible to Java code through the JNI.

    You may want to rewrite the necessary application in Java, but this is not possible in all cases. Many application libraries on the 'Net have taken an enormous amount of time to perfect (we're talking hundreds of thousands of hours); rewriting them in Java is not likely in the short term.

    Unfortunately, using native methods may not be the best solution. When you use native methods in computation-intensive tasks like tight loops, which occur when you repeatedly call a function, you may find that the process of setting up parameters, calling the method, and getting the return values for each iteration of the loop takes longer than the time it takes to execute the function.

  • Print
  • Feedback

Resources