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.
--
Florian Weimer / Red Hat Product Security
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
