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.

About krzysztoftomaszewski

I've got M.Sc. in software engineering. I graduated in 2005 at Institute of Computer Science, Warsaw University of Technology, Faculty of Electronics and Information Technology. I'm working on computer software design and engineering continuously since 2004.
This entry was posted in Java and tagged . Bookmark the permalink.

2 Responses to Don’t use Lombok

  1. panhaipeng says:

    Very useful to help me to make a dicision! Thank you!

  2. Brian Silva says:

    Good article, this battle of using or not using Lombok has no winner, some people love it and others hate it. I’m still wondering if I should use lombok, but thanks for your perspective.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s