Java Native Interface (JNI)

It’s a programming framework which allows Java code (running on a JVM) to call and be called by the native applications. Native applications mean the set of programs written specific to the hardware and the underlying operating system. These programs are normally written in C, C++, or Assembly language.

It’s normally used either to use an existing application written in some other language or in the case when some platform or OS dependent modules can’t be implemented effectively using Java. Many of the standard libraries internally use JNI to provide platform and OS specific functionalities to the developers. For example: Standard libraries offering the functionalities related to I/O file read/write, sound recognition, storage, etc. internally use JNI to get the task done as such platform dependent things can’t be done directly in Java, not at least effectively :-)

JNI can add great value in some specific scenarios like the ones which involve time-critical complex computations. Native applications will execute faster in such cases. So, if you use JNI then effectively you get best of both the worlds.

JNI lets a native method handle the Java objects created by your application the same way that a normal Java method uses them. Not only this, a native method can create and inspect objects as well to get the desired tasks done.

But, like every other good thing, JNI also requires a price to be paid. You need to be very careful while using JNI in your application. Coding/Debugging can be really complex and it’s not a Java API, so you’ll get limited help from Java documentations or other Java related resources. Memory management, Thread Management, Database connectivity, etc. such features can really get complex to code and debug in C/C++ (as compared to Java). This is the reason why JNI is normally used by experienced Java programmers only. Mainly the people involved in the development of Tools/IDE use JNI.