Rejoice, Groovy times lie ahead
Groovy 2.0 is finally here - Interview with Guillaume Laforge, Project Lead
Today, the popular dynamic language Groovy finally got its 2.0 release, signalling big changes in its development. Amongst the new features for this monumental milestone are a static type checker which lets the compiler tell you how correct your code is, static compilation and a new modular approach. There's also some leaps made towards JDK 7 in Project Coin and Invokedynamic, keeping Groovy's ties to Java strong.
One of the key men behind Groovy 2.0 is Guillaume Laforge, SpringSource's Project Lead for Groovy. Recently in April's Java Tech Journal: The Groovy Universe, we talked to him as the final preparations were being made towards the release. Part 1 discusses Groovy's genesis and the 2.0 release, whilst Part 2 looks at the Java-centric updates and the future for the language
Despite a projection of May for Groovy 2.0 being slightly off, it's been worth the wait. We're glad it's finally here giving the Groovy community a vital update in the language they love...
JAX So first things first: the version numbering change. Why was this done, switching from 1.8 to 2.0, and missing 1.9 out all together?
Guillaume Laforge: It already happened once in the life of the project, when switching from 1.1 to 1.5 instead. It’s the second time we’re doing a big version number change to reflect the importance of the release. Initially, 1.9 (now called 2.0) had a smaller feature scope. But with all the work done in that release, we felt it wasn’t very fair to make this release appear as a “minor” version, although it was quite major instead. Our “dot releases” have always been major releases in our minds, so the old naming scheme didn’t really reflect that aspect. So from now on, what we consider major versions will really have a version number that really reflects that. But don’t worry, we will not increase version numbers like web browsers!
JAX: How long has the process been between 1.8 and 2.0? How many committers have played a part?
Laforge: We usually release a major version every year, or year and a half at most (except for the very first 1.0 version of course). So 2.0 should be out soon, hopefully in May. It’s always difficult to give exact dates, as the scope of the release changes over time, and it also depends on the time our contributors can devote to the project, etc. We always have a handful of very active committers (some working full-time on the project), plus many more who contribute on specific topics once in a while.
JAX: Can you explain some of the key concepts behind Groovy in the first place? Did you feel frustrated with certain aspects of Java, or wanted to improve upon them?
Laforge: Indeed Groovy started somehow as a frustration with certain aspects of Java. There are many interesting features available for years in other languages that we would have liked to have in Java, but which unfortunately were not available. For instance, closures. Groovy’s had closures since 2003, while it’s only in JDK 8 in a year or two that we will eventually have closures in the Java programming language. Don’t get me wrong though, we do love Java, and are usually advertising Groovy as Java’s cousin or best friend, as the interoperability between the two languages has always been a key concern to us, and even actually a design goal, so that Java developers can be productive in Groovy right away, without any steep learning curve to follow.
At its core, Groovy builds upon the Java grammar to extend Java’s syntax in a number of ways, to make the code more concise and expressive. A key design goal of the language has always been productivity: to make sure that Groovy developers can focus on the key business task at hand, rather than writing too much boilerplate code preventing them from crafting their business logic. Beyond just the syntax which is very familiar for Java developers, Groovy adds key features such as closures, some functional programming flavour to easily deal with collections to ease the writing of complex algorithms, and brings many improvements over key JDK APIs to add missing functionalities.
Also, the nature of Groovy is to be a “dynamic” language. It’s a language with a multiple dispatch runtime, rather than a statically compiled behavior. It opens up very interesting perspectives for library or framework authors. And projects like Grails, Gradle, GPars, Griffon, Spock and many more are taking advantage of these aspects, to make their usage very easy and readable.
JAX: Groovy is described as a powerful language, taking in concepts from Java and other languages. What sets Groovy apart from other JVM languages? Domain-Specific Languages? AST Transforms?
Laforge: You put the finger on two of the key sweet spots of Groovy. I’d also add a third related point which is its scripting and embeddable nature. Domain-Specific Languages (DSL) are easy to write in Groovy thanks to its concise and flexible nature, to its metaprogramming capabilities. You can do things like adding properties to numbers, write English-like sentences, overload certain operators, etc. When combining all these techniques, your business logic becomes even more readable and easy to understand and maintain than having to use a mere Java API. That’s why Groovy is often used as a business language in vertical applications (financial, medical, and more).
This is possible also because of the third point I added, because you can pretty easily embed Groovy in a Java application (Spring, Java EE, any framework). So you can have Groovy just cover the business logic aspect, while your infrastructure technical code is just Java.
AST transforms (Abstract Syntax Tree), are part of the DSL aspect, actually, as it’s one of the techniques that can be used to manipulate the Groovy language, so as to taylor it for a given business need. You can somehow hijack the syntax of the language, and bend it or limit it to your needs, to better represent concepts of the domain you’re working on.
JAX: What key goals were in mind for Groovy 2.0, in terms of features?
Laforge: With about half a million Groovy users, we’ve come to realise that there are so many different ways Groovy is used these days, and that obviously not everybody needs the same things. Groovy users write full-blown applications in Groovy, whereas others are just embedding Groovy business rules in their Java applications. Some are using Groovy as a more flexible Java. And also some users need performance for doing intensive calculation, or others are interested in the templating capabilities, but not the Swing UI capabilities, and vice versa. That’s why the key themes of this release are safety, performance and modularity.
First of all, on “safety”, Java developers using Groovy as a more flexible Java tend to like using Groovy just like they use Java. So they don’t need all the dynamic aspects of Groovy. They would also like to be able to get compile-time errors for simple errors like typos in method names or variable names, of type errors on their assignments, etc. That’s why Groovy 2.0 proposes a new AST transformation that brings compile-time type checking, which makes the compiler more grumpy and complain about common mistakes.
Now, on “performance”. If you don’t need dynamic capabilities, we could as well compile your code into pretty much the same bytecode as javac generates, so that you get the same speed as Java! This is quite a compelling argument for those who work on more real-time systems, etc. But if you rely on the dynamic capabilities of Groovy, don’t worry, you’re covered too, since the JDK 7 “invoke dynamic” support will also bring some nice performance improvements even for those dynamic parts of your application logic.
And in the spirit of “not everybody needs everything”, we are focusing on modularity, splitting the Groovy library into smaller modules, so that users can pick up just the modules they are interested in. I want the Ant scripting capabilities, but not the Swing support. I want the templating capabilities, but not JMX support, etc. Further down the road, it should also allow us to evolve our APIs easier, so that we can offer newer and better APIs that the ones we currently have.
- Part 1 - Groovy's inception and 2.0
- Part 2 - JDK 7 and Groovy beyond