Groovy String API offers many useful methods to make working with strings much more pleasant. Today I would like to show you three, not so very popular, yet convenient methods. Let’s jump straight into it!
I started reading "Cracking the Coding Interview, 6th Edition" book recently and it inspired me to experiment a bit. It’s been a while since I implemented the quicksort algorithm the last time, and I did that in Haskell. I remember some old and imperative implementations in Java, but I never tried to implement it in Groovy. Let’s give it a try!
A few weeks ago an interesting question was asked on the StackOverflow. Someone experimented with a recursion in Groovy and stepped into
Closure.trampoline() . It quickly turned out that using
TrampolineClosure makes a recursive execution slower. Is this a valid behavior, or do we do something wrong?
Spock Framework executes test methods (features) in a single class (specification) in the declaration order. There is nothing wrong in this default behavior - we should write tests with their isolation in mind. However, in some cases, we would like to randomize test methods execution. Today we are going to learn how to do it.
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?
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.
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!