Groovy, an Open Source Success Story

Apache Groovy is a multi-faceted general purpose programming language for the Java platform. While primarily an object-oriented language with many dynamic language features, it also supports functional programming, static type checking and static compilation. This article looks at some interesting aspects of Groovy's history and some of the significant guiding principles which help keep it a vibrant open source project.

What is Groovy and why should I care?

There are many available programming languages, and several popular alternatives to Java that are specifically designed to run on the JVM, so what's so special about Groovy? Groovy is particularly known for its:

• close integration with and low learning-curve from Java
• multi-paradigm support for functional and object-oriented styles
• flexible syntax and productive libraries
• extensibility through metaprogramming
• scripting capabilities
• support for domain specific languages (DSLs)

It's also one of the most widely used alternative languages for the JVM with downloads of about 12 million per year and steadily rising. But this isn't an article to sell you on the features of Groovy, rather it describes the role open source played in Groovy's evolution.

Groovy has been an open source project since its inception. It started life from the desire to be able to program using less boilerplate code like you could using Ruby, Python or Smalltalk but on the JVM platform and using a syntax that a Java programmer would find natural. Without that spark of inspiration, Groovy wouldn't exist, but that inspiration alone didn't bring Groovy to where it is today. A number of other factors were crucial, and various hurdles needed to be overcome. Let's look at some of those factors - different pillars, if you like, supporting a successful open source project.

Building a better light bulb but standing on the shoulders of giants

A key motivator behind many of the early features of Groovy were things that the project members deemed were needed but missing in Java. However, the Groovy team was much smaller than the engineering team behind Java. So an underlying strategy was made to let Java do the things it does well and Groovy would focus on the gaps: Don't do all things but do the things you do well.

The integration between the two would be kept closer than what other alternative JVM languages had attempted. When new versions of Java came out, sometimes with features inspired by what Groovy had added years earlier, Groovy would just try to move the goalposts out further with the next round of missing features.

Having said that, it is worth noting that Groovy's addition of static type checking and static compilation to get better compile-time errors and dramatically improve performance does overlap somewhat with Java. Even though Groovy allows seamless interplay between mixed Java and Groovy codebases, many users just didn't want to leave Groovy and have to revert back to Java yet wanted some of the benefits from Java's static typing and type checking. Of course Groovy, always wanting to raise the bar further, made the type checker extensible so that you could add your own custom checkers for stricter-than-Java checking if you desire.

As well as building upon Java, many early Groovy features were inspired heavily by features found in Python, Ruby, Smalltalk and other languages - no need to reinvent the concept, just provide a version that is JVM friendly and intuitive to someone with a Java developer mindset. Examples of such features include:

• Groovy's metaprogramming capabilities and range data type borrowed ideas heavily from Ruby
• the list and map literal notation and the syntax for default parameters were inspired by Python
• the collection processing methods, collect and inject, followed Smalltalk's naming scheme
• closures came from the world of functional programming

In recent years, the nice observation is that Groovy features have found their way back into languages like C#, Swift, Scala, Kotlin, Frege and even Java. Some examples include:

• Java's lambda expressions can be thought of as a limited version of Groovy's closures
• as part of project Coin, Java added strings to switch statements (Groovy allows strings, regex expressions, class expressions and closures as possible targets for a case statement)
• the syntax for the Elvis operator ?: is now used in PHP, Fantom and Kotlin though they test against null rather than applying Groovy truth; numerous languages have instead added a ?? operator for null coalescing including C# and Swift
• the safe navigation operator ?. is now in C#, Swift, Kotlin, Fantom and Ruby (as &.)
• the spaceship operator <=> is now in PHP, Ceylon and Ruby
• numerous dynamic languages have looked at ways to add static typing checking

The fact that Groovy is open source and its design and implementation are out in the open make this exchange of ideas possible; fostering innovation and raising the bar for all open source languages.

Professional leading-edge development

A common characteristic of many (but not all) open source projects is a high-quality codebase and often the pioneering use of good development practices. People interested in best-practice techniques are also often the ones looking for the latest technology that might ease some of their pain points. Groovy has certainly been fortunate to have such individuals involved within its community at various points. Numerous techniques and approaches have been incorporated along the way to keep code quality high, improve test coverage, maintain appropriate compatibility and adopt best-of-breed devops practices to lower the barrier of entry for potential new contributors and minimize the workload for existing project members. Two examples to illustrate the point are:

• every PR that is submitted is tested automatically on a CI server; Groovy's committers know if a submission would break tests without having to manually apply and run the tests themselves
• Checkstyle was an important additional check on the Java code sources but doesn't work on Groovy code, so the Codenarc project was created to provide a similar checking framework for Groovy code

It might sound like the project has a heavy-handed set of policies and procedures that developers need to follow but that isn't the case. Indeed, the project's governance, i.e. how it is run, is very lightweight. Good practices are embedded within the project artifacts and practices are encouraged and reinforced as needed. As new contributors join the team, existing committers give guidance as to why things have been done a certain way in the past. We'll come back to say a little more about governance shortly.

One of the commonly heard agile mantras is release early, release often. Certainly Java's historically very slow release cycle and slow adoption of new features is one of the reasons for Groovy's existence. Groovy has tried to improve upon that dramatically, by providing new features much earlier and at a much improved pace. Having said that, sometimes technical issues have even slowed Groovy releases, but that is being worked on. Of course, being a language, we don't want to force our users to have to upgrade every week, so we don't need to be as aggressive as some other projects.

Keeping it fun

While striving for professionalism and quality, the project team has also taken a stance of pragmatics over theoretical purity. Groovy users want to get things done and have fun doing it; the language shouldn't get in the way. With this in mind, Groovy has adopted a somewhat agnostic position on how the language should be used. It supports object-oriented and functional styles, imperative and declarative. It strongly encourages quite a few good practices but doesn't get in the way with the particular style a programmer may choose. It has a somewhat mature approach to how developers should be treated. Try not to let developers shoot themselves in the foot but don't prohibit them from doing so if they really go out of their way to do it.

Continue reading %Groovy, an Open Source Success Story%

by Paul King via SitePoint