Release notes for Groovy 2.0

The static type checker is built using Groovy’s existing powerful AST (Abstract Syntax Tree) transformation mechanisms but for those not familiar with these mechanisms you can think of it as an optional compiler plugin triggered through an annotation. Being an optional feature, you are not forced to use it if you don’t need it. To trigger static type checking, just use the @TypeChecked annotation on a method or on a class to turn on checking at your desired level of granularity. Let’s see that in action with a first example:

We annotated the test() method with the @TypeChecked annotation, which instructs the Groovy compiler to run the static type checking for that particular method at compilation time. We’re trying to call someMethod() with some obvious typos, and to print the name variable again with another typo, and the compiler will throw two compilation errors because respectively, the method and variable are not found or declared.

The static type checker also verifies that the return types and values of your assignments are coherent:

In this example, the compiler will complain about the fact you cannot assign a Date in an int variable, nor can you return a String instead of a Date value specified in the method signature. The compilation error from the middle of the script is also interesting, as not only does it complain of the wrong assignment, but also because it shows type inference at play, because the type checker, of course, knows that letters[0] is of type String, because we’re dealing with an array of Strings.

Since we’re mentioning type inference, let’s have a look at some other occurrences of it. We mentioned the type checker tracks the return types and values:

Given a method returning  a value of primitive type int, the type checker is able to also check the values returned from different constructs like if / else branches, try / catch blocks or switch / case blocks. Here, in our example, one branch of the if / else blocks tries to return a String value instead of a primitive int, and the compiler complains about it.

The static type checker, however, won’t complain about certain automatic type conversions that Groovy supports. For instance, for method signatures returning String, boolean or Class, Groovy converts return values to these types automatically:

The static type checker is also clever enough to do type inference:

Although the name variable was defined with def, the type checker understands it is of type String. Then, when this variable is used in the interpolated string, it knows it can call String’s toUpperCase() method, or the trim() method later one, which is a method added by the Groovy Development Kit decorating the String class. Last, when iterating over the elements of an array of primitive ints, it also understands that an element of that array is obviously an int.

An important aspect to have in mind is that using the static type checking facility restricts what you are allowed to use in Groovy. Most runtime dynamic features are not allowed, as they can’t be statically type checked at compilation time. So adding a new method at runtime through the type’s metaclasses is not allowed. But when you need to use some particular dynamic feature, like Groovy’s builders, you can opt out of static type checking should you wish to.
 
The @TypeChecked annotation can be put at the class level or at the method level. So if you want to have a whole class type checked, put the annotation on the class, and if you want only a few methods type checked, put the annotation on just those methods. Also, if you want to have everything type checked, except a specific method, you can annotate the latter with @TypeChecked(TypeCheckingMode.SKIP) — or @TypeChecked(SKIP) for short, if you statically import the associated enum. Let’s illustrate the situation with the following script, where the greeting() method is type checked, whereas the generateMarkup() method is not:

Current production releases of Java don’t support general type inference; hence we find today many places where code is often quite verbose and cluttered with boilerplate constructs. This obscures the intent of the code and without the support of powerful IDEs is also harder to write. This is the case with instanceof checks: You often check the class of a value with instanceof inside an if condition, and afterwards in the if block, you must still use casts to be able to use methods of the value at hand. In plain Groovy, as well as in the new static type checking mode, you can completely get rid of those casts.

In the above example, the static type checker knows that the val parameter is of type String inside the if block, and of type Number in the else if block, without requiring any cast.

The static type checker goes a bit further in terms of type inference in the sense that it has a more granular understanding of the type of your objects. Consider the following code:

In this example, we return, intuitively, a list of numbers: an Integer and a BigDecimal. But the static type checker computes what we call a "lowest upper bound", which is actually a list of numbers which are also serializable and comparable. It’s not possible to denote that type with the standard Java type notation, but if we had some kind of intersection operator like an ampersand, it could look like List<Number & Serializable & Comparable>.

Although this is not really recommended as a good practice, sometimes developers use the same untyped variable to store values of different types. Look at this method body:

The var variable is initialized with an int. Then, a String is assigned. The "flow typing" algorithm follows the flow of assignment and understands that the variable now holds a String, so the static type checker will be happy with the toInteger() method added by Groovy on top of String. Next, a number is put back in the var variable, but then, when calling toUpperCase(), the type checker will throw a compilation error, as there’s no toUpperCase() method on Integer.
 
There are some special cases for the flow typing algorithm when a variable is shared with a closure which are interesting. What happens when a local variable is referenced in a closure inside a method where that variable is defined? Let’s have a look at this example:

The var local variable is assigned a String, but then, var might be assigned a Date if some random value is true. Typically, it’s only at runtime that we really know if the condition in the if statement of the closure is made or not. Hence, at compile-time, there’s no chance the compiler can know if var now contains a String or a Date. That’s why the compiler will actually complain about the toUpperCase() call, as it is not able to infer that the variable contains a String or not. This example is certainly a bit contrived, but there are some more interesting cases:

