Bug#212863: finjava: a tentative summary
Ean Schuessler wrote:
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.
Turn 'proper "alternative"' into 'working "alternative"' and you've got
the original motivation ;)
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.
the way I understood it, it has little to do with specific tunings, and
more with giving the application packager a simple, common way to tell
the user which VMs will work with the package, while at the same time
giving the user some choice, and allowing him to overwrite the choice
the packager made.
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 ;)
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.
Wouldn't specifying gij as the only VM in the findjava setup file that
can run the gcj-ed tomcat be enough? You certainly wouldn't want to
recompile tomcat with gcj on every invocation? ;)
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.
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 ;)
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.
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.
Findjava, on the other hand, doesn't care about java home at all. It is
just a mechanism for users and application packagers to come together on
a VM-application combination that is supposed to work. If the app uses
JAVA_HOME and a VM provides enough of it for an app to run, then fine,
the applicatin packager can add the VM to the list of VMs his
application should work on. But assuming that just because a VM provides
a debian specific JAVA_HOME directory structure some JAVA_HOME using app
will run, is wrong, in my experience ;)
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.
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.
cheers,
dalibor topic
Reply to: