Channels ▼

JVM Languages

The Groovy Conundrum

I doubt any successful language has a had a more troubled childhood than Groovy. It was originally designed to be a Java-like alternative to Java — a scripting language that could provide the power of the JVM with a syntax that required far less ceremony to get things done. In this regard, it followed in the steps of NetRexx, the first Java alternative, but avoided that language's design choice of a syntax that was foreign to Java developers. The initial 2003 proposal for Groovy got far enough that a JSR was issued for it. A short while later, its champions abandoned it and the project appeared to be moribund. Then, a French developer, Guillaume LaForge, jumped in and began patching the initial efforts. LaForge was a talented project manager and, over time, he fostered the community needed to move the language forward.

More Insights

White Papers

More >>


More >>


More >>

Groovy was given a shot in the arm by the advent of Grails, a Web framework that leveraged the new language's features to deliver a "convention over configuration" model à la Rails for the JVM. By 2007, Groovy reached 1.0. Despite attacks on the language by both spec leads from the original JSR, the language was embraced for two traits: a brevity that did not compromise readability, and a superb capacity for developing domain-specific languages. The latter trait was evident in many of the projects that today drive Groovy usage (in addition to Grails): the Griffon Swing framework; the Jolt award-winning test framework, easyb; and the latest rage in build systems, Gradle.

For all its strengths, however, Groovy suffered from several important drawbacks: the first and most painful was performance. It was slow — even for a dynamic language. The second limitation was that Groovy had no real design philosophy, save for a wide-ranging pragmatism. Any new feature that brightened enough eyes in the community got thrown in. So the language grew organically in ways that were hard to predict, rather than having a clear philosophy and a long-term trajectory. Finally, there was the problem that I believe most cramped its acceptance: limited documentation. There was one "Bible" and a pair of tutorials that rehashed the basics.

Despite these limitations, I used Groovy quite a bit for writing UATs and functional tests for Java programs. The scripting syntax was good for wiring tests together quickly. As they were slow-running tests, the performance limitation was not an issue. And because my tests tended to reuse scaffolding code a lot, the documentation was a superable problem. But because of both of those issues, Groovy remained for me (and, I expect, for many others) a language for writing scripts, not for building apps.

In 2008, the Groovy and Grails teams were brought into VMware, making the language the only Java alternative backed by a publicly owned company (which is still the case today). However, VMware was a phlegmatic supporter of the language, and it moved Groovy forward slowly (although advancing the tool ecosystem appreciably). This allowed alternatives such as Scala, JRuby, and Clojure to gain traction. From being a front-runner, Groovy fell back to where it is today — just another Java alternative, albeit with the largest developer base.

Last year, that alternative became considerably more appealing with release 2.0, which resolved the performance issue. Keying off ideas prototyped by Alex Tkachman, the Groovy team added static typing. They also greatly optimized the generated code so that execution speed is now comparable to most natively compiled Java languages. The just-released version 2.1 refines some of these earlier advances. The language is suddenly much more interesting and promising than it once was. In addition, during the intervening years, support in the IDEs and tooling has grown and is quite acceptable (IntelliJ IDEA leads the parade, but all major Java IDEs now support Groovy.)

However, some historical problems persist. Another major release is planned for this year, but details are sketchy and there is still no useful roadmap. Likewise, documentation remains a real problem. A major update to the "Bible" was initiated in 2009 and is still far from being complete. One tutorial has been updated to the 2.0 release. And the semi-official docs contain pages of widely differing quality, some with obvious errors in them.

With the performance issues behind it, Groovy is a language primed for widespread use. It delivers some truly unique benefits: terse, readable, Java-like syntax; excellent technology for writing DSLs; uniquely good support for unit testing; powerful metaprogramming capabilities; an excellent framework for concurrency; and, finally, both dynamic and static typing (you choose). Add an active community and the high-quality tooling, and you have a language primed to be a major player. There is the conundrum.

