Your opinion matters! Please fill in the InfoQ Survey!

What's New in Groovy 1.6

| Posted by Guillaume LaForge Follow 0 Followers on Feb 27, 2009. Estimated reading time: 34 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Groovy is a very successful and powerful dynamic language for the Java Virtual Machine that provides seamless integration with Java, and has its roots firmly planted in Java itself for the syntax and APIs and other languages such as Smalltalk, Python or Ruby for its dynamic capabilities.

Groovy is used in many Open Source projects such as Grails, Spring, JBoss Seam and more, as well as integrated in commercial products and Fortune 500 mission-critical applications for its scripting capabilities offering a nice extension mechanism to these applications, or for its ability to let subject matter experts and developers author embedded Domain-Specific Languages to express business concepts in a readable and maintainable fashion.

In this article, Guillaume Laforge, Groovy Project Manager and Head of Groovy Development at SpringSource, will go through an overview of the novelties offered by the newly released Groovy 1.6.

Overview of Groovy 1.6

As we shall see in this article, the main highlights of this Groovy 1.6 release are:

  • Greater compile-time and runtime performance improvements
  • Multiple assignments
  • Optional return in if/else and try/catch blocks
  • Java 5 annotation definition
  • AST transformations and all the provided transformation annotations like @Singleton, @Lazy, @Immutable, @Delegate and friends
  • The Grape module and dependency system and its @Grab transformation
  • Various Swing builder improvements, thanks to the Swing / Griffon team, as well as several Swing console improvements
  • The integration of JMX builder
  • Various metaprogramming improvements, like the EMC DSL, per-instance metaclasses even for POJOs, and runtime mixins
  • JSR-223 scripting engine built-in
  • Out-of-the-box OSGi readiness

All those improvements and new features serve one goal: helping developers be more productive and more agile, by:

  • Focusing more on the task at hand than on boiler-plate technical code
  • Leveraging existing Enterprise APIs rather than reinventing the wheel
  • Improving the overal performance and quality of the language
  • Enabling developers to customize the language at will to derive their own Domain-Specific Languages

But beyond all these important aspects, Groovy is not just a language, it's a whole ecosystem.

The improvements in Groovy's generated bytecode information helps capable tools coverage like Cobertura and its Groovy support, or pave the way for new utilities like CodeNarc for static code analysis for Groovy.

The malleability of the syntax of the language and its metaprogramming capabilities give birth to advanced testing tools such as the Easyb Behavior-Driven-Development project, the GMock mocking library or the Spock testing and specification framework.

Again, Groovy's flexibility and expressivity and its scripting capabilities open the doors to advanced build scripting or infrastructure systems for your continuous integration practices and project build solutions, such as Gant and Graddle.

At the tooling level, Groovy also progresses, for instance with its groovydoc Ant task to let you generate proper JavaDoc covering, documenting and interlinking both your Groovy and Java source files for your Groovy/Java mixed projects.

And at the same time, IDE makers improve their support for Groovy, by giving users powerful weapons such as cross-language code refactoring, profound understanding of dynamic language idioms, code completion, and more, to make developers productive when using Groovy in their projects.

Now, armed with this knowledge of the Groovy world, it's time to dive into the novelties of Groovy 1.6!

Performance improvements

A lot of care has been taken to improve both the compile-time and runtime performance of Groovy, compared to previous releases.

The compiler is 3 to 5 times faster than in previous releases. This improvement has also been backported in the 1.5.x branch, so that both the old maintenance branch and the current stable branch benefit from this work. Thanks to class lookup caches, the bigger the project, the faster the compilation will be.

However, the most noticeable changes will be in the general runtime performance improvements of Groovy. We used several benchmarks from the Great Language Shootout to measure our progress. On those we selected, compared to the old Groovy 1.5.x line, the performance improvements ranged from 150% to 460%. Micro-benchmarks obviously rarely reflect the kind of code you have in your own projects, but the overal performance of your projects should improve significantly.

Multiple assignments

In Groovy 1.6, there is only one syntax addition for being able to define and assign several variables at once:

def (a, b) = [1, 2]

assert a == 1
assert b == 2

A more meaninful example may be methods returning longitute and latitude coordinates. If these coordinates are represented as a list of two elements, you can easily get back to each element as follows:

