Ten little things I love about Groovy
I recently wrote a short introduction explaining why Groovy is still my preferred programming language. The main reason is that I feel very productive when writing Groovy code. I don’t need to spend time keeping the compiler happy. Easy things are just easy. Let me give you a few examples, in no particular order.
Look Ma, no semicolons.
I found semicolons annoying and, in most cases, completely unnecessary. Take a look at this Java code:
Can you see the error? A semicolon is missing in the constructor body. Easy to fix, right? But how come we are almost in 2023 and Java is still unable to fix this automatically? Why does this fail to compile?
Not a problem with Groovy:
This is relatively minor, but semicolons make the code uglier. That’s just me.
Lists (and Maps) are easy to use
It has always bothered me that Java wasted an operator as useful as the bracket in a poor and inflexible data structure like the array. Please, be honest, when was the last time you wanted to use an array rather than a List? Java always refused to provide List literals, but Groovy never made that mistake.
You can use brackets with Lists. You even have a dedicated left-shift operator to add elements to a list. And looping over a list is dead simple with the “each” method.
And, of course, Maps are also simple to use:
The Elvis Operator
One of my favourites.
Safe Navigation
We all have found ourselves in a situation like this, maybe when reading a big chunk of JSON data or dealing with a complicated set of POJOs:
I cannot think of an uglier code. Sure, you can use Optional sometimes, but not always, and it looks overkill. Groovy makes it safer with the “?” operator, which will prevent NullPointerExceptions.
Properties
Astute readers will have noticed that we haven’t used any getters in the Groovy code above. The reason is that Groovy implements properties. A property is declared without any access modifier, and Groovy will generate a backing field, a getter and a setter under the hood.
Going back to having to write (or at least, have IntelliJ automatically generate) getters and setters for a bunch of Java classes is particularly painful and depressing.
Constructors with named parameters
Did you look at the way we created the User object above? We used a feature called named parameters. Please don’t tell me that the code isn’t so much cleaner!
The awesome Spread-dot operation
This is so useful that you have to worry about any language that doesn’t implement it. It can be applied to any collection or iterator, and runs a method on each of the elements of the collection, returning just another collection. Easier to see with an example:
It is so smart that it handles null values properly and doesn’t throw a NullPointerException.
Use == rather than equals.
In Groovy, the == does not compare references. Instead, it executes the equals method. Not only do you save a few keystrokes and get an easier-to-understand expression, but you also avoid a potential NullPointerException. Note the following Java code:
Good IDEs like IntelliJ will warn you about this issue, but most of the time our code won’t be this straightforward. Both variables are null, so they should be considered equals. Instead, a NullPointerException will be thrown. Groovy avoids the problem:
Default Arguments
Again, 2023 is approaching, and Java still lacks default arguments. You can simulate them, but it is ugly and verbose. Here is Groovy:
The Groovy Truth
In Groovy, not only “false” is false. An empty string is also false. And an empty map. And an empty list. This means you can write code like this:
This simplifies the following code, as you don’t need to explicitly check for a null AND an empty list separately:
I feel I could write a “78 things that I love about Groovy” article, but let’s leave it for now. I hope I have motivated you to at least take a look at Groovy. It might not be the coolest kid in the block anymore, but it is still a damn good language. Learn it, you won’t regret it.
