coroutines

You may know I’m a big fan of OpenTelemetry. I recently finished developing a master class for the YOW! conference at the end of the year. During development, I noticed massive differences in configuration and results across programming languages. Even worse, differences exist across frameworks inside the same programming language. In this post, I want to compare the different zero-code OpenTelemetry approaches on the JVM, covering the most widespread: Spring Boot with Micrometer Tracing

I recently compared three OpenTelemetry approaches on the JVM: Java Agent v1, v2, and Micrometer. I used Kotlin and coroutines without overthinking. I received interesting feedback on the usage of @WithSpan with coroutines: Nice one..by the way to instrument the coroutine context properly, don't we need "opentelemetry-extension-kotlin" also? Without that, spans are not recorded properly for suspend functions (https://t.co/DSgJklnllD) pic.twitter.com/5wDwhYhoDM— Suresh G (@sur

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’

Last September, I wrote how to migrate from an Imperative Programming codebase to a Reactive Programming one in a step-by-step process. Because of its popularity, I illustrated the post with a Spring Boot demo. The final result uses Mono and Flux from Project Reactor. I also made sure that no step in the processing pipeline is blocking thanks to Blockhound. I wrote the code in Java so that it could be accessible to the largest audience. But I’m still a Kotlin fan at heart. Hence, I ported

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