On 07/29/2014 04:09 PM, Christopher wrote:

As far as I can tell, currently, System.loadLibrary() is mostly
unusable for Java libraries because they cannot influence the
library search path.  If you want to transparently load a DSO, you
need to use System.load() and hard-code the path.  This probably
means patching upstream sources.

To be clear, you can use LD_LIBRARY_PATH, or -Djava.library.path to influence the search path in any launch scripts, just like you'd control the bootstrap classpath in those same scripts. By choosing to use System.loadLibrary(), instead of System.load(), the developer has already decided to defer any influence over the search path to something external, like a script (or the system's ld cache), so I've not found this to be much of a limitation. I'm sure there are arguments against doing this, but it is imprecise to say that it's not possible.

It's not possible from a library (unless you provide your own class loader, as David explained). A library cannot influence how the launcher is invoked.

Debian patches the default search path so that System.loadLibrary()
searches /usr/lib/jni for DSOs with native code.  This means that
classes which call System.loadLibrary() just work, assuming that the
Debian package installs its DSOs into /usr/lib/jni.

Forgive my ignorance, but what exactly is wrong with just using /usr/lib[64], and how does putting them in a separate directory from other system shared libraries offer any greater degree of control?

These Java DSOs are not for general system use. Programmers are not supposed to link against them, for instance. ldconfig processing of files in /usr/lib{,64} is potentially harmful as well.

The (non-Java) Fedora Packaging Guidelines seem to imply to me that such DSOs should not be put into /usr/lib{,64}, but the wording isn't completely clear. See http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages and the paragraph starting with “As an additional complication, some software generates unversioned shared objects which are not intended to be used as system libraries.”

The Debian Policy does not explicit prevents using /usr/lib, either but I assume that putting the JNI DSOs there (or the equivalent multi-arch directory) would be problematic.