“Project Lombok is a java library that automatically plugs into your editor and build tools, spicing up your java.
https://projectlombok.org/
Never write another getter or equals method again”
If you’re a Java developer, you’ve probably been exposed to Lombok through @Getter, @EqualsAndHashCode, @Builder, or one of Lombok’s many other helpful annotations. Lombok is an amazing library for generating boilerplate code, and it works great. I’ve used it for about 8 years, as long as I’ve been programming in Java, and it just works. Most of the time, anyway.
If Lombok works, why get rid of it?
There’s a simple formula for productivity tools that applies to Lombok as well as any other:
Time Saved must be greater than Time Spent configuring and debugging the tool
If you’re not getting value from your productivity tools, you should look for alternatives. Over time, I found that Lombok often cost more time than it saved, due to debugging and integration issues.
Lombok errors generally manifest into the following categories:
- Classpath or IDE problems: Slight misconfigurations in a user’s environment could cause Lombok annotations to fail, resulting in various compile-time errors. These types of errors are a pain to debug, as the code will compile in your environment, but not a user’s.
- Problems with other libraries: Sometimes Lombok doesn’t mix well with other modules, like a generated equals method on a JPA entity that causes infinite recursion. This leads to rules like “Don’t use
@EqualsAndHashCodeand@Dataon JPA entities, but use Lombok for everything else”. - Abstraction of simple boilerplate: If you’re familiar with Lombok, this is fine. If you’re not? You might end up applying annotations on your classes without really understanding what they do, generating code that differs from your assumptions. You may say this is a user-error issue, and I agree, but it’s one that’s all too common for many Lombok use cases.
The result? I was spending time helping other developers debug why their Getter and Setter methods weren’t compiling. This is a waste of time, and led me to “de-lombok” (remove Lombok) from a project I maintain.
What am I going to use instead?
I’ll write or generate the boilerplate myself.
Lombok annotations generally apply to code that is trivial to write yourself. In many cases, your IDE can generate it for you: getters, setters, constructors, equals, hashcode, etc.
Writing your own boilerplate is straightforward, fast with IDE shortcuts, and results in code that’s explicit and easy to read. I can generate getters and setters for a class using IntelliJ with (⌘) + N just as fast as I could add @Getter and @Setter annotations.
What Lombok features will I miss the most?
Getters, setters, constructors, and other methods are easily generated by any modern IDE with reasonable Java support. But Builders? I really liked the @Builder annotation, as builders involve a bit more code and many IDEs or AIs can’t generate them properly. For example, there’s a Builder plugin for IntelliJ, but it doesn’t quite work the way I’d like it to (yet). For now, I’ll stick to writing my own builders.
Note: Builders with Lombok weren’t a silver bullet. When using abstract classes and inheritance, things could get really weird. The @SuperBuilder annotation was added to assist with this.
I’ll also miss how Lombok also transparently updates methods as you modify a Java class, like when you add a new field. This is a really, really cool feature, as it saved me the trouble of remembering/having to do it myself.
Final Thoughts
This article represents my own personal experience with Lombok, and isn’t a call for developers to “never use Lombok”.
Lombok isn’t perfect. But neither is duplicating thousands of lines of boilerplate by hand. If you’re a developer, this is a contextual choice, not a binary one. Rather than “de-Lomboking” a project wholesale, the better question is: Where does Lombok help more than it hurts? For me, the answer was “not often”.
Leave a Reply