View source for Java Programming/Java Native Interface

← Java Programming/Java Native Interface

You do not have permission to edit this page, for the following reason:

Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis.

The block was made by ‪EPIC‬. The reason given is Open proxy/Webhost: See the help page if you are affected.

Start of block: 15:48, 19 October 2024
Expiry of block: 15:48, 19 October 2027

Your current IP address is 18.221.82.133. The blocked range is 18.221.0.0/16.

Please include all above details in any queries you make.

If you believe you were blocked by mistake, you can find additional information and instructions in the Stewards Block Wizard.

You can view and copy the source of this page.

<noinclude>{{Displaytitle|title=Java Native Interface}}
{{Nav}}
{{Java Programming/AdvancedTopics/Nav}}
__NOTOC__</noinclude>

The Java Native Interface (JNI) enables Java code running in a Java Virtual Machine (JVM) to call and to be called by native applications (programs specific to a hardware and operating system platform) and libraries written in other languages, such as C, C++ and assembly.

JNI can be used:

* To implement or use features that are platform-specific.
* To implement or use features that the standard Java class library does not support.
* To enable an existing application&mdash;written in another programming language&mdash;to be accessible to Java applications.
* To let a native method use Java 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).
* To let a native method inspect and use objects created by Java application code.
* For time-critical calculations or operations like solving complicated mathematical equations (native code may be faster than JVM code).

On the other hand, an application that relies on JNI loses the platform portability Java offers. So you will have 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. Many of the standard library classes depend on JNI to provide functionality to the developer and the user (file I/O, 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. Only applications and signed applets can invoke JNI. JNI should be used with caution. Subtle errors in the use of JNI can destabilize the entire JVM in ways that are very difficult to reproduce and debug. Error checking is a must or it has the potential to crash the JNI side and the JVM.

This page will only explain how to call native code from JVM, not how to call JVM from native code.

==Calling native code from JVM==

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. A JNI function may look like this:
<syntaxhighlight lang="c">
 JNIEXPORT void JNICALL Java_ClassName_MethodName
   (JNIEnv *env, jobject obj)
 {
     /*Implement Native Method Here*/
 }
</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.

On Linux and Solaris platforms, if the native code registers itself as a signal handler, it could intercept signals intended for the JVM.  Signal chaining should be used to allow native code to better interoperate with JVM. On Windows platforms, 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.

=== C++ code ===

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)
 {
     //Get the native string from javaString
     const char *nativeString = env->GetStringUTFChars(javaString, 0);

     //Do something with the nativeString

     //DON'T FORGET THIS LINE!!!
     env->ReleaseStringUTFChars(javaString, nativeString);
 }
</syntaxhighlight>
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 C, C++, or assembly language) must assume the responsibility for explicitly releasing any such memory resources that it itself acquires.

=== C code ===

<syntaxhighlight lang="c">
 JNIEXPORT void JNICALL Java_ClassName_MethodName
   (JNIEnv *env, jobject obj, jstring javaString)
 {
     /*Get the native string from javaString*/
     const char *nativeString = (*env)->GetStringUTFChars(env, javaString, 0);

     /*Do something with the nativeString*/

     /*DON'T FORGET THIS LINE!!!*/
     (*env)->ReleaseStringUTFChars(env, javaString, nativeString);
 }
</syntaxhighlight>

Note that C++ JNI code is syntactically slightly cleaner than C JNI code because like Java, C++ uses object method invocation semantics.  That means that in C, the <code>env</code> parameter is dereferenced using <code>(*env)-></code> and <code>env</code> has to be explicitly passed to <code>JNIEnv</code> methods. In C++, the <code>env</code> parameter is dereferenced using <code>env-></code> and the <code>env</code> parameter is implicitly passed as part of the object method invocation semantics.

=== Objective-C code ===

<syntaxhighlight lang="objc">
 JNIEXPORT void JNICALL Java_ClassName_MethodName(JNIEnv *env, jobject obj, jstring javaString)
 {
     /*DON'T FORGET THIS LINE!!!*/
     JNF_COCOA_ENTER(env);

     /*Get the native string from javaString*/
     NSString* nativeString = JNFJavaToNSString(env, javaString);

     /*Do something with the nativeString*/

     /*DON'T FORGET THIS LINE!!!*/
     JNF_COCOA_EXIT(env);
 }
</syntaxhighlight>

JNI also allows direct access to assembly code, without even going through a C bridge.

===Mapping types===

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 <code>JNIEnv</code>. The following table shows the mapping of types between Java (JNI) and native code.

{| class="wikitable" style="margin: auto;"
!Native Type
!JNI Type
!Description
!Type signature
|-
|unsigned char
|jboolean
|unsigned 8 bits
|Z
|-
|signed char
|jbyte
|signed 8 bits
|B
|-
|unsigned short
|jchar
|unsigned 16 bits
|C
|-
|short
|jshort
|signed 16 bits
|S
|-
|long
|jint
|signed 32 bits
|I
|-
|
long long<br/>__int64
|jlong
|signed 64 bits
|J
|-
|float
|jfloat
|32 bits
|F
|-
|double
|jdouble
|64 bits
|D
|}

In addition, the signature <code>"L 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.
Here, these types are interchangeable. You can use <code>jint</code> where you normally use an <code>int</code>, and vice-versa, without any typecasting required.

