reactive

Mid-January, I held a talk at Kotlin.amsterdam based on my post Migrating from Imperative to Reactive (a Spring Boot application). Because it was a Kotlin meetup, I demoed Kotlin code, and I added a step by migrating the codebase to coroutines. During Q&A, somebody asked whether coroutines implemented backpressure. I admit I was not sure of the answer, so I did a bit of research. This post provides information on backpressure in general and how RxJava (v3), Project Reactor and Kotlin’

Java 15 will see the first release of Project Loom. I believe this will be a game-changer for the JVM. In this post, I’d like to dive a bit into the reasons that lead me to believe that. First, we need to understand the core problem. Then, I will try to describe how previous technologies try to solve it. Afterwards, we will see the approach taken by Project Loom. Finally, I’ll extrapolate on what effects the latter could have on the ecosystem. Threading We first have to remember

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call it magic, and claim it’s hard to understand the flow of the application. It’s IMHO part of a developer’s job to know about some main frameworks. But it’s hard to argue in favor of annotations when there are more annotations than actual code.