This paper looks at the history of the Groovy programming language. The language started out with a goal to allow a rapid and productive scripting style of programming for users familiar with the Java programming language. In order to achieve this, various pain points associated with Java programming were addressed.

One early goal was to reduce the amount of ceremony involved in writing a simple “hello world” program. Early evolution of the language involving additional sub-goals of reducing the amount of code involved to solve various additional common programming tasks such as working with files, processes, GUI libraries, XML documents, database interactions and aggregate data types.

While being more succinct, the code to achieve these common tasks looks and feels familiar to a Java programmer both in terms of language keywords and syntax, and also in terms of the language types (classes) and libraries being used. In addition to piggy-backing and extending Java’s class libraries, Groovy retained the same security model, threading model and object model (with just a few enhancements like native properties).

Groovy provided some of its own classes and library functions to meet these evolving goals but in many instances, it achieved the desired functionality by extending or enhancing classes from the Java class library. This was achieved through a runtime metaprogramming mechanism.

The metaprogramming mechanism supports intercepting method and property access, as well as adding new methods and properties to classes. The capability was not only used internally to support Groovy’s libraries but opened up to language users so that they too could enhance the classes they wrote. This was one of the key design decisions that allowed the language to grow in a scalable way over many years.

Initially, it was never a goal to replace Java but rather extend the reach of Java into areas like scripting and Domain Specific Languages (DSLs) while supporting some elements of declarative and functional programming. Seamless integration with Java was maintained in order to keep the languages complementary rather than competitors. Over time, Groovy’s evolution has made it more compelling to be used as a standalone language for ever increasing scenarios.

Support for overriding operators for any class was added but only for about a dozen common operators. This is used internally for classes like BigInteger, BigDecimal and Date but more importantly is an extension point for language growth, allowing others to define operators for Matrices, Temperatures, Currencies or whatever classes are relevant for their domain.

Inspiration for the extensions came from many places but was heavily influenced by features found in other languages, e.g. Groovy early String support and literal list and map notations borrowed heavily Python. Named parameters and collection method names (collect, inject, findAll) came from Smalltalk. Ruby influenced numerous aspects of the metaprogramming mechanism and both Ruby and Smalltalk influenced to a lesser extent the closure syntax.

Over time, Groovy was enhanced in numerous ways: * It was expanded greatly to fully cover many aspects when Java moved to version 5 including generics support, annotations, enums, varargs. * A simplified syntax for numerous user defined metaprogramming scenarios was introduced. * New operators like the Elvis and spaceship operators were added. * Tool support for joint compilation, repl-like facilities and documentation were added. * Support for anonymous inner classes and annotation definitions.

The next big fundamental change was the support of compile-time metaprogramming. Rather than adding methods and classes at runtime, these could now be added at compile time through a facility that allowed you to modify or transform the compiler’s Abstract Syntax Tree during the compilation process. Many of these AST transforms were added that captured design patterns, best practices or mechanisms that just removed boiler-plate coding but rather than hard-coded into the language, they were akin to library capabilities. Importantly, this mechanism was also opened up to all Groovy users. If they didn’t like the AST transforms that we provided, they could relatively easily write their own.

With its support for both runtime and compile-time metaprogamming, and its flexible syntax, Groovy was becoming popular for writing Domain Specific Languages (DSLs). Groovy added command chains to enhance that capability further.

Another fundamental change was to give Groovy a static flavor. Code could be statically type checked to pick up additional classes of errors that a static compiler can pick up or dynamic features could be turned off altogether to produce Java-like performance when the dynamic capabilities weren’t needed. Flow typing was introduced to support expected behavior for styles of programming common when using Groovy’s dynamic flavor even when using the static compiler. Also traits were added influenced by Scala’s similar feature.

An important feature of the static compiler was that it was made extensible. Again, the choice to allow users to grow the language as they need. Later macros were added to allow AST transformations to be written primarily using Groovy code, allowing non-compiler Guru users of the language to more easily extend it. The macro method invocation mechanism too was opened up to users. They can also define their own powerful methods, allowing even greater language extension possibilities.

Many choices made by Groovy in it’s design were later borrowed by others (Swift, C#, Kotlin, Ceylon, PHP, Ruby, Coffeescript, Scala, Frege, Facebook Flow, TypeScript and Java itself). Things like Groovy’s trailing closure, Groovy builders, null-safe navigation, the Elvis operator, ranges, the spaceship operator, and flow typing.

The governance of the language has also evolved through various nuanced flavors and various companies have been involved in helping sponsor its development but Groovy has always been a highly collaborative open source project.

https://doi.org/10.1145/3386326