Iâve started in a new job so itâs been some time since the last time wrote a blog entry. The other day I realized that itâs been around three years since I started looking into Groovy. Iâm mostly doing Java programming in my new job so this has been an opportunity for me to take a step back and have a look at Groovy in relation to Java.
 - In no particular order
Excellent support for writing DSLâs!
This makes it perfect for configuration, plumbing, wiring of various kinds. Think of it as the familiar Java builder pattern on steroids.
A meta object protocol and support for compile time AST transformations is the backbone behind these DSLâs.
http://www.slideshare.net/glaforge/practical-groovy-dsl
Gentle learning curve for Java developers
Itâs very easy for Java programmers to get started with Groovy. Almost all Java code is already valid Groovy code so programmers used to writing Java can start out writing what theyâre already used to and slowly start taking advantage of Groovy.
Important: Do note that even despite the familiar syntax, Groovy code often has very different runtime behavior! Groovy puts a lot more thought into picking what implementation to call during method invocation then Java.
http://groovy.codehaus.org/Differences+from+Java
Syntax support for lists and maps
Being able to initialize lists and maps directly saves a lot of boilerplate code. This is part of what makes Groovy particularly suited for writing tests.
Very good Java - Groovy interoperability
Calling back and forth between the two languages is fairly straight forward. This means that you can continue to use the Java libraries you already know and love. Just keep in mind that calling Groovy from Java bypasses the meta-programming protocol.
Support for closures means that you can say a lot more with a lot less code. Code will often be more readable and can enjoy spending more time working on the actual problem instead of pleasing the Java type system.
When Java 8 is released in 2050* Java programmers will also be able to enjoy closures.
* Release date estimated based on previous releases
http://groovy.codehaus.org/Closures
Catching checked exceptions are optional
Groovy doesnât force you to catch checked exceptions!
Groovy extends many JDK classes with new utility methods. One of my personal favorites is probably the âgetTextâ method on File and URL that turns reading a file or a web page into a string a one-liner!
These are the kind of features that actually makes me consider writing one-off scripts in a JVM language!
http://groovy.codehaus.org/groovy-jdk/
Backed by a large company
Spring Source acquired Groovy before being acquired itself by VMware . This is great! Groovy is as far as I know the only dynamic language on the JVM backed by a large company.
This point alone should make it easier to convince your manager that itâs safe to use.
IDE support is getting pretty good
Good IDE support in Eclipse (STS) and Idea. NetBeans has some support, but very slow and outdated unless something has happened since the last time I tried it.
There is a lot of innovation going on in the world of Groovy! Projects like Spock, Grails and Gradle leverages Groovy for many of their innovative features.
People on the mailing lists are very friendly and helpful.Â
 - Not all bad if youâre a pragmatic and disciplined developer
It requires more a lot more discipline
Meta-programming is cool, but makes it more difficult to read the code and write unit tests. Applying lot of magic behavior at runtime can make it very difficult to reason about the system.
Questions like where the **** is this functionality implemented / activated?! has come to mind during code review..
My advice: Try to limit the scope of meta-programming magic to avoid getting into a test / maintenance nightmare. It should be very clear to developers where meta-programming rules apply. Write tests first so you never find yourself implementing something that is a nightmare to test.
Makes it easier to leave dead code in the project
Better IDE support can remedy the situation slightly, but with all the options to go overboard with meta-programming combined with dynamic typing means that they will never be as good as what weâre spoiled with from Java.
This problem grows exponentially with the number of colleagues working on the same project because nobody dares to remove some code that just might be in use.
My advice: Limit the use of global meta-programming and be really disciplined when it comes to making sure that you donât leave dead code behind during re-factoring. Agree on conventions with your team mates and do code reviews / buddy checking.
I see quite a lot of people complaining about this. Personally, I donât look at Groovyâs runtime performance as a problem. My biggest reason for using Groovy is the expressive power, not the performance. The good Groovy-Java interoperability means that itâs very simple to implement hot spots in Java should performance ever turn out to be a problem.
Start-up performance could be better though⌠Groovy does a lot of tricks involving classloaders, call site caching and byte code generation in order to allow the JIT to generate optimized code. This takes a bit of time...
Many larger Groovy projects like Gradle and Grails tries to work around this problem by keeping a daemon process running in the background to work around this.
The groovy-all jar file is closing in on 6mb as Iâm writing this. Adding this dependency to a project is an absolute no-go if all Iâm looking for is closures and a slightly nicer syntax.
Modularization of groovy-all is on the roadmap for Groovy 1.9 2.0. This is something that Iâm really looking forward to, even though having the groovy-all option is very convenient in situations where you just want to script something and canât be bothered to find all the right dependencies.
A modularized Groovy is very high on my wish list!
The web site has been looking quite outdated and unprofessional for quite some time, but theyâve given it a face lift after I started writing on this blog entry! Nice!
The only thing they have to do now is to come up with 10$ for a proper domain :-)
One might say that the looks of the website isnât that important, but an outdated and unprofessional web page can make it a lot harder to convince management that this is a project we should start using!
A bit hard to find documentation
Documentation is spread across various wiki pages, web sites, mailing lists and java-doc. Iâd love to see a more coherent system for documentation - Spring and Grails are good examples.
Update: Like with the web page, this has improved a lot since I started writing this post.
My advice: Buy a book! Not only will it provide you with lots and lots of Groovy knowledge, but youâll also be supporting the project.
 - Things Iâd rather see go awayâŚ
Enormously huge stacktraces!
Stack traces from Java EE applications with Hibernate and deployed on an âenterpriseâ container will look small and readable in comparison. Iâve seen Groovy stack traces several hundred lines long during Grails development.
Groovy will add a lot of small steps in between what looks as simple method invocations to you in order to support meta-programming and various dynamic features.
My advice: Look into options for filtering out at least some of the noise. A disturbingly large part of a Groovy stacktrace is often just noise distracting you from the real problem.
Where Java in my opinion might be a bit too careful about not breaking backwards compatibility, Groovy is not that careful. This probably allows the project to move a lot faster, but growing pain / regressions between releases can be very annoying and frustrating.
Be mentally prepared to deal with and learn about various problems and bugs related to garbage collection, perm-gen and classloaders. I hope that some of these issues will go away when they start taking advantage of JSR 232 (invoke dynamic).
Even though I'm not using Groovy in my day-to-day programming I'm still very fond of the project and try to keep up with what's moving in the community. I do hope that they're able to remain relevant as more of Groovy's selling point features are becoming available in Java.
If you're considering adopting Groovy in your project I'd recommend starting out slowly, perhaps by writing some of your tests in Groovy and Spock instead of Java and Junit.
As you're familiarizing yourself with the language and get a better understanding of its runtime behavior you can start writing isolated parts of the production code in Groovy.