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!
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.
GraalVM became one of the most popular topics in the JVM ecosystem. It promises the highest possible speed of running JVM-based programs (when compiled to native images), hand in hand with the smaller memory footprint. It sounds interesting enough to give it a try. And today we are going to play around a little bit with running simple Groovy program after compiling to a standalone native image.
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.
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.
GraalVM became one of the most popular topics in the JVM ecosystem. It promises the highest possible speed of running JVM-based programs (when compiled to native images), hand in hand with the smaller memory footprint. It sounds interesting enough to give it a try. And today we are going to play around a little bit with running simple Groovy program after compiling to a standalone native image.
I guess you may heard about Groovy’s Collection.each(Closure cl) method - it was introduced 15 years ago [1] and it was a great alternative for a good old for-loop, for-each or even using an iterator approach. You may also heard, that you should not overuse it, because creating a closure to do such simple operation like collection iteration is an overhead. But what if I tell you that nothing could be further from the truth - Groovy’s each method may be faster than iterator or Java’s for-each. Sounds interesting? Enjoy the reading!
One of the first mistakes people do when starting their journey with Java programming language is using == to compare objects instead calling a.equals(b). When you begin playing around with Groovy you quickly notice that equal operator == is used to compare objects in place of calling a.equals(b). "Finally something more intuitive!" you might think. In today’s article we will dig a little bit deeper to learn avoiding problems equal operator in Groovy may produce.
