In recent years, we have witnessed major improvements in software development with Java—and beyond. It’s easy to overlook these achievements when you’re bogged down with daily development work. We work with elaborate tool support, have all kinds of frameworks for various domains, and have discovered new agile ways of organizing software development in teams. Each of these disciplines—tooling, frameworks, and methodology—has successfully pushed its limits. We are still waiting for two other important aspects of software development to contribute to bringing our trade forward: personal skills management and programming languages.

Language does matter. It determines how you perceive the world—and it determines your world. Your programming language determines how you think about software solutions and the way you think about the underlying problems. Your knowledge of programming languages is key to your personal skill portfolio as a software developer.

Source code is a means of communication: from you to the compiler, to other team members, and then back to you. There is both a technical and a human aspect in this communication. Classical programming languages focus on the technical aspect and are optimized for performance and resource consumption. Other languages focus on the human aspect, trying to reveal the programmer’s intent in the code as clearly as possible. Many attempts have been made to bridge the two aspects, ranging from Literate Programming to Programming in Logic, none of which has taken the world by storm.

While Groovy is unlikely to dominate traditional languages, what distinguishes it from previous attempts is that it allows a smooth transition from machine-centric to human-centric coding. It builds on the basic idea of the Java platform with a new interpretation of code appearance. That means that on the bytecode level, Groovy is Java, allowing a seamless mix-and-match of the two languages. For example, unlike other projects that try to make scripting languages available on the Java platform, a literal string in Groovy is of the type java.lang.String. You get the best of both worlds.

As a direct consequence, Groovy fully leverages the availability of frameworks, with the Java standard library being the most important one. James Strachan and Bob McWhirter founded the Groovy project in 2003, recognizing that application development in Java is characterized by using multiple frameworks and gluing them together to form a product. They designed Groovy to streamline exactly this kind of work.

At the same time, Richard Monson-Haefel met James, who introduced him to Groovy. Richard immediately recognized Groovy’s potential and suggested the submission of a Java Specification Request (JSR-241). To make a long story short, this JSR passed “without a hitch,” as Richard puts it in his blog, thanks to additional support from Geir Magnusson, Jr. and the foresight of the folks at Sun Microsystems. They don’t see Groovy as Java’s rival but rather as a companion that attracts brilliant developers who might otherwise move to Ruby or Python and thus away from the Java platform. Since the JSR has been accepted, Groovy is the second standard language for the Java VM (besides the Java language itself).

The JSR process was the acid test for the Groovy community. It showed where contributors were pushing in different directions and it imposed more structure on the development than some were willing to accept. Development slowed down in late 2004. This was when some key people stepped in and took the lead: Guillaume Laforge and Jeremy Rayner organized what was later called GroovyOne. This led to a Groovy Language Specification (GLS), a Test Compatibility Kit (TCK), and a new parser generated from a descriptive grammar specification. They got the ball rolling again—a ball that has now become an avalanche.

From the beginning, it was clear that Groovy would need a book like Groovy in Action to introduce newcomers to the language, provide comprehensive documentation, and show what’s possible with Groovy in order to trigger the reader’s curiosity and imagination.

John Wilson started this venture and passed the baton to Scott Stirling, who in turn came across some contributions that I had made to the Groovy Wiki. He quickly convinced me to join the book effort. By that time, I was downloading every single bit of information that I could find about Groovy into my personal knowledge base to have it available offline. I jotted down personal notes about Groovy idioms that I found helpful. Putting all this into a book seemed natural, even if it was only for my personal purposes.

Unfortunately, Scott had to resign and I was left alone for half a year, pushing things forward as best I could. I was lucky enough to get support from Andrew and Guillaume, both well-known Groovy experts. Andrew runs the Practically Groovy online series and Guillaume is not only the Groovy project manager, he is the heart and soul of Groovy. From day one of this book project, I was aware that as I am not a native speaker, I would not be able to write a full-length book in English without serious help. This was the initial reason for asking Dr. Paul King and Jon Skeet to come on board. I could not have been luckier. It turned out that they not only plowed tirelessly through every sentence in this book, leaving no stone unturned, but clarified the book’s arguments, made the text more accessible, and corrected errors and weaknesses. They also suggested more compelling examples, and, last but not least, contributed content. This book would never have come to fruition without their diligent and mindful work.

Even though we will probably never see the day that Richard envisions “when Groovy is used to control space flight and has solved world hunger,” I would be pleased if Groovy, and this book, help to push our profession of software development one inch farther.

DIERK KÖNIG