Recently, Project Lombok celebrated its 10th birthday. This framework has proven its merits in replacing boilerplate Java code with clear and concise annotations. The project in which I’m currently involved started using it about a year ago, and for us, it’s been quite a success. Let’s run over what we’ve liked and disliked about it.

Java is notorious for its verbosity. Even the simplest of POJOs looks cumbersome:

While it’s true that constructors, getters and setters can be autogenerated nowadays, it doesn’t prevent the average class from being, basically, a mess. If I have to work on a class, I want to focus on its logic, without being distracted by lots of repetitive code that’s never going to be touched anyway.

Enter Project Lombok.

Here’s the same class, devoid of any boilerplating:

Even considering it is a class with just 2 properties, it’s almost hilariously shorter and more concise. Now think of your average JPA entity class with, say, 6 properties: instant profit!

Lombok’s website, though very ugly, does a good job documenting all the goodies this framework has to offer. Nonetheless, here’s another peek at Lombok’s niceties, specifically @Builder . Just look at that second example: isn’t this gorgeous?

Having seen what Lombok has to offer, we were impressed.

Now, about a year ago, our project was facing a major datamodel overhaul. All entity classes were going to be rewritten from scratch, and just to give it a try, we went Lombok. Enjoying the much more readable code, we all agreed this was a success!

The good thing about it is that you can take a gradual approach to implement it. Not being in any hurry, other parts of our project were migrated at our leisure.

Looking back, after using it for a while, there are some things worth noting:

IDE support

It seems that every major IDE has support for Lombok. However, new or experimental features can cause issues when the plugin is not up-to-date. In our case, we have been using @SuperBuilder  for a while with this being the case. In the end, even though the IDE might be complaining, compiling will work of course. Still, the IDE errors were a bit annoying.

JDK support

Not something we had to cope with ourselves, but due to the very nature of Lombok, a new JDK means Lombok will break, and will need changes to work again. As an example, Lombok support for JDK 1.9 came out 3 months after the JDK itself. If you’re on the bleeding edge, this will be an issue.


Should you want to place a breakpoint inside of a Lombok-generated method, you need the Delombok functionality (probably included in your Lombok IDE plugin). Not a scenario that pops up often, but still something to keep in mind.

Version updating scheme

The version numbering is a bit suspect. For example, the 1.18.2 -> 1.18.4 update mentions 2 breaking changes. Not something you would expect from such an apparent minor update.

It’s addicting

Once you go Lombok, it’s tough to go back. After having become used to all this nice and tidy code, running into a non-Lombok class with zillions of getters and setters brings tears to your eyes.


Over the last 10 years, Lombok has built a definite fanbase. Why not give it a try yourself: here’s a YouTube playlist that guides you through its features quite neatly.