Avoid Lombok @Data as the default on JPA entities because it generates more than accessors: field-based equals, hashCode, and toString, plus a required-arguments constructor that is not a dependable substitute for JPA’s required no-argument constructor. It does not make every entity fail, but it can quietly impose constructor, mutability, and identity choices that should be made deliberately.
What @Data generates—and why that matters
Project Lombok describes @Data as a shortcut bundling @Getter, @Setter, @ToString, @EqualsAndHashCode, and @RequiredArgsConstructor (Lombok’s @Data documentation). It generates public getters, setters for non-final fields, and methods based on fields by default. An explicitly declared constructor suppresses the constructor generation that @Data would otherwise provide.
As an Amazon Associate I earn from qualifying purchases.
The concern is not simply the number of generated methods. Each method affects a different part of an entity’s design: how the persistence provider instantiates it, which fields callers can change, what gets logged or displayed, and what the application treats as the entity’s identity.
Recommended Free Tools
The constructor may not meet JPA’s requirement
The released Jakarta Persistence 3.2 specification requires an entity class to have a public or protected constructor with no parameters; the persistence provider uses it to instantiate the entity. It also requires entity classes to be non-final, with no final methods or persistent instance variables (Jakarta Persistence 3.2 specification).
@Data generates a required-arguments constructor, not an unconditional public or protected no-argument constructor. In a class with no required-argument fields, that generated constructor may happen to have no parameters. That coincidence is not a safe general guarantee: adding a required field can change the generated constructor, and writing a constructor suppresses the generated one.
If you use Lombok on an entity, declare the required constructor explicitly, for example with @NoArgsConstructor and an appropriate visibility, or write the constructor yourself. Lombok documents @NoArgsConstructor separately and notes that frameworks such as Hibernate require a no-argument constructor (Lombok constructor annotations).
Rank #2
Generated equality can conflict with entity identity
By default, Lombok’s @EqualsAndHashCode includes non-static, non-transient fields. That means an entity’s equality and hash code may depend on ordinary field values rather than a deliberately chosen identity policy (Lombok’s equality documentation).
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →That choice deserves care because entity fields can change during the object’s lifecycle. If a field included in hashCode changes while the object is in a hash-based collection, the object may no longer be findable in the bucket where it was placed. Generated equality may also involve fields whose values are not a suitable definition of persistent identity, including relationships or mutable business data.
Lombok documents a generated canEqual method intended to support equality between JPA proxies and their base classes. That proxy accommodation is useful, but it does not establish that including every non-static, non-transient field is right for a particular entity. Choose equality according to the entity’s key, lifecycle, inheritance, and relationship model; do not treat the annotation’s defaults as an identity policy.
Generated toString can expose relationships and mutable state
@Data also generates toString using fields by default. On an entity, that may pull associations or other fields into a log message or debugging output. Whether that causes trouble depends on the mapping and runtime context, so it is not a guaranteed failure. It is still a reason to decide explicitly which values are safe and useful to print, rather than accepting every field by default.
Rank #4
Setters make broad mutation the default
@Data generates setters for non-final fields. That can make every such field publicly mutable through the generated API, even when the entity’s domain rules would be clearer with selected setters or methods that enforce valid state changes. Jakarta Persistence’s non-final requirements do not require an entity to expose a setter for every persistent field; access and mutation choices should match the entity’s design.
Use narrower annotations and make each choice explicit
A more controlled Lombok approach is to place @Getter on the entity, then add only the setters and constructors the class needs. Decide separately whether to implement toString, and define equality and hash code based on an intentional entity policy. This avoids importing all of @Data’s generated behavior just to save accessor boilerplate.
Best Value
Before adding Lombok to an entity, check these points:
- Does the class have a public or protected no-argument constructor?
- Which persistent fields should callers be able to mutate through setters?
- Which fields, if any, should appear in
toString? - Which values define equality and hash code, and can those values change during the entity lifecycle?
- Does the equality implementation behave as intended with proxies and entity inheritance?
The practical rule is to avoid @Data as a blanket entity annotation. Use it only when you have verified that its generated constructor and methods match the entity’s persistence and domain requirements.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
