Re: Proposed addition to java-common
> Oh. (Sheepishly looking in the archives for your script and
> otherwise nosing around.) Well now, I'm not sure I see who is
> helped by your script (in its current form).
Well, the idea is that *every* java interpreter or compiler packaged by
Debian gets placed in these scripts. Thus the app packager can ideally
use these scripts and have their app work for all debian JVMs;
furthermore, when a new JVM is added only java-common needs to be updated,
not all the individual packages.
I don't see how the current situation is better off, in which AFAICT I
have to either give the user a nice script to start my app but dictate
precisely which JVM to use, or otherwise I provide jars and classes and
just throw them at the user with no neat method of incantation.
Yes, at the moment findjava only seems to have kaffe as an interesting
case to handle. But then again, kaffe is one of the precious few JVMs in
main. Btw, last time I looked japhar was badly broken.
You will also find that findjavac supports several compilers with even
more diverse methods of invocation.
> - You only do anything for Kaffe if it is installed in /usr, but the
> Debian package of Kaffe already has a wrapper that seems to take
> care of everything.
Which wrapper is this? I couldn't work out how to start kaffe with my own
classpath additions without having to explicitly specify the bootstrap
classpath as well. But then again perhaps I didn't look hard enough.
> - Taking the interpreter from the path is questionable. Many people
> probably have a locally installed JVM, but I think it is better
> for Debian Java programs to prefer a Debian packaged JVM by
> default.
The reason for choosing a JVM from the path was to try and use the JVM
that the user would normally choose to run. If a debian JVM is installed,
it will find it. Otherwise one hopes the locally installed JVM is on the
path, in which case it will still find it. Otherwise there's really not
a lot more automation that can be done.
> Unless there is some compelling benefit to your script _right now_,
> I think it is better not to introduce it, since we will only want to
> transition away later.
Well, the compelling benefit I see is that it gets around differences in
command-line parameters (hard to fix) and JVM names (easy to fix via
alternatives), the result being to allow any JVM with any apps. Which I
think is a sufficiently strong advantage that the scripts are worth
introducing.
> Note I have no objection to having a Debian wrapper script (possibly
> based on yours) that is declared to be the official way for Debian
> programs to launch a JVM. What I oppose is encouraging Java program
> packagers to take matters into their own hands.
How does this encourage java program packagers to take matters into their
own hands? I proposed this as an addition to java-common precisely to try
and provide a standard method of incantation instead of the mess we have
at present.
Ben.
Reply to: