Groovy 2.0 is finally here – Interview with Guillaume Laforge, Project Lead
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 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.
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 now?
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?
Laforge: 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?
Laforge: 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?
Laforge: 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 integration.
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?
Laforge: 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 Hibernate.
The ecosystem of projects is a key asset to the big success of Groovy.
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 being?
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 Groovy.
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.