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.

Advertisement