Two years ago, my friend José Paumard held the talk 'Concurrent and Asynchronous Programming : Loom' at the Geneva Java User Group. In his talk, he mentioned that the Spring team would need to completely redesign their approach to transaction: his reasoning was that the transactions are implemented on top of ThreadLocal object and Loom’s virtual threads break this approach.

Recently, I stumbled upon one of Baeldung’s post showing how to use threads to print odd and even numbers: one thread dedicated to print odd numbers, another one to print even ones. Since I became aware of them, I was very interested in Kotlin coroutines and how they make concurrent programming code easier to read and write. I wanted to check how using coroutines would yield better code. Show me the code This is what I came up with: import java.util.concurrent.

I don’t know if events became part of software engineering since Graphical-User Interface interactions, but for sure they are a very convenient way of modeling them. With more and more interconnected systems, asynchronous event management has become an important issue to tackle. With Functional-Programming also on the raise, this gave birth to libraries such as RxJava. However, modeling a problem as the handling of a stream of events shouldn’t be restricted to system events handling.