In my last blog post, I gave you an introduction to reactive programming that was meant to explain when to use and, even more important, when not to use reactive programming. This emerging programming paradigm is initially anything but easy to grasp. The abstraction level is relatively high and there are a few rules for dealing with publishers and subscribers that you need to adhere to.

One of the most difficult things at the beginning is to start thinking reactive. To do so, it is helpful to get to know a few essential reactive operators and just play around with…

Reactive Programming has long since begun its journey from pure web applications to Java Enterprise applications. It promises higher performance and lower memory footprints through the use of asynchronous non-blocking calls.

Most likely, you already read some documentation and blog posts about Reactive Programming or one of its implementations in Java. In this series, it is not my intention to go into the deep details of how to program using one of the existing Reactive frameworks. I will rather elucidate what it actually means to use reactive programming and what obstacles are going to await you. Common things like debugging…

Every programmer knows this situation. At some point, you come across a piece of code that is so full of nested if, else and case statements that you sit in front of the screen shaking your head for a while. The reasons for code like this are numerous. The application may have grown historically over the years. The knowledge gap between the individual developers may be relatively large. Maybe, the project plan did not allow time to remediate technical debts.

Reducing branch complexity is quite important for maintainability reasons. It simplifies reasoning about the code. …

In all of my recent projects as a consultant, a microservice architecture was selected to reduce the interdependency between business functionality by organizing services around business capabilities. In these projects, JSON over HTTP (in a more or less REST-ful way) is usually the first choice for inter-service communication.

Don’t get me wrong! JSON is absolutely fine for many use cases, being a human readable data interchange format with a wide range of adoption. But especially in high-performance environments or for pure machine-to-machine communication, there are more concise and efficient alternatives. One of them is Protocol Buffers.

Protocol Buffers is a…

Speaking with some developers (mostly having a Java background) you will sooner or later hear a quotation like “Optional is a safe way for handling null”. Programmers on the JVM to a great extent mistakenly use the Option type (known as Optional in Java) to just handle null values as a sophisticated alternative to if(x == null) do this else do that.

Having to handle null in Java is so omnipresent that this conclusion is quite easy to draw. But this is just a Java-biased view and was never the intention for the concept behind Optional. …

Bei einem Gespräch mit einem Arbeitskollegen, der aktuell die Kombination Spring + Kotlin in einem Projekt einsetzt, ist mir die Idee für diesen Blog-Artikel gekommen — wie gut lassen sich Scala (meine favorisierte Programmiersprache) und Spring (ein großartiges Framework) mittlerweile in einer Anwendung miteinander kombinieren? Bei Kotlin scheint dies nach einhelliger Meinung hervorragend zu funktionieren dank nativem Support seitens Spring. Für diejenigen, die sich auch für Kotlin interessieren, sei hierfür auf diesen Blog-Artikel verwiesen: 7 things any Java developer should know when starting with Kotlin

Es gab zahlreiche Versuche, Erweiterungen für Spring zu schreiben, die den nativen Umgang mit dem…