Refuting Common Arguments Against Using Lombok in Java Projects

JDK Version Issue

When upgrading a project from Java 8 to Java 11, the author experienced Lombok failing to work, forcing manual removal of Lombok annotations and regeneration of getters, setters, equals, hashCode, toString, and constructors, which is time‑consuming.

Rebuttal: Many companies lock their JDK version for long periods (e.g., banking projects still on JDK 1.6). Even if newer JDKs appear, they often continue using the older version, and Lombok will eventually support newer releases, eliminating compatibility concerns.

Coerced Adoption

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

Rebuttal: Installing the plugin is a workplace requirement, not a personal choice; Lombok is simple to learn within ten minutes, and continuous learning is part of a programmer’s job.

Poor Readability

Lombok hides JavaBean details; for example, @AllArgsConstructor generates a massive constructor that can unintentionally expose all fields, leading to unsafe object initialization, unwieldy parameter lists, and loss of control over parameter order.

Rebuttal: If @AllArgsConstructor is undesirable, developers can use @Builder to create objects in any order and quantity; getters and setters are trivial, and Lombok’s other features mitigate the cited readability issues.

Increased Code Coupling

Using Lombok makes any module that depends on it require the Lombok dependency and IDE plugin, creating invasive coupling; combined with JDK version problems, this can become disastrous.

Rebuttal: Modern projects already depend on many libraries; a small Lombok JAR is routinely added via a Maven parent POM, so forced inclusion is not a significant burden.

Cost‑Benefit Imbalance

The author claims Lombok pollutes code, harms completeness, readability, and safety, and adds technical debt, suggesting a switch to Scala or Kotlin for cleaner code.

Rebuttal: Lombok’s ten‑minute learning curve does not meaningfully increase technical debt, and while Kotlin is attractive, many enterprises are not ready to adopt it widely yet.