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) > 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. > 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. Dealing with the use of Sun internals is a border case that needs to be addressed seperately for those apps that do so. > 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 able to 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. -- _____________________________________________________________________ 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]
