Code and comments

Practical and theoretical aspects of software development

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.


Written by Eric Wilson

September 13, 2011 at 12:26 pm

Posted in commentary

Tagged with , ,

6 Responses

Subscribe to comments with RSS.

  1. Good thoughts.

    As another data point. I’ve been back in the Java world for 3 months and (surprisingly) have had little inclination to use Groovy. So anecdotally you may be onto something.

    However I think you underestimate the appeal outside the web space. It seems to be filling a niche as a scripting language for JVM based tools e.g. Jenkins.

    Rob Conaway

    September 13, 2011 at 7:04 pm

  2. Others have put it better than I can…
    “More than anything, I believe Groovy missed its window of opportunity. It is a solid scripting language with decent job growth trends, but how can it differentiate itself from Ruby, Python, Erlang and Scala?”
    “However, Groovy was written ‘to target’ Java programmers — it is the dynamic language Sun should have built for the JVM as dynamic languages gained popularity and the Java language stagnated.”

    Groovy has been around since 2003ish, Sun should have jumped on it then. It will probably survive, like you stated, due to Grails… and Grails will likely survive/grow due to its ability to be deployed to nearly every jvm app server released in the past 6-7 years.

    krsmes (@krsmes)

    September 13, 2011 at 8:31 pm

  3. Nice follow up to ur original question on the stackoverflow. I have been using groovy n grails for 6 months. Some ups and down but my impression is that the groovy ecosystem is getting better and better. You have now very good testing framework like Spock, browser automation (geb), task/dependency solution like gradle and now a groovy env manager called gvm. I think it’s quite exiting to see all of these projects enriching the groovy world.


    January 15, 2013 at 12:27 pm

  4. I have recently started using Grails and I am fairly impressed with both Groovy and Grails. Groovy is a very good dynamic foundation to Grails and both are fairly powerful. Certainly allows much higher productivity than Java/JPA/Hibernate/EJB/Spring alone.


    November 27, 2013 at 7:37 am

  5. It appears that groovy’s popularity is significantly increasing.


    December 3, 2013 at 10:35 pm

  6. I do agree with what you said. I work for a product that supports Groovy scripting and I sometimes need to write some code in Groovy ( I understand why the creators of the product chose Groovy over other scripting languages, the very reason that you specified in your post). But for other purposes, I generally use Bash or Python or even Perl.

    Subhadip Ghosh

    January 12, 2017 at 7:56 am

Comments are closed.

%d bloggers like this: