Groovy's support of annotations is identical to Java 5 annotations, but we felt that in some cases it would be interesting to be able to add annotations in other places than the usual places (types, fields, methods, parameters, etc.). For instance, in Java, it is impossible to add annotations on imports, packages or variable declarations. Groovy does go beyond and adds support for annotation on imports, packages and variable declarations. We'll take a look at the usage of those extended annotations on Grape.
The Grape dependency system lets you request dependencies in your scripts, without having to deal with downloading, packaging, or specifying the classpath yourself. To use Grape, we had to use the @Grab annotation to "grab" a dependency from a repository (Maven's central repository, for example). The problem was that annotation had to be attached to some allowed elements, ie. the places where annotations can be put in Java. Now, we can put annotations on imports:
Another example with @Grab on variable declarations:
Please note on this one an improvement in the @Grab annotation: we provide a shorter version taking just a String as value parameter representing the dependency, in addition to the more verbose example in the previous example. You simply append the group, module, version and classifier together, joined by colons.
Groovy's "assert" keyword has sometimes been criticized as it's, in a way, limited, as it just checks that the expression it's being passed is true or false. Unlike with testing frameworks such as JUnit/TestNG and the various additional assertion utilities, where you get nicer and more descriptive messages, Groovy's assert would just tell you the expression was false, and would give the value of variables used in the expression, but nothing more. With Power Asserts, initially developed in the Spock Framework, the output of the assert is now much nicer and provides a visual representation of the value of each sub-expressions of the expression being asserted. For example:
With Groovy 1.6, we introduced AST Transformations, for letting developers do compile-time metaprogramming, by modifying the Abstract Syntax Tree before it is transformed into bytecode. In Groovy 1.6, several such transformations were added, especially "local" transformations triggered by annotations (such as @Delegate, @Singleton, @Bindable and friends). However powerful this feature is, writing AST transformation has always been a bit tedious. Groovy 1.7 features two new features which should help simplify the work of AST transformation writers: an AST viewer and an AST builder.
The following screenshot shows a new window that can be launched from the Groovy Swing Console. You can visualize the AST of a script you're working on in the console: for instance, writing the code you'd like to create in your AST transformation. The AST viewer greatly help with figuring out how Groovy builds its AST when compiling your Groovy code.
Visualizing the AST is one thing, but we also need a mechanism to create and modify ASTs more easily. The introduction of the AST builder simplifies the authoring of AST transformations, by giving you three different approaches for working on the AST:
- building from string
- building from code
- building from specification
Before the AST builder, one had to create and instanciate manually all the various AST nodes. Let's see how those three forms helps with this, for instance for create a node representing a constant string.
For more information, please have a look at the documentation on the AST Builder. You'll discover the advantages and inconvenients of the various forms, and why all three are needed depending on what you want to achieve with the AST.
Some of the dependencies of Groovy have been upgraded to newer versions.
For instance, Groovy now uses the latest ASM version, which is "invokedynamic"-ready. So as we progress towards the inclusion of JSR-292 / invokedynamic, we'll be ready and be using the latest version of ASM. We also use the latest versions of Ivy which is used by the Grape dependency module.
The GroovyScriptEngine (which is also used by Groovlets) has been rewritten to solve various dependency issues it was suffering from, and the outcome of this is that it should also now be much faster overal.
The new logic uses additional phase operations to track dependencies. As a result the error-prone class loader technique to track them is gone now. These operations ensure that every script file will be tracked, its dependencies recorded during compilation and all transitive dependencies will be calculated. And only scripts will be recorded as dependency, no classes. The new GroovyScriptEngine also uses only one compilation "process" for script compilation which solves the problem of circular or mutual dependencies, that caused stack overflows in the past. As a result the new engine can reliably handle dependencies and should be much faster.
A small annoyance, especially for developers using big LCD screens: the Groovy Console didn't remember preferences of position of the separator between the coding area and output view, or the font size being used. This is now fixed, as the console remembers such settings. You won't need anymore to adjust the console to your liking each time you run it, it should now have some more brain cells to remember your preferences.
The Groovy Sql class now features batch updates, thanks to its new withBatch() method, taking a closure and a statement instance:
Similarly, there's a withTransaction() method added to Sql, which works also with datasets: