Bug#212863: finjava: a tentative summary
Hello Ean,
Thursday, October 9, 2003, 7:33:22 AM, you wrote:
> For instance, if the Tomcat maintainer decides that compiling certain
> baseline classes with GCJ before running the main system with GIJ is a
> good idea then I can't see that findjava will elegantly accomodate that.
> The idea itself may be sound but probably doesn't belong in a common
> package and actually probably belongs in something like
> tomcat-gcj-booster.deb or somesuch.
True. And this package will depend *only' on gcj and will not touch
any java related things like jar files or java bytecode
interpreeter. This things will be handled --more or less-- under
normal debian policy.
> All things considered, I think that my preference is to have each VM
> provide some Debian-specific tightened up version of $JAVA_HOME that we
> specify in java-policy and then have $JAVA_HOME be managed by
> alternatives.
IMO:
JAVA_HOME is good for three things:
* ant, which depends on the java property java.home set and some
apps in java.home/bin/*
* other apps, which rely on internal things in java.home
* uses '$JAVA_HOME/bin/java to start the app
The first is done in the 'ant-environment', which specifies a 'kind
of' java.home, but the only requirement is 'it runs ant'.
The second can't properly be helped in any other way than
'Depends: <only sun dereived JVMs>'
The third can be trivaly helped by patching the startup script,
which would probably anyway be needed bvecause of 'free VMs', which
are surely not considered (think: internal options) in this
startscripts.
Did I miss something?
Anyway, even if we specify a 'JAVA_HOME' layout, it will not help us
with the alternative system. The problem with alternactives are
quite different from why a JAVA_HOME layout would be usefull or not.
No matter we are using '/usr/bin/java' or
'/usr/lib/java-home[/bin/java]', the same problems will show up. We
would then need a 'findjavahome' script.
Jan
Reply to: