On Thu, 2003-10-09 at 13:46, Dalibor Topic wrote: > Which only works for those apps that use JAVA_HOME to find the java > executable to run themselves. Not for the others.
They often use JAVA_HOME to find the executable, the base class libraries, the compiler and jar. Of course, that presents another set of issues with regard to alternatives. If JAVA_HOME points at /usr/lib/kaffe then how can javac = jikes and so forth. I'm not saying that JAVA_HOME kicks ass or is even sane, it is just a widely used convention. > I've gone over this with Jan, and it seems that most apps use JAVA_HOME > for two things: > > a) access Sun internal code, where having a JAVA_HOME layout doesn't > help the free VMs run that code anyway. > > b) running with a VM that's not in $PATH. Which is what findjava is made > for ;) >From that perspective, shouldn't findjava just be /usr/bin/java? > Is there any other use of JAVA_HOME you've seen? Where there is > something gained by using JAVA_HOME that a) can not be provided by > findjava and at the same time b) is portable through java runtimes? Other than what I said earlier, no. > I believe that's wishful thinking. The JAVA_HOME variable could be set > by findjava script as well, if it would matter that much. But from my > experience of wrestling with poorly programmed java applications, most > of the stuff uses JAVA_HOME for trivial things, like finding the java > binary, or utterly non-portable mess ;) It could, if all Debian VMs provide a JAVA_HOME-like structure. > Maybe it would be better to maintain the findjava-vm-binding as a > separate package, so that bugs in one don't force exclusion of the other > from testing? Sensible enough. -- _____________________________________________________________________ Ean Schuessler [EMAIL PROTECTED] Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
