Lombok After One Year: Is the Convenience Worth the Hidden Costs?

Project Lombok is a Java library that uses annotations to generate getters, setters, equals, hashCode, toString, and constructors at compile time, reducing boilerplate code.

Initially the author praised Lombok for making code slimmer, but after a year of real‑world use on a Spring Boot 3 + JDK 17 e‑commerce project, several drawbacks emerged.

Code before Lombok

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

    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }
    public int getGender() { return gender; }
    public void setGender(int gender) { this.gender = gender; }

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

Code with Lombok annotations

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

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

Further reduction is possible with @EqualsAndHashCode, @ToString, and finally the combined @Data annotation, which eliminates all explicit methods.

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

Why Lombok can be problematic

1. JDK version issues

Upgrading from Java 8 to Java 11 broke Lombok in the author’s project, forcing a manual removal of annotations or use of the Delombok tool, which consumes considerable time.

2. Forced adoption

Consumers of a Lombok‑annotated library must also install the Lombok plugin and understand its annotations, creating an unwanted dependency.

3. Reduced readability

Generated constructors and methods are invisible in source code, making debugging harder and allowing unsafe bulk constructors via @AllArgsConstructor.

4. Increased coupling

Any module that depends on a Lombok‑enhanced class must also include Lombok on its classpath, introducing invasive coupling and potential build failures.

5. Cost‑benefit imbalance

While Lombok shortens code, it compromises code integrity, readability, and maintainability, often adding more technical debt than it saves; alternatives like Kotlin or Scala may be preferable.

Conclusion

Lombok offers a clever syntax‑sugar for Java, but teams should weigh its convenience against the long‑term risks of hidden boilerplate, version incompatibility, and tighter coupling before adopting it in production projects.