Is Project Lombok Worth It? A Year‑Long Developer’s Deep Dive

If you are reading this, you probably already know Project Lombok and are considering adopting it or recommending it to your team. After a year of using Lombok, I share my experience and the pitfalls I encountered.

Love’s beginning, hate’s origin

Installing the Lombok plugin in IntelliJ IDEA is trivial, and the annotations immediately reduce the boilerplate of getters, setters, equals, hashCode, and toString. The code shrinks from a verbose JavaBean to a much slimmer version.

public class MyObject {
    private Long id;
    private String name;
    private int age;
    private int gender;

    // getters, setters, equals, hashCode, toString ...
}

After adding @Getter and @Setter, the same class becomes:

@Getter
@Setter
public class MyObject {
    private Long id;
    private String name;
    private int age;
    private int gender;

    @Override
    public boolean equals(Object o) { /* ... */ }
    @Override
    public int hashCode() { /* ... */ }
    @Override
    public String toString() { /* ... */ }
}

Further, @Data can replace all those annotations with a single line, making the class look extremely concise.

@Data
public class MyObject {
    private Long id;
    private String name;
    private int age;
    private int gender;
}

While the code looks cleaner, several hidden problems arise.

1. JDK version issues

Upgrading a project from Java 8 to Java 11 broke Lombok, forcing me to remove all Lombok annotations and regenerate the boilerplate manually or with the Delombok tool, which consumed a lot of time.

2. Forced adoption

Anyone who depends on code that uses Lombok must also install the Lombok plugin and understand its annotations; otherwise the code will not compile, which feels coercive.

3. Poor readability

Lombok hides the actual getter/setter implementations. Using annotations like @AllArgsConstructor injects a massive constructor that can modify every field, which is unsafe and makes debugging difficult.

4. Increased coupling

Modules that use Lombok force all dependent modules to include the Lombok dependency and plugin, creating invasive coupling and potential disasters when JDK versions change.

5. Cost‑benefit imbalance

Although Lombok reduces boilerplate, it pollutes the codebase, harms readability, and raises technical debt. For a cleaner and safer solution, consider using JVM languages like Scala or Kotlin.

Conclusion

Lombok is a clever syntactic sugar that can make Java code shorter, but it is not a standard library. Its use adds technical debt, reduces readability, increases coupling, and can introduce hidden risks. Teams should discuss carefully before adopting Lombok, especially for large or long‑term projects.