Rejoice, Groovy times lie ahead
Groovy 2.0 is finally here - Interview with Guillaume Laforge, Project Lead - Part 2
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.
- Part 1 - Groovy's inception and 2.0
- Part 2 - JDK 7 and Groovy beyond