I’ve never enjoyed working with regular expressions in Java. It was always very error-prone. You had to remember to escape backslashes, and a very simple match elements check required writing at least 5 lines of code. Booooring. However, Groovy solved most of these issues, and today we are going to take a closer look at features like pattern operator, find operator or exact match operator. We will focus on learning the new syntax, as well as measuring and comparing its performance. Let’s begin!
One of the most interesting Groovy features is its ability to configure advanced compiler 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?
GraalVM 1.0.0-RC11 was released yesterday, and I thought it would be an excellent excuse to play around with it a while. I decided to create a simple Groovy script that uses Grape dependency management system to load an external library and create a standalone native image from it. I thought it wouldn’t be possible, but luckily - I was wrong.
When I get the paperback copy of the "Programming Groovy 2" book back in the June 2017, I was wondering if I can find something new or exciting in the book that was written in July 2013. It took me almost 1,5 year before I have finally put the book on my desk and started reading and playing around with the examples. As a veteran Groovy developer, I have to say - it was worth it!
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.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.
In this short blog post I would like to explain how to avoid popular mistake when you write your first JUnit 5 test case in Groovy.