Re: java-getopt

[Christopher William Turner <cwturner@cycom.co.uk>]

Hi Mariusz,

We are agreed that if sablecc uses getopt and mystuff
uses sablecc and getopt2 then
life is hard if getopt2 is not backward compatible with getopt.

I don't think we need to solve that rare case immediately.
Concentrating on the more common case of getopt2 is compatible with
getopt, I still think that multiple jars are "better" than putting
everything in 1 jar. A disadvantage of the 1 jar approach is the lack of
transparency
about which jar exports the published component getopt interface to
client programs
(unless you rename the classes or package to hide the interface).

My suggestion of using manifest "Class-Path:" was just to avoid forcing
existing users from having to edit their CLASSPATHS.

Add a manifest entry in sablecc.jar of:-

Class-Path: getopt.jar

To upgrade, simply overwrite getopt.jar with getopt2.jar (keeping file
name same).
or delete getopt.jar and add getopt2.jar to CLASSPATH,
or edit manifest of sablecc.jar, (to Class-Path: getopt2.jar),
or edit manifest of mystuff.jar (to Class-Path: getopt2.jar
sablecc.jar).

I have investigated that manifest Class-Path is used regardless of
invoking method, so these should all work:-

java -jar sablecc.jar
java -cp sablecc.jar org.sablecc.MainEntry
java -cp mystuff.jar com.mystuff.MainEntry

or even
export CLASSPATH=mystuff.jar
java com.mystuff.MainEntry

I just can't see any extra operational benefit of bundling getopt inside
the sablecc.jar.

I attach a small (6Kb) jar of my test sources.

P.S. Java Web Start (JNLP standards) has many auto-upgrade, library
version pattern matching rules etc already, so maybe the hard
versioning problems will be solved by Java Web Start.


-- 
Christopher William Turner, http://www.cycom.co.uk/ "Serving fine Java
since 1996"

classpathdemo.jar