Java Native Interface - Wikipedia (FazBrowse)

native in Java) can create Java objects and inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code.

An application that relies on JNI loses the platform portability Java offers (a partial workaround is to write a separate implementation of JNI code for each platform and have Java detect the operating system and load the correct one at runtime).

Not only can native code interface with Java, it can also draw on a Java bool char or C S int jint signed 32 bits int32_t long or F double jdouble 64 bits float64_t V int[][], up to a maximum of 255 dimensions.

These types are interchangeable. One can use jint where you normally use an int[].

JNI additionally contains the following declarations for Java reference types in <jni.h>:

java.lang.Class (non-generic) jclass boolean[] jbooleanArray short[] jshortArray float[] jfloatArray java.lang.reflect.Method.

Design

edit

The communication between native code and Java code is intermediated by the JNI, acting as an ABI.

.c or extern"C"{ JNIEXPORTvoidJNICALLJava_ClassName_MethodName(JNIEnv*env,jobjectobj,jstringjavaString){ constchar*nativeString=env->GetStringUTFChars(javaString,0); // Do something with the nativeString env->ReleaseStringUTFChars(javaString,nativeString); } }

The env pointer is a structure that contains the interface to the JVM. It includes all of the functions necessary to interact with the JVM and to work with Java objects. Anything that Java code can do can be done using JNIEnv. The argument obj is a reference to the Java object inside which this native method has been declared.

Native data types can be mapped to/from Java data types. For compound types, such as objects, arrays and strings, the native code must explicitly convert the data by calling methods in the JNIEnv.

A JNI environment pointer (JNIEnv*) is passed as an argument for each native function mapped to a Java method, allowing for interaction with the JNI environment within the native method. This JNI interface pointer can be stored, but remains valid only in the current thread. Other threads must first call AttachCurrentThread() to attach themselves to the VM and obtain a JNI interface pointer. Once attached, a native thread works like a regular Java thread running within a native method. The native thread remains attached to the VM until it calls DetachCurrentThread() to detach itself.

The JNI framework does not provide any automatic garbage collection for non-JVM memory resources allocated by code executing on the native side. Consequently, native code is responsible explicitly releasing all acquired resources.

On Linux and Solaris platforms, if the native code registers itself as a signal handler, it can intercept signals intended for the JVM. A chain of responsibility can be used to allow native code to interoperate with the JVM. On Windows platforms, Structured Exception Handling (SEH) may be employed to wrap native code in SEH U+0000) and codepoints not on the Basic Multilingual Plane (greater than or equal to #include<stdio.h> #include<jni.h> JNIEXPORTvoidJNICALLJava_HelloJNI_sayHello(JNIEnv*env,jobjectobj){ printf("Hello from C!\n"); }

Then, in Java, the function is called like so:

java.lang.foreign which can be seen as a sort of successor to the Java Native Interface. It has a simpler interface and generally requires less boilerplate than JNI, due to no longer requiring the inclusion of <jni.h> in the foreign library to invoke, and Foreign Function and Memory API abstracts away the usage of the java.lang.foreign.Arena which controls the lifetime of the region of memory backing its allocated segment of memory.

The java.lang.foreign.Arena offers the following arena kinds: