The Hidden Pitfalls of Using Project Lombok in Java Development

If you are reading this, you probably already know Project Lombok and are considering adopting it for your Java projects. After a year of using Lombok, the author shares personal experiences that reveal both the allure and the hidden costs of the library.

Initially, Lombok appears attractive because a few annotations can eliminate a large amount of repetitive getter, setter, equals, hashCode, and toString code. The author shows a typical JavaBean before Lombok, which contains verbose boilerplate:

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(){ /* ... */ }
}

After installing the Lombok plugin, the same class can be reduced to:

@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 reduction is possible by adding @EqualsAndHashCode, then @ToString, and finally the composite @Data annotation, resulting in a class that contains only field declarations:

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

While the code looks much slimmer, the author points out several serious drawbacks:

JDK version issues: Upgrading from Java 8 to Java 11 broke Lombok, forcing the removal of all Lombok annotations and regeneration of boilerplate code.

Forced adoption: Any consumer of a Lombok‑annotated library must install the Lombok plugin and understand its annotations, creating an unwanted dependency.

Readability problems: Lombok hides the actual generated methods, making it hard to know what constructors or builders exist, especially when using @AllArgsConstructor.

Increased coupling: Modules that use Lombok force all dependent modules to include Lombok’s JAR, leading to invasive coupling and potential build‑time conflicts.

Cost‑benefit imbalance: The short‑term convenience is outweighed by the long‑term technical debt, reduced code clarity, and maintenance difficulty; alternatives like Kotlin or Scala may be preferable.

In summary, Lombok is a clever syntactic sugar that can reduce boilerplate, but it is not a standard Java library and brings hidden risks. Teams should weigh the benefits against the potential increase in technical debt, readability loss, and coupling before deciding to adopt it.