23

Java versions prior Java 8 requires native code to be in a shared library, but I've read that with Java 8 it's possible to use static linked libraries with JNI. I have searched for examples but couldn't find any.

How can I statically link a JNI library into my java application?

chmod
  • 278
  • 1
  • 2
  • 7

3 Answers3

17

The Java SE 8 specification has been changed to support static linking, and static linking is implemented in the JDK. This is mentioned briefly in the spec for System.loadLibrary. The sections of the JNI Specification to which it refers are here and here.

Native method signatures and data types are the same for statically and dynamically linked methods. You might have to hack on the JDK makefiles to get it to link your library statically, though.

One significant difference is the way static libraries are initialized. Dynamic libraries are initialized by calling the JNI_OnLoad function and are deinitialized by calling JNI_OnUnload. Each dynamic library can have its own version of these functions. If there are multiple statically linked libraries, clearly they can't all have functions with these same names. For a static library named libname the load/unload functions are JNI_OnLoad_libname and JNI_OnUnload_libname.

The JNI_OnLoad_libname function must return a value of JNI_VERSION_1_8 or higher. If it doesn't, the JVM will ignore the static library.

Basically, if you call System.loadLibrary("foo"), the system looks for the function JNI_OnLoad_foo in the running executable image, and if it's found, it assumes that the library is statically linked, and its native methods are searched for within the running image. If JNI_OnLoad_foo is not found, then the usual searching and loading of dynamic libraries takes place, and native methods are linked from the dynamic library so found.

Stuart Marks
  • 127,867
  • 37
  • 205
  • 259
  • Thanks for your answer. But now I'm a bit unsure. Can I still use `javah` to create a header for the source or do I need to name methods and such myself? – chmod Jul 04 '14 at 13:47
  • 1
    @chmod The mechanics of writing the native method itself should be the same as for dynamic natives. The differences with static are that you have to compile and link your native code to produce a static library, and then perform a second step to link that static library into the JVM itself. – Stuart Marks Jul 05 '14 at 21:39
  • Okay, do you know how I can modify my JDK in order to get it to work with my library? – chmod Jul 06 '14 at 00:47
  • 2
    @chmod I don't think you can modify a prebuilt JDK, since (I believe) one cannot link an additional static library into an executable. If you're building from source, you may need to hack the makefile with additional arguments or variable settings to supply static libraries to the linker command. See [vm.make](http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/jdk9-b21/make/linux/makefiles/vm.make) from OpenJDK, for example, near lines 320 and following. – Stuart Marks Jul 07 '14 at 20:12
  • @StuartMarks But libjvm.so itself is also a shared library, so how to statically link a non-PIC library (having assembly code)? Should I link such a library to who loads libjvm.so? Is it ever possible? – basicthinker Dec 04 '14 at 01:44
  • @basicthinker I'm a bit distant from how this is all put together, but the static linking support is primarily targeted at embedded environments, where I believe everything, including libjvm, is statically linked. The idea is that the JVM and all static libraries are linked statically ahead-of-time, so mixing PIC and non-PIC libraries isn't an issue. Offhand I'm not sure what it takes to get OpenJDK to do static linking. Like I said above, you might have to hack on the makefiles. – Stuart Marks Dec 04 '14 at 06:49
  • 2
    Don't forget to make your `JNI_OnLoad_X` function returns at least `JNI_VERSION_1_8` or the library will be silently ignored. – lesenk Jul 06 '16 at 17:32
4

Accoding to the JEP 178 you linked to in your comment, you don't have to do anything differently. System.loadLibrary will now load both dynamic and static libraries.

Require no changes to existing Java code in order to use a static native library as opposed to a dynamic native library. A method invocation of the form System.loadLibrary("foo"), in particular, should be able to load the "foo" library regardless of whether that library is provided in static or dynamic form.

You probably just need to make sure your java.library.path is set correctly.

dkatzel
  • 31,188
  • 3
  • 63
  • 67
  • So the only thing I need to do differently compared to a shared library is to compile it different? No change in C/C++ code? – chmod Jun 30 '14 at 15:43
  • @user3525110 No changes to either Java or C code. Just use whatever compiler options you usually use to create a shared or static library from the C compiled object files. – dkatzel Jun 30 '14 at 16:01
  • Does this really work? I got a static library (.a file) but even if I set the java.library.path correctly the library is not found: "Exception in thread "main" java.lang.UnsatisfiedLinkError: no in java.library.path". I'm using Java 8 & Debian. – little_planet Mar 03 '16 at 18:22
  • 4
    @little_planet : no, you cannot simply copy a static library into the path. The new approach is only relevant for those who embed JVM into their executable. – Alex Cohn Jul 09 '16 at 05:28
1

The Java 8 enhancement https://openjdk.java.net/jeps/178 is meant for the JVM.

Given two files:

  • Main.java
  • Main.c

Create libnative.so:

javac Main.java
javah Main
gcc -c Main.c
gcc -c Main.c -I /home/dx/.sdkman/candidates/java/current/include/linux -I /home/dx/.sdkman/candidates/java/current/include
gcc -shared -o libnative.so Main.o

Create libnative.a:

ar -cvq libnative.a Main.o

For each libnative.a, libnative.so test run via:

java -Djava.library.path=.  Main

Result:

  • Success execution when libnative.so
  • Fail execution when libnative.a

This proves that 178 is for the JVM.

References:

daparic
  • 3,794
  • 2
  • 36
  • 38