Why my code is rarely Groovy
I’ve spent over half a year using Groovy as my primary language, and it was a very good experience. The flexibility of Groovy is a joy to anyone coming from the rigid Kingdom of Nouns, and the Grails web framework is excellent, far preferable to the various combinations of Struts/Spring/Hibernate (and others) that I had used with Java. And for a Java developer, the benefits of using the familiar, rock-solid Java infrastructure — libraries, web application servers, and the JVM itself — are significant.
I often found myself wondering why Groovy doesn’t get more interest among Java developers. After all, everyone needs a scripting language for small tasks, why not use one that you practically know already? And just because your production code is Java doesn’t mean you can’t test with Groovy.
But then a funny thing happened.
When I stopped using Groovy as my primary language, I stopped using it completely. I found I preferred to write short scripts in Python. And as for my unit tests, Java+Mockito is more straightforward than testing Java with Groovy.
In the end, Groovy gets no love. I enjoyed working with it, but I don’t look for opportunities to use it. Everyone complains about Java, and yearns for Python, Ruby, Scala, or Clojure, but Groovy is an afterthought. Why?
The first problem with Groovy is that it is a compromise. It is an effort to give Java devs the benefits of Ruby or Python, while appeasing the decision-makers that are concerned with the loss of productivity involved in programmers learning a new paradigm. As a result, there is no romance to Groovy. It’s a good language, and it’s viable for enterprise software, but it isn’t exciting.
This lack of romance is revealed when you consider Groovy’s killer feature: “Java code is almost always valid Groovy code.” That’s as exciting as a sports-car with an automatic transmission. “You can write Groovy without learning anything new!”
The second problem with Groovy is that it feels like a hack. This is best explained by an example. In Java, if a method will throw an Exception it must be declared. Groovy, not wanting to continue Java’s mistakes, does not require this. Nothing new so far, this is the same decision made by C#, Python, Ruby, etc.
But then when you throw an exception from a method, catch it in another method, and try to access your exception, you find that it has been wrapped in a
UndeclaredThrowableException. So you can find the exception you threw by accessing the
cause field of the wrapped exception.
What’s going on? An understanding of Java’s Exception Hierarchy sheds some light here. The
UndeclaredThrowableException is a
RuntimeException, so does not need to be declared. Apparently before Groovy throws an exception, it checks to see if it has been declared. If it hasn’t, and should have been (by Java’s rules) then it is wrapped in an exception that could be thrown anytime in Java.
It all makes perfect Java sense, but it’s a type of circuitous thinking that you needn’t do in Python or Ruby or Java or any language that was designed from scratch. This type of thing occurs on a regular basis, and it just doesn’t make you feel good about Groovy.
The last reason I’m disinclined to use Groovy is that it seems to be applied to a very limited problem domain. Groovy may as well be called GroovyGrails because it’s not really used apart from the Grails web framework. Python, for comparison, is used significantly in scientific and financial computing, in addition to web programming and general purpose scripting. Groovy is not built explicitly for the web, like PHP, but in practice it is used that way, which means less library support for those that leave the well-worn path.
Don’t get the wrong idea. I like Groovy. It was a great idea, and it was well executed, which is more than I can say about a few languages. If I wanted to have a web application created and deployed ASAP, I’d choose Groovy/Grails without hesitation … and without affection.