Avoiding JNI pitfalls

There is a great new article on developerWorks entitled "Best practices for using the Java Native Interface".

Here is the summary:

The Java™ Native Interface (JNI) is a standard Java API that enables Java code to integrate with code written in other programming languages. JNI can be a key element in your toolkit if you want to leverage existing code assets — for example, in a service-oriented architecture (SOA) or a cloud-based system. But when used without due care, JNI can quickly lead to poorly performing and unstable applications. This article identifies the top 10 JNI programming pitfalls, provides best practices for avoiding them, and introduces the tools available for implementing these practices.

I think my "favorite" pitfall is using the wrong JNIEnv. I've seen many a crash due to this error. Usually, this occurs because someone thought it was a good idea to cache the JNIEnv once and use the cached version. Problem is that the JNIEnv is thread specific and the cached one can end up being used from a thread other than the one the JNIEnv belongs to.

Caching of the JNIEnv is typically attempted when integrating legacy code into a Java application where you would need to change many function signatures to accommodate passing the JNIEnv down to the right function. Instead of caching the JNIEnv, cache the JavaVM; it is not thread specific and can be used to obtain the appropriate JNIEnv using the GetEnv() call.