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.
- Stop Malware, Stop Breaches? How to Add Values Through Malware Analysis
- Vulnerability Threat Management in 2015
- SaaS and E-Discovery: Navigating Complex Waters
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
- Real results: Speeding quality application delivery with DevOps [in financial services]
- Client Windows Migration: Expert Tips for Application Readiness
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.