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!
If you haven’t heard about Micronaut you have been probably just woken up from deep hibernation. No worries, I’m joking :) Anyway, Micronaut 1.0 GA was released yesterday and it is the right time to play around with it a bit. In this article I would like to show you how easy it is to handle HTTP requests in a non-blocking manner, using just a single computation thread. Interested? Let’s start!
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  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!
I have found Hexo a great tool for building a blog and apply many well-known software development principles. One of them is automation. This is why I have decided to integrate this blog with Travis CI to perform a deployment to GitHub pages. It was a great decision, however a few days later I have noticed one significant issue - deploying a new version of the blog from the CI server caused removing all commits from
master branch and starting with initial commit over and over again. It took me a while to find working solution to this problem. This blog post explains a simple solution to this problem.
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.
Some time ago I have found another interesting Groovy related question on Stack Overflow. This time someone was asking about static variants of popular
methodMissing methods. The official Groovy documentation does not explain how to do it - it only explains how to add any static method through
metaClass. Today we are going to learn how to define these methods in two different ways.
Groovy is a very powerful language on a JVM platform and with this great power comes great responsibility. There are many language features that are not intuitive for many people that start using Groovy. One of these features is dynamic coercion and type promotion which may cause you a headache if you use it carelessly.