📊 Poll: Should we discard Lombok 🌶️❌ from Java projects? YES/ DEPENDS/ NO/ IDK
📊 Poll: Should we discard Lombok 🌶️❌ from Java projects? YES/ DEPENDS/ NO/ IDK
💡 Why I Believe Lombok Should Be Discarded from Java Projects
Lombok is often praised as a boilerplate killer. Annotations like @Data, @Builder, or @NonNull look like shortcuts to cleaner code. But behind the scenes, Lombok alters the Abstract Syntax Tree (AST) at compile time, injecting methods and fields into your classes.
While that “magic” feels convenient, here’s why I think Lombok introduces more problems than it solves:
🔹 Increased compilation time – AST manipulation slows builds, especially in large projects.
🔹 Misplaced sense of benefit – @Builder can create objects in invalid states. Explicit domain-driven constructors are often safer and clearer.
🔹 Overreliance on @Data / @Getter / @Setter – Since Java 14, Records provide a native way to model immutable data.
🔹 Null handling – Instead of @NonNull, Java’s own Objects.requireNonNull() is clearer and explicit.
🔹 Compatibility risks – Lombok relies on internal APIs. A new JDK release can easily break builds until Lombok catches up.
🔹 Standards & tooling – Tools that compile with plain javac will fail if Lombok preprocessing is missing.
👉 In the end, Lombok doesn’t just reduce boilerplate — it creates a “Lombok Java dialect” that makes codebases harder to maintain and less aligned with Java’s evolving ecosystem.
With modern Java features like Records, pattern matching, sealed classes, and powerful IDEs, Lombok feels less like a necessity and more like a fragile shortcut.
🚀 My take: it’s time to move away from Lombok and let Java itself shine.
Do you agree, or do you think Lombok still has a place in today’s Java projects? Cast your vote above ⬇️ and share your thoughts in the comments 👇
Full article:
by Ivelin Yanev on Sep 1, 2024