jvm_update
jvm_update

Reputation: 265

portable statement to load JNI library from a different directory using relative pathname?

Is there a platform-independent Java statement to load a native library from a different directory than the Java source code is in? I would like to use something like this:

public class HelloWorld {
    static {
        System.loadLibrary("../some_project/HelloWorld");
    }

    public static native void print();
}

The problem is that System.loadLibrary() doesn't support directory separators in the pathname argument. Also, System.load() unfortunately requires an absolute pathname, which not only means I can't specify a relative directory as above (which I would like to do), but it also requires the argument to include, for example, the preceding "lib" and ".so" extension on the JNI library name on a Linux system.

Is there a standard way of dealing with this? If possible, I would like to avoid writing a bunch of platform-dependent Java code just to construct the correct JNI library name.

Upvotes: 10

Views: 6860

Answers (2)

Brett Kail
Brett Kail

Reputation: 33936

I believe you're looking for System.mapLibraryName, which is the method typically used by ClassLoader.findLibrary implementations. For example:

File lib = new File("../some_project/" + System.mapLibraryName("HelloWorld"));
System.load(lib.getAbsolutePath());

This will use libHelloWorld.so on Linux and HelloWorld.dll on Windows. Be aware that some operating systems support multiple extensions, and mapLibraryName can only support one, by design. The ones I'm aware of are MacOS (.dylib primarily and .jnilib for legacy) and AIX (.a and .so).

Upvotes: 23

David Heffernan
David Heffernan

Reputation: 612794

Well, as you have clearly explained, you can't use loadLibrary. And so that leaves load. But that requires an absolute path. So, expand your relative path into an absolute path using your preferred file path utility functions, and pass that on to load. This may seem inconvenient but it's much more robust than relying on the vagaries of library search paths.

Upvotes: 0

Related Questions