Groovy, Java 6, and Classpath Wildcards

Java 6 introduced the capability of selecting all jar files in a directory for the classpath rather than having to list every jar file. With Groovy 1.7.1, Groovy caught up with this capability…sort of.

(It is a little odd to me that Groovy had to catch up to this in the first place actually; it seems like Groovy might have addressed this syntactic simplification in the spirit of doing the right thing before Java did.)

Starting with the Java 6 syntax, wilcard support is simply “*” following a directory reference, like “./lib/*”. So when running Groovy you might do this.

groovy -classpath "../batch.jar;../lib/*;." testClasspath

Note that the wildcard needs to be in quotes on Unix or the shell will take over exploding it. This does not work at all on Windows though. Just about anything you try along this line results in:

The syntax of the command is incorrect.

To avoid this error in Windows you must not put anything but the wildcard entry in the classpath and eliminate the quotes. This makes it a very limited solution at best.

groovy -classpath ../lib/* testClasspath

All of these Windows problems tie to the processing of the classpath by startGroovy.bat. While I do not have a solution to that, it seems to be avoidable by setting the CLASSPATH environment variable rather than trying to pass it into the groovy script.

set CLASSPATH=../batch.jar;../lib/*;.
groovy testClasspath

Why You Should Never Set GROOVY_HOME

I have half a dozen books on Groovy and spend much of my time on the Groovy web site, so it was a big surprise to me when I found out that setting the GROOVY_HOME system environment variable is a really bad idea. Everything I ever read said:

1. Install
2. Set GROOVY_HOME
3. Optionally add the Groovy bin directory to your system path

(And actually from my recent thread on the Groovy user email list, this has been modified on the web site to suggest setting GROOVY_HOME is optional, but there is no real indication of what the tradeoffs are.)

If you ever need to run multiple versions of Groovy (as I did recently while in the process of upgrading Groovy to the version used by my upgraded Grails version) having GROOVY_HOME set is a real detriment. As it happens, when you run a script out of the Groovy bin directory it will set GROOVY_HOME based on where the script is that you are running only if GROOVY_HOME is not already set. If you set it and then run Groovy from a different version you are likely to get some classloader error because of the mismatch.

Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/groovy/tools/GroovyStarter
Caused by: java.lang.ClassNotFoundException: org.codehaus.groovy.tools.GroovyStarter
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

So it is only likely to cause you pain if you set GROOVY_HOME, unless you are intentionally trying to run the script of one version with the guts of another, or the internal Groovy mechanism for setting it is misbehaving somehow.