Release notes for Groovy 1.5

In Java 5, the ellipsis notation was created to denote methods with variable length arguments. With those little triple dots, Java lets users put as many parameters of the same type at the end of a method - actually, the vararg parameter is just an array of elements of that type. Varargs were already present in Groovy 1.0 - and still work with a JDK 1.4 runtime, but it is good to show how you can use them. Basically, whenever the last argument of a method is an array of objects, or a parameter declaration with a triple dot, you can pass multiple parameters to this method.

A first example will show the usage of varargs in Groovy with the ellipsis:

The assertions used in this example show how we can pass as many ints as desired. It is also interesting to see that, for more syntax compatibility with Java, the classical for loop has been added into Groovy - despite the presence of the groovier version with the in keyword that can also transparently iterate over various array or collection types.

Note that it is possible to have varargs support even with an array as last parameter by declaring the method as follows:

This snippet is really trivial, and there are obviously more expressive ways of calculating a sum. For instance, if you have a list of numbers, you can sum all of them in a single line of code:

Varargs in Groovy don’t require JDK 5 as the underlying Java runtime, unlike annotations that we are now going to look at in the following section.

As shown in the documentation of JBoss Seam which supports Groovy for writing its entities, controllers and components, annotations like @Entity, @Id, @Override and others can be used to decorate your beans:

The Hotel entity is marked with the @Entity annotation, and it’s given a name through @Name. Different parameters can be passed to your annotations like in the @Length annotation constraint where different upper and lower bound can be set for validation purpose. You can also notice Groovy properties in action: Where are all the getters and setters? Where are the public or private modifiers? You don’t have to wait for Java 7 or 8 to get properties! By convention, defining a property is as simple as String country: a private country field will be auto-generated, as well as a public getter and setter. Your code becomes naturally more concise and readable.

Annotations can be used on classes, fields, methods and method parameters, like in Java. There are, however, two gotchas to be aware of. Firstly, you can use annotations in Groovy, but you cannot yet define them - however, it will be possible in an upcoming version of Groovy. Secondly, although the syntax is almost 100% the same as in Java, there is a little difference when an array of values is passed in parameter of the annotation: instead of curly braces to surround the elements, Groovy requires the use of square brackets to offer a more homogeneous syntax - since Groovy lists and arrays use square brackets to surround their elements as well.

With annotations in Groovy 1.5, you can easily define your JPA or Hibernate annotated beans in Groovy, add an @Transactional annotation on your Spring services, test your Swing UI with TestNG and Fest (http://jroller.com/aalmiray/entry/testing_groovy_uis_with_fest). All the useful and powerful enterprise frameworks leveraging annotations can be used from your Groovy-powered projects.

Whenever you need a fixed set of constants of a same type, Enums come in handy. Say you need a clean way to define constants for days without resorting to using integer constants? Then Enums are your friend. The following snippet shows how to define the days of the week:

Once you have defined your enum, you can use it as in Java with the usual notation Day.MONDAY and you can spice up your switch / case statements with it as well:

Notice that Groovy’s switch is a bit more powerful than C-like languages switches in that it is possible to use any kind of object in the switch and case. Instead of stacking up seven different case block with each enumerated value, you can regroup them in lists or ranges: whenever the value is in the list or the range, the case will be true and its associated instructions will be executed.

A more complex example inspired by the Java tutorial takes a more astronomical perspective on enums, and shows how your enums can have properties, constructors and methods:

Like annotations, enums in Groovy require a JDK 5+ to run on, as Java 5 bytecode is generated.

In our previous examples of enums, we always had to prefix the enumerated value with its parent enum class, but thanks to static imports (which work even on a JDK 1.4 runtime) we can save some characters by dropping the Planet prefix:

No more Planet prefix. But of course, static imports aren’t only available for enums, but also work for other classes and static fields. What about doing some math?

Both the static methods of java.lang.Math and its static constants were statically imported to make the expression more concise. But if the abbreviations of sine and cosine are not readable for you, you can use aliasing in Groovy with the as keyword:

Aliasing also works with normal imports too, not just static imports, and it can be pretty handy for adding some shortcut notation to very long class names as found in many frameworks, or for renaming methods or constants with non-obvious names, or not following your naming convention standards.

A somewhat more controversial feature of Java 5 also finds its way in the latest release of Groovy 1.5 with Generics. Initially, it may feel odd to add even more typing information to a dynamic language, after all. Java developers usually believe that because of type erasure (for backward compatibility reasons with older versions of Java) no information is left in the class bytecode to represent the generic type. However, this is wrong, since through the reflection API, you are able to introspect a class to discover the types of its fields or of its methods arguments with the generics details.

So for instance, when you declare of field of type List<String>, somewhere in the bytecode, this information is kept in the form of some meta-information, although this field is really just of type List. This kind of reflexive information is used by enterprise frameworks like JPA or Hibernate to be able to relate a collection of elements from an entity to the entity representing the type of these elements.

To put this into practice, let us check if the generics information is kept on class fields:

We defined two classes: a Speaker class giving Talks at conferences. In the Speaker class, the talks property is of type List<Talk>. Then, we create a Speaker instance with two nice shortcuts for initializing the name and talks properties, and for creating a list of Talk instances. Once this setup code is ready, we retrieve the field representing the talks, and we check that the generic type information is correct: yes, talks is a List, but a List of Talks.

In Java 5, if you have a method in a subclass with the same name and parameter types as in a parent class, but with a return type derived from the parent method’s return type, then we can override the parent method. In Groovy 1.0, covariant return types were not supported. But in Groovy 1.5, you can use them. Additionally, if you are trying to override a method with a return type not deriving from the parent class method’s return type, a compilation error will be thrown. Covariant return types also work with parameterized types.

Beyond the support of Java 5 features which brought a few additions to the language, a few other syntax enhancements have been introduced in Groovy 1.5, and we are going to discover them in the following section.

Apart from the Java 5 features that brought annotations, generics and enums into Groovy, a new operator finds its way into the language: ?: the Elvis operator. When you see the operator in question, you will easily guess why it was nicknamed that way - if not, think in terms of Smiley. This new operator is, in fact, a shortcut notation for the ternary operator. How many times are you using the ternary operator to change the value of a variable if its content is null to assign it some default value? The typical case in Java is as follows:

In Groovy, since the language is able to ``coerce'' types to boolean values as needed (for instance where conditional expressions are required like in if or while constructs), in this statement, we can omit the comparison to null, because when a String is null, it is coerced to false, so in Groovy, the statement would become:

However, you will still notice the repetition of the name variable, which would violate the DRY principle (Don’t Repeat Yourself). As this construct is pretty common, the Elvis operator was introduced to simplify such recurring cases, and the statements become:

The second occurrence of the name variable is simply omitted and the ternary operator is no more ternary and is shortened to this more concise form.

It is also worth noticing that there are no side effects to this new construct, since the first element (here the name) is not evaluated twice as it would be the case with the ternary operator, so there’s no need to introduce some intermediate temporary value to hold the result of the first evaluation of the first element of the ternary operator.

Although Groovy is not strictly speaking a 100% superset of Java, the Groovy syntax comes closer to the Java syntax after each release, and more and more Java code is also valid Groovy. The net benefit of this is that when you begin with Groovy, you can copy and paste Java code in your Groovy classes, and this should just work as expected. Then, over time, as you learn the language, you start throwing away the semicolons which are not mandatory in Groovy, using GStrings (interpolated strings), or closures, etc. Groovy offers a rather flat learning curve to Java developers.

However, there was one omission to this Java-syntax compatibility in the fact the classical for loop inherited from Java’s C background wasn’t allowed in Groovy. Initially, the Groovy developers thought it was not the nicest syntax of all and preferred using the for / in construct which was more readable. But as the Groovy users regularly asked for this old construct to be also part of Groovy, the team decided to bring it back to Groovy.

With Groovy 1.5, you can either choose the Groovy for / in, or prefer the classical for loop:

At the end of the day, it is probably more a matter of taste, and long time Groovy users usually prefer the most concise syntax with the for / in loop instead.

With its malleable and concise syntax, and its advanced dynamic capabilities, Groovy is an ideal choice for implementing internal Domain-Specific Languages. When you want to share a common metaphor between subject-matter experts and developers, you can leverage Groovy to create a dedicated business language which models the key concept and business rules of your application. An important aspect of these DSLs is to make the code very readable, and also easier to write by non-technical persons. To achieve this goal even further, the grammar of the language was tweaked to allow us to use named parameters without the surrounding parenthesis.

First of all, in Groovy, named parameters look like this:

By adding new properties to numbers - which is possible in Groovy but beyond the scope of this article - we can also write code like this:

Now by omitting parenthesis, the code can become a little clearer as shown below:

Obviously, this is not a big difference, but each statement becomes closer to real plain English sentences, and removes the usual boilerplate technical code of the host language. This little enhancement of the grammar of the Groovy language gives more options to the designers of the business DSL.

For the Maven users, there is also a fully featured Maven plugin hosted at Codehaus which allows you to build your Java / Groovy applications: compile your Groovy and Java code, generate documentation from the JavaDoc tags, or it even lets you write your own Maven plugins in Groovy. There is also a Maven archetype to bootstrap your Groovy project more rapidly.

As a Java developer, you are used to documenting your code through JavaDoc tags in the comments of your classes, interfaces, fields, or methods. In Groovy, you can also use such tags in your comments, and have them being used by a tool called GroovyDoc to generate the equivalent JavaDoc documentation for all your Groovy classes.

There’s an Ant task you can define then use to generate the documentation as follows:

I will save the best of tooling support till the end of this section by mentioning the JetGroovy plugin: a free and Open Source IntelliJ IDEA plugin dedicated to the support of both Groovy and Grails. This plugin has been developed by JetBrains themselves, and provides unmatched support for both the language and the web framework.

To list a few of the available features of the Groovy support:

At the end of the day, you won’t even notice whether you’re developing a class in Groovy or in Java, considering the level of interplay and support offered inside IntelliJ IDEA. This is definitely a plugin to install if you’re considering adding some dose of Groovy in your Java project, or if you plan to develop Grails applications.

More information can be found on JetBrains website.

Although I’m only mentioning the plugin for IntelliJ IDEA, for your Groovy developments, you don’t have to change your habits. You can also use the Eclipse plugin which is regularly improved by the IBM Project Zero developers, or Sun’s brand-new support of Groovy and Grails in NetBeans.