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/tmarble What do you want from Java Libre? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
