On Fri, Jul 27, 2001 at 06:58:12AM -0500, Ben Burton wrote:
>
> > 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.
Of course--but if you're targeting compatibility with
not-yet-packaged JVM's, I think energy is better spent ensuring that
they get packaged correctly, than assuming they will be broken and
preparing to work around them.
> > - 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.
On my Woody system, /usr/bin/kaffe is a shell script. Here are some
of the comments, in case you can't easily get your hands on it:
# This script invokes the "Kaffe" executable after modifying
# CLASSPATH and LD_LIBRARY_PATH as needed.
# The effective CLASSPATH is made up of four parts, which
# are composed in the following order:
#
# 1. a user-specified CLASSPATH or .
# 2. Klasses.jar in $datadir/kaffe
# 3. Kaffe extensions jar files in $datadir/kaffe
# 4. kjc.jar in $datadir/kaffe
# 5. classes.zip in $datadir/kaffe iff it exists.
#
# Note that as the last thing we slurp in the files $datadir/kafferc
# and $HOME/.kafferc (in that order) if they exist. This allows site
# and user specific JAR files to be automatically added to
# CLASSPATH.
> > - 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.
Sure, this is not a black and white question, but most Debian
programs can't easily be broken by the installation of local
software. For example, Debian Perl programs generally specify
/usr/bin/perl. Maybe Java should be different. But I can imagine
someone, for example, locally installing a pre-release of some JVM
to test his own programs, and finding to his surprise that Debian
Java programs break (due to bugs in the pre-release). So I don't
think that using the path should be the default.
> > 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.
But unless I misunderstand the current situation, it's not
compelling _right now_. The only way it will become compelling is
if future JVM's are broken, and with your script they have less
incentive not to be broken.
> How does this encourage java program packagers to take matters into their
> own hands?
Because the proposed Java policy strongly suggests that the official
way to run java programs is to run /usr/bin/java, and you are
encouraging packagers to disregard that standard.
If you want to propose this wrapper as the official way to run Java
programs, I think that would be better. But in that case, there are
different issues to discuss.
Andrew
