The Hidden Pitfalls of Using Project Lombok in Java Development

Project Lombok is a popular Java library that generates boilerplate code such as getters, setters, equals , hashCode and toString through annotations, promising a cleaner and more concise source code. The author, after a year of using Lombok, shares personal experiences and concerns that arose when trying to upgrade a large project.

Before Lombok, a typical JavaBean looks like this:

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) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        MyObject obj = (MyObject) o;
        return age == obj.age &&
               gender == obj.gender &&
               Objects.equals(id, obj.id) &&
               Objects.equals(name, obj.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, name, age, gender);
    }

    @Override
    public String toString() {
        return "MyObject{" +
               "id=" + id +
               ", name=" + name +
               ", age=" + age +
               ", gender=" + gender +
               '}';
    }
}

Adding Lombok's @Getter and @Setter reduces the visible code dramatically:

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

    @Override
    public boolean equals(Object o) { /* same implementation as before */ }
    @Override
    public int hashCode() { return Objects.hash(id, name, age, gender); }
    @Override
    public String toString() { return "MyObject{" + "id=" + id + ", name=" + name + ", age=" + age + ", gender=" + gender + '}'; }
}

Further reduction is possible with @EqualsAndHashCode and @ToString , and finally the combined @Data annotation eliminates all explicit method definitions:

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

Despite the visual brevity, the author points out several serious drawbacks:

1. JDK version issues

When upgrading from Java 8 to Java 11, Lombok stopped working, forcing the removal of all Lombok annotations and regeneration of boilerplate code, which is time‑consuming.

2. Forced dependency

Any downstream project that consumes code annotated with Lombok must also install the Lombok plugin and understand its annotations, otherwise the code will not compile.

3. Reduced readability

Generated constructors (e.g., @AllArgsConstructor ) can contain dozens of parameters in an order dictated by Lombok, making debugging and understanding the class difficult.

4. Increased coupling

Modules that use Lombok force all dependent modules to include Lombok as a transitive dependency, creating invasive coupling and potential version conflicts.

5. Cost‑benefit imbalance

The short‑term convenience is outweighed by long‑term technical debt, reduced code safety, and maintenance overhead; the author suggests considering JVM languages like Scala or Kotlin for truly concise code.

In summary, Lombok offers a clever way to cut boilerplate but introduces hidden risks that can degrade code quality, readability, and maintainability, especially in large or evolving projects.