Why Banning Lombok Is Misguided: A Technical Rebuttal

JDK Version Issues

When upgrading a project from Java 8 to Java 11, Lombok may stop working, forcing developers to remove Lombok annotations and regenerate boilerplate code manually or with Delombok, which consumes significant time.

Counter‑argument: many companies lock their JDK version for years (e.g., JDK 1.6 or 1.8) and are unlikely to upgrade soon; future Lombok versions will support newer JDKs, so compatibility concerns will disappear.

Forced Adoption

Using Lombok requires every consumer of the code to install the Lombok plugin and understand its annotations, otherwise the code will not compile, which some view as intrusive.

Counter‑argument: plugin installation is a company policy, Lombok is easy to learn in minutes, and refusing to use it limits productivity.

Poor Readability

Lombok hides JavaBean details; @AllArgsConstructor generates a massive constructor exposing all fields, which can be unsafe and unwieldy, especially for classes with many attributes, and the parameter order is uncontrolled.

Counter‑argument: developers can use @Builder to control object creation, and getters/setters are straightforward to inspect.

Increased Coupling

Modules that use Lombok force all dependent modules to include Lombok as a dependency and install its IDE plugin, creating invasive coupling and potential disaster when combined with JDK version issues.

Counter‑argument: large projects already manage many dependencies; Lombok is lightweight and often added centrally via a Maven parent.

Cost‑Benefit Imbalance

While Lombok speeds up coding, it can pollute codebases, reduce readability and safety, and increase technical debt; alternatives like Kotlin or Scala may offer more concise syntax without these drawbacks.

Counter‑argument: learning Lombok takes minutes, and adopting Kotlin or Scala may be unrealistic for many enterprises.

Readers are invited to share their own viewpoints.