Critiquing Lombok: Common Objections and Counterarguments

JDK Version Issue

When upgrading a project from Java 8 to Java 11, Lombok may stop working, forcing developers to remove annotations and manually generate boilerplate code, which is time‑consuming.

Rebuttal: Many companies lock their JDK version for years; even when newer versions appear, they continue using the same JDK, and Lombok will eventually support newer releases, eliminating compatibility problems.

Coercive Use

If a codebase uses Lombok, downstream developers must install the Lombok plugin and learn its annotations, otherwise the code will not compile, which the author describes as intrusive.

Rebuttal: Using Lombok is a simple skill that can be learned in minutes, and developers are expected to adapt to required tools as part of their job.

Poor Readability

Lombok hides JavaBean details; annotations like @AllArgsConstructor generate large constructors that expose all fields, making the class unsafe and hard to control, especially when many fields exist.

Rebuttal: Developers can use alternatives such as @Builder to control parameter order and quantity, and the generated getters/setters are straightforward to understand.

Increased Code Coupling

Modules that depend on Lombok require the Lombok JAR and IDE plugin, creating invasive coupling and potential disaster when JDK version mismatches occur.

Rebuttal: Modern projects already depend on numerous libraries; Lombok is lightweight and commonly added as a parent dependency, so the coupling impact is minimal.

Not Worth the Trade‑off

The author claims Lombok pollutes code, harms readability and safety, and adds technical debt, suggesting alternatives like Scala or Kotlin.

Rebuttal: Learning Lombok takes only minutes, and while Kotlin offers similar benefits, it is not yet widely adopted in many enterprises.