[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#212863: java-common: New java policy including tools to manage the changes



Hello Ean,

Wednesday, October 8, 2003, 6:22:49 AM, you wrote:
> I still don't understand what this achieves that alternatives do not.

Imagine this situation:

Application needs a special feature, which is implemented in about
half the java alternatives. /usr/bin/java will be set by all java
binaries and in this case, /usr/bin/java is set by a package, which
does not implement the requirements. There is a second installed
java package, which does implement it.

-> apt will see all dependencies fullfiled, app will call
/usr/bin/java and will not run.

The workaround would be to follow the symlinks, but that would be
the working *around* teh alternative system *and* you would end up
with the 'findjava' code in every starter script (as the fallback,
when /usr/bin/java isn't working).

You get a similar 'feature' with the /etc/findjavarc and
'PREFERRED_...' variable.

> There is nothing particularly special about Java that requires a more
> elaborate alternatives mechanism than any other interpreter.

IMO there is. See the discussion in debian-java, where this was
turned over and over again.

>  If the
> wrapper script for each VM does its job properly then the classpath
> should get set to what it needs to be and the VM will be invoked with
> all the proper conventions.

This isn't the problem at all. The problem is that some java VMs
will be able to start something and others will not.

> It would seem to me that findjava will simply invoke whichever VM it

Please read the manpage of findjava and how it is used. It does not
invoke anything, it just outputs the 'java command' to stdout. It
garantees, that this outputed command is available on this system.
If you need more than this, you can still do some magic based on
this.

> finds first in its list of VMs and that will be that. It loses the
> priority mechanism of the alternatives scheme and doesn't really add

The priorites were also discusssed and the 'would be' consensus was,
that we can't assign different priorities without having a big row.
based on what facts will you assign priorities? And you could still
end up in a situation, where a lower priority JVM will run a app,
but a hiher priority JVM will not.

> that much that cannot be done with proper wrapper scripts for each VM.

IMO for the basic function (starting a app with a classpath and a
main class) it's already now enough. For more, you cannot specifiy it
*enough* to satisfy every situation (like: enable the jitter with
what option? Enable what GC with what option? What subset would you
implement?) and IMO SUN should do this and not we.

> I may need to go back and read the earlier discussions more carefully
> but I never saw how the findjava script adds anything that cannot be
> achieved using the usual (and up til now sufficient)

IMO the today mechanism is *not* sufficient. Have a look at the
starterscripts of all big java papps how they find the java binary:
all uses JAVA_HOME for it and /usr/bin/java as a fallback.

Please read the script and what it does. Also there is a lot of
mails about the 'alternatives are enough to find a java binary'
discussion during the second edition of the proposal.

Jan




Reply to: