Take the tour ×

I want to load my own native libraries in my java application. Those native libraries depend upon third-party libraries (which may or may not be present when my application is installed on the client computer).

Inside my java application, I ask the user to specify the location of dependent libs. Once I have this information, I am using it to update the "LD_LIBRARY_PATH" environment variable using JNI code. The following is the code snippet that I am using to change the "LD_LIBRARY_PATH" environment variable.

Java code

public static final int setEnv(String key, String value) {
        if (key == null) {
            throw new NullPointerException("key cannot be null");
        if (value == null) {
            throw new NullPointerException("value cannot be null");
        return nativeSetEnv(key, value);

public static final native int nativeSetEnv(String key, String value);

Jni code (C)

    JNIEXPORT jint JNICALL Java_Test_nativeSetEnv(JNIEnv *env, jclass cls, jstring key, jstring value) {
    const char *nativeKey = NULL;
    const char *nativeValue = NULL;
    nativeKey = (*env)->GetStringUTFChars(env, key, NULL);
    nativeValue = (*env)->GetStringUTFChars(env, value, NULL);
    int result = setenv(nativeKey, nativeValue, 1);
    return (jint) result;

I also have corresponding native methods to fetch the environment variable.

I can successfully update the LD_LIBRARY_PATH (this assertion is based on the output of C routine getenv().

I am still not able to load my native library. The dependent third-party libraries are still not detected.

Any help/pointers are appreciated. I am using Linux 64 bit.


I wrote a SSCE (in C) to test if dynamic loader is working. Here is the SSCE


int main(int argc, const char* const argv[]) {

    const char* const dependentLibPath = "...:";
    const char* const sharedLibrary = "...";
    char *newLibPath = NULL;
    char *originalLibPath = NULL;
    int l1, l2, result;
    void* handle = NULL;

    originalLibPath = getenv("LD_LIBRARY_PATH");
    fprintf(stdout,"\nOriginal library path =%s\n",originalLibPath);
    l1 = strlen(originalLibPath);
    l2 = strlen(dependentLibPath);
    newLibPath = (char *)malloc((l1+l2)*sizeof(char));
    fprintf(stdout,"\nNew library path =%s\n",newLibPath);

    result = setenv("LD_LIBRARY_PATH", newLibPath, 1);
    if(result!=0) {
        fprintf(stderr,"\nEnvironment could not be updated\n");
    newLibPath = getenv("LD_LIBRARY_PATH");
    fprintf(stdout,"\nNew library path from the env =%s\n",newLibPath);

    handle = dlopen(sharedLibrary, RTLD_NOW);
    if(handle==NULL) {
        fprintf(stderr,"\nCould not load the shared library: %s\n",dlerror());
    fprintf(stdout,"\n The shared library was successfully loaded.\n");

    result = dlclose(handle);
    if(result!=0) {
        fprintf(stderr,"\nCould not unload the shared library: %s\n",dlerror());

    return 0;

The C code also does not work. Apparently, the dynamic loader is not rereading the LD_LIBRARY_PATH environment variable. I need to figure out how to force the dynamic loader to re-read the LD_LIBRARY_PATH environment variable.

share|improve this question
I really don't see why it doesn't work, since I've done something which is really similar (under Windows) and it works like a charm. By the way, have you tried (just for debugging purposes) loading the libraries with System.load(...) putting them in a "default" lib directory, just to see if the libraries are broken (and not you nativeSetEnv code). However, good question (+1) –  gd1 Apr 29 '11 at 22:42
..and that's off topic but I think you should free up memory allocated by GetStringUTFChars –  gd1 Apr 29 '11 at 22:42
@Giacomo: It works if I set LD_LIBRARY_PATH when launching my application. I will free up the allocated memory. Thanks for pointing it out. :) –  Santosh Tiwari May 2 '11 at 19:04
I hate telling you so, but there's a radical "solution" that can help you overcome this problem. Drop JNI, create a native executable that mediates between the Java application and that libraries. I remember that after struggling a lot with these messy JNI things (like dynamically loading dependent libs) I created a trait-union between Java and the dynamic libraries w/ a native executable that communicates w/ Java using stdin and stdout, and in rare cases uses the filesystem (temp files). Nasty but very easy to implement. –  gd1 May 2 '11 at 19:50
So my original comment was wrong. It was a long time ago. After struggling a lot with JNI, I've done like I said in my prev. comment. It may be harder or easier depending on how much data do Java and the native stuff share. See ProcessBuilder class if you're interested. –  gd1 May 2 '11 at 19:51
add comment

3 Answers

up vote 1 down vote accepted

See the accepted answer here:

Changing LD_LIBRARY_PATH at runtime for ctypes

In other words, what you're trying to do isn't possible. You'll need to launch a new process with an updated LD_LIBRARY_PATH (e.g., use ProcessBuilder and update environment() to concatenate the necessary directory)

share|improve this answer
This is Java we're talking about, not Python. –  Peter Knego Apr 29 '11 at 23:51
Of course, but the point remains: the dynamic loader code that ran as part of the native java executable has already read the LD_LIBRARY_PATH environment variable. –  bkail Apr 30 '11 at 4:47
I tested what you said, and your are most probably right. Now, how do I force the dynamic loader to reread the LD_LIBRARY_PATH environment variable? Thanks. –  Santosh Tiwari May 2 '11 at 19:48
You can't; the dynamic loader doesn't work that way. You'll need to launch a new process with an updated LD_LIBRARY_PATH (e.g., use ProcessBuilder and update environment() to concatenate the necessary directory). Note, all the other answers are suggesting that you update the java.library.path system property, which you've probably noticed misses the point: your problem is with dependencies between native libraries (and not with the initial load of a native library from Java), so updating a Java system property can't help. –  bkail May 2 '11 at 21:08
add comment

This is a hack used to manipulate JVM's library path programmatically. NOTE: it relies on internals of ClassLoader implementation so it might not work on all JVMs/versions.

String currentPath = System.getProperty("java.library.path");
System.setProperty( "java.library.path", current + ":/path/to/my/libs" );

// this forces JVM to reload "java.library.path" property
Field fieldSysPath = ClassLoader.class.getDeclaredField( "sys_paths" );
fieldSysPath.setAccessible( true );
fieldSysPath.set( null, null );

This code uses UNIX-style file path separators ('/') and library path separator (':'). For cross-platform way of doing this use System Properties to get system-specific separators: http://download.oracle.com/javase/tutorial/essential/environment/sysprop.html

share|improve this answer
If I am not mistaken, JVM uses "java.library.path" to search for shared libraries. The dependent libraries are searched using the LD_LIBRARY_PATH on linux, and PATH on windows. In my specific case, the loading of dependent shared libraries is failing. –  Santosh Tiwari May 2 '11 at 19:07
Yes you are right. Just looked it up: kalblogs.blogspot.com/2009/01/java.html –  Peter Knego May 2 '11 at 20:56
add comment

I have successfully implemented something similar for CollabNet Subversion Edge, which depends on the SIGAR libraries across ALL Operating Systems (we support Windows/Linux/Sparc both 32 bits and 64 bits)...

Subversion Edge is a web application that helps one managing Subversion repositories through a web console and uses SIGAR to the SIGAR libraries helps us provide users data values directly from the OS... You need to update the value of the property "java.library.path" at runtime. (https://ctf.open.collab.net/integration/viewvc/viewvc.cgi/trunk/console/grails-app/services/com/collabnet/svnedge/console/OperatingSystemService.groovy?revision=1890&root=svnedge&system=exsy1005&view=markup Note that the URL is a Groovy code, but I have modified it to a Java here)...

The following example is the implementation in URL above... (On Windows, your user will be required to restart the machine if he/she has downloaded the libraries after or downloaded them using your application)... The "java.library.path" will update the user's path "usr_paths" instead of System path "sys_paths" (permissions exception might be raised depending on the OS when using the latter).

134 * Updates the java.library.path at run-time.
135 * @param libraryDirPath
136 */
137 public void addDirToJavaLibraryPathAtRuntime(String libraryDirPath) 
138    throws Exception {
139    try {
140         Field field = ClassLoader.class.getDeclaredField("usr_paths");
141         field.setAccessible(true);
142         String[] paths = (String[])field.get(null);
143         for (int i = 0; i < paths.length; i++) {
144             if (libraryDirPath.equals(paths[i])) {
145                 return;
146             }
147         }
148         String[] tmp = new String[paths.length+1];
149         System.arraycopy(paths,0,tmp,0,paths.length);
150         tmp[paths.length] = libraryDirPath;
151         field.set(null,tmp);
152         String javaLib = "java.library.path";
153         System.setProperty(javaLib, System.getProperty(javaLib) +
154             File.pathSeparator + libraryDirPath);
156     } catch (IllegalAccessException e) {
157         throw new IOException("Failed to get permissions to set " +
158             "library path to " + libraryDirPath);
159     } catch (NoSuchFieldException e) {
160         throw new IOException("Failed to get field handle to set " +
161            "library path to " + libraryDirPath);
162     }
163 }

The Bootstrap services (Groovy on Grails application) class of the console runs a service and executes it with the full path to the library directory... UNiX-based servers do not need to restart the server to get the libraries, but Windows boxes do need a server restart after the installation. In your case, you would be calling this as follows:

     String yourLib = new File(appHomePath, "SUBDIRECTORY/").getCanonicalPath();
124  try {
125      addDirToJavaLibraryPathAtRuntime(yourLib);
126  } catch (Exception e) {
127      log.error("Error adding the MY Libraries at " + yourLib + " " +
128            "java.library.path: " + e.message);
129  }

For each OS you ship your application, just make sure to provide a matching version of the libraries for the specific platform (32bit-Linux, 64bit-Windows, etc...).

share|improve this answer
You posted the same solution as I. We try to avoid doing that. –  Peter Knego Apr 30 '11 at 8:38
add comment

Your Answer


