Debunking Common Arguments Against Using Lombok in Java Projects

In this discussion, the author challenges widespread claims that companies should prohibit Lombok, presenting counter‑arguments to each alleged drawback.

JDK version issue: While upgrading from Java 8 to Java 11 may temporarily break Lombok, the author notes that many enterprises lock in a JDK version for years, and future Lombok releases will likely support newer JDKs, making compatibility a non‑issue.

Coercion to use: The author argues that requiring Lombok is a workplace policy, not a personal preference, and that developers must adapt to company standards.

Readability concerns: Critics say Lombok hides JavaBean details and generates large constructors, but the author counters that alternatives like @Builder provide flexible object creation and that getters/setters are trivial to understand.

Increased code coupling: Although Lombok adds a dependency that other modules must also include, the author points out that most projects already rely on numerous libraries, and a small Lombok jar is a negligible addition.

Cost‑benefit analysis: The author concludes that Lombok’s productivity gains outweigh perceived drawbacks, suggesting that if developers seek even more concise code they might consider JVM languages such as Scala or Kotlin, though adoption may be limited.

Overall, the piece invites readers to discuss differing viewpoints on Lombok’s impact on Java codebases.