Groovy 1.8 release notes
Command chains for nicer Domain-Specific Languages
Groovy is well known for its Domain-Specific Language capabilities, thanks to its flexible syntax, and its compile-time and runtime metaprogramming capabilities. However, we felt that we could improve upon the syntax to get rid of even more punctuation when users chain method calls, to allow DSL implementors to develop language closer to natural sentences.
Before Groovy 1.8, we could omit parentheses around the arguments of a method call for top level statements. But we couldn't chain method calls. The new "command chain" feature allows us to chain such parenthese-free method calls, without requiring neither parentheses around arguments, nor dots between the chained calls. The general idea is that a call like
a b c d will actually be equivalent to
a(b).c(d). This is also working with multiple arguments, closure arguments, and even named arguments. Furthermore, such command chains can also appear on the right-hand side of assignments. Let's have a look at some examples of the kind of syntaxes that this allows:
It is also possible to use methods, in the chain, which don't take arguments, but in the case, the parentheses are needed:
If your command chain contains an odd number of elements, the chain will be composed of method / arguments, and will finish by a final property access:
This new command chain approach opens up interesting possibilities in terms of DSLs that are now possible to be written. This new feature has been developed thanks to the Google Summer of Code program, where our student, Lidia, helped us modify the Groovy Antlr grammar to extend top-level statements to accept that command chain syntax.
You will be able to find some further examples of "command chains" on the Groovy Web Console.
In general the goal of these improvements is to bypass the MOP where allowed and possible without altering the original MOP too much.
Groovy 1.8.0 contains several integer based optimizations for basic operations like plus, minus, multiply, increment, decrement and comparisons. This versiondoesn't support the mixed usage of different types and then falls back to the classical way of performing the operation.
This version also contains an optimization for direct method calls. Such a method call is done directly if it is done on "this" and if the argument types are a direct match with the parameter types of the method we may call. Since this is an operation that does not behave too well with a method call logic based on runtime types we select only methods where the primtive types match, the parameter types are final or for methods that take no arguments. Currently methods with variable arguments are not matched in general, unless a fitting array is used for the method call.
Those two optimizations are only the beginning of further similar improvements related to primitive type handline. Upcoming versions of the Groovy 1.8.x branch will see more optimizations coming.
GPars bundled within the Groovy distribution
The GPars project offers developers new intuitive and safe ways to handle Java or Groovy tasks concurrently, asynchronously, and distributed by utilizing the power of the Java platform and the flexibility of the Groovy language. Groovy 1.8 now bundles GPars 0.11 in the libraries of the Groovy installation, so that you can leverage all the features of the library for your concurrent, asynchronous and parallel needs.
Closure annotation parameters
Closure functional flavors
Native JSON support
New AST Transformations
Controlling the execution of your code
You will find a great write-up on @Canonical, @ToString, @EqualsAndHashCode and @TupleConstructor on John Prystash weblog.
Alignments with JDK 7
Groovy 1.9 will be the version which will align as much as possible with the upcoming JDK 7, so beyond those aspects already covered in Groovy (like strings in switch and others), most of those "Project Coin" proposals will be in 1.9, except the "diamond operator" which was added in 1.8, as explained in the following paragraph.