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