View source for Java Native Interface

{{Short description|Foreign function interface}}
{{Redirect|JNI}}
{{multiple issues|
{{more citations needed|date=February 2017}}
{{lead too short|date=February 2017}}
}}

The '''Java Native Interface''' ('''JNI''') is a [[foreign function interface]] programming [[software framework|framework]] that enables [[Java (programming language)|Java]] code running in a [[Java virtual machine]] (JVM) to call and be called by<ref name="role">{{cite web |url=https://docs.oracle.com/en/java/javase/11/docs/specs/jni/intro.html#java-native-interface-overview |title=Java Native Interface Overview |access-date=2018-12-27 |work= The Java Native Interface Programmer's Guide and Specification}}
</ref> native applications (programs specific to a hardware and [[operating system]] platform) and [[Library (computing)|libraries]] written in other languages such as [[C (programming language)|C]], [[C++]] and [[assembly language|assembly]].

Java 22 introduces the Foreign Function and Memory API, which can be seen as the successor to Java Native Interface.

== Objectives ==
JNI enables programmers to write native methods to handle situations when an application cannot be written entirely in the Java programming language, e.g. when the standard Java [[class (computer science)|class]] [[Library (computer science)|library]] does not support the platform-specific features or program library. It is also used to modify an existing application (written in another programming language) to be accessible to Java applications. Many of the standard library classes depend on JNI to provide functionality to the developer and the user, e.g. file I/O and sound capabilities. Including performance- and platform-sensitive API implementations in the standard library allows all Java applications to access this functionality in a safe and platform-independent manner.

The JNI framework lets a native method use Java [[object (computer science)|objects]] in the same way that Java code uses these objects. A native method can create Java objects and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code.

Only applications and signed applets can invoke JNI.

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 {{Javadoc:SE|java/awt|Canvas|module=java.desktop}}, which is possible with the [[Java AWT Native Interface]]. The process is almost the same, with just a few changes. The Java AWT Native Interface is only available since [[Java Platform, Standard Edition|J2SE]] 1.3.

JNI also allows direct access to [[Assembly language|assembly code]], without even going through a [[C (programming language)|C]] bridge.<ref>{{cite web | url = http://today.java.net/pub/a/today/2006/10/19/invoking-assembly-language-from-java.html | title = Invoking Assembly Language Programs from Java | publisher = Java.net | date = 2006-10-19 | access-date = 2007-10-06 | url-status = dead | archive-url = https://web.archive.org/web/20080330002620/http://today.java.net/pub/a/today/2006/10/19/invoking-assembly-language-from-java.html | archive-date = 2008-03-30 }}</ref> Accessing Java applications from assembly is possible in the same way.<ref>{{ cite web | url = http://today.java.net/pub/a/today/2007/10/04/launch-java-applications-from-assembly-language-programs.html | title = Launch Java Applications from Assembly Language Programs | publisher = Java.net | date = 2006-10-19 | access-date = 2007-10-04 | url-status = dead | archive-url = https://web.archive.org/web/20071011014140/http://today.java.net/pub/a/today/2007/10/04/launch-java-applications-from-assembly-language-programs.html | archive-date = 2007-10-11 }}</ref>

== Design ==
In the JNI framework, native functions are implemented in separate .c or .cpp files. (C++ provides a slightly simpler interface with JNI.) When the JVM invokes the function, it passes a <code>JNIEnv</code> pointer, a <code>jobject</code> pointer, and any Java arguments declared by the Java method. For example, the following converts a Java string to a native string:

<syntaxhighlight lang="cpp">
extern "C"
JNIEXPORT void JNICALL Java_ClassName_MethodName
  (JNIEnv *env, jobject obj, jstring javaString)
{
    const char *nativeString = env->GetStringUTFChars(javaString, 0);

    //Do something with the nativeString

    env->ReleaseStringUTFChars(javaString, nativeString);
}
</syntaxhighlight>

The ''<code>env</code>'' 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. Example JNI functions are converting native arrays to/from Java arrays, converting native strings to/from Java strings, instantiating objects, throwing exceptions, etc. Basically, anything that Java code can do can be done using <code>JNIEnv</code>, albeit with considerably less ease.

The argument ''<code>obj</code>'' is a reference to the Java object inside which this native method has been declared.

Native [[data type]]s can be mapped to/from Java data types. For compound types such as objects, [[Array data structure|arrays]] and [[string (computer science)|string]]s the native code must explicitly convert the data by calling methods in the <code>JNIEnv</code>.

A JNI environment pointer ({{mono|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 {{mono|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 {{mono|DetachCurrentThread()}} to detach itself.<ref>The Invocation API. Sun Microsystems. https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html</ref>

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 side code (such as assembly language) assumes the responsibility for explicitly releasing any such memory resources that the native code acquires.

On Linux and Solaris platforms, if the native code registers itself as a signal handler, it could intercept signals intended for the JVM. A [[Chain-of-responsibility pattern|chain of responsibility]] can be used to allow native code to better inter-operate with the JVM. On Windows platforms, [[Microsoft-specific exception handling mechanisms#Structured Exception Handling|Structured Exception Handling (SEH)]] may be employed to wrap native code in SEH try/catch blocks so as to capture machine (CPU/FPU) generated software interrupts (such as NULL pointer access violations and divide-by-zero operations), and to handle these situations before the interrupt is propagated back up into the JVM (i.e. Java side code), in all likelihood resulting in an unhandled exception.{{original research inline|date=February 2017}}

The encoding used for the NewStringUTF, GetStringUTFLength, GetStringUTFChars, ReleaseStringUTFChars and GetStringUTFRegion functions is "modified UTF-8",<ref name="jniModifiedUtf">{{cite web|url=http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/types.html#wp16542|title=JNI Types and Data Structures}}</ref> which is not valid UTF-8 for all inputs, but a different encoding really. The null character (U+0000) and codepoints not on the [[Plane (Unicode)#Basic Multilingual Plane|Basic Multilingual Plane]] (greater than or equal to U+10000, i.e. those represented as ''surrogate pairs'' in UTF-16) are encoded differently in modified UTF-8. Many programs actually use these functions incorrectly and treat the UTF-8 strings returned or passed into the functions as standard UTF-8 strings instead of modified UTF-8 strings. Programs should use the NewString, GetStringLength, GetStringChars, ReleaseStringChars, GetStringRegion, GetStringCritical and ReleaseStringCritical functions, which use UTF-16LE encoding on little-endian architectures and UTF-16BE on big-endian architectures, and then use a UTF-16 to UTF-8 conversion routine.{{original research inline|date=February 2017}}

== Mapping types ==
The following table shows the mapping of types between Java (JNI) and native code.

{| class="wikitable"
!C Type
!Java Language Type
!Description
!Type signature
|-
| {{mono|unsigned char<br/>uint8_t}}
| {{mono|jboolean}}
|unsigned 8 bits
| {{mono|Z}}
|-
| {{mono|signed char<br/>int8_t}}
| {{mono|jbyte}}
|signed 8 bits
| {{mono|B}}
|-
| {{mono|unsigned short<br/>uint16_t}}
| {{mono|jchar}}
|unsigned 16 bits
| {{mono|C}}
|-
| {{mono|short<br/>int16_t}}
| {{mono|jshort}}
|signed 16 bits
| {{mono|S}}
|-
| {{mono|int<br/>int32_t}}
| {{mono|jint}}
|signed 32 bits
| {{mono|I}}
|-
| {{mono|long long<br/>int64_t}}
| {{mono|jlong}}
|signed 64 bits
| {{mono|J}}
|-
| {{mono|float}}
| {{mono|jfloat}}
|32 bits
| {{mono|F}}
|-
| {{mono|double}}
| {{mono|jdouble}}
|64 bits
| {{mono|D}}
|-
| {{mono|void}}
|
|
| {{mono|V}}
|}

In addition, the signature <code>"L {{Sic|hide=y|fully|-}}qualified-class ;"</code> would mean the class uniquely specified by that name; e.g., the signature <code>"Ljava/lang/String;"</code> refers to the class {{Javadoc:SE|package=java.lang|java/lang|String}}. Also, prefixing <code>[</code> to the signature makes the array of that type; for example, <code>[I</code> means the int array type (<code>int[]</code>). Finally, a <code>void</code> signature uses the <code>V</code> code.

These types are interchangeable. One can use <code>jint</code> where you normally use an <code>int</code>, and vice versa, without any [[type conversion|typecast]]ing required. However, mapping between Java Strings and arrays to native strings and arrays is different. If a <code>jstring</code> is used where a <code>char *</code> would be, the code could crash the JVM.{{original research inline|date=February 2017}}

== Performance ==
JNI incurs considerable overhead and performance loss under certain circumstances:<ref name="StackOverflow: What makes JNI calls slow?">{{cite web|url=https://stackoverflow.com/a/7809300/1068537|title=Java: What makes JNI calls slow? |website=Stack Overflow}}</ref>
* Function calls to JNI methods are expensive, especially when calling a method repeatedly.
* Native methods are not inlined by the JVM, nor can the method be [[Just-in-time compilation|JIT compiled]], as the method is already compiled.
* A Java array may be copied for access in native code, and later copied back. The cost can be linear in the size of the array.
* If the method is passed an object, or needs to make a callback, then the native method will likely be making its own calls to the JVM. Accessing Java fields, methods and types from the native code requires something similar to [[reflective programming]] (reflection). Signatures are specified in strings and queried from the JVM. This is both slow and error-prone.
* Java Strings are objects, have length and are encoded. Accessing or creating a string may require an O(n) copy.

== Alternatives ==
Microsoft's proprietary implementation of a Java Virtual Machine ([[Visual J++]]) had a similar mechanism for calling native code from Java, called the ''Raw Native Interface'' (''RNI''). In addition, it had an easy way to call existing native code that was not itself aware of Java, such as (but not limited to) the Windows API, called ''J/Direct''. However, following the [[Visual J++#Litigation against J++|Sun–Microsoft litigation]] about this implementation, [[Visual J++]] is no longer maintained.

RNI was less clumsy to use than JNI, because no bookkeeping with a Java environment pointer was needed. Instead, all Java objects could be accessed directly. To facilitate this, a tool was used to generate header files from Java classes. Similarly, J/Direct was easier to use than using the necessary intermediate native library and JNI.

[[Java Native Access|Java Native Access (JNA)]] is a community-developed library that provides Java programmers easy access to native shared libraries without using JNI. However, this requires the redistribution of the dependent jar library. The tradeoff is between JNI being harder to code and JNA being slower.<ref>{{cite web |last1=Zakusylo |first1=Alexander |title=Github is also the original JNA source. JNA vs JNI benchmark speed tests |url=https://github.com/zakgof/java-native-benchmark |website=Github |publisher=Github |access-date=30 March 2023}}</ref> JNI is built in to core Java.

Since Java 22, the newer Foreign Function and Memory API is encouraged for use over JNI, due to the reduced boilerplate and simplified interface.<ref>{{cite web|url= https://openjdk.org/jeps/454|title= JEP 454: Foreign Function & Memory API|date=7 April 2025|publisher=OpenJDK}}</ref> It is located in package {{Javadoc:SE|package=java.lang.foreign|java/lang/foreign}}.

== See also ==
* [[GIWS (software)]]
* [[GlueGen]]
* [[Platform Invocation Services]]
* [[SWIG]]
* [[C++/CLI]]

== References ==
{{reflist|30em}}

== Bibliography ==
{{refbegin}}
* {{cite book
| first = Rob
| last = Gordon
| date = March 1998
| title = Essential Jni: Java Native Interface
| publisher = [[Prentice Hall]]
| edition = 1st
| pages = 498
| isbn = 0-13-679895-0
| url = http://www.informit.com/store/product.aspx?isbn=9780136798958
}}
* {{cite book
| first = Sheng
| last = Liang
| date = June 20, 1999
| title = Java(TM) Native Interface: Programmer's Guide and Specification
| publisher = [[Prentice Hall]]
| edition = 1st
| pages = 320
| isbn = 0-201-32577-2
| url = http://www.informit.com/store/product.aspx?isbn=9780201325775
}}
{{refend}}

== External links ==
* [https://docs.oracle.com/javase/8/docs/technotes/guides/jni/ Oracle's JNI 6.0 API Specification]
* [https://web.archive.org/web/20120728074805/http://java.sun.com/docs/books/jni/ Java Native Interface: Programmer's Guide and Specification]
* [https://web.archive.org/web/20111014002625/http://developer.apple.com/java/jniuniversal.html JNI in XCode from Apple]
* [http://www.codeproject.com/KB/debug/jni_ex.aspx Exception handling in JNI]
* [https://www.scapix.com/java_link Java Link] (modern C++17 wrapper for JNI)

[[Category:Java platform]]
<!-- Hidden categories below -->
[[Category:Articles with example Java code]]