Re: Handling native libs within a Virtual Machine
Hi Tom,
Tom Marble wrote:
All:
Current Debian Java Policy [1] in section "Chapter 2.1: Virtual Machines"
stipulates "If a virtual machine supports native code, it must include the
directory /usr/lib/jni in its search path for these dynamic libraries."
There is no rationale given for this policy choice and I fail to
see the advantage of it. On the other hand I can imagine the
following contraindications:
- Multiple VM's, or different versions of the same VM, may use similarly
named native libraries which have different version dependencies.
In the aforementioned policy scheme there is no way to avoid such
a version clash.
- Each VM under /usr/lib/jvm/<vm-name>/ it would seem should be
self contained in that file hierarchy, insomuch as possible.
- Usually VM native libraries are required to implement the VM
itself and would not have any utility being exposed in
a "public path" as a native Java add-on library would
Shall this requirement be dropped for virtual machines?
JVMs should not put their native libraries into /usr/lib/jni, they
should just add '/usr/lib/jni' to the search path for
System.loadLibrary().
This allows the installation of JNI libraries for use with all
installed JVMs. Of course this only works if the JVMs also find the
corresponding Java libraries.
For Blackdown, we add '/usr/lib/jni' to the search path for
System.loadLibrary() and '/usr/share/java' to java.ext.dirs when the
VM was installed from a .deb. (Implemented in HotSpot's os_linux.cpp.)
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/
Reply to: