You don't need Lombok anymore. 🌶️ For years, Lombok was the answer to Java's boilerplate problem. Getters, setters, constructors, toString, equals, hashCode... one annotation and done. Unfortunately, a lot of YouTube tutorials and courses are still teaching this practice. But Java has caught up, and it's time to update the playbook. Lombok hooks into javac internals. Every JDK upgrade risks breakage. It's an annotation processor with deep access to your build. That's supply chain risk. Generated code is invisible to debuggers. You can't step through what doesn't exist in source. @Data generates public setters with zero validation. Any code can put your object in an invalid state. Records can fix this. Validate once at construction, no setters to bypass, immutable by default. Even for JPA entities where records don't work, your IDE generates the boilerplate in seconds. It's a one-time cost. My recommendation: stop adding Lombok to new code. Use records for data carriers. Leave plain Java classes for JPA entities only. Migrate gradually. 👉 **The best dependency is the one you don't need. I wrote a full annotation-by-annotation migration guide with before/after code examples for every Lombok feature: 🔗 https://lnkd.in/eHVJ5tQJ #Java #Lombok #ModernJava #CleanCode
Mikalai Sitsko
1mo
Records are good for dto, immutable data. But what about services, entities, others classes? Boilerplate code? About debugging — it works for getters/setters, just setup breakpoints on field. But do we need to debug setter/getter?
Hamza GHANNAM
1mo
Records replaces only immutable classes and you still need lombok for others
Matheus Oliveira
1mo
I don't like lombok either, but many colleagues still uses for the Builder notation
Nuno M.
1mo
That only applies for immutable data like a DTO for example, lombok it's still helpful for JPA entities
Nassim-Niclas Y.
1mo
I couldn't agree more. Also in some high sensitive projects lombock may have code traceability and auditability concerns. See also ISO/IEC 27001
Ramesh Fadatare
1mo
I don’t fully agree. Lombok still plays a key role, especially in JPA entities where records are not suitable due to proxies, mutability, and no-arg constructor requirements. It also simplifies service and controller layers with clean code using annotations like @RequiredArgsConstructor. Builder patterns with @Builder are still more flexible than records for complex object creation. Modern Java reduces boilerplate, but Lombok remains highly practical in real-world Spring Boot applications. Records are great for DTOs and immutable data transfer between layers. They reduce boilerplate significantly and fit well in APIs and projections.
💪🏾 Peter Pilgrim
1mo
The major issue is in the Java programming language. Builder pattern is a work around for named parameters passed to functions, procedures and of course constructors. See Scala and/or Kotlin for details *** Fazit ***: Type Safe Builders https://kotlinlang.org/docs/type-safe-builders.html and Kotlin Builder with Type Inference https://kotlinlang.org/docs/using-builders-with-builder-inference.html Named Arguments in Scala https://docs.scala-lang.org/tour/named-arguments.html Case classes in Scala: https://docs.scala-lang.org/tour/case-classes.html PS: Records have been around since Java 14 and we are now on to Java 26! +PP+ March 2026
Muzaffar Aliyev
1mo
Mostly agree but depends on the use case. Records are great for simple, immutable data. But when a class gets big or starts having logic, they can feel cramped and less readable. In those cases, a Lombok + class gives you more flexibility and structure.
Records are inmutable, it works for some cases but not for all. I make use of lombok in mutable classes and records for inmutable. Also Lombok Data annotation is dangerous when you use it in JPA. Example: 2 Entities A and B with a OneToMany and ManyToOne declared relations. If there is an error and one of those entities is printed, since "toString()" is overrided in both entities, they call themselves in a dead loop. ¿Why? Lombok Data Annotation overrrides toString calling the toString of every single method. This is just an example but I always warn my collegues to use wisely the tools and frameworks and don't delegate parts that they don't know how to work. Have a nice day.
I think the key point is not in creation of new code. It is in its maintainability. The only Lombok annotations I use are: @Getter @Setter, @Builder @RequiredArgsConstructor and @NonArgsConstructor. I usually use records for DTOs when using Java 17+ but I do not like having records for domain. For interactions with JPA implementations, classes are mandatory so...Lombok annotations come in handy.