Bug#212863: finjava: a tentative summary
On Wed, 2003-10-08 at 05:11, Daniel Bonniot wrote:
> 1) Necessity for findjava
>
> I think Jan explained this well in his last message. Package A might
> work with kaffe or gij but not sablevm, while package B works with gij
> or sablevm but not kaffe. Alternatives cannot handle this situation.
> Findjava is the tool that allow the startup scripts of A and B to
> declare this fact, while being abstract over binary locations.
> Furthermore, one can invent more abstract tags to pass to finjava, like
> 'awt', 'server' or whatever.
Ok, I begin to see the motivation. Findjava overrides (replaces) the
alternatives mechanism because the proper "alternative" for a given java
app may vary from application to application. Certain apps that know
they can run on certain free VMs may take advantage of certain specific
features and so forth and therefore want a common way to search for
those apps locations.
This seems like a reasonable motivation. However, my concern would be
that these tunings can become so app <--> vm specific that findjava does
not really support their needs or contains elaborate tunings specific to
a single app/vm relationship. It seems more straightforward to me to
have the "for java in kaffe, sable, foo, bar" logic reside in the
kick-off script for the actual app that knows it wants to do special
free VM oriented things.
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.
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. Therefore, /usr/lib/javahome will be an alternative that
points into a set of directories provided by some VM that looks and
feels like a Sun style JAVA_HOME. That's just me but I think its the
sanest option that will get the most things running the quickest.
> 2) Independence of the JVM packages
>
> That's Ean's point. Each JVM has its own command line arguments, so code
> is needed to translate a standardized set of command line arguments to
> the JVM own format. We should not put this translation code in a common
> package, because then each maintainer will need to update it from time
> to time, and it will be a mess.
Yes. That is where I'm at.
> Ean wrote:
Nope, not me.
--
_____________________________________________________________________
Ean Schuessler ean@brainfood.com
Chief Technology Officer 214-720-0700 x 315
Brainfood, Inc. http://www.brainfood.com
Reply to: