Implications of Using JNI

Even though adding native code to your Java games can have many benefits, you should be aware of its implications. There are scenarios when porting a section of your Java code to C code can result in some performance increases, but you should keep in mind that C/C++ compilers output code that is optimized for a specific target CPU. On the other hand, HotSpot VMs compile bytecode to machine code for any hardware on which the bytecode is running. In addition, HotSpot VMs perform optimizations during runtime. One of the optimizations is inlining bytecode.

If you use native functions, the HotSpot will not be able to inline them and perform additional optimizations. Please refer to Chapter 6, “Performance and the Java Virtual Machine,” for more information on the optimizations performed by the VM. You should also keep in mind that some overhead is involved when using JNI. As discussed earlier, some JNI functions may even disable the garbage collector temporarily. When using native code, it is harder to keep track of how much memory is used by an application. Intuitively, the VM does not know about any memory that it is allocated by other native functions.

Another significant implication of using native code is the portability issues. If you want your application to remain cross platform, you must provide your native libraries for every platform of interest. This means that at the very least you must recompile the native source files for each platform. This task can be much more complicated if you are using OS functions or other libraries that are not available across platforms. For example, the joystick example we provided earlier is useful only on Windows. In fact, because it is a binding for part of the OS API, you will not be able to port the code without modifying the Java code that uses the bindings. One of Java’s most important characteristics is its safety. By mixing native code with your Java code, you are in a way reducing the reliability of your application.