The Hidden Risks of Using Lombok in Java Projects

During the Chinese New Year, the author's company issued a statement banning the use of Lombok in new projects, prompting a discussion on why Lombok, despite its convenience, may be problematic.

Without Lombok, a typical JavaBean contains repetitive getter, setter, equals , hashCode and toString methods, as shown below:

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() { return Objects.hash(id, name, age, gender); }
    @Override
    public String toString() { return "MyObject{" + "id=" + id + ", name=" + name + ", age=" + age + ", gender=" + gender + '}'; }
}

After installing the Lombok plugin, the same class can be reduced to a few annotations, making the source appear much slimmer:

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

Lombok also provides composite annotations such as @Data , which automatically generates getters, setters, equals , hashCode and toString :

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

While the code looks cleaner, the author identifies five major pain points:

1. JDK version issues

Upgrading from Java 8 to Java 11 can break Lombok, forcing developers to remove annotations and regenerate boilerplate code manually or with the Delombok tool.

2. Forced adoption

Any project that depends on Lombok requires downstream developers to install the Lombok plugin and understand its annotations, creating a hidden dependency.

3. Poor readability

Generated methods are invisible in the source, making debugging harder and hiding potentially unsafe constructors generated by annotations like @AllArgsConstructor .

4. Increased coupling

Modules that use Lombok force all dependent modules to include the Lombok JAR and IDE plugin, leading to invasive coupling and potential cascade failures when JDK compatibility changes.

5. Cost‑benefit imbalance

Although Lombok reduces boilerplate, it introduces technical debt, reduces code clarity, and can compromise safety; alternatives such as Kotlin or Scala may provide similar conciseness without these drawbacks.

In conclusion, Lombok is a powerful syntactic sugar for Java, but teams should carefully evaluate its impact on maintainability, readability, and long‑term project health before adopting it.