java

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.

Welcome to the part 3 of "Non-blocking and async Micronaut" article. In the previous post we have created connection between two services using HTTP protocol and we have run some experiments with handling 10,000 requests. Today we are going to extend this example by setting some timeouts to see what happens.

Yesterday I have found this interesting question on Stack Overflow asked by Opal. He faced some unexpected compilation errors when dealing with Java generics and Vavr library. It turned out the root cause of the issue there was not the library, but Java compiler itself. This was pretty interesting use case and it motivated me to investigate it even further. This blog post reveals untold truth about Java generics type inference. Are you ready? :)

Welcome to the part 2 of "Non-blocking and async Micronaut" article. In the previous part we have explained the idea behind this demo and we have implemented product-service - a simple endpoint that returns information about some products. Today we will focus on implementing recommendations-service part and we will run some simple benchmark tests. Let’s start!

Micronaut framework inventors says it is designed for building modern microservice applications. It supports reactive and non-blocking HTTP requests processing thanks to a powerful network application framework - Netty. In this blog post I will give you a quick and practical introduction to a asynchronous HTTP requests processing using a simple demo application. No more talking, it’s time to make our hands dirty with some Micronaut application code!

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.

Every Java developer works with lists daily. There are many popular list (or collection) operations implemented in the standard Java 8 library, but there is one that is useful and commonly used, yet missing - partitioning. In this blog post, I would like to show you how you can split any list into chunks of fixed size without using any 3rd party library. Let’s start!