linux - Difference between using java.library.path and LD_LIBRARY_PATH

Question

Is there a difference between setting the JVM argument

-Djava.library.path=/path 

at JVM start and setting the Linux environment variable

export LD_LIBRARY_PATH=/path 

before the JVM is started?

What are the advantages/disadvantages of the two approaches?

Answer 1

The first form

-Djava.library.path=/path

will be handled in java bytecode level, System.loadLibrary will call Runtime.loadLibary, then will call java/lang/ClassLoader.loadLibrary. In the function call ClassLoader.loadLibrary, the system property java.library.path will be checked to get the full path of the library and pass this full path to native code to call system api dlopen/dlsym, eventually make the library loaded. You can browse the source from OpenJDK repository. The following code snippet is the segment I copy from the link.

The advantage of this form is that you will get error or warning or exception in Java code, if there are some problems with your library path.

// Invoked in the java.lang.Runtime class to implement load and loadLibrary.
static void loadLibrary(Class fromClass, String name,
                        boolean isAbsolute) {
    ClassLoader loader =
        (fromClass == null) ? null : fromClass.getClassLoader();
    if (sys_paths == null) {
        usr_paths = initializePath("java.library.path");
        sys_paths = initializePath("sun.boot.library.path");
    }
    if (isAbsolute) {
        if (loadLibrary0(fromClass, new File(name))) {
            return;
        }
        throw new UnsatisfiedLinkError("Can't load library: " + name);
    }
// ....

The second form

export LD_LIBRARY_PATH=/path

will be handled in native, according to the document of dlopen/dlsym

 dlopen()
   The function dlopen() loads the dynamic library file named by the null-terminated string filename and returns an opaque  "handle"  for  the
   dynamic  library.   If  filename is NULL, then the returned handle is for the main program.  If filename contains a slash ("/"), then it is
   interpreted as a (relative or absolute) pathname.  Otherwise, the dynamic linker searches for the library as follows (see ld.so(8) for fur‐
   ther details):

   o   (ELF  only)  If  the  executable  file for the calling program contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag, then the
       directories listed in the DT_RPATH tag are searched.

   o   If, at the time that the program was started, the environment variable LD_LIBRARY_PATH was defined to contain a colon-separated list of
       directories, then these are searched.  (As a security measure this variable is ignored for set-user-ID and set-group-ID programs.)

In this manner, if there are some problems with your library path and the system can't load your library, the system won't give too much clue what happen and will fail silently (I guess). It depends whether or not to implement LD_LIBRARY_PATH, Android didn't use LD_LIBRARY_PATH to determine the library location, you can see Android's implementation from here.