[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed addition to java-common

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

> > - 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.


Reply to: