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 [EMAIL PROTECTED] Chief Technology Officer 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
