Rejoice, Groovy times lie ahead

Groovy 2.0 is finally here – Interview with Guillaume Laforge, Project Lead

Chris Mayer

Originally appearing in Java Tech Journal, we took time out to speak with Guillaume Laforge about the imminent release of Groovy 2.0

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

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


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?

: 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?

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

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

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.


JAX:You’ve upgraded to JDK 7 and added in a lot of JDK 7
support. Was this progression natural? Why was this decision made

Laforge: We
have “upgraded” to JDK 7 in the sense that we offer some particular
support for users running on JDK 7. There are particularly two key
aspects at play here: Project Coin syntax enhancements and Invoke
Dynamic support. We’re adopting most of the JDK 7 syntax
enhancements, as Java developers will become familiar with them,
they will expect to have them available in Groovy as well. The
second aspect is to continue the performance improvements of the
Groovy runtime, and particularly its dynamic heart, by using the
new Invoke Dynamic bytecode instruction and APIs to speed up
Groovy’s dynamic method calls, its method caching capabilities, and
so on. While the former is visible as it is about syntax additions,
the latter is transparent to our users, as they will benefit from
those performance improvements without having to change anything in
their programs.

So this is a natural decision to keep on benefiting from the
novelties of newer JDKs, considering how close and interoperable
Groovy and Java are, unlike other alternative languages.

Why now? Well, now, although Java 6 is still the dominant Java
version, JDK 7 is being deployed more and more, so Java developers
are adopting it and will want to leverage those new features of
Java 7 and the JDK.

JAX: Tell us more about introducing new things from
Project Coin?

Groovy syntax deriving from the Java 5 grammar means a very big
percentage of Java programs are actually also valid Groovy
programs! Some even often refer to that as “copy’n paste”
compatibility – beware to this bug-prone approach of copying Java
code snippets into your Groovy programs!

And indeed, beginner Groovy users often code in Groovy with a
very Java-ish syntax. As they progress through their understanding
of Groovy, they progressively take advantage of the various
shortcuts and APIs provided by Groovy.

Given that syntax-level compatibility, we expect our users to
want to be able to reuse certain of the novelties found in the
syntax enhancements of Java 7 (i. e. the new Project Coin syntax
elements). Groovy users were used to some of them already though,
as for example, Groovy users have been able to use Strings and many
more types in their switch/case blocks since 2003. But it’s nice to
see that Java is still evolving, despite at a slower pace.

Groovy 2.0 users will thus be able to use the new binary
literals, the underscore in number literals, the diamond operator,
etc. Currently, the sole non-supported syntax is the try/resource
bit, as Groovy offers already many ways to take care of resources,
like streams, files, and more, as part of its API. We’ll see if
there’s demand from our user base to decide whether we should end
up also supporting that feature.

Also, what’s interesting to know is that despite Project Coin
aspects are available in Java 7 and beyond, Groovy users will be
able to use these enhancements even when running Groovy on top of a
JDK 5! They can use today the features that they will use in the
future when they can finally upgrade to JDK 7!

JAX: Can you detail some of the new major aspects of the
JDK 7 support? Why did you decide to add in invoke dynamic support
and static type checking? Was there a clamouring from the Groovy
community for them?

Laforge: So we
already mentioned the Project Coin syntax enhancements, that you’ll
be able to use on top JDK 5+. We’re adding Invoke Dynamic support
to benefit from performance improvements for dynamic languages
provided by JDK 7. Productivity, streamlined and effective syntax
are always topics dear to the developers of the Groovy language.
Static type checking and static compilation will certainly please
Java developers who have some a prioris about dynamic languages, or
that want type safety, or Java-like speed. So it should definitely
increase the reach of the language to attract new users and
covering more use cases.

JAX: What benefits arise from moving towards a module
approach? How is this being done with Groovy?

Groovy is delivered in the form of a JAR that you can use as a
library in your project. And also as part of a distribution, with
command-line and UI tools and third-party libraries. The Groovy
library contains the language itself (parser, compiler, etc), but
also many library enhancements on top of things like Swing, JDK
collection classes, Ant scripting, JMX integration, templating,
etc. As I said earlier, not everybody needs everything, so it’s
important to be able to just pick up the bits you’re interested in
so you have a smaller dependency to add in your project.
Furthermore, modularity will allow us in the future to evolve the
APIs that Groovy provides much more easily, so that users can
upgrade to newer and better versions that might come.

So we are splitting the Groovy sources and the JAR into smaller
sub-projects and modules that will end up forming additional JARs
with specific features. You’ll then be able to import a particular
module in your project should you need it. This will also allow us
to continue to grow the set of APIs that Groovy provides, as we
were a bit reluctant to add new API support given the size of the
Groovy runtime. But with modularity, we’ll be able to add new APIs
more easily.

JTJ: To reiterate, there will still be support for those
in JDK5/6 though right?

Laforge: Yes,
the plan is to continue supporting JDK 5 and beyond for Groovy 2.0.
We still have Groovy users that are stuck with JDK 5, so we’re
trying to be fair with them and allow them to continue to use
Groovy until they have time to migrate to a newer JDK. For later
Groovy versions though, we will certainly require a more recent JDK
as a base, perhaps even jumping to JDK 7 as a new base. It’s still
up for debate.

JAX: What are the best attributes of Groovy?
Advantages over Java and other languages in your view?

Groovy’s always been a very nice companion of any JDK-based
project, and Groovy’s always interoperated very seamlessly with
Java. That’s a key advantage that other alternative languages often
overlook, despite offering a certain level of

Groovy’s syntax is very easy to learn and use for the big Java
community of developers. So it’s also easier to learn and master
than a lot of the competing alternative languages which may have a
syntax too foreign, or that require PhDs to understand a single
line of code.

Groovy definitely shines in terms of learning curve and ease of
use on the JVM platform compared to the other languages.

JAX: There’s a lot of other projects appearing on
their own as a nod to Groovy such as Gradle, Grails and the
recently added GPars to Groovy 1.8. Do you think that in part has
helped formed a vibrant community around the language?

Groovy is a very popular project that is used by many developers
around the world for very different projects and domains. Groovy’s
versatility, expressiveness and powerful capabilities make it a
nice language to use for other libraries and frameworks, which gave
birth to a full ecosystem of projects around Groovy, using the
language in different ways. This ecosystem, in turn, brought a lot
of new users to the language! Grails is a very prominent example of
that, which brought a big exposure to the language. Gradle today is
also a build automation project using Groovy that is used by many
enterprise projects and by big Open Source projects like Spring or

The ecosystem of projects is a key asset to the big success of

JAX: It might be early to ask this but, what plans
are their in the future for the Groovy roadmap? Is the focus purely
on making Groovy 2.0 as great as possible for the time

Laforge: We
still have quite some work to finalize Groovy 2.0, so we’re
spending most of our time on delivering this key milestone to our
big user community.

That said, we do of course have plans for later versions too! In
particular, we’d like to completely rework the dynamic heart of
Groovy (the Meta-Object Protocol), to make it even more homogenous
and powerful, giving more fine-grain control over the dynamic
features, more safety as well to control the reach of
metaprogramming changes, etc.

We’d also like to rewrite our parser to use a newer version of
Antlr, offering better tooling in IDEs to evolve the grammar of

The work on modularity will also continue, and will allow us to
evolve the existing APIs more easily.

And as usual, we’ll continue to listen carefully to the needs of
our user base, to try to fulfil their wishes for improvements and
new features.


This article originally appeared in Java Tech Journal: The
Groovy Universe. Check out further Groovy-centric articles here.

comments powered by Disqus