java library installation issues

[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.
> 
> 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 wath 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.)

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.

> > With this setup:

> > (1) All Java compilers and VMs can compile find all "installed" .jars,
> > without users having to fiddle with classpaths.
> 
> An second option is to have a system wide CLASSPATH set, that would
> include all jars... 

That's a really super bad idea, for two reasons:
1) jar explosion. Assuming we finally get a decent standard worked out,
and everyone uses it, there could be dozens or hundreds of jar files.
That creates needless overhead for the JVM's classloader, which would
have to dig through the mess for your classes. The classloader certainly
doesn't need to be any _slower_.
2) what good are versions then? How do you prevent two conflicting
implementations from being in the classpath at the same time? What about
order? 

I've never liked the "global classpath" approach; it always caused
problems with our deployment.

-- 


Paul Reavis                                      preavis@partnersoft.com
Design Lead
Partner Software, Inc.                        http://www.partnersoft.com