Groovy in light of Java 8

I gave a talk at the last Spring One 2GX on the effect of Java 8 on Groovy. It’s a long presentation (well over an hour), so I think a nice summary is in order for those that don’t have the time to watch the whole thing.

Groovy and Java have a fairly long history together, with Groovy having passed it’s 10th anniversary already. I guess there were probably several goals for Groovy when originally envisaged, but when I discovered it, I definitely saw the language as a productive alternative to pure Java. This was back when dynamic languages were all the rage and Java (the language) had seemed to stagnate. Two of the most important features that contributed to Groovy’s improved productivity were closures and its extensions to the collections API.

Fast forward to today, and Java 8 has incorporated higher order functions in the form of lambdas and brought us a new stream API that makes full use of them. These two features combined represent a big leap in developer productivity once you learn how to use them. Because of this, many people wonder whether Java 8 pushes Groovy into irrelevancy.

Let me start by highlighting some of the current benefits of Groovy:

  • Makes writing scripts very easy, with some great enhancements to the JDK class library
  • Has better literal support (regular expression patterns and multi-line strings)
  • Has syntax support for regular expression matching
  • Supports operator overloading
  • Has built-in property support
  • Supports coercion of various types to Boolean, allowing for more succinct conditions
  • Built-in support for generating and parsing both XML & JSON
  • Traits for something akin to multiple inheritance
  • Works on Java 6 and above VMs (such as Android!)

In essence, I still think that Groovy is significantly more expressive than Java and allows for code that’s easier to read and comprehend. Even developers that hate dynamic languages now have the option to enable static type checking in Groovy via the @TypeChecked and @CompileStatic annotations. The latter of these results in code that’s about as fast as Java too.

Does this mean I think all Java developers should be using Groovy? Probably, but not for everything. Let’s consider some of the advantages of Java:

  • Stable language and runtime
  • Less affected by JVM bugs than other languages such as Groovy
  • Other JVM languages have to integrate with it
  • Few binary incompatibilities
  • Large pool of developers

And even though I think Groovy’s static compilation feature is great, it’s relatively new and somewhat risky to use everywhere. I see it more as a way to improve the performance of a hotspot in a Groovy application than as something to use throughout an entire app.

Ultimately, Groovy and Java are more friends than competitors. The real difficulty is knowing when to use one over the other. That’s a whole other blog post. But even if you start with Groovy and find that, for whatever reason, you’re better off sticking to Java, it’s not that hard to convert between the two. It’s not exactly trivial, but the similarity in syntax and the shared class library make the transition easier than between other languages and Java.

One final thing to note: improvements in the Java class library and runtime also benefit Groovy. As a case in point, you can use the new stream API directly from Groovy with closures in place of lambda functions. In fact, if you’re already a Groovy developer and are allowed to use the Java 8 runtime, I encourage you to do so. The stream API is great!

Update I just want to clarify the statement about @CompileStatic because it may seem rather dismissive. It’s now about 2.5 years old and most of the critical and major bugs have been quashed. It’s popular, but there is little information on how widely or extensively it’s used. Android development is likely to ensure a big uptake in @CompileStatic though, so I can see it becoming as reliable as Groovy itself within a year. Ultimately it’s about assessing the risk on a particular project before deciding whether and how extensively to use it.

3 thoughts on “Groovy in light of Java 8

  1. Pingback: Settimanale Groovy #53 | BME

  2. Peter Post author

    I know of at least one JVM issue that specifically affects Groovy, but if I remember correctly, it does affect others too. I’d be surprised if there is any alternative JVM language (such as Scala) that hasn’t at some point been affected by a JVM bug that doesn’t impact Java the language.

Leave a Reply

Your email address will not be published. Required fields are marked *