November 17th, 2011

By Stoyan Rachev

In the afternoon of Devoxx Day 2, the new language parade continued with Andres Almiray’s overview of The Groovy Ecosystem.

Unlike Scala, I have some previous experience with Groovy. I studied the language earlier this year and was really impressed by its richness and expressive power. You could think of it as “Java on steroids” or as “Scala with a Java-compatible syntax”. On the downside, in my experience its dynamic typing, Eclipse support and performance were not that great. At the time, I thought Groovy might still be ideal for internal use, in any case much better than ant, batch files, or other scripting languages we use so far in this area.

The session abstract says that “Groovy is the fastest growing JVM language out there. It might be because it is so easy for Java developers to pick it up, but also because there’s an increasing number of projects and libraries that make use of Groovy as the starting point.”

Instead of presenting language or framework concepts on slides, Andres showed just a single slide per framework, and moved straight into coding to demo their features. Most of the demos went flawlessly and were quite impressive. You could check the slides here.


Grails is a popular Web application framework similar to Ruby on Rails. It builds on top of Spring and Hibernate and has more than 600 plugins available. In a few minutes, with the help of few console commands and a text editor (no IDE), a new “Book / Author” application was born and then enhanced by adding custom actions, views, and even tags. One could use the built-in Grails console as an interactive playground to test various dynamic methods (added by the framework), or other behavior of the application. Finally, it could be further enhanced by adding more plugins, and even by creating a custom plugin, all with very little effort.


Griffon is another framework that brings the power of Grails to desktop applications. It also has a very rich plugin ecosystem, and is “polyglot aware”. Using Griffon is very similar to using Grails, just the grails command is replaced with griffon. Swing or SWT components can be created and wired with a special DSL, instead of custom code. The same Griffon application can be started as a standalone app, as an applet, or with Java Web Start by just using a different command for launching it. Properties of UI controls can be easily bound to other properties or the model with very little code. With a simple annotation one could control if the controller code runs in the same or in a different thread than the UI (event dispatcher) thread.

There are also archetypes that allow you to bootstrap applications in a different way. In the demo, one of the built-in archetypes was used to create an application with a predefined set of models, views, and controllers and a richer set of features. Griffon also has a very lightweight event bus. With it, you can publish an event and then listen to that event following a simple convention, in the same or different threads.

What if you are not allowed Groovy, but forced to use Java? You could still use Griffon by specifying the correct “file type” and “archetype” when creating your application, which creates Java code instead. If a certain plugin is installed, Groovy annotations such as @Bindable could be used as well. The Java version took a few rounds to compile correctly since the speaker didn’t use an IDE. As one might expect, it had twice the amount of lines of code compared to the Groovy application.

With Griffon, you can package your applications as a zip file, or as a different distribution type (dmg, izpack, rpm, …) with the help of the installer-plugin.


Gaelyk lets you access Google App Engine (GAE) services by lightweight abstractions. According to Andres, it is “the PHP for GAE”. It also has an emergent plugin system.

Gradle and Gant

Gradle is a better way to build. This is a Groovy DSL for building projects, which harnesses the power of Maven conventions. It is actually similar and compatible with Maven, just much less verbose. If the conventions are followed, a simple application can have a build script which contains just a single line of code. In the demo, this simple build finished in 6 seconds the first time and much faster after that, because Gradle is smart enough not to repeat the steps that are not needed. If conventions are not followed, Gradle still gives you the full power to configure what you may need. Unlike Maven, it uses a very clear and concise syntax, typical for Groovy DSLs. Multi-projects in Gradle are also much easier than in Ant or Maven. Just by calling install, Gradle generates pom files and install the artifacts in the local Maven repository.

Gant is a “groovier” version of Ant – take away the XML and substitute it with a real scripting language. Although both Grails and Griffon still use Gant, it’s now somehow fading away because of Gradle.

Easyb and Spock

Easyb enables Behavior-Driven Development (BDD) for Groovy and Java. Some claim that BDD is TDD done right. When doing BDD, you define expectations from your customer’s point of view, write it in a natural language, and finally sprinkle some code inside. With Easyb, you could test both Java and Groovy code. It follows the usual BDD “given / when / then” syntax for defining stories and scenarios.

Spock is a testing DSL similar to RSpec. It hijacks the Groovy syntax to create something really “funky” using features that are available in the JVM, but not really exposed in programming languages. Did you know that you could have method names that are strings? With a simple @Unroll annotation, one could have a single method test multiple inputs, which is “unrolled” into multiple tests. Good bye @RunWith(Parameterized.class).

More …

CodeNarc is Groovy’s version of FindBugs and PMD. It enables static code analysis for Groovy code, and has plugins for Grails, Griffon, and Gradle. Andres showed how to add the plugin to Gradle and analyze the Groovy code with it. You could define what rules you want to apply using either XML or a Groovy-based DSL.

Concurrency is a new hotness. GPars brings concurrency management abstractions and facilities to Groovy, including actors, dataflow, and fork / join.

Ratpack is a clone of Sinatra for Groovy. It’s a nice way to create REST-based API for a command line tool.

GContracts provides “contract-oriented development”, which allows you to define pre-conditions and post-conditions to methods in the form of annotations (@Requires and @Ensures). This should not be seen as an alternative for testing or semantic validation.

Groovy++ is an attempt to make certain extensions to the Groovy language such as static compilations, traits (similar to Scala), immutable data structures, etc.


It seems that not only the Groovy language has all the features you may not see in Java in the next 10 years, but also that those Groovy guys have built up frameworks comparable (and to a large extent compatible) with whatever is in the Java SE / EE space, just much easier to use. And despite that they are built as open source by different people, they are still amazingly consistent. How did they manage to do all of that without JCP?

One Response to “ Devoxx 2011: The Groovy Ecosystem ”

  1. […] Almiary stellte Neues aus dem Groovy ?kosystem (Slides, Blog) vor, insbesondere die Vielfalt im Griffon Umfeld war mir in diesem Ausma? nicht bewusst: ?ber […]

Leave a Reply


one × = 4