Re: java library installation issues

[Egon Willighagen <egonw@subdimension.com>]

Op dinsdag 03 april 2001 18:49, schreef Paul Reavis:
> On 03 Apr 2001 07:50:33 +0200, Egon Willighagen wrote:
> > > I've left out versioning issues.  If one want to support multiple
> > > versions of the same library one could install LIBRARY-VERSION.jar,
> > > and install a symlink from LIBRARY.jar, but having compilers and
> > > VMs pick the right version is unclear to me.

This would be done by Debian::JavaLauncher. (see below)

> > Versioning of jars is very important to me. It currently is not in the
> > Java policy,  but i would love to see that happen.
> >
> > I like your proposol. I am not sure what Debian policy says about
> > linking, but i can imagine that the link will also point to the most
> > recent release... Since we want to move forward... and that if
> > applications need an older version, they (the /usr/bin/exec) should
> > classpath the old library itself...
>
> I was playing around with a scheme; it went like this:
> -> versioned files and symlinks much like .so
> -> e.g.
> ---> antlr-1.2.3.jar
> ---> antlr-1.2.4.jar
> ---> antlr-2.0.1.jar
> ---> antlr-2.1.0.jar
> ---> antlr-2.1.3.jar
> ---> antlr.jar -> antlr-2.1.3.jar
> ---> antlr-2.jar -> antlr-2.1.3.jar
> ---> antlr-1.jar -> antlr-1.2.4.jar
>
> Then you have some wrapper script utlities to help you build a
> classpath. E.g. (pardon my scripting; I'm a Java programmer):
>
> #!/usr/bin/perl
>
> use "debclasspath";
>
> @jars = ("antlr", "mystuff");
>
> launchJava("com.mydotcom.mystuff.myapp", \@jars, \@ARGV);
>
>
> That would launch the app with the latest versions of whatever. And if
> you wanted to use an older version for a legacy app or whatever, or need
> a very specific version you just specify the version as far as you like:
>
> @jars = ("antlr-1", "mystuff-1.0.3.2.9");
>
> Wrapper scripts are also good e.g. if there need to be special VM
> parameters passed (maximum heap size, no incremental image drawing,
> etc.)

I like the idea of a Perl launcher... it would be included in java-common.deb.
And the policy would say, every java executable should be run using this
launcher. This launcher would now things about JVM's installed, versions
etc...

The example above would be extended like:

#!/usr/bin/perl -w
use strict;
use Debian::JavaLauncher;

my @jars = ("antlr", "mystuff");
my %options = {
   allowedJavaVersions => ("1.1", "1.2", "1.3"),
   allowedVMs => ("kaffe", "gcj", "ibm-java", "blackdown"),
}

launchJava("com.mydotcom.mystuff.myapp", \@jars, \%options, \@ARGV);

# end program

The launch procedure would choose the most optimal VM/version combo
available in that particular machine... If gcj available, this would be 
preferred, but if it is not installed it automatically falls back to an other
version.... unless the options disallow it. In that case the launchJava proc
would generate an error...

> Alternately, it can all be done in Java, though that poses some other
> interesting problems (e.g. which java to do it in). Attached is source
> for our current Java launcher, which requires only one Jar in the
> classpath, and adds the others based on a config file. It then passes
> control to another class which is loads a registry of
> appname->classname+argument mappings.

I think Perl would do fine. 

Egon