Debunking Common Criticisms of Lombok: A Counterargument

People often claim that companies forbid the use of Lombok, but I find those arguments unconvincing and will refute them point by point.

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 via Delombok, which consumes a lot of time.

My rebuttal: Many companies lock their JDK version for years (e.g., banks still on JDK 1.6) and rarely upgrade; even if newer JDKs appear, they continue using JDK 1.8, and Lombok will eventually support newer versions, eliminating compatibility concerns.

Coercive Use

If your source code uses Lombok, anyone depending on your code must also install the Lombok plugin (regardless of preference) and spend time learning its annotations, otherwise the code won’t compile; this feels like a forced, intrusive practice.

My rebuttal: Installing the Lombok plugin is a work requirement, not a personal choice; Lombok is simple to learn in ten minutes, and programmers are expected to continuously learn new tools.

Poor Readability

Lombok hides JavaBean details; using @AllArgsConstructor generates a massive constructor that allows external code to modify all fields, which can be unsafe and unwieldy when a class has many attributes, and the parameter order is controlled by Lombok.

My rebuttal: If @AllArgsConstructor is undesirable, you can use @Builder to control order and quantity; getters and setters are straightforward and not a readability issue.

Increased Coupling

When a module uses Lombok, all dependent modules must also include Lombok as a dependency and install the IDE plugin, creating invasive coupling; combined with JDK version problems, this can become disastrous.

My rebuttal: Modern projects already depend on many libraries; Lombok is lightweight and commonly added via a Maven parent pom, so forced inclusion is not a problem.

Cost‑Benefit Imbalance

While Lombok feels great initially, it pollutes code, harms Java code integrity, readability, and safety, and adds technical debt; alternatives like Scala or Kotlin might be better for concise code.

My rebuttal: Claiming Lombok destroys integrity while also adding boilerplate is contradictory; learning Lombok takes minutes and most enterprises are not ready to adopt Kotlin at scale.

Feel free to share other viewpoints for discussion.

PS: If you liked my share, please give a like or a view.