In the test() method above, var is assigned an instance of A, and then an instance of B in the closure which is call afterwards, so we can at least infer that var is of type A.
 
All those checks added to the Groovy compiler are done at compile-time, but the generated bytecode is still the same dynamic code as usual — no changes in behavior at all.
 
Since the compiler now knows a lot more about your program in terms of types, it opens up some interesting possibilities: what about compiling that type checked code statically? The obvious advantage will be that the generated bytecode will more closely resemble the bytecode created by the javac compiler itself, making statically compiled Groovy code as fast as plain Java, among other advantages. In the next section, we’ll learn more about Groovy’s static compilation.

In Java 6 and before, as well as in Groovy, numbers could be represented in decimal, octal and hexadecimal bases, and with Java 7 and Groovy 2, you can use a binary notation with the 0b prefix:

When writing long literal numbers, it’s harder on the eye to figure out how some numbers are grouped together, for example with groups of thousands, of words, etc. By allowing you to place underscore in number literals, it’s easier to spot those groups:

When catching exceptions, we often replicate the catch block for two or more exceptions as we want to handle them in the same way. A workaround is either to factor out the commonalities in its own method, or in a more ugly fashion to have a catch-all approach by catching Exception, or worse, Throwable. With the multi catch block, we’re able to define several exceptions to be caught and treated by the same catch block:

Using the indy JARs is not enough, however, to compile your Groovy code so that it leverages the invokedynamic support. For that, you’ll have to use the –indy flag when using the groovyc compiler or the groovy command. This also means that even if you’re using the indy JARs, you can still target JDK 5 or 6 for compilation.
 
Similarly, if you’re using the groovyc Ant task for compiling your projects, you can also specify the indy attribute:

The Groovy Eclipse Maven compiler plugin hasn’t yet been updated with the support of Groovy 2.0 but this will be the case shortly. For GMaven plugin users, although it’s possible to configure the plugin to use Groovy 2.0 already, there’s currently no flag to enable the invoke dynamic support. Again, GMaven will also be updated soon in that regard.
 
When integrating Groovy in your Java applications, with GroovyShell, for example, you can also enable the invoke dynamic support by passing a CompilerConfiguration instance to the GroovyShell constructor on which you access and set the optimization options:

As invokedynamic is supposed to be a full replacement to dynamic method dispatch, it is also necessary to disable the primitive optimizations which generate extra bytecode that is here to optimize edge cases. Even if it is in some cases slower than with primitive optimizations activated, future versions of the JVM will feature an improved JIT which will be capable of inlining most of the calls and remove unnecessary boxings.

In our testing, we noticed some interesting performance gains in some areas, whereas other programs could run slower than when not using the invoke dynamic support. The Groovy team has further performance improvements in the pipeline for Groovy 2.1 however, but we noticed the JVM isn’t yet finely tuned and still has a long way to go to be fully optimized. But fortunately, upcoming JDK 7 updates (in particular update 8) should already contain such improvements, so the situation can only improve. Furthermore, as invoke dynamic is used for the implementation of JDK 8 Lambdas, we can be sure more improvements are forthcoming.

To add new methods to an existing type, you’ll have to create a helper class that will contain those methods. Inside that helper class, all the extension methods will actually be public (the default for Groovy but required if implementing in Java) and static (although they will be available on instances of that class). They will always take a first parameter which is actually the instance on which this method will be called. And then following parameters will be the parameters passed when calling the method. This is the same convention use for Groovy categories.
 
Say we want to add a greets() method on String, that would greet the name of the person passed in parameters, so that you could that method as follows:

To accomplish that, you will create a helper class with an extension method like so:

Static extension methods are defined using the same mechanism, but have to be declared in a separate class. The extension module descriptor then determines whether the class provides instance or static methods. Let’s add a new static method to Random to get a random integer between two values, you could proceed as in this class:

That way, you are able to use that extension method as follows:

Once you’ve coded your helper classes (in Groovy or even in Java) containing the extension methods, you need to create a descriptor for your module. You must create a file called org.codehaus.groovy.runtime.ExtensionModule in the META-INF/services directory of your module archive. Four essential fields can be defined, to tell the Groovy runtime about the name and version of your module, as well as to point at your helper classes for extension methods with a comma-separated list of class names. Here is what our final module descriptor looks like:

With this extension module descriptor on the classpath, you are now able to use those extension methods in your code, without needing an import or anything else, as those extension methods are automatically registered.

With the @Grab annotation in your scripts, you can fetch dependencies from Maven repositories like Maven Central. With the addition of the @GrabResolver annotation, you can specify your own location for your dependencies as well. If you are "grabbing" an extension module dependency through this mechanism, the extension method will also be installed automatically. Ideally, for consistency, your module name and version should be coherent with the artifact id and version of your artifact.