def geocode(String location) {
    // implementation returns [48.824068, 2.531733] for Paris, France

def (lat, long) = geocode("Paris, France")

assert lat == 48.824068
assert long == 2.531733

And you can also define the types of the variables in one shot as follows:

def (int i, String s) = [1, 'Groovy']

assert i == 1
assert s == 'Groovy'

For the assignment (with prior definition of the variables), just omit the def keyword:

def firstname, lastname

(firstname, lastname) = "Guillaume Laforge".tokenize()

assert firstname == "Guillaume"
assert lastname == "Laforge"

If the list on the right-hand side contains more elements than the number of variables on the left-hand side, only the first elements will be assigned in order into the variables. Also, when there are less elements than variables, the extra variables will be assigned null.

So for the case with more variables than list elements, here, c will be null:

def elements = [1, 2]
def (a, b, c) = elements

assert a == 1
assert b == 2
assert c == null

Whereas in the case where there are more list elements than variables, we'll get the following expectations:

def elements = [1, 2, 3, 4]
def (a, b, c) = elements

assert a == 1
assert b == 2
assert c == 3

For the curious minds, supporting multiple assignments also means we can do the standard school swap case in one line:

// given those two variables
def a = 1, b = 2

// swap variables with a list
(a, b) = [b, a]

assert a == 2
assert b == 1

Annotation definition

Actually, when I said that multiple assignments were the sole syntax addition, it's not entirely true. Groovy supported the syntax for annotation definition even in Groovy 1.5, but we had not implemented the feature completely. Fortunately, this is now fixed, and it wraps up all the Java 5 features supported by Groovy, such as static imports, generics, annotations, and enums, making Groovy the sole alternative dynamic language for the JVM supporting all those Java 5 features, which is critical for a seamless Java integration story, and for the usage in Enterprise frameworks relying on annotations, generics and more, like JPA, EJB3, Spring, TestNG, etc.

Optional return for if/else and try/catch/finally blocks

It is now possible for if/else and try/catch/finally blocks to return a value when they are the last expression in a method or a closure. No need to explicitly use the return keyword inside these constructs, as long as they are the latest expression in the block of code.

As an example, the following method will return 1, although the return keyword was omitted.

def method() {
    if (true) 1 else 0

assert method() == 1

For try/catch/finally blocks, the last expression evaluated is the one being returned. If an exception is thrown in the try block, the last expression in the catch block is returned instead. Note that finally blocks don't return any value.

def method(bool) {
    try {
        if (bool) throw new Exception("foo")
    } catch(e) {
    } finally {

assert method(false) == 1
assert method(true) == 2

AST Transformations

Although at times, it may sound like a good idea to extend the syntax of Groovy to implement new features (like this is the case for instance for multiple assignments), most of the time, we can't just add a new keyword to the grammar, or create some new syntax construct to represent a new concept. However, with the idea of AST (Abstract Syntax Tree) Transformations, we are able to tackle new and innovative ideas without necessary grammar changes.

When the Groovy compiler compiles Groovy scripts and classes, at some point in the process, the source code will end up being represented in memory in the form of a Concrete Syntax Tree, then transformed into an Abstract Syntax Tree. The purpose of AST Transformations is to let developers hook into the compilation process to be able to modify the AST before it is turned into bytecode that will be run by the JVM.

AST Transformations provides Groovy with improved compile-time metaprogramming capabilities allowing powerful flexibility at the language level, without a runtime performance penalty.

There are two kinds of transformations: global and local transformations.

  • Global transformations are applied to by the compiler on the code being compiled, wherever the transformation apply. A JAR added to the classpath of the compiler should contain a service locator file at META-INF/services/org.codehaus.groovy.transform.ASTTransformation with a line with the name of the transformation class. The transformation class must have a no-args constructor and implement the org.codehaus.groovy.transform.ASTTransformation interface. It will be run against every source in the compilation, so be sure to not create transformations which scan all the AST in an expansive and time-consuming manner, to keep the compiler fast.
  • Local transformations are transformations applied locally by annotating code elements you want to transform. For this, we reuse the annotation notation, and those annotations should implement org.codehaus.groovy.transform.ASTTransformation. The compiler will discover them and apply the transformation on these code elements.


Groovy 1.6 provides several local transformation annotations, in the Groovy Swing Builder for data binding (@Bindable and @Vetoable), in the Grape module system for adding script library dependencies (@Grab), or as general language features without requiring any syntax change to support them (@Singleton, @Immutable, @Delegate, @Lazy, @Newify, @Category, @Mixin and @PackageScope). Let's have a look at some of these transformations (@Bindable and @Vetoable will be covered in the section related to the Swing enhancements, and @Grab in the section about Grape).


Whether the singleton is pattern or an anti-pattern, there are still some cases where we need to create singletons. We're used to create a private constructor, a getInstance() method for a static field or even an initialized public static final field. So instead of writing code like this in Java:

public class T {
    public static final T instance = new T();
    private T() {}

You just need to annotate your type with the @Singleton annotation:

@Singleton class T {}

The singleton instance can then simply be accessed with T.instance (direct public field access).

You can also have the lazy loading approach with an additional annotation parameter:

@Singleton(lazy = true) class T {}

Would become more or less equivalent to this Groovy class:

class T {
    private static volatile T instance
    private T() {}
    static T getInstance () {
        if (instance) {
        } else {
            synchronized(T) {
                if (instance) {
                } else {
                    instance = new T ()

Lazy or not, once again, to access the instance, simply do T.instance (property access, shorcut for T.getInstance()).


Immutable objects are ones which don't change after initial creation. Such objects are frequently desirable because they are simple and can be safely shared even in multi-threading contexts. This makes them great for functional and concurrent scenarios. The rules for creating such objects are well-known:

  • No mutators (methods that modify internal state)
  • Class must be final
  • Fields must be private and final
  • Defensive copying of mutable components
  • equals(), hashCode() and toString() must be implemented in terms of the fields if you want to compare your objects or use them as keys in e.g. maps

Instead of writing a very long Java or Groovy class mimicking this immutability behavior, Groovy lets you just write an immutable class as follow:


@Immutable final class Coordinates {
    Double latitude, longitude

def c1 = new Coordinates(latitude: 48.824068, longitude: 2.531733)
def c2 = new Coordinates(48.824068, 2.531733)

assert c1 == c2

All the boiler-plate code is generated at compile-time for you! The example shows that to instantiate such immutable coordinates, you can use one of the two constructors created by the transformation, one taking a map whose keys are the properties to set to the values associated with those keys, and the other taking the values of the properties as parameters. The assert also shows that equals() was implemented and allows us to properly compare such immutable objects.

You can have a look at the details of the implementation of this transformation. For the record, the Groovy example above using the @Immutable transformation is over 50 lines of equivalent Java code.


Another transformation is @Lazy. Sometimes, you want to handle the initialization of a field of your clas lazily, so that its value is computed only on first use, often because it may be time-consuming or memory-expensive to create. The usual approach is to customize the getter of said field, so that it takes care of the initialization when the getter is called the first time. But in Groovy 1.6, you can now use the @Lazy annotation for that purpose:

class Person {
    @Lazy pets = ['Cat', 'Dog', 'Bird']

def p = new Person()
assert !(p.dump().contains('Cat'))

assert p.pets.size() == 3
assert p.dump().contains('Cat')

In the case of complex computation for initializing the field, you may need to call some method for doing the work, instead of a value like our pets list. This is then possible to have the lazy evaluation being done by a closure call, as the following example shows:

class Person {
    @Lazy List pets = { /* complex computation here */ }()

There is also an option for leveraging Soft references for garbage collection friendliness for expensive data structures that may be contained by such lazy fields:

class Person {
    @Lazy(soft = true) List pets = ['Cat', 'Dog', 'Bird']

def p = new Person()
assert p.pets.contains('Cat')

The internal field created by the compiler for pets will actually be a Soft reference, but accessing p.pets directly will return the value (ie. the list of pets) held by that reference, making the use of the soft reference transparent to the user of that class.


Java doesn't provide any built-in delegation mechanism, and so far Groovy didn't either. But with the @Delegate transformation, a class field or property can be annotated and become an object to which method calls are delegated. In the following example, an Event class has a date delegate, and the compiler will delegate all of Date's methods invoked on the Event class to the Date delegate. As shown in the latest assert, the Event class has got a before(Date) method, and all of Date's methods.

import java.text.SimpleDateFormat

class Event {
    @Delegate Date when
    String title, url

def df = new SimpleDateFormat("yyyy/MM/dd")

def gr8conf = new Event(title: "GR8 Conference",
                          url: "",
                         when: df.parse("2009/05/18"))
def javaOne = new Event(title: "JavaOne",
                          url: "",
                         when: df.parse("2009/06/02"))

assert gr8conf.before(javaOne.when)

The Groovy compiler adds all of Date's methods to the Event class, and those methods simply delegate the call to the Date field. If the delegate is not a final class, it is even possible to make the Event class a subclass of Date simply by extending Date, as shown below. No need to implement the delegation ourselves by adding each and every Date methods to our Event class, since the compiler is friendly-enough with us to do the job itself.

class Event extends Date {
    @Delegate Date when
    String title, url

In the case you are delegating to an interface, however, you don't even need to explictely say you implement the interface of the delegate. The @Delegate transformation will take care of this and implement that interface. So the instances of your class will automatically be instanceof the delegate's interface.

import java.util.concurrent.locks.*

class LockableList {
    @Delegate private List list = []
    @Delegate private Lock lock = new ReentrantLock()

def list = new LockableList()

try {
    list << 'Groovy'
    list << 'Grails'
    list << 'Griffon'
} finally {

assert list.size() == 3
assert list instanceof Lock
assert list instanceof List

In this example, our LockableList is now a composite of a list and a lock and is instanceof of List and Lock. However, if you didn't intend your class to be implementing these interfaces, you would still be able to do so by specifying a parameter on the annotation:

@Delegate(interfaces = false) private List list = []


The @Newify transformation proposes two new ways of instantiating classes. The first one is providing Ruby like approach to creating instances with a new() class method:

@Newify rubyLikeNew() {
    assert == 42


But it is also possible to follow the Python approach with omitting the new keyword. Imagine the following tree creation:

class Tree {
    def elements
    Tree(Object... elements) { this.elements = elements as List }

class Leaf {
    def value
    Leaf(value) { this.value = value }

def buildTree() {
    new Tree(new Tree(new Leaf(1), new Leaf(2)), new Leaf(3))


The creation of the tree is not very readable because of all those new keywords spread across the line. The Ruby approach wouldn't be more readable, since a new() method call for creating each element is needed. But by using @Newify, we can improve our tree building slightly to make it easier on the eye:

@Newify([Tree, Leaf]) buildTree() {
    Tree(Tree(Leaf(1), Leaf(2)), Leaf(3))

You'll also notice that we just allowed Tree and Leaf to be newified. By default, under the scope which is annotated, all instantiations are newified, but you can limit the reach by specifying the classes you're interested in. Also, note that for our example, perhaps a Groovy builder may have been more appropriate, since its purpose is to indeed create any kind of hierarchical / tree strucutre.

If we take another look at our coordinates example from a few sections earlier, using both @Immutable and @Newify can be interesting for creating a path with a concise but type-safe manner:

@Immutable final class Coordinates {
    Double latitude, longitude

@Immutable final class Path {
    Coordinates[] coordinates

@Newify([Coordinates, Path])
def build() {
        Coordinates(48.824068, 2.531733),
        Coordinates(48.857840, 2.347212),
        Coordinates(48.858429, 2.342622)

assert build().coordinates.size() == 3

A closing remark here: since a Path(Coordinates[] coordinates) was generated, we can use that constructor in a varargs way in Groovy, just as if it had been defined as Path(Coordinates... coordinates).

@Category and @Mixin

If you've been using Groovy for a while, you're certainly familiar with the concept of Categories. It's a mechanism to extend existing types (even final classes from the JDK or third-party libraries), to add new methods to them. This is also a technique which can be used when writing Domain-Specific Languages. Let's consider the example below:

final class Distance {
    def number
    String toString() { "${number}m" }

class NumberCategory {
    static Distance getMeters(Number self) {
        new Distance(number: self)

use(NumberCategory) {
    def dist = 300.meters

    assert dist instanceof Distance
    assert dist.toString() == "300m"

We have a simplistic and fictive Distance class which may have been provided by a third-party, who had the bad idea of making the class final so that nobody could ever extend it in any way. But thanks to a Groovy Category, we are able to decorate the Distance type with additional methods. Here, we're going to add a getMeters() method to numbers, by actually decorating the Number type. By adding a getter to a number, you're able to reference it using the nice property syntax of Groovy. So instead of writing 300.getMeters(), you're able to write 300.meters.

The downside of this category system and notation is that to add instance methods to other types, you have to create static methods, and furthermore, there's a first argument which represents the instance of the type we're working on. The other arguments are the normal arguments the method will take as parameters. So it may be a bit less intuitive than a normal method definition we would have added to Distance, should we have had access to its source code for enhancing it. Here comes the @Category annotation, which transforms a class with instance methods into a Groovy category:

class NumberCategory {
    Distance getMeters() {
        new Distance(number: this)

No need for declaring the methods static, and the this you use here is actually the number on which the category will apply, it's not the real this of the category instance should we create one. Then to use the category, you can continue to use the use(Category) {} construct. What you'll notice however is that these kind of categories only apply to one single type at a time, unlike classical categories which can be applied to any number of types.

Now, pair @Category extensions to the @Mixin transformation, and you can mix in various behavior in a class, with an approach similar to multiple inheritance:

@Category(Vehicle) class FlyingAbility {
    def fly() { "I'm the ${name} and I fly!" }

@Category(Vehicle) class DivingAbility {
    def dive() { "I'm the ${name} and I dive!" }

interface Vehicle {
    String getName()

class Submarine implements Vehicle {
    String getName() { "Yellow Submarine" }

class Plane implements Vehicle {
    String getName() { "Concorde" }

@Mixin([DivingAbility, FlyingAbility])
class JamesBondVehicle implements Vehicle {
    String getName() { "James Bond's vehicle" }

assert new Plane().fly() ==
       "I'm the Concorde and I fly!"
assert new Submarine().dive() ==
       "I'm the Yellow Submarine and I dive!"

assert new JamesBondVehicle().fly() ==
       "I'm the James Bond's vehicle and I fly!"
assert new JamesBondVehicle().dive() ==
       "I'm the James Bond's vehicle and I dive!"

You don't inherit from various interfaces and inject the same behavior in each subclass, instead you mixin the categories into your class. Here, our marvelous James Bond vehicle gets the flying and diving capabilities through mixins.

An important point to make here is that unlike @Delegate which can inject interfaces into the class in which the delegate is declared, @Mixin just does runtime mixing — as we shall see in the metaprogramming enhancements further down in this article.


Groovy's convention for properties is that any field without any visibility modifier is exposed as a property, with a getter and a setter transparently generated for you. For instance, this Person class exposes a getter getName() and a setter setName() for a private name field:

class Person {
    String name

Which is equivalent to this Java class:

public class Person {
    private String name;
    public String getName() { return name; }
    public void setName(name) { = name; }

That said, this approach has one drawback in that you don't have the possibility to define a field with package-scope visibility. To be able to expose a field with package-scope visibility, you can now annotate your field with the @PackageScope annotation.

Grape, the Groovy Adaptable / Advanced Packaging Engine

To continue our overview of the AST transformations, we'll now learn more about Grape, a mechanism to add and leverage dependencies in your Groovy scripts. Groovy scripts can require certain libraries: by explicitly saying so in your script with the @Grab transformation or with the Grape.grab() method call, the runtime will find the needed JARs for you. With Grape, you can easily distribute scripts without their dependencies, and have them downloaded on first use of your script and cached. Under the hood, Grape uses Ivy and Maven repositories containing the libraries you may need in your scripts.

Imagine you want to get the links of all the PDF documents referenced by the Java 5 documentation. You want to parse the HTML page as if it were an XML-compliant document (which it is not) with the Groovy XmlParser, so you can use the TagSoup SAX-compliant parser which transforms HTML into well-formed valid XML. You don't even have to mess up with your classpath when running your script, just grab the TagSoup library through Grape:

import org.ccil.cowan.tagsoup.Parser

// find the PDF links in the Java 1.5.0 documentation
@Grab(group='org.ccil.cowan.tagsoup', module='tagsoup', version='0.9.7')
def getHtml() {
    def tagsoupParser = new Parser()
    def parser = new XmlParser(tagsoupParser)

html.body.'**'.a.@href.grep(~/.*\.pdf/).each{ println it }

For the pleasure of giving another example: let's use the Jetty servlet container to expose Groovy templates in a few lines of code:

import org.mortbay.jetty.Server
import org.mortbay.jetty.servlet.*
import groovy.servlet.*

@Grab(group = 'org.mortbay.jetty', module = 'jetty-embedded', version = '6.1.0')
def runServer(duration) {
    def server = new Server(8080)
    def context = new Context(server, "/", Context.SESSIONS);
    context.resourceBase = "."
    context.addServlet(TemplateServlet, "*.gsp")
    sleep duration


Grape will download Jetty and its dependencies on first launch of this script, and cache them. We're creating a new Jetty Server on port 8080, then expose Groovy's TemplateServlet at the root of the context — Groovy comes with its own powerful template engine mechanism. We start the server and let it run for a certain duration. Each time someone will hit http://localhost:8080/somepage.gsp, it will display the somepage.gsp template to the user — those template pages should be situated in the same directory as this server script.

Grape can also be used as a method call instead of as an annotation. You can also install, list, resolve dependencies from the command-line using the grape command. For more information on Grape, please refer to the documentation.

Swing builder improvements

To wrap up our overview of AST transformations, let's finish by speaking about two transformations very useful to Swing developers: @Bindable and @Vetoable. When creating Swing UIs, you're often interested in monitoring the changes of value of certain UI elements. For this purpose, the usual approach is to use JavaBeans PropertyChangeListeners to be notified when the value of a class field changes. You then end up writing this very common boiler-plate code in your Java beans:

import java.beans.PropertyChangeSupport;
import java.beans.PropertyChangeListener;

public class MyBean {
    private String prop;

    PropertyChangeSupport pcs = new PropertyChangeSupport(this);

    public void addPropertyChangeListener(PropertyChangeListener l) {

    public void removePropertyChangeListener(PropertyChangeListener l) {

    public String getProp() {
        return prop;

    public void setProp(String prop) {
        pcs.firePropertyChanged("prop", this.prop, this.prop = prop);


Fortunately, with Groovy and the @Bindable annotation, this code can be greatly simplified:

class MyBean {
    @Bindable String prop

Now pair that with Groovy's Swing builder new bind() method, define a text field and bind its value to a property of your data model:

textField text: bind(source: myBeanInstance, sourceProperty: 'prop')

Or even:

textField text: bind { myBeanInstance.prop }

The binding also works with simple expressions in the closure, for instance something like this is possible too:

bean location: bind { pos.x + ', ' + pos.y }

You may also be interested in having a look at ObservableMap and ObservableList, for a similar mechanism on maps and lists.

Along with @Bindable, there's also a @Vetoable transformation for when you need to be able to veto some property change. Let's consider a Trompetist class, where the performer's name is not allowed to contain the letter 'z':

import java.beans.*
import groovy.beans.Vetoable

class Trumpetist {
    @Vetoable String name

def me = new Trumpetist()
me.vetoableChange = { PropertyChangeEvent pce ->
    if (pce.newValue.contains('z'))
        throw new PropertyVetoException("The letter 'z' is not allowed in a name", pce)
} = "Louis Armstrong"

try { = "Dizzy Gillespie"
    assert false: "You should not be able to set a name with letter 'z' in it."
} catch (PropertyVetoException pve) {
    assert true

Looking at a more thorough Swing builder example with binding:

import groovy.swing.SwingBuilder
import groovy.beans.Bindable
import static javax.swing.JFrame.EXIT_ON_CLOSE

class TextModel {
    @Bindable String text

def textModel = new TextModel() {
    frame( title: 'Binding Example (Groovy)', size: [240,100], show: true,
          locationRelativeTo: null, defaultCloseOperation: EXIT_ON_CLOSE ) {
        gridLayout cols: 1, rows: 2
        textField id: 'textField'
        bean textModel, text: bind{ textField.text }
        label text: bind{ textModel.text }

Running this script shows up the frame below with a text field and a lable below, and the label's text is bound on the text field's content.

@Bindable Swing builder demo

SwingBuilder has evolved so nicely in the past year that the Groovy Swing team decided to launch a new project based on it, and on the Grails foundations: project Griffon was born. Griffon proposes to bring the Convention over Configuration paradigm of Grails, as well as all its project structure, plugin system, gant scripting capabilities, etc.

If you are developing Swing rich clients, make sure to have a look at Griffon.

Swing console improvements

Swinging along the topic of UIs, the Swing console has also evolved:

  • The console can be run as an Applet (groovy.ui.ConsoleApplet).
  • Beyond syntax highlighting, the editor also supports code indentation.
  • Drag'n droping a Groovy script over the text area will open the file.
  • You can modify the classpath with which the script in the console is being run, by adding a new JAR or a directory to the classpath as shown in the screenshot below.
    Swing console: Add a JAR in the classpath
  • A couple options have been added to the view menu item: for showing the script being run in the output area, and for visualizing the execution results.
    Swing console: visualization options
  • When an exception is thrown in your script, the lines of the stacktrace relative to your script are clickable, for easy navigation to the point where the error occurred.
  • Also, when your script contains compilation errors, the error messages are clickable too.

Back on the visualization of the results in the script output area, a fun system was added to let you customize how certain results are rendered. When you execute a script returning a map of Jazz musicians, you may see something like this in your console:

What you see here is the usual textual representation of a Map. But, what if we enabled custom visualization of certain results? The Swing console allows you to do just that. First of all, you have to ensure that the visualization option is ticked: View -> Visualize Script Results — for the record, all settings of the Groovy Console are stored and remembered thanks to the Preference API. There are a few result visualizations built-in: if the script returns a java.awt.Image, a javax.swing.Icon, or a java.awt.Component with no parent, the object is displayed instead of its toString() representation. Otherwise, everything else is still just represented as text. Now, create the following Groovy script in ~/.groovy/OutputTransforms.groovy:


import javax.swing.*

transforms << { result ->
    if (result instanceof Map) {
        def table = new JTable(
            result.collect{ k, v -<
                [k, v?.inspect()] as Object[]
            } as Object[][],
            ['Key', 'Value'] as Object[])
        table.preferredViewportSize = table.preferredSize
        return new JScrollPane(table)

The Groovy Swing console will execute that script on startup, injecting a transforms list in the binding of the script, so that you can add your own script results representations. In our case, we transform the Map into a nice-looking Swing JTable. And we're now able to visualize maps in a friendly and attractive fashion, as the screenshot below shows:

The Swing console is obviously not to be confused with a real full-blown IDE, but for daily scripting tasks, the console is a handy tool in your toolbox.

Metaprogramming enhancements

What makes Groovy a dynamic language is its Meta-Object Protocol and its concept of metaclasses which represent the runtime behavior of your classes and instances. In Groovy 1.6, we continue improving this dynamic runtime system, bringing several new capabilities into the mix.

Per instance metaclass even for POJOs

So far, Groovy POGOs (Plain Old Groovy Objects) could have a per-instance metaclass, but POJOs could only have one metaclass for all instances (ie. a per-class metaclass). This is now not the case anymore, as POJOs can have a per-instance metaclass too. Also, setting the metaclass property to null will restore the default metaclass.

ExpandoMetaClass DSL

Initially developed under the Grails umbrella and integrated back into Groovy 1.5, ExpandoMetaClass is a very handy way for changing the runtime behavior of your objects and classes, instead of writing full-blow MetaClass classes. Each time, we want to add / change several properties or methods of an existing type, there is too much of a repetition of Take for example this extract of a Unit manipulation DSL dealing with operator overloading:

Number.metaClass.multiply = { Amount amount -> amount.times(delegate) }
Number.metaClass.div =      { Amount amount -> amount.inverse().times(delegate) }

Amount.metaClass.div =      { Number factor -> delegate.divide(factor) }
Amount.metaClass.div =      { Amount factor -> delegate.divide(factor) }
Amount.metaClass.multiply = { Number factor -> delegate.times(factor) }
Amount.metaClass.power =    { Number factor -> delegate.pow(factor) }
Amount.metaClass.negative = { -> delegate.opposite() }

The repetition, here, looks obvious. But with the ExpandoMetaClass DSL, we can streamline the code by regrouping the operators per type:

Number.metaClass {
    multiply { Amount amount -> amount.times(delegate) }
    div      { Amount amount -> amount.inverse().times(delegate) }

Amount.metaClass {
    div <<   { Number factor -> delegate.divide(factor) }
    div <<   { Amount factor -> delegate.divide(factor) }
    multiply { Number factor -> delegate.times(factor) }
    power    { Number factor -> delegate.pow(factor) }
    negative { -> delegate.opposite() }

A metaClass() method takes a closure as single argument, containing the various definitions of the methods and properties, instead of repeating the Type.metaClass on each line. When there is just one method of a given name, use the pattern methodName { /* closure */ }, but when there are several, you should use the append operator and follow the patten methodName << { /* closure */ }. Static methods can also be added through this mechanism, so instead of the classical approach:

// add a fqn() method to Class to get the fully
// qualified name of the class (ie. simply Class#getName)
Class.metaClass.static.fqn = { }

assert String.fqn() == "java.lang.String"

You can now do:

Class.metaClass {
    'static' {
        fqn { }

Note here that you have to quote the static keyword, to avoid this construct to look like a static initializer. For one off method addition, the classical approach is obviously more concise, but when you have several methods to add, the EMC DSL makes sense.

The usual approach for adding properties to existing classes through ExpandoMetaClass is to add a getter and a setter as methods. For instance, say you want to add a method that counts the number of words in a text file, you could try this:

File.metaClass.getWordCount = {

new File('myFile.txt').wordCount

When there is some logic inside the getter, this is certainly the best approach, but when you just want to have new properties holding simple values, through the ExpandoMetaClass DSL, it is possible to define them. In the following example, a lastAccessed property is added to a Car class — each instance will have its property. Whenever a method is called on that car, this property is updated with a newer timestamp.

class Car {
    void turnOn() {}
    void drive() {}
    void turnOff() {}

Car.metaClass {
    lastAccessed = null
    invokeMethod = { String name, args ->
        def metaMethod = delegate.metaClass.getMetaMethod(name, args)
        if (metaMethod) {
            delegate.lastAccessed = new Date()
            metaMethod.doMethodInvoke(delegate, args)
        } else {
            throw new MissingMethodException(name, delegate.class, args)

def car = new Car()
println "Last accessed: ${car.lastAccessed ?: 'Never'}"

println "Last accessed: ${car.lastAccessed ?: 'Never'}"
sleep 1000
println "Last accessed: ${car.lastAccessed ?: 'Never'}"

sleep 1000
println "Last accessed: ${car.lastAccessed ?: 'Never'}"

In our example, in the DSL, we access that property through the delegate of the closure, with delegate.lastAccessed = new Date(). And we intercept any method call thanks to invokeMethod(), delegating to the original method for the call, and throwing an exception in case the method doesn't exist. Later on, you can see by executing this script that lastAccessed is updated as soon as we call a method on our instance.

Runtime mixins

Last metaprogramming feature we'll cover today: runtime mixins. @Mixin allowed you to mixin new behavior to classes you owned and were designing. But you could not mixin anything to types you didn't own. Runtime mixins propose to fill that gap by letting you add a mixin on any type at runtime. If we think again about our example of vehicles with some mixed-in capabilities, if we didn't own James Bond's vehicle and give it some diving ability, we could use this mechanism:

// provided by a third-party
interface Vehicle {
    String getName()

// provided by a third-party
class JamesBondVehicle implements Vehicle {
    String getName() { "James Bond's vehicle" }

JamesBondVehicle.mixin DivingAbility, FlyingAbility

assert new JamesBondVehicle().fly() ==
       "I'm the James Bond's vehicle and I fly!"
assert new JamesBondVehicle().dive() ==
       "I'm the James Bond's vehicle and I dive!"

One or more mixins can be passed as argument to the static mixin() method added by Groovy on Class.

JSR-223 Groovy Scripting Engine

Before Groovy 1.6, if you wanted to integrate Groovy in your Java projects through JSR-223 / javax.script.*, you had to download a Groovy script engine implementation from, and put the JAR in your classpath. This additional step wasn't very developer friendly, requiring some additional work — the JAR wasn't even provided in the Groovy distribution. Thankfully, 1.6 comes with an implementation of the javax.script.* APIs.

Below, you'll find an example evaluating Groovy expressions (the code is in Groovy, but it's straightforward to convert it back to Java):

import javax.script.*

def manager = new ScriptEngineManager()
def engine = manager.getEngineByName("groovy")

assert engine.evaluate("2 + 3") == 5

Please note that the javax.script.* APIs are available only on Java 6.

JMX Builder

Originiating as an external Open-Source project hosted on Google Code, JMX Builder has been integrated in Groovy 1.6, to simplify the life of developers needing to interact or expose JMX services. JMX Builder features:

  • Domain Specific Language (DSL) for JMX API using Builder pattern
  • Simplified JMX API's programmability
  • Declaratively expose Java/Groovy objects as JMX managed MBeans
  • Support class-embedded or explicit descriptors
  • Inherent support for JMX's event model
  • Seamlessly create JMX event broadcasters
  • Attach event listeners as inline closures
  • Use Groovy's dynamic nature to easily react to JMX events notifications
  • Provides a flexible registration policy for MBean
  • No special interfaces or class path restrictions
  • Shields developer from complexity of JMX API
  • Exposes attribute, constructors, operations, parameters, and notifications
  • Simplifies the creation of connector servers and connector clients
  • Support for exporting JMX timers

You can find more information on JMX Builder and its very extensive coverage of the JMX system. Lots of examples will show you how to create a JMX connector server or client, how to easily export POGOs as JMX managed beans, how to listen to JMX events, and much more.

Improved OSGi support

The Groovy jar files are released with correct OSGi metadata, so they can be loaded as a bundle into any OSGi compliant container, such as Eclipse Equinox or Apache Felix. You can find more information on how to use Groovy and OSGi on the Groovy project website. This tutorial will explain how to:

  • Load Groovy as an OSGi service
  • Write a Groovy OSGi service
  • Incude the Groovy JAR within a bundle
  • Plublish a service written in Groovy
  • Consume a service from Groovy
  • Troubleshoot in case you're encountering any problem along the way

You may also be interested in, for instance, how you can use different versions of Groovy in your application, thanks to OSGi.


Groovy continues its march towards the goal of simplifying the life of developers, providing various new features and improvements in this new release: AST transformations reducing dramatically the number of lines of code to express certain concerns and patterns and opening the language to developers for further extension, several metaprogramming enhancements to streamline your code and let you write more expressive business rules, and support for common enterprise APIs such as Java 6's scripting APIs, JMX management system, or OSGi's programming model. All of this is done obviously without compromising on the seamless integration with Java, and furthermore, with a level of performance way higher than previous releases.

We've now reached the end of this article and if you're not a Groovy user yet, I hope this artcile will give you a better understanding of what Groovy has to offer in your projects, and if you knew and used Groovy already, that you learned about all the new features of the language. The next step for you, dear reader, is to go download Groovy 1.6. And if you wish to dive deeper into Groovy, Grails and Griffon, I also invite you to join us at the GR8 Conference, a conference dedicated to Groovy, Grails and Griffon, taking place in Copenhagen, Denmark, where experts and makers of these technologies will guide you through with practical presentations and hands-on labs.

About the author

Guillaume Laforge, Groovy Project Manager As Head of Groovy Development for SpringSource, Guillaume Laforge is the official Groovy Project Manager, and the spec lead of JSR-241, the Java Specification Request that standardizes the Groovy dynamic language. He is also a frequent conference speaker presenting Groovy and Grails at JavaOne, SpringOne, QCon, the Sun TechDays, and JavaPolis/Devoxx. Guillaume also co-authored Groovy in Action along with Dierk König. Before founding G2One, the Groovy/Grails company, which was acquired by SpringSource in late 2008, and taking the role of VP Technology, Guillaume worked for OCTO Technology, a consultancy focusing on architecture and agile methodologies. While at OCTO, Guillaume developed new offerings around Groovy and Grails for its customers.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Good Job ! by Jean-Simon LaRochelle

Groovy is really becoming my favorite scripting language. Any speed improvement is welcome even for day to day scripting tasks but it is even more important for use in mainstream commercial application.

Bravo a Guillaume et à toute l'équipe de Groovy. Vraiment du beau travail!


Wow! by Rick Hightower

@Delegate, @Category and @Mixin: How can I ever go back to plain Java now? These are just too cool... the possibilities are endless. As if Groovy wasn't Groovy enough. WOW! Groovy!

Groovy 1.6 AST Transformations are blowing my mind...

Then I can't forget about @Bindable and @Grab :-)

I need to switch to Groovy 1.6... from 1.5... I know this now... I did not realize how much cool stuff was going to be in Groovy 1.6.

Excellent article BTW and an amazing release... Thanks thanks thanks

Great article showcasing 1.6 by Matthew McCullough

Really enjoyed getting an overview of what is new in Groovy 1.6. Excited about the AST transformations!

Great improvements by andrej koelewijn

Great improvements all around. Especially like the build in dependency management: Groovy and Grape - easiest way to send gtalk message with Apache Camel?

Immutable objects by Mike Rettig

Great to see that the groovy team is embracing immutability as a critical part of the language.

Can methods require @immutable arguments and return types? That would make it possible to write side effect free functions that can be parallelized. If the compiler can enforce immutability, then it would be trivial to write an erlang-like messaging library or a a parallelized linear algebra implementation.

Also, immutable types should also generate modifiers for all properties. Otherwise, working with immutable types is cumbersome and involves a lot of boilerplate copying of fields between objects.

def c1 = new Coordinates(latitude: 48.824068, longitude: 2.531733)
def c2 = new Coordinates(48.824068, 2.531733

//copies the prior longitude, and sets the latitude to the provided value
def c3 = c2.modify(latitude:49.13123)

This is a trivial example, but in practice data structures can be large and complicated, so it should be trivial to create slight variations of existing data.

Support for immutable types is critical as more people attempt to embrace multi-core machines through message based concurrency or side-effect free functional programming.


Awesome! by Maxim Gubin

This is a truly great achievement! Not only are there performance improvements but all of that added jazz (AST Transformations). I did not realize what the AST transformations did until I read this release article and I am truly amazed.
It's great that you've added full annotation support, because that makes Groovy code truly more Java-esque. I think after this release Groovy is going to get much more attention that it so truly deserves!
When is the standalone Gorm coming? I am really looking forward to that (Hope I'm not asking too much).

Great job once again!

Re: Immutable objects by Guillaume Laforge

Mike, I've started a thread on the Groovy mailing-list which mentions your ideas.
You can follow it here:

Re: Awesome! by Guillaume Laforge

GORM standalone will be available in Grails 1.1.
If you look at the samples of the latest RC, you'll see a Spring MVC PetClinic app using GORM (ie. outside Grails)

@Singleton and double checked locking by Hans-Peter Störr

Very impressive! Only one comment: it seems @Singleton uses the problematic double checked locking. I suggest using the private static class method that does not even need explicit locking - see .

Nice but some issues with Groovy... by Sony Mathew

Multi variable returns, assignments and swaps is a feature i've always longed - so that is great. And the other features look fabulous as well.

I've only newly embraced groovy for general scripting use and quick prototyping - but here are some issues I've run into constantly.. Correct me on any of them..

Inability to create anonymous classes easily to pass into various APIs being scripted (e.g. Eclipse API or Thread/Process API).

Thread interruptions (e.g. during Thread.sleep) seem to be silently and mysteriously handled causing unexpected behaviours during Ctrl-C and shutdown hook processings.

Scripting against different APIs leads to many castings to appropriate types desired by API methods (e.g. frequently casting to various Arrays). Its not always clear what type Groovy uses natively. This should be seamless.

Adding classpath in script to current GroovyClassLoader still causes script to not recognize classes used right after - groovy is not dynamic enough..haha. I have to use reflection(e.g. Classloader.loadClass()) for all newly added classpaths.

Scoping of variables with/without def and with/without types (like Java) is confusing. Scripts cannot access variables defined in another script even if via a method inside that script (but instantiation and method invokation of that script works as long as no variables are accessed!!). Named inner classes cannot access surrounding scope.

Spent a good hour+ figuring out why something wasn't happenning as expected - later found out my override of an API method was silently returning false. I had forgotten to return a value for the boolean method() - no errors given.

There are several Java language features gotchas that are not implemented as expected (so "code in Java" is not always a correct stmt) - I can't remember them now - i just worked around them.

I am sure there are good reasons for all the above - but my point is - things listed above are going to be the first things a Java guy tries and expects them to just work.

Lazy closures by Ray Davis

The "@Lazy" annotation also seems to work for overriding default values before they're consumed by closures:

class DataLoader {
// Can override with named parameter in the constructor.
def getService = { ComponentManager.get(it) }
@Lazy def siteService = getService("SiteService")

def serviceGetter = { AlternativeManager.getService(it) }
def dataLoader = new DataLoader(getService: serviceGetter)

Re: Nice but some issues with Groovy... by Guillaume Laforge

Multi variable returns, assignments and swaps is a feature i've always longed - so that is great. And the other features look fabulous as well.

Cool, I'm glad you like them.

I've only newly embraced groovy for general scripting use and quick prototyping - but here are some issues I've run into constantly.. Correct me on any of them..

Inability to create anonymous classes easily to pass into various APIs being scripted (e.g. Eclipse API or Thread/Process API).

Groovy provides a couple mechanisms for that, with map and closure coercion, like {} as SomeInterface (for interfaces with just one method), or even [meth1:{}, meth2:{}] as SomeOtherInterface (for when you need to implement or extend several methods).

In Groovy 1.7, we'll be adding raw / classical anonymous inner classes, even though they're not really necessary per se in most situations.

Thread interruptions (e.g. during Thread.sleep) seem to be silently and mysteriously handled causing unexpected behaviours during Ctrl-C and shutdown hook processings.

We're not doing anything special there.

Scripting against different APIs leads to many castings to appropriate types desired by API methods (e.g. frequently casting to various Arrays). Its not always clear what type Groovy uses natively. This should be seamless.

There are some occasions where we need casting, but they're not very frequent.
Unlike a statically compiled language, you have to remember that a dynamic language chooses methods at runtime, according to the runtime type of the parameters passed to the method you're calling. So that difference makes that sometimes you need to help the dynamic runtime know which method you really intended to call.
That said, some precise examples would be needed, because that statement doesn't help much, I'm afraid.

Adding classpath in script to current GroovyClassLoader still causes script to not recognize classes used right after - groovy is not dynamic enough..haha. I have to use reflection(e.g. Classloader.loadClass()) for all newly added classpaths.

Again, an example would be helpful, as I'm sure we can find a neater solution here.

Scoping of variables with/without def and with/without types (like Java) is confusing. Scripts cannot access variables defined in another script even if via a method inside that script (but instantiation and method invokation of that script works as long as no variables are accessed!!). Named inner classes cannot access surrounding scope.

Variables not def'ed or without types, in scripts, go into the binding of the script.
Otherwise, def'ed and typed variables are just "local" variables. Local to your script, so that's normal (and as designed) that they are not available to other scripts.
If you need to share variables, you'd better share the same binding for all your scripts.

As for named inner classes, I'm not sure I understand what you mean here.
If it's in scripts again, if you want to access local variables, they are indeed local to the script, a bit like if you added a local variable to your main() method. So they indeed can't be seen from another class defined in your script.
So, again, you use the binding (don't def/don't type your variables). That seems like what's best for your use case, it seems.

Spent a good hour+ figuring out why something wasn't happenning as expected - later found out my override of an API method was silently returning false. I had forgotten to return a value for the boolean method() - no errors given.

That's because of optional return.
If your forget to return anything, the latest statement of your method will be evaluated to a boolean.

There are several Java language features gotchas that are not implemented as expected (so "code in Java" is not always a correct stmt) - I can't remember them now - i just worked around them.

There aren't many differences left with Java anyway, apart from anonymous inner classes, for instance, or array initializers. Otherwise, the "compatibility" is very high.

I am sure there are good reasons for all the above - but my point is - things listed above are going to be the first things a Java guy tries and expects them to just work.

When you're encountering problems, please report them on the Groovy user mailing-list, you'll get very fast responses to all your questions.
Furthermore, remember that Groovy is a dynamic language, so there are obviously some differences with Java from times to times, but it's close to Java enough to be very easy to get started with.

Re: @Singleton and double checked locking by Jean-Simon LaRochelle

Another good way to lazy initialize the reference would be to use an AtomicReference.


@Delegate-Annotation by Stefan Undorf

Multiple-Inheritance without AspectJ - I love this feature. What will happen if two or more delegates implement the same method signature, which one is called? What happens if my own class implements that method signature too? Is there a way to specify which class's method should be called in that scenario (like in C++ Class::method)?

Re: Nice but some issues with Groovy... by Sony Mathew

Thanks Guillaume, I will post some examples on the mailing list soon....

Can developers create new AST Transformations? by Jarppe Lansio

Thanks for really great article. Especially the AST Transformations are really nice feature I look forward to use.

Is it possible to write new AST Transformations for my own purposes? For example, a transformation to create a builder class for each immutable etc.


Re: Can developers create new AST Transformations? by Guillaume Laforge

It's definitely possible to create your own AST transformations, of course.
You can have a look at those two wiki pages explaining (through a tutorial) the process:

PackageScope by Tuomas Kassila

More clear sample of how to use PackageScope you can found at
This message contain a web link to actual sample.

Really amazing features by Matthew Adams

Great job with all of the enhancements. I'm especially impressed, almost to the point of intimidation, by the AST Transformation features. They let you do almost anything. The only detriment that I can see (and that I'm willing to live with) is the magic factor: so much is going on behind the scenes that you wouldn't know about otherwise. The use of annotations to drive the AST Transformations is a nice way, however, to indicate to readers of the source "Hey, something special is happening here, so you'd better either know what it is or go look it up."

@Category and @Mixin/.mixin() are really nice, too. @Delegate is extremely convenient. Nice!

Really great stuff. I can't wait to get my hands dirty.


PS: I'm also glad to see the OSGi support as well!

Excelent! by Jaromir Nemec

I find the JSR 233 integration great feature.

One small typo:

assert engine.evaluate("2 + 3") == 5

I guess the method should be eval; evaluate did not worked for me.

The wordCount example illustrates nice the extensibility of the metaclass, but I wonder if the regex shouldn't be something like split(/\W+/) to get the word count.

One again a good job, I upgraded immediatelly after reading this:)


Jaromir D.B. Nemec

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

20 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you