Don’t use Lombok

Some time ago I’ve responded to a question “What are the risks with Project Lombok?” on StackOverflow. My answer got some positive attention so I’ve decided to share it here:

In my opinion source code in “Java+Lombok” is not Java source code anymore. I see it as something similar Borland company made many years ago in their Borland C++ Builder IDE for VCL – they introduced “properties” in C++ code effectively introducing some kind of a new programming language that wasn’t C++ anymore (not C++ in sense of standard of C++ language). Sources using “Java+Lombok” are not valid sources in sense of Java language specification. Moreover I think annotations were not designed to influence language semantic.

Now I can add that polluting Java code with lots of Lombok annotations have more disadvantages:

• It really starts to be confusing as the number of Lombok annotations added for a single Java class gets bigger and bigger – and I’ve seen such cases in the wild! Let just imagine all these @ToString, @EqualsAndHashCode, @NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor together. And some of these annotations can have parameters which make things a lot more complex when used. And of course these annotations are stacked on other annotations like annotations related to ORM (JPA, Hibernate), Bean Validation or serialization (JAXB, Jackson).
• It works when you use Java 8 but try to migrate to newer Java: let it be 9, 10 or 11. You will quickly notice how huge technical debt Lombok added to your project! For those unfamiliar with the topic: Lombok is making use of hackish internals of Java and it will not work with newer Java editions that introduced modularization.

It can be even worse. In last year I’ve witnessed a runtime error in JSON marshalling/unmarshalling caused by… some unknown reason. My colleague couldn’t track it down. I’ve advised to remove Lombok annotation from the model class in question and… it helped! Unfortunately I couldn’t reproduce it later.

Then I found this blog post:

“Don’t use Lombok” by Gonzalo Vallejos

(yes, I’ve used the same title 🙂 ). Really good analysis and summary. I recommend reading it if you consider using Lombok.

My conclusion

It’s not worth to bind the Java code to Lombok annotations risking all mentioned drawbacks when every modern Java IDE is providing code generation for getters, setters, constructors, equals, hashCode and toString methods. All this available just within couple of mouse clicks! And more than 12 years of my professional career clearly tells me that it isn’t this “boilerplate code” that make problems in Java projects. So don’t make false assumption that Lombok will add anything good.