This blog post explains the motivation behind removing Project Lombok from one of the projects to which I contribute. It reflects my personal opinion and is not discouraging particular technologies.

About three years ago, I got to know Project Lombok, a library that spices up Java code. I liked it from the beginning as it contributes so much useful functionality. I work a lot with entities (data classes) and value objects, so it does not come as a surprise that @Data or Kotlins data class are very convenient. You get more bang for the buck – literally.
I’m mentioning Kotlin here because it shares some of the properties that we also get from Lombok.

Spring Framework announced recently to ship with support for reactive transaction management.
Let’s take an in-depth look at how this works for R2DBC, the reactive specification for SQL database access.

R2DBC Tour took place in Mid- and North-parts of Germany. R2DBC standardizes reactive integrations with SQL databases as Open Source initiative.

Reactive Relational Database Connectivity (R2DBC) started out as idea to see what’s possible when thinking about reactive programming and SQL databases. Since the last months, R2DBC grew beyond that idea. It inspired driver maintainers and client library authors as common language: A specification for drivers and an interface for library authors so they can build client libraries on top of a vendor-independent SPI. Client libraries are tools that we as application developers need to keep productivity high and not to solve problems that are solved already.

Last year I announced the R2DBC Java User Group and recently I started the tour visiting various user groups and conferences. Reactive Relational Database Connectivity lifts a roadblock when integrating with SQL databases. It’s an Open Source standardized API across multiple database drivers and an ongoing specification effort hosted on GitHub.