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
Reply to: