Lombok @Data: Handy Shortcut with Hidden Pitfalls and Key Technical Details

@Data expands to multiple Lombok annotations

The @Data annotation is a composite that is equivalent to applying @Getter, @Setter, @RequiredArgsConstructor, @ToString, and @EqualsAndHashCode together.

callSuper defaults to false

The @EqualsAndHashCode annotation has a callSuper parameter whose default value is false. When a class extends a superclass, the generated equals() and hashCode() methods only consider the fields declared in the subclass. In the example:

public class BaseEntity {
    private Long id;
    private LocalDateTime createTime;
}

@Data
public class User extends BaseEntity {
    private String name;
    private String email;
}

the resulting equals() compares only name and email, ignoring id and createTime. Consequently, two User objects with different id values but identical name and email are considered equal.

This design choice stems from Lombok’s inability to know whether the superclass’s equals() should be based on all fields or just a business identifier, and it aligns with the recommendation in Effective Java to favor composition over inheritance.

If you need the superclass fields to participate in equality, you must set callSuper = true:

@EqualsAndHashCode(callSuper = true)
public class User extends BaseEntity { ... }

IDEA will highlight incorrect usage with a yellow squiggle.

serialVersionUID is not generated

For classes that implement Serializable, the JVM computes a default serialVersionUID based on the class structure. Adding or renaming fields changes this value, which can cause InvalidClassException during deserialization. Lombok does not generate a serialVersionUID field; you must declare it yourself, e.g.:

private static final long serialVersionUID = 1L;

Starting with JDK 14, the @Serial annotation can be used to mark the field as the serialization version identifier.

Practical usage recommendations

If you are already familiar with Lombok’s boundaries, you may skip this section. Otherwise, the author suggests using @Getter and @Setter instead of the all‑in‑one @Data, and adding @EqualsAndHashCode only when you need custom equality logic. For JPA entities, where proxy objects and lazy loading can affect id values, writing equals() and hashCode() manually is safer.

The core takeaway is that the implementation of equals() and hashCode() should be defined by you, not automatically by Lombok.

Final notes

The author acknowledges that some points were imprecise and thanks the community for feedback, noting that Lombok also provides other annotations such as @Cleanup, @Locked, and @Synchronized.