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
_____________________________________________________________________________
Tom.Marble@sun.com
Senior Java Performance Engineer Sun Microsystems, Inc.
http://blogs.sun.com/tmarble What do you want from Java Libre?
Reply to: