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 [EMAIL PROTECTED] Chief Technology Officer 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