The endless variety of features requires considerable documentation, which is simply not available, especially for the advanced features that give Groovy much of its benefit. And so, if you jump in today, you'll find the language is easy to learn, but hard to master. Fortunately, this limitation is not incurable. However, time is of the essence as Groovy's principal competitor for the hearts and minds of Java developers — Scala — has a small, laser-focused company behind it, which revs the product frequently and generates considerable documentation. If Groovy acts soon, it can retain leadership among Java alternatives. If not, it will have to resign itself to being an also-ran.

Related Reading

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



I've been using Groovy for a couple of years in limited situations. It is a useful tool for sure, but the limitations offset many of the benefits. In general, people seem to want a quick solution to roadblocks in development without realizing they might be buying into much more serious problems in the future.

IMO, the most serious issue is the lack of adaption in general. Anyone picking this technology for projects should be cautious because we don't develop in a vacuum. One roadblock would be finding employees to maintain and develop projects. If Groovy saves 10 hours on a project, but costs 100k more in total cost in the lifetime of the project it is a loss. Nothing to do with Groovy, but matter of reality.


Excellent article, thanks!

I have four differences of opinion though:

0. The slow adoption of Groovy: As Groovy matured and became a viable language, the world experienced a global depression. Budgets and staff were reduced; adoption of new technologies stalled. The effect is unclear, but the economy certainly played some part.

1. Groovy documentation: I've heard this complaint before but I've been using Groovy since 2008, and I've always considered the docs acceptable (relative to open source standards). Much of it is somewhat unique in that is it expressed as unit tests, but I find that concise and quicker to grasp than English. There are gaps, but behavior is easily verified with assets like groovyConsole and source code.

2. Scala (and Closure) as a competitor: I like Scala but doubt it will ever be a competitor for two reasons. The first is, Groovy code is easier to read than Java, whereas Scala code is more difficult. Historically, simple usually wins. The second is the heart of Scala & Closure: functional programming. This technology has been around for decades and has never gained more than niche success. The usual view is that it is syntactically complex, too complex for most programmers. So why should it suddenly take off now?

3. Performance: As you point out, there are situations when performance is not a show stopper. The common example is scripting. However, there is another case where Groovy performance is sufficient, a case that corresponds to a huge market: Web Applications. Most app servers sit idle waiting for database or service calls to return, and any cpu-bound code can be written in Java. Yet I've never had to resort to Java. And, as you point out, Groovy keeps getting faster.

The first time I heard someone advise me to drop Groovy because it was "too slow" reminded me of other languages that experts predicted would fail due to being too slow. These include COBOL, SQL and Java itself.

The trend is clearly going in the opposite direction: costs of staff continue to increase whereas costs of hardware continue to decrease.


To clarify/extend what korzhs is saying: The Groovy compiler will accept pure Java syntax. So getting onboard with the language is pretty easy.


Cedric Hurst pointed out on Twitter that the emerging JVM language, Ceylon, is backed by Red Hat, which is a public company.


What a 'Tower of Babel' the software development enterprise has come to be!


We've been working with Groovy and Grails for 2 years now and still exciting about its brevity, readability, conciseness and most of all its full syntax compatibility with Java (which Andrew didn't pay an attention in the article).
The thing is: every Java programmer can start writing in Groovy almost immediately and learn new syntax constructions "on the go". No language (including Scala) has such possibility.


Thank you for this wonderful history. I tried Groovy when it first appeared, but it became clear that the language designers had enough good ideas to make a great demo, but didn't know enough about language design to be able to add features cleanly. (Which is hardly a kiss of death: see PHP. Except, of course, that "Java-like syntax" was a moving target, with the modern for-loop syntax on its way.) When Grails arrived, I was amazed that Groovy was still popular.

This is an exciting time for JVM languages. I've switched to Scala, but it has too much of a learning curve for me to recommend it wholeheartedly to most others. It will be interesting to see how Kotlin fares, as it promises to have many of Scala's features, but with a simpler (and faster to compile) syntax.