Re: Java policy change proposal: runtime/compiler selection
Matthias Klose wrote: > Tom Marble writes: >> Jeroen van Wolffelaar wrote: >>> Currently, there is update-java-alternatives in java-common to manage >>> the various java commands and how they refer to which implementation. >>> People can however ignore it and update-alternatives themselves, things >>> can get out-of-sync, and how to set priorities is unclear and not easy >>> to decide on. >> problem 1: update-alternatives w/o update-java-alternatives (UJA) can >> lead to an "out of sync" situation. > > we currently do have this problem; maybe the introduction of a > null-environment with dummy binaries would avoid that. That sounds like a good idea. Should we also add a comment to all JVM post-inst's that selecting this (or any) Java implementation can be done with UJA? >>> - All java commands such as /usr/bin/java, javac, javap, javadoc, etc >>> etc are all replaced by a shellscript provided by java-common. The >>> alternatives are removed >> Regrettably I must state that this would break a very large number >> of things the reason is that the PID returned by the /usr/bin/java >> script would be for the script and not Java. We found out in the course >> of developing JDK 6 that when we introduced a feature (called the >> mini-launcher) that this problem of having the PID returned *not* be >> that of the target JVM process caused a great deal of problems related >> to job control of Java applications. > > would calling the real binary using exec a solution? Yes (the reason we could not do that in JDK 6 is the Windows API does not have a "real" exec call -- only spawn). >> so, in order to address the problems above: >> >> proposed solution to problem 1: >> >> Would it be possible to use slaves or some other mechanism of >> update-alternatives to avoid this scenario? I expect this use case -- >> of needing to marshal more than one alternative at the same time -- >> may not be limited to Java. One way would be to extend update-alternatives >> with the concept of a "group hook"? The idea would be that modifying the >> alternative without using the group hook would result in a "are you sure?" >> message. >> >> The problem with this solution is that it would require a fundamentally >> new behavior in update-alternatives which, as it's end result, simply >> protects >> the user from naive behavior. Instead of a technical solution, could >> we address this problem through better documentation? > > update-alternatives doesn't work well if some of the links are setup > as master, and some as slaves. that's the reason currently all > binaries are setup using it's own master. Until this is fixed, u-a is > not a solution. > > An alternative could be to manage a symlink to a JAVA_HOME with an > alternative and have a set of hard coded binaries point to the > binaries inside this JAVA_HOME. The downside is that single binaries > like kaffe are not able to register an alternative like java anymore. Right.. that is a problem. So in some sense allowing UA to override UJA and create an out-of-sync situation can be viewed as a feature. In re-reading Jeroen's original proposal I can see some merit of using the java-common "launch/exec" script approach as opposed to the current UJA approach. I'm not sure how certain elements, such as the N browser to M implementation plugin problem would be handled (perhaps somehow in the java-common registry?). Note that Jeroen says "When a user invokes for example /usr/bin/java, the shellscript consults the register directory, and retrieves the currently selected implementation. It initializes environment variables as needed, and execs the correct implementation." Presumably that could include LD_LIBRARY_PATH which contains /usr/lib/jni (to handle the native library part of Debian Java Policy). Note that "problem 2: setting classpath does not happen automatically" would *still* need to be addressed by the the Java application launcher (not by /usr/bin/java). Presumably "problem 3: illegal combinations are avoided" presumably this could be done at invocation time by /usr/bin/java (by inspecting the currently chosen JVM and current settings for classpath (CLASSPATH/-cp .../bootclasspath). This seems like overkill (and a startup performance degradation). In the only case we have found so far of an illegal combination that was obvious by inspecting the launch script (i.e. seems like a high price to pay for every invocation of Java). Regards, --Tom _ [EMAIL PROTECTED] Senior Java Performance Engineer Sun Microsystems, Inc. http://blogs.sun.com/tmarbleWhat do you want from Java Libre? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling native libs within a Virtual Machine
Matthias Klose wrote:
>> 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.
Right. I was "simulating" (part) of what a Debian package would do
based on my interpretation of Debian Java Policy.
>> 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.
Can you clarify "binaries must be able to run without an explicit set of
environment variables"?
The only case where an environment variable would be required is
for those applications that depend on a jni libary -- and the only environment
variable needed then is LD_LIBRARY_PATH. And then the only addition
to LD_LIBRARY_PATH is the canonical location for Java native
libraries: /usr/lib/jni. As such that location could be added in
/etc/environment or even more generally to ldconfig(8). Either of these
solutions would eliminate the need for ALL Java launchers setting ANY
environment variables (were that the desired goal).
In examining an Etch system I find the following (partial output):
[EMAIL PROTECTED] 3% cd /usr/bin
[EMAIL PROTECTED] 4% grep LD_LIBRARY_PATH *
dh_shlibdeps:Before dpkg-shlibdeps is run, LD_LIBRARY_PATH will have added to
it the
dpkg-shlibdeps:if ($ENV{LD_LIBRARY_PATH}) {
fakeroot:if test -n "$LD_LIBRARY_PATH"; then
firefox:## Set LD_LIBRARY_PATH
Binary file gdb matches
Binary file gdbtui matches
kaffe:# CLASSPATH and LD_LIBRARY_PATH as needed.
mozilla:## Set LD_LIBRARY_PATH
Binary file nautilus matches
Binary file php matches
Binary file php4 matches
Binary file php4-cgi matches
Binary file php-cgi matches
unix-lpr.sh:LD_LIBRARY_PATH=${X11HOME}/lib
[EMAIL PROTECTED] 5%
And so I'm wondering if a clarification of Debian Java Policy for JVM's would
allow us to address this bug:
sun-java5-jre does not add /usr/lib/jni to the library path
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382686
Regards,
--Tom
_
[EMAIL PROTECTED]
Senior Java Performance Engineer Sun Microsystems, Inc.
http://blogs.sun.com/tmarbleWhat do you want from Java Libre?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java policy change proposal: runtime/compiler selection
Tom Marble writes: > Jeroen van Wolffelaar wrote: > > Currently, there is update-java-alternatives in java-common to manage > > the various java commands and how they refer to which implementation. > > People can however ignore it and update-alternatives themselves, things > > can get out-of-sync, and how to set priorities is unclear and not easy > > to decide on. > problem 1: update-alternatives w/o update-java-alternatives (UJA) can > lead to an "out of sync" situation. we currently do have this problem; maybe the introduction of a null-environment with dummy binaries would avoid that. > > In the current Debian Java policy, java libraries are required to > > properly document how to modify classpath such that people can use them > > -- this does not work automatically. > problem 2: setting classpath does not happen automatically > > > Because of the above two issues, let me propose a different approach. > > > > - All java commands such as /usr/bin/java, javac, javap, javadoc, etc > > etc are all replaced by a shellscript provided by java-common. The > > alternatives are removed > Regrettably I must state that this would break a very large number > of things the reason is that the PID returned by the /usr/bin/java > script would be for the script and not Java. We found out in the course > of developing JDK 6 that when we introduced a feature (called the > mini-launcher) that this problem of having the PID returned *not* be > that of the target JVM process caused a great deal of problems related > to job control of Java applications. would calling the real binary using exec a solution? > so, in order to address the problems above: > > proposed solution to problem 1: > > Would it be possible to use slaves or some other mechanism of > update-alternatives to avoid this scenario? I expect this use case -- > of needing to marshal more than one alternative at the same time -- > may not be limited to Java. One way would be to extend update-alternatives > with the concept of a "group hook"? The idea would be that modifying the > alternative without using the group hook would result in a "are you sure?" > message. > > The problem with this solution is that it would require a fundamentally > new behavior in update-alternatives which, as it's end result, simply protects > the user from naive behavior. Instead of a technical solution, could > we address this problem through better documentation? update-alternatives doesn't work well if some of the links are setup as master, and some as slaves. that's the reason currently all binaries are setup using it's own master. Until this is fixed, u-a is not a solution. An alternative could be to manage a symlink to a JAVA_HOME with an alternative and have a set of hard coded binaries point to the binaries inside this JAVA_HOME. The downside is that single binaries like kaffe are not able to register an alternative like java anymore. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling native libs within a Virtual Machine
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]
Is batik squiggle supposed to work?
I've been testing batik on and off with Classpath the last year, hoping it would make it to Debian/main and thus allow the OpenJump package to make it into Debian/main. But there are still issues. But I am starting to suspect that the problem isn't with Classpath, but with batik itself, as it fail to run with SUN Java as well. Is batik supposed to work? When I use the ./squiggle.sh in the pkg-java svn, it throws an exception: % JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun-1.5.0.08 ./squiggle.sh Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location - find_vma failed java.security.AccessControlException: access denied (java.net.NetPermission setDefaultAuthenticator) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.net.Authenticator.setDefault(Authenticator.java:110) at org.apache.batik.apps.svgbrowser.Main.(Unknown Source) at org.apache.batik.apps.svgbrowser.Main.main(Unknown Source) % Is the batik package broken? Did something change in SUN Java breaking batik, or did this never work? Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
