Chapter11.Native Methods

Chapter 11. Native Methods

• Calling a C Function from the Java Programming Language

• Numeric Parameters and Return Values

• String Parameters

• Accessing Fields

• Encoding Signatures

• Calling Java Methods

• Accessing Array Elements

• Handling Errors

• Using the Invocation API

• A Complete Example: Accessing The Windows Registry

We hope we have convinced you that code written in the Java programming language has a number of advantages over code written in languages like C or C++ even for platform -specific applications. Here, of course, portability is not the issue but rather features like these:

• You are more likely to produce bug-free code with the Java programming language than with C or C++.

• Multithreading is probably easier to code in the Java programming language than in most other languages.

• Networking code is a breeze.

Portability is simply a bonus that you may or may not want to take advantage of down the line.

While a "100% Pure Java" solution is nice in principle, realistically, for an application, there are situations in which you will want to write (or use) code written in another language. (Such code is usually called native code.) There are three obvious reasons why that may be the right choice:

1. You have substantial amounts of tested and debugged code available in that language. Porting the code to the Java programming language would be time consuming, and the resulting code would need to be tested and debugged again.

2. Your application requires access to system features or devices, and using Java technology would be cumbersome at best, or impossible at worst.

3. Maximizing the speed of the code is essential. For example, the task may be time critical, or it may be code that is used so often that optimizing it has a big payoff. This is actually the least plausible reason. With just-in-time (JIT) compilation, intensive computations coded in the Java programming language are not that much slower than compiled C code.

If you are in one of these three situations, it might make sense to call the native code from programs written in the Java programming language. Of course, with the usual security manager in place, once you start using native code, you are restricted to applications rather than applets. In particular, the native code library you are calling must exist on the client machine, and it must work with the client machine architecture.

To make calling native methods possible, Java technology comes with hooks for working with system libraries, and the JDK has a few tools to relieve some (but not all) of the programming tedium.

NOTE

The language you use for your native code doesn't have to be C or C++; you could use code compiled with a FORTRAN compiler if you have access to a binding between Java code and FORTRAN.

Still, keep this in mind: If you use native methods, you lose portability. Even when you distribute your program as an application, you must supply a separate native method library for every platform you want to support. This means you must also educate your users on how to install these libraries! Also, whereas users may trust that applets can neither damage data nor steal confidential information, they may not want to extend the same trust to code that uses native method libraries. For that reason, many potential users will be reluctant to use programs in the Java programming language that require native code. Aside from the security issue, native libraries are unlikely to be as safe as Java code, especially if they are written in a language like C or C++ that offers no protection against overwriting memory through invalid pointer usage. It is easy to write native methods that corrupt the Java virtual machine, compromise its security, or trash the operating system.

Thus, we suggest using native code only as a last resort. If you must gain access to a device, such as a serial port, in a program, then you may need to write native code. If you need to access an existing body of code, why not consider native methods as a stopgap measure and eventually port the code to the Java programming language? If you are concerned about efficiency, benchmark a Java platform implementation. In most cases, the speed with a just-in-time compiler will be sufficient. A talk at the 1996 JavaOne conference showed this clearly. The implementors of the cryptography library at Sun Microsystems reported that a pure Java platform implementation of their cryptographic functions was more than adequate. It was true that the code was not as fast as a C implementation would have been, but it turned out not to matter. The Java platform implementation was far faster than the network I/O. And this turns out to be the real bottleneck.

In summary, there is no point in sacrificing portability for a meaningless speed improvement; don't go native until you determine that you have no other choice.

NOTE

In this chapter, we describe the so-called Java Native Interface (JNI) binding. An earlier language binding (sometimes called the raw native interface) was used with Java 1.0, and a variation of that earlier binding was used by the Microsoft Virtual Machine. Sun Microsystems has assured developers that the JNI binding described here is a permanent part of the Java platform and that it needs to be supported by all Java virtual machines.

Finally, we use C as our language for native methods in this chapter because C is probably the language most often used for native methods. In particular, you'll see how to make the correspondence between Java data types, feature names, and function calls and those of C. (This correspondence is usually called the C binding.)

C++ NOTE

You can also use C++ instead of C to write native methods. There are a few advantagestype checking is slightly stricter, and accessing the JNI functions is a bit more convenient. However, JNI does not support any direct correspondence between Java platform classes and those in C++.