On May 17th-19th, I took the opportunity to escape the daily “Java business as usual” on the GR8Conf conference in Copenhagen, Denmark. The three days were packed with the latest information on Groovy related technologies such as Grails, Griffon, Gradle, GPars, Spock etc.
The whole conference seemed to have a mantra: A-S-T for Abstract Syntax Tree transformations. A language should have access to its own abstract syntax, as McCarthy claimed back in the days of LISP – Groovy has its access via AST transformations.
In a nutshell AST transformations are Java annotations allowing to manipulate Groovy code. Practical use cases are best practices patterns such as Joshua Blochs ‘Effective Java’ implemented once in terms of an AST annotation applied to every day Groovy code.
Examples are @Canonical applied to a Groovy class generating correct implementations of Object.hashCode, Object.equals, and Object.toString or @Synchronized, @WithReadLockor @WithWriteLock generating the correct error prone synchronization boiler plate code for synchronization of mutual state access.
Another handy AST annotation is @Log which creates the standard logger and guarding log level check code for log statements.
AST transformation are very powerful but one must not forget that – like AOP – your code will look different in a debugger.
Design by Contract with GContracts
The GContracts project uses AST transformations to implement a feature the Eiffel language has for years: Design by Contract by defining invariants and pre- and post conditions. The infamous example of an integer overflow that caused the spectacular Ariane 5 crash served as the obvious example.
Applying these contract annotations obviously seems like a good idea.
Static Code analysis for Groovy
Java has some mature static code analysis tools such as Findbugs, PMD or the inspections built into the IntelliJ IDE bugging a developer with violations of best coding practices rules. CodeNarc is a tool that offer a similar functionality. It doesn’t seem to be as mature as its senior Java counter parts, but the number of rules is increasing and writing CodeNarc rules is quite easy. Integrating CodeNarc into a Groovy build process and enabling the corresponding IntelliJ plugin should become as mandatory as using Findbugs and friends.
Happy spec’ing with Spock
Spock is a JUnit compliant testing framework allowing to write very expressive test cases. Peter Niederwieser, the creator of Spock uses Groovy’s internal DSL capabilities to provide some very appealing features to write test cases called specifications in the Spock terminology.
A specification follows the given-when-then pattern also known as AAA, arrange-act-assert. JUnit provides the @Before and @Test annotations in combination with a whole bunch of Assert-Methods. Asserts are implict in the “then” section of a spec and the “given” and “then” sections are the arrange and act realizations.
Apart from this basic functionality Spock comes with many more powerful features such as the Power Assert which has been extracted into the standard Groovy GDK, by the way. One of these features is the “where” section allowing to provide test data in a tabular form or to be read from a database in a very convenient way.
Languages are either concurrent or obsolete
A very good argument to persuade Java purist to consider Groovy as a language is GPars. Vaclav Pech, the project lead of the GPars project gave a very good introduction to GPars by demonstrating its power by coding concrete examples instead of flipping slides.
GPars can be considered as an abstraction layer on top of the Java concurrency packages. It is a library that enhances Groovy in a way that a programmer can safely use all prominent concurrency patterns such as thread pools, actors or data flow variables. Vaclav demonstrated with a simple piece of code sequentially processing a number of images that the eight cores of his machine are not used as they are supposed to. By simply wrapping the same code with a “withPool” clause the process monitor showed all cores at work. The interesting fact was that no threads had to be created manually – the GPars construct figured out how to distribute the work load.
Data flow variables take care of the synchronization of concurrently executed tasks. There are no explicit threads and locks required any longer. Anyone who has to implement concurrent computations should consider using GPars instead of having to code the corresponding concurrency patterns using the lower level Java concurrency packages.
Gr8Conf was worth a visit. Compared to the heavy weight JCP the evolution of the Java language is tied to, the growth of the Groovy ecosystem is breath taking. Some of the projects presented on this conference should be evaluated for existing and upcoming mgm projects.