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"