#23 Reactive Systems in Java
On the Performance of User-Mode Threads and Coroutines. Building a decent Java CLI. The Secret Ingredient of the High Performing Teams.
Welcome to the twenty-third edition of the Dukesletter!
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
— Bjarne Stroustrup
Reactive Systems in Java
The world is becoming digital. There are more interconnected systems and these are becoming more complex.
Our applications need to be responsive (respond in a timely manner), resilient (stay responsive in the face of failure), and elastic (stay responsive under varying workload). We can achieve this by creating message-driven systems.
These are the 4 pillars of the reactive manifesto:
This sounds very nice and we would like our systems to be like this.
How is the code of an application that uses a reactive paradigm? Does it change much from a traditional style?
To answer these questions I recommend you to read “Reactive Systems in Java” in Baeldung. The article is a good and concrete example of a reactive implementation.
It begins with a classic distributed system implementation based on HTTP requests to microservices. After explaining its problems, changes to an implementation based on Spring Reactor, WebFlux, and MongoDB Reactive Driver. Finally, changes the synchronous communication to a Message-Driven architecture based on Kafka.
When will you need to turn your application into a distributed system with microservices? When will you have such a volume of users that you will need to adopt a reactive-based architecture? If creating a hexagonal architecture is already complicated, adding this type of frameworks makes it even more complicated.
These architectures are not free and introduce a lot of complexity. It’s much more difficult to design, evolve, deploy, and debug. These architectural decisions must be supported by data or reasonable expectations, not by trends.
Your code must be decoupled enough to allow its evolution to this type of architecture, but unless you are Netflix or Amazon, I would not adopt it as my first choice.
On the Performance of User-Mode Threads and Coroutines
Project Loom continues its progress, and discussions about it arise: how do user-mode threads offer better application performance than OS threads?
Ron Pressler, the technical lead for OpenJDK’s Project Loom, answers this question in: “On the Performance of User-Mode Threads and Coroutines”.
The article is not technical and does not go into implementation details. Using queueing theory and Little's law, Ron explains that although task-switching costs in virtual threads are less than in OS threads, the real gain lies in being able to increase the number of processes doing real work while keeping their cost down (we can have much more threads consuming few resources by itself).
This idea is important, and will help us to understand better this article “Will Project Loom obliterate Java Futures?”
Also, related to the first entry of this newsletter, Nicolas Fränkel reflects about the impact of Project Loom in the Reactive model paradigm: “On Project Loom, the Reactive model and coroutines”. I am personally more aligned with Nicolas' ideas.
Building a decent Java CLI
Excluding Android platform, probably 99% of Java applications are server web applications, and 1% are desktop applications.
Very few people think of making command-line utilities with Java: it is very slow to start up. Java's great strength, JIT, is its great weakness.
But the arrival of GraalVM has changed everything, and now it is not unreasonable to create command line applications with Java/Scala/Kotlin. GraalVM native compilations produce small executables (hello world application takes only 5.6 megabytes) which starts very fast.
How do you parse command line parameters? do you manage
String args manually or use a library? which are the good practices to define the parameters and help command?
For me, the combination of Picocli + Micronaut + GraalVM is most likely to succeed.
The Secret Ingredient of the High Performing Teams
What makes a High Performance Team? Having a Ninja Developer? Their frameworks? Their tools? Their manager? Probably some of these options are correlated but are not the root cause, when you discover enviously a High Perfoming team in other organization.
Félix López, Sr Engineer Manager at Eventbrite and ex-googler, gives us the secret ingredient: Motivation and Ownership.
Ownership comes when you have autonomy, authority, trust, purpose, and motivation
Even though Felix's picture looks like he's in police detention, he's a good guy and the talk is very good 😄.