Re: jar installation standards

[Nic Ferrier <nferrier at tapsellferrier dot co dot uk>]

Per Bothner <per@bothner.com> writes:

> Bryce McKinlay wrote: 
> > I think this is the best approach, due to its simplicity and  
> > compatibility with existing behaviour of the JDK.  .jars do not really  
> > support versioning, and given the binary compatibility reqirements,  
> > typically do not suffer from the same versioning problems as shared  
> > libraries. 
>  
>  From the discussion on the debian-java list it appears a lot of people 
> disagree.  Supposedly many people have had problems because some library 
> or application needs a specific version of some other jar.  Various 
> people emphatically did not want an automatic "put everything in the 
> classpath" extension mechanism, because they feel they need to precisely 
> control which version of which jar gets linked in.  I do think we 
> need such an extension mechanism, but it needs to support multiple 
> versions of jars. 
>  
> Using the latest version of a jar does not work.  For example each 
> version of the servlet interfaces has new methods, so classes that 
> implement the interfaces will often only work against a specific 
> version.  (Thank you Sun.) 
>
> So take it as given that we will need to install multiple versions 
> of various jara at the same time.  We can have an "ext" directory 
> that contains symlinks without versions.  E.g. 
> $prefix/java contains PACKAGE-VERSION.jar 
> $prefix/java-ext contains PACKAGE.jar which is s symlink to 
> ../java/PACKAGE-VERSION.jar. 

It seems to me that we need two things:

- an --extpath switch on the compiler (to choose the extension
  directory(s) that should be used

- a jar management tool.


I'm pessimistic that you're going to kill both birds with one stone.


Nic