Groovy Cookbook

In the second part of the "Groovy Regular Expression" blog post, I want to show you some benchmarks. And let me make one thing clear - the following results you are going to see are not scientific proof. I present those results only to give you a hint about the overall performance of some cool features you have seen before.

Welcome to "Groovy Regular Expressions - The Definitive Guide"! In the next 15 minutes, you are going to learn everything you need to start working productively with regular expressions in Groovy programming language. Let’s get started!

One of the most interesting Groovy features is its ability to configure advanced compiler^[1] options using DSL script. It becomes handy when you want to apply some global modifications to all Groovy classes. (For instance, you want to add @CompileStatic annotation to all classes, without applying changes to the source code). In most cases, you want to add something to the existing source code, e.g., classes imports or useful annotations, but what if we want to remove one annotation or another?

We have learned how to create GraalVM native image from standalone Groovy script in the previous blog post. Today we continue the experiments, and this time we are going to create a Docker image to see what are the benefits and drawbacks of this solution.

The Apache Groovy programming language has extraordinary scripting capabilities. When you combine it with the Grape dependency management system, it turns out that the sky is the limit. In one of the previous blog posts, I explained how you can start compiling Groovy code to the native binary files, using GraalVM’s native-image compiler. This time I tried to do the same with the Groovy script that uses Grape to provide an external library to the classpath. I thought it won’t be possible, but luckily - I was wrong.

Spock Framework is one of my favorite tools in the Groovy ecosystem toolbox. It makes writing automated tests a few times more pleasant thanks to its opinionated syntax. From time to time I see some corner cases where Spock behaves unexpectedly. Today I would like to show you one of these corner cases and explains what happens under the hood.

Ignoring some of the unit tests when given conditions are not satisfied is a handy feature of a JUnit framework. I guess you have used many times constructions like Assume.assumeTrue(expr) or Assume.assumeNotNull(expr) in your test code. Today I would like to show you one pretty interesting corner case when the usage of Assume.assumeNotNull(expr) throws NPE in the unit test written in Groovy.

Groovy has many useful functions built-in, and one of them is Iterable.combinations() that takes aggregated collections and finds all combinations of items. However, if we take a look its source code, we will find out that it was implemented using very imperative approach (nested for-loops + some if-statement). In this blog post I will show you how to implement the same function using Groovy and tail-recursion algorithm. Enjoy!

Most of the object-oriented programmers prefer constructing algorithms using imperative style over using recursion. This is pretty obvious in the JVM ecosystem, where imperative iteration is much more efficient than recursive function call chain. However, what if I tell you that in Groovy you can take advantage of clean tail-recursive functions without sacrificing performance? Interested? Let’s deep dive into it.