The journey inside the exciting world of GraalVM continues. Today I would like to share with you results of running Ratpack on GraalVM experiment. You are going to learn how to build a native binary of a simple "Hello, World!" Ratpack application. In the end we are going to run some benchmarks to see if running GraalVM executable produces better results than running JAR on a regular Oracle JDK.
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.
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.
This is the second blog post in "Programmer’s Bookshelf" category, and today I would like to share with you my opinion on the "Deep Work" book by Cal Newport. It’s not about programming, but it’s still beneficial to any software developer out there.
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.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.
The 4th edition of Advent Of Code just started! In this short blog post, I would like to share with you some of my thoughts about it and why I participate in this event for the second time in the row.
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.