thanks for your quick reply!
Ean Schuessler wrote:
On Thu, 2003-10-09 at 12:17, Dalibor Topic wrote:
For example, it seems to be impossible for a non-root user, to overwrite the java alternative, whereas the proposed scheme allows the user to specify a different (maybe even working ;) jvm that he one that comes up on top of the alternative system. Given that currently some applications may run with some VMs, but not with others, and not on all platforms, findjava seems like a good compromise to me, which takes the idea of alternatives system, and extends it to be more flexible to be able to cope with current VM situation, i.e. debug everywhere ;)
export JAVA_HOME=/usr/lib/kaffe (not so hard)
Which only works for those apps that use JAVA_HOME to find the java executable to run themselves. Not for the others.
The trouble with JAVA_HOME is that even if debian specifies it, hardly any java application developer would be bothered to follow debian's specification, instead of whatever ad-hoc pseudo-standard de-jour JAVA_HOME seems to ben in whatever the current JVM release on the developer's target/developement platform is. From my experience with dealing with open source java developers, to most of them JAVA_HOME is like crack: once they get hooked on accessing sun's internals directly, it's very hard to get them off the quick fix.
While kaffe now follows a more jre like file layout, some things will fail nevertheless (like code trying to access tools.jar in order to use Sun's javac, a classical ant, or tomcat fallacy). Code that relies on JAVA_HOME is VM dependant by design, and runs on free VMs by pure chance. That it often runs nevertheless is mostly the fruit of hard work trying to find ways to work around, ahem, sloppy programming ;)
These issues are orthogonal. The directory structure of a VM that launches an app has no impact on whether it can call Sun internal code or not. It comes down to what the ClassLoaders will find.
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 ;)
c) avoiding free VMs like kaffe: See http://lists.codehaus.org/pipermail/jcontainer-commits/2003-July/000399.html
for example:
# Checking for JAVA_HOME is required on *nix due
# to some distributions stupidly including kaffe in /usr/bin
there providing a JAVA_HOME doesn't help either.
d) to work around Cygwin's unix paths vs. Windows paths issues: http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03231.html there providing JAVA_HOME doesn't make sense for debian either.
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?
So I'm quite opposed to debian trying to standardise/faciliate something that is bad practice. Instead, it would be, in my opinion, better to teach the open source java developers to avoid using Sun's internals in their code.
A noble ambition but I don't see us having much influence on the general community of Java authors out there. The JAVA_HOME convention is a reality, crappy as it may be, and many Java applications attempt to use it. Requiring Debian Java VMs to present some semblance of the JAVA_HOME "standard" is going to make more apps run on more VMs for Debian.
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 ;)
Dealing with the use of Sun internals is a border case that needs to be addressed seperately for those apps that do so.
Yep. A pox on their house and all that! ;)
Both debian-java-home and findjava are attempts to deal with the same problem. But debian-java-home doesn't do much good: it adds some more burden on package maintainers, giving developers some hope that their apps may run on the VMs, if they use JAVA_HOME at all. But it's not giving users the security that a particular java application they installed will actually run on their system.
From that perspective I'm not against the notion of packages being ableto specify their own preference for a VM to run against and I'm not against centralizing the logic that finds that VM.
Could the findjava script then be split apart into VM specific 'plugins' to do the work? then the VM package maintainers could independently update 'findjava-kaffe' from 'findjava-sablevm', while keeping the calling interface for the main 'findjava' script.
Maybe something like:
/etc/findjava/kaffe: JAVA_HOME=/usr/lib/kaffe JAVA_BIN=/usr/lib/kaffe/bin/java BASE_CLASSES=$JAVA_HOME/jre/lib/rt.jar MX=-mx COMMAND_LINE_CLASSPATH=-classpath=$BASE_CLASSES:$CLASSPATH ..etc.. or something like that...
or something... but then kaffe would provide /etc/findjava/kaffe as part of its package and findjava would pick it up and invocation time.
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?
cheers, dalibor topic
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
