Java Native Access | |
Latest Release Version: | 5.14.0 |
Latest Release Date: | [1] |
Operating System: | Windows, macOS, Android, AIX, FreeBSD, Linux, OpenBSD, Solaris, Windows Mobile |
Platform: | Java 1.4 or later (for JNA 3.5.2 or earlier), Java 1.6 for JNA 4.0.0 and later |
Size: | 1.83 MB (archived) |
Programming Language: | C and Java |
Genre: | Software Library |
License: | LGPL version 2.1 or later and (from version 4.0 onward) the Apache Software License, version 2.0 |
Author: | Todd Fast, Timothy Wall, Liang Chen |
Java Native Access (JNA) is a community-developed library that provides Java programs easy access to native shared libraries without using the Java Native Interface (JNI). JNA's design aims to provide native access in a natural way with a minimum of effort. Unlike JNI, no boilerplate or generated glue code is required.
The JNA library uses a small native library called foreign function interface library (libffi) to dynamically invoke native code. The JNA library uses native functions allowing code to load a library by name and retrieve a pointer to a function within that library, and uses libffi library to invoke it, all without static bindings, header files, or any compile phase. The developer uses a Java interface to describe functions and structures in the target native library. This makes it quite easy to take advantage of native platform features without incurring the high development overhead of configuring and building JNI code.
JNA is built and tested on macOS, Microsoft Windows, FreeBSD / OpenBSD, Solaris, Linux, AIX, Windows Mobile, and Android. It is also possible to tweak and recompile the native build configurations to make it work on most other platforms that run Java.
The following table shows an overview of types mapping between Java and native code and supported by the JNA library.[2]
Native Type | Size | Java Type | Common Windows Types | |
---|---|---|---|---|
8-bit integer | ||||
16-bit integer | ||||
16/32-bit character | ||||
32-bit integer | ||||
boolean value | ||||
32/64-bit integer | ||||
long long | 64-bit integer | |||
32-bit FP | ||||
64-bit FP | ||||
C string | ||||
Note: The meaning of changes between and according to some preprocessor definitions. follows.
Native libraries have no standardized memory byte alignment flavor. JNA defaults to an OS platform specific setting, that can be overridden by a library specific custom alignment. If the alignment details are not given in the documentation of the native library, the correct alignment must be determined by trial and error during implementation of the Java wrapper.
The following program loads the local C standard library implementation and uses it to call the printf function.
Note: The following code is portable and works the same on Windows and POSIX (Linux / Unix / macOS) platforms.
/** Simple example of native library declaration and usage. */public class HelloWorld
The following program loads the C POSIX library and uses it to call the standard mkdir function.
Note: The following code is portable and works the same on POSIX standards platforms.
/** Simple example of native C POSIX library declaration and usage. */public class ExampleOfPOSIX
The program below loads the Kernel32.dll and uses it to call the Beep and Sleep functions.
Note: The following code works only on Windows platforms.
/** Simple example of Windows native library declaration and usage. */public class BeepExample
Benchmarks show JNA averages ten times slower than JNI.[3] [4] [5]
Several alternatives are emerging.[6] The tradeoff between easy to implement the code and runtime speed should be considered when evaluating these software development tools. The addition of third party dependent libraries that must be redistributed and updated is another factor in the decision of which tool to use. The Technology readiness level should also be considered.