Bug#212863: java-common: New java policy including tools to manage the changes
I still don't understand what this achieves that alternatives do not.
There is nothing particularly special about Java that requires a more
elaborate alternatives mechanism than any other interpreter. 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.
It would seem to me that findjava will simply invoke whichever VM it
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
that much that cannot be done with proper wrapper scripts for each VM.
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) mechanisms that
Debian already provides.
Sorry for the continued stubborn-headedness.
On Tue, 2003-10-07 at 18:48, Jan Schulz wrote:
> The goal is to provide a search mechnism for the alternatives. The
> discussion in debian-java has shown, that the alternative machnism
> isn't enough and especial isn't reliable.
>
> findjava will be called with the list of the 'known working' java
> implementations and will either return one of them, which is
> installed or exit with an error code. This will ensure that the
> called java command is known to be working with your package. The
> basic equivalent of this code is
>
> for java in /usr/bin/kaffe /usr/lib/j2sdk1.4/bin/java ... ; do
> if [ -x $java ] ; then
> JAVACMD="$java"
> break
> fi
> done
--
_____________________________________________________________________
Ean Schuessler ean@brainfood.com
Chief Technology Officer 214-720-0700 x 315
Brainfood, Inc. http://www.brainfood.com
Reply to: