Why Lombok Can Turn Your Java Code into a Hidden Liability

If you are reading this, you probably already know Project Lombok and are considering adopting it or recommending it to your team; here are my reflections after a year of using Lombok.

Lombok is a useful Java library that lets you write less code by using a few annotations to eliminate a lot of boilerplate.

However, most source code is meant to be read, and only a little time is spent executing it.

One year ago I, like most people, believed Lombok would improve Java coding experience and strongly recommended it to my team.

After a year, especially when upgrading the Una‑Boot blog system to a newer Java version, I realized Lombok fell into a trick trap.

Analyzing its source and annotation mechanisms showed I didn’t need a non‑standard third‑party library to make Java look sleek.

Introducing Lombok made the project feel great at first, but the cost was accumulating technical debt as the project progressed. Below are several familiar scenarios illustrating how I fell into Lombok’s trap.

Love’s Beginning, Hate’s Origin

Installing the Lombok plugin in IntelliJ IDEA is easy, but the love quickly turns to hate.

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) { /* ... */ }
    @Override
    public int hashCode() { /* ... */ }
    @Override
    public String toString() { /* ... */ }
}

After installing the Lombok plugin, the IDE recognizes annotations and the code becomes much slimmer:

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

You can even remove the explicit toString method with @ToString, and replace all annotations with the combined @Data:

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

While Lombok makes the code look sleek, it also introduces hidden risks.

Distorted Aesthetics, Hidden Hazards

Using Lombok puts your code in an “unhealthy” state, similar to a body that looks fit but is actually compromised.

The core idea of reducing boilerplate to improve readability and maintainability is sound, but Lombok achieves this by injecting methods at compile time, which can obscure the actual code.

1. JDK Version Issues

When upgrading a project from Java 8 to Java 11, Lombok stopped working, forcing me to remove all Lombok annotations and regenerate getters, setters, equals, hashCode, toString, and constructors manually or with the Delombok tool, consuming a lot of time.

2. Forced Adoption

Anyone using code that depends on Lombok must also install the Lombok plugin and understand its annotations; otherwise the code won’t compile, which feels coercive.

3. Poor Readability

Lombok hides JavaBean details; annotations like @AllArgsConstructor generate massive constructors that expose all fields, which can be unsafe and make debugging difficult.

4. Increased Coupling

Modules that use Lombok force all dependent modules to also include Lombok and its IDE plugin, creating invasive coupling and potential disaster when JDK versions change.

5. Cost‑Benefit Imbalance

Although Lombok reduces boilerplate, it pollutes code, harms readability, increases technical debt, and can be risky; using JVM languages like Scala or Kotlin may be a better alternative for concise code.

Conclusion

Lombok is a clever Java library that simplifies code, but it is not a standard Java library; using it adds technical debt, reduces readability, and increases coupling and debugging difficulty.

If you are working on a team or large project, discuss carefully before deciding to adopt Lombok.