Tom Marble writes: > Juergen Kreileder wrote: > > Tom Marble wrote: > >> 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." > > > > 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 [1] to demonstrate the point. > > If I follow the instructions for "Local installation" [2] which keeping > Debian Policy [3] 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 [4]): > > [EMAIL PROTECTED] 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) > LD_LIBRARY_PATH=/usr/lib/jni:/usr/local/lib:/usr/X11R6/lib > java -client -Djava.ext.dirs=/usr/share/java:/usr/share/jogl-demos > demos.vertexProgRefract.VertexProgRefract > > [EMAIL PROTECTED] 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. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
