[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> If you do bundle getopt into sablecc jar, please change the class
It would be technically possible, but quite awkward to do, I guess.
> sablecc is used with other code which also uses getopt and
> may want a different version.
The problem is not when you are running jars using java -jar xxx.jar
command, the problem is when you have to use it all from a call like:
java -cp getopt1.jar:getopt2.jar:sablecc.jar:yourstuff.jar
To solve that, using different names (awkward), or using custom class
loaders (the clean way to go I guess) is the only solution (**).
> It really is no trouble to ship 2 jars. You just
> list the getopt jar in a manifest header of the sablecc jar.
> ClassPath: getopt.jar
> See the "m" option to "jar" to support custom manifests
> (or ant "manifest" parameter).
> The java class loader does all the work. You need never mention
> getopt.jar in any of your startup scripts or user CLASSPATH so all
> existing clients will need no script changes, and the dependency is
> clearly stated in just one place (albeit invisible to most people!).
Unfortunatelly it will not solve (**). If we follow the suggestion, and
the user is using CLASSPATH and call org.sablecc.sablecc.SableCC instead
of using java -jar sablecc.jar call, he is in trouble, if he needs to mix
two versions of getopt library anyway (no matter what you have in your
manifest). From the other hand, if the user is using sablecc like in
java -jar sablecc.jar, there is no need for anything special, because the
only thing running in this particular JVM is sablecc anyway.
So, to sum up:
1) for calls like java -jar sablecc.jar, there is no problem with the
current solution, because sablecc is in charge, uses its own boundled
getopt and all is sweet.
2) for calls like: java -jar yourstaff.jar put inside your manifest
your own getop reference first, then use sablecc.jar. I believe it will
just work - I think on the JVM I am using the classloader uses classes
from the jar first, if referenced from the same jar. We found it quite not
nice as it does not allow you to "upgrade" classes just by reordering the
jars, if the classes in question are boundled with a particular jar.
3) for calls using CLASSPATH, and mixing two versions of getopt, the user
is in trouble anyway, and yes, it could be solved by changing the
package/class names, but I do no know we should do it though - I think the
system which uses such combination should make use of custom classloaders
solving it transparently for the libraries. Any other opinions?