JNI enables Java to interact with native code for accessing system resources, improving performance, or reusing existing libraries; 1) Write Java with native methods and load the library; 2) Generate a C/C header using javac -h; 3) Implement the native method in C/C using JNIEnv to interface with JVM; 4) Compile into a shared library (e.g., libhello.so or hello.dll); 5) Run the Java program with java.library.path pointing to the library; use alternatives like JNA or Panama for simpler or safer native access when possible.

Java Native Interface (JNI) allows Java code running in the Java Virtual Machine (JVM) to interact with native applications and libraries written in other languages such as C, C , or assembly. This is useful when you need to access system-level resources, leverage existing native code, or optimize performance-critical sections of code.

Here’s a practical breakdown of how JNI works and what you need to know.

Why Use JNI?

There are several reasons you might use JNI:

• Access to platform-specific features: Like file system details, hardware interfaces, or OS-level APIs not exposed in Java.
• Performance: For computationally heavy tasks, native code (e.g., C ) can be faster than pure Java.
• Reuse existing native libraries: Integrate legacy code or third-party libraries (e.g., OpenCV, OpenSSL).
• Interfacing with drivers or low-level system software.

However, JNI comes with trade-offs: reduced portability, increased complexity, and potential crashes (since native code can corrupt memory and crash the JVM).

How JNI Works: Step-by-Step

Using JNI involves a few key steps:

1. Write Java code with native methods

   public class NativeExample {
       // Declare a native method
       public native void sayHello();
   
       static {
           // Load the native library
           System.loadLibrary("hello");
       }
   
       public static void main(String[] args) {
           new NativeExample().sayHello();
       }
   }

2. Generate a C/C header file Use the javac and javah tools (or javac with -h in newer JDKs):

   javac NativeExample.java
   javac -h . NativeExample.java  # Generates a .h file

   This creates a header like com_example_NativeExample.h with a function signature:

   JNIEXPORT void JNICALL Java_com_example_NativeExample_sayHello
     (JNIEnv *, jobject);

3. Implement the native method in C/C

   #include <jni.h>
   #include <stdio.h>
   #include "com_example_NativeExample.h"
   
   JNIEXPORT void JNICALL Java_com_example_NativeExample_sayHello
     (JNIEnv *env, jobject obj) {
       printf("Hello from native C code!\n");
   }

4. Compile to a shared library On Linux:

   gcc -fPIC -shared -I${JAVA_HOME}/include -I${JAVA_HOME}/include/linux \
       -o libhello.so native_implementation.c

   On Windows (using cl):

   cl -I"%JAVA_HOME%\include" -I"%JAVA_HOME%\include\win32" -LD native_implementation.c -Fe:hello.dll

5. Run the Java program Make sure the JVM can find the native library:

   java -Djava.library.path=. NativeExample

   Output:

   Hello from native C code!

Key JNI Concepts

JNIEnv and Java Objects

• JNIEnv* is a pointer to a structure of function pointers that lets C code interact with the JVM.
• You can call Java methods, create objects, or throw exceptions from native code using JNIEnv.
• Example: calling a Java method from C:

  jclass cls = (*env)->GetObjectClass(env, obj);
  jmethodID mid = (*env)->GetMethodID(env, cls, "callback", "()V");
  (*env)->CallVoidMethod(env, obj, mid);

Data Type Mapping

JNI maps Java types to native C types:

• jint → int
• jboolean → unsigned char
• jobject → generic Java object reference
• jstring → Java string (must be converted to C string using GetStringUTFChars)

Be careful with string handling—Java uses Unicode, while C often uses UTF-8 or other encodings.

Memory and Performance Considerations

• Local references (e.g., jobject) created in native code are automatically cleaned up when the native method returns.
• For long-running native methods, use DeleteLocalRef or push/pop local reference frames to avoid memory leaks.
• Avoid frequent JNI calls in tight loops—crossing the JNI boundary has overhead.

---

Common Pitfalls and Best Practices

• *Don’t cache `JNIEnvacross threads**:JNIEnvis thread-specific. UseJavaVMto getJNIEnv` in other threads.
• Handle exceptions properly: If a Java call from native code throws an exception, check with ExceptionCheck() and handle it.
• Use JNI OnLoad for initialization: Define a JNI_OnLoad() function to register native methods or perform setup.
• Avoid global static variables for Java objects: Use GlobalRef if you need to keep a Java object alive across calls.
• Be cautious with threading: Native code can block or interfere with JVM thread management.

---

Alternatives to JNI

While powerful, JNI is complex. Consider alternatives:

• JNA (Java Native Access): Simpler, no need to write C code—directly call shared libraries.
• Panama Project (Foreign Function & Memory API): A modern Java initiative (since JDK 17 ) to replace JNI with safer, easier native interop.
• GraalVM Native Image: Compile Java to native binaries, reducing the need for JNI in some cases.

---

JNI isn’t needed for most Java applications, but when you must go beyond the JVM, it’s the most direct way. It’s powerful but requires care—especially around memory, threading, and error handling.

Basically: use JNI when necessary, test thoroughly, and keep the native part as small and safe as possible.

The above is the detailed content of Java Native Interface (JNI) Explained. For more information, please follow other related articles on the PHP Chinese website!