Java Native Interface - Revision history

HotMess: /* Mapping types */

2025-05-27T13:19:10Z

Mapping types

← Previous revision		Revision as of 13:19, 27 May 2025
Line 109:		Line 109:
	\|}		\|}

	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 ~~<code>~~java.lang~~.String<~~/~~code>~~. Also, prefixing <code>[</code> to the signature makes the array of that type; for example, <code>[I</code> means the int array type. Finally, a <code>void</code> signature uses the <code>V</code> code.		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}}		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}}

HotMess: /* Alternatives */ Foreign Function and Memory API javadoc link

2025-05-27T13:12:34Z

Alternatives: Foreign Function and Memory API javadoc link

← Previous revision		Revision as of 13:12, 27 May 2025
Line 124:		Line 124:
	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.		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 ~~that~~ ~~generated~~ header files from Java classes. Similarly, J/Direct was easier to use than using the necessary intermediate native library and JNI.		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.		[[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 ~~<code>~~java.lang.foreign</~~code>~~.		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 ==		== See also ==

2620:101:F000:7C0:0:0:0:25CF at 00:26, 10 April 2025

2025-04-10T00:26:42Z

← Previous revision		Revision as of 00:26, 10 April 2025
Line 128:		Line 128:
	[[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.		[[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>		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 <code>java.lang.foreign</code>.

	== See also ==		== See also ==

2620:101:F000:7C0:0:0:0:25CF at 00:25, 10 April 2025

2025-04-10T00:25:47Z

← Previous revision		Revision as of 00:25, 10 April 2025
Line 8:		Line 8:
	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}}		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]].		</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 ==		== Objectives ==

Basil.bourque: /* Alternatives */Updated reference to preview version of specification document to refer to the official final version.

2025-04-07T17:45:33Z

Alternatives: Updated reference to preview version of specification document to refer to the official final version.

← Previous revision		Revision as of 17:45, 7 April 2025
Line 126:		Line 126:
	[[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.		[[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 21, 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/~~442~~\|title=JEP ~~442~~: Foreign Function & Memory API ~~(Third Preview)~~\|date=~~27 September~~ ~~2023~~ \|publisher=OpenJDK}}</ref>		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>

	== See also ==		== See also ==

Lorraine Crane: common typo "programer" corrected

2025-04-06T19:27:17Z

common typo "programer" corrected

← Previous revision		Revision as of 19:27, 6 April 2025
Line 124:		Line 124:
	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 that generated header files from Java classes. Similarly, J/Direct was easier to use than using the necessary intermediate native library and JNI.		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 that generated 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 ~~programers~~ 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.		[[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 21, 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/442\|title=JEP 442: Foreign Function & Memory API (Third Preview)\|date=27 September 2023 \|publisher=OpenJDK}}</ref>		Since Java 21, 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/442\|title=JEP 442: Foreign Function & Memory API (Third Preview)\|date=27 September 2023 \|publisher=OpenJDK}}</ref>

99.250.195.60: /* Alternatives */

2025-02-22T23:59:40Z

Alternatives

← Previous revision		Revision as of 23:59, 22 February 2025
Line 125:		Line 125:

	[[Java Native Access\|Java Native Access (JNA)]] is a community-developed library that provides Java programers 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.		[[Java Native Access\|Java Native Access (JNA)]] is a community-developed library that provides Java programers 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 21, 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/442\|title=JEP 442: Foreign Function & Memory API (Third Preview)\|date=27 September 2023 \|publisher=OpenJDK}}</ref>

	== See also ==		== See also ==

75.22.163.163 at 21:52, 17 February 2025

2025-02-17T21:52:50Z

← Previous revision		Revision as of 21:52, 17 February 2025
Line 6:		Line 6:
	}}		}}

	~~In [[software design]], 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}}		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]].		</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]].

Jerryobject: /* External links */ Adds: MOS:COMMENT, WP:CATEGORY.

2024-12-27T05:19:06Z

External links: Adds: MOS:COMMENT, WP:CATEGORY.

← Previous revision		Revision as of 05:19, 27 December 2024
Line 170:		Line 170:

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

Jerryobject: /* Performance */ WP:REFerence WP:CITation parameter add. Spaced: MOS:EMDASH > colon (punctuation). WP:LINK update-standardize.

2024-12-27T05:13:44Z

Performance: WP:REFerence WP:CITation parameter add. Spaced: MOS:EMDASH > colon (punctuation). WP:LINK update-standardize.

← Previous revision		Revision as of 05:13, 27 December 2024
Line 112:		Line 112:

	== Performance ==		== 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? - Stack Overflow}}</ref>		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.		* 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.		* 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.		* 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 [[~~Reflection (computer~~ programming~~)\|reflection~~]]. Signatures are specified in strings and queried from the JVM. This is both slow and error-prone.		* 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.		* Java Strings are objects, have length and are encoded. Accessing or creating a string may require an O(n) copy.