However, mapping between Java Strings and arrays to native strings and arrays is different. If you use a <code>jstring</code> in where a <code>char *</code> would be, your code could crash the JVM.
<syntaxhighlight lang="cpp">
JNIEXPORT void JNICALL Java_ClassName_MethodName
        (JNIEnv *env, jobject obj, jstring javaString) {
    // printf("%s", javaString);        // INCORRECT: Could crash VM!

    // Correct way: Create and release native string from Java string
    const char *nativeString = (*env)->GetStringUTFChars(env, javaString, 0);
    printf("%s", nativeString);
    (*env)->ReleaseStringUTFChars(env, javaString, nativeString);
}
</syntaxhighlight>

The encoding used for the <code>NewStringUTF</code>, <code>GetStringUTFLength</code>, <code>GetStringUTFChars</code>, <code>ReleaseStringUTFChars</code>, <code>GetStringUTFRegion</code> functions is not standard UTF-8, but modified UTF-8. The null character (U+0000) and codepoints greater than or equal to U+10000 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 <code>NewString</code>, <code>GetStringLength</code>, <code>GetStringChars</code>, <code>ReleaseStringChars</code>, <code>GetStringRegion</code>, <code>GetStringCritical</code>, and <code>ReleaseStringCritical</code> functions, which use UTF-16LE encoding on little-endian architectures and UTF-16BE on big-endian architectures, and then use a UTF-16 to standard UTF-8 conversion routine.

The code is similar with Java arrays, as illustrated in the example below that takes the sum of all the elements in an array.
<syntaxhighlight lang="cpp">
JNIEXPORT jint JNICALL Java_IntArray_sumArray
        (JNIEnv *env, jobject obj, jintArray arr) {
    jint buf[10];
    jint i, sum = 0;
    // This line is necessary, since Java arrays are not guaranteed
    // to have a continuous memory layout like C arrays.
    env->GetIntArrayRegion(arr, 0, 10, buf);
    for (i = 0; i < 10; i++) {
        sum += buf[i];
    }
    return sum;
}
</syntaxhighlight>

Of course, there is much more to it than this.

=== JNIEnv* ===
A JNI environment pointer (<code>JNIEnv*</code>) 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 <code>AttachCurrentThread()</code> 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 <code>DetachCurrentThread()</code> to detach itself.

To attach to the current thread and get a JNI interface pointer:
 JNIEnv *env;
 (*g_vm)->AttachCurrentThread (g_vm, (void **) &env, NULL);

To detach from the current thread:
 (*g_vm)->DetachCurrentThread (g_vm);

==HelloWorld==

{{XCode|1=<span id="code-listing-1">'''Code listing 10.1: HelloWorld.java'''</span>
<syntaxhighlight lang="Java5" line start="1">
public class HelloWorld {
 private native void print();

 public static void main(String[] args) {
  new HelloWorld().print();
 }

 static {
  System.loadLibrary("HelloWorld");
 }
}
</syntaxhighlight>}}

HelloWorld.h

<syntaxhighlight lang="c">
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class HelloWorld */

#ifndef _Included_HelloWorld
#define _Included_HelloWorld
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     HelloWorld
 * Method:    print
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_HelloWorld_print
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif

</syntaxhighlight>

libHelloWorld.c

<syntaxhighlight lang="c">
 #include <stdio.h>
 #include "HelloWorld.h"

 JNIEXPORT void JNICALL
 Java_HelloWorld_print(JNIEnv *env, jobject obj)
 {
     printf("Hello World!\n");
     return;
 }

</syntaxhighlight>

make.sh
<syntaxhighlight lang="bash">
#!/bin/sh

# openbsd 4.9
# gcc 4.2.1
# openjdk 1.7.0
JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:bin/javac::")
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
javac HelloWorld.java
javah HelloWorld
gcc -I${JAVA_HOME}/include -shared libHelloWorld.c -o libHelloWorld.so
java HelloWorld
</syntaxhighlight>

{{XCode|1='''Commands to execute on POSIX'''
<pre style="background-color:#000; color:#fff;">
chmod +x make.sh
./make.sh
</pre>}}

==Advanced uses==
Not only can native code interface with Java, it can also draw on a {{java web api|java/awt/Canvas.html|java.awt.Canvas}}, 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 J2SE 1.3.

<noinclude>{{Nav}}
{{Status|100%}}</noinclude>

Templates used on this page:

Java Programming/TOC (edit)
Template:BOOKCATEGORY (view source) (protected)
Template:BookCat (view source) (protected)
Template:BookCat/core (view source) (protected)
Template:BookCat/default (view source) (protected)
Template:Displaytitle (view source) (protected)
Template:Evalx (view source) (protected)
Template:Java Programming/Advanced/Topic (edit)
Template:Java Programming/AdvancedTopics/Nav (edit)
Template:Java web api (edit)
Template:NAIVEBOOKNAME (view source) (protected)
Template:Nav (edit)
Template:Navbar (view source) (protected)
Template:Stage short (view source) (protected)
Template:Status (view source) (protected)
Template:Transclude (view source) (protected)
Template:XCode (edit)
Module:Printable version (edit)
Module:TNT (edit)
Module:TScope (view source) (protected)
Module:Wikilisp (view source) (protected)

Return to Java Programming/Java Native Interface.

Retrieved from "https://en.wikibooks.org/wiki/Java_Programming/Java_Native_Interface"