0

I am calling a Java application inside my C program, via JNI.

Having installed JDK 1.8, I have the following JNI .so libraries on my system:

/usr/java/jdk1.8.0_51/jre/lib/amd64/jli/libjli.so
/usr/java/jdk1.8.0_51/jre/lib/amd64/server/libjvm.so

To make these two files known to ldconfig, I can create links to them in /usr/lib64/, or create a /etc/ld.so.conf.d/java.conf file which lists them.

This allows me to compile my C code as follows:

gcc -I$JAVA_HOME/include/ -I$JAVA_HOME/include/linux/ \
-L/usr/java/jdk1.8.0_51/jre/lib/amd64/jli \
-L/usr/java/jdk1.8.0_51/jre/lib/amd64/server/ \
callSomeJava.c -ljvm -ljli

This feels like a system hack rather than a reliable way to develop and deploy JNI code. The JDK does not feel like it has exposed these libs to the OS in a way that encourages reliance upon them.

My questions are as follows:

  • Why does the JDK contain a linker name (lib.so) rather than real name (lib.so.N.N) of these libs? 3.1.1. Shared Library Names
  • Where should I get the required libs from, so they are already installed in a linkable manner without my system hacks?
  • How can I compile/deploy my C, in a way which:
    • is not dependent on me manually maintaining ldconfig whenever I update my JDK?
    • allows the resulting a.out to find the libs in deployment environments which have not had my ldconfig hacks?
Neal
  • 137
  • 1
  • 7
  • 1
    I found getting the JVM lib dynamically from env variables, `java` executable symlink information and /or Debian alternative system and then using `dlopen`/`dlsym` to get at the functions more versatile than linking with `-l` – user2543253 Jun 19 '18 at 11:35
  • That sounds great, and ties in with a suggestion here https://web.archive.org/web/20120626011516/http://java.sun.com:80/docs/books/jni/html/invoke.html#24891. – Neal Jun 21 '18 at 14:32

0 Answers0