Bug#212863: finjava: a tentative summary
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 ean@brainfood.com
Brainfood, Inc. http://www.brainfood.com
Reply to: