Re: Handling native libs within a Virtual Machine
Tom Marble writes:
> Juergen Kreileder wrote:
> > Tom Marble wrote:
> >> Current Debian Java Policy  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."
> > 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.)
> It may be easiest to demonstrate an alternative with an example.
> Allow me to use the JOGL project  to demonstrate the point.
> If I follow the instructions for "Local installation"  which keeping
> Debian Policy  in mind I then can do the following (to simulate
local installations should never install directly into /usr, always in
/usr/local. I think the Debian packaging guidelines are clear about that.
> So if we assume that there is at least one Java runtime installed and
> it has been selected with update-java-alternatives (UJA) then the jogl-demos
> launcher can be used to launch each of the demos (demos docs here ):
> tmarble@techno 10% jogl-demos -v 7
> running JOGL demo 7 = demos.vertexProgRefract.VertexProgRefract
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
> java -client -Djava.ext.dirs=/usr/share/java:/usr/share/jogl-demos demos.vertexProgRefract.VertexProgRefract
> tmarble@techno 11%
> So note with this example that we didn't need to /usr/lib/jni to the search
> path for System.loadLibrary() nor add /usr/share/java to the default java.ext.dirs
> in the JVM. Note also, from the JOGL documentation, "Dropping the JOGL jar and
> native library into the extension directory of the JRE is strongly discouraged.
> Doing so can cause conflicts with third-party applications launched via
> Java Web Start, and causes confusion later when upgrading the distribution."
> And, we know already from Debian Java Policy and existing Java applications
> in Debian that a launcher script will be required in /usr/bin *anyway*
> so adding LD_LIBRARY_PATH and -Djava.ext.dirs (or to -cp) seems like an
> easy and a JVM neutral approach while preserving the consistency of
> Java libraries in /usr/share/java and JNI in /usr/lib/jni. In fact
> one could even imagine a genericized java application launcher that,
> optionally, uses a specific settings a separate file
> (e.g. /etc/default/jogl-demos and /usr/bin/jogl-demos -> javalauncher ).
> What does everyone think of this alternative?
Please correct me if I'm wrong, but binaries must be able to run
without an explicit set of environment variables. With your setup
every additional binary would need to setup this runtime
environment. Even applications not directly depending on a jni library
would need to know about that environment.