A Java geek

The need for shorter and shorter Time-To-Market requires to integrate more and more third-party libraries. There’s no time for the NIH syndrom anymore if it ever was. While most of the time, the library’s API is ready to use, it happens that one needs to 'adapt' it to the codebase sometimes. How easy the adaptation is depends a lot on the language. For example, in the JVM, there are a couple of Reactive-Programming libraries: RxJava, Project Reactor, Mutiny, and coroutines.

Last week, we described several criteria to look at to choose a cache. This week, it’s time to list Java cache providers based on these criteria. Java Caching System Guava Caffeine Ehcache Infinispan Coherence Community Edition Ignite Geode Hazelcast Java Caching System JCS is a distributed caching system written in Java. It is intended to speed up applications by providing a means to manage cached data of various dynamic natures.

Today, I’d like to provide some help on how to choose a cache solution. I will organize it into two parts: In this post, we will list what features a cache must have and which ones it can optionally provide. Most criteria are general and can be used regardless of the tech stack, while a couple is specific to the JVM.In the second part, I’ll list providers and verify their respective capabilities Why cache? First, let’s bust a common myth.

Some time ago, I read a post describing how to run a serverless Kotlin function on OpenFaaS. While the content is technically correct, I believe the concept itself is very wrong. Such posts can lead people to make ill-advised decisions: 'because we can' is hardly a winning strategy. in this post, I’d like to first explain why the JVM platform is a bad idea for FaaS. Then, I’ll proceed to propose alternatives to use Kotlin nonetheless.

Last week, I described different techniques to fasten your Maven builds. Today, I’d like to widen the scope and do the same for Maven builds inside Docker. Between each run, we change the source code by adding a single blank line; between each section, we remove all built images, including the intermediate ones that are the results of the multi-stage build. The idea is to avoid reusing a previously built image. Baseline To compute a helpful baseline, we need a sample project.

Builds require a few properties, chief among them reproducibility. I would consider speed to be low on the order of priorities. However, it’s also one of the most limiting factors to your release cycle: if your build takes T, you cannot release faster than each T. Hence, you’ll probably want to speed up your builds after you’ve reached a certain maturity level to enable more frequent releases.