Do JPA/Hibernate entity classes need custom equals() and hashCode(), or is the reference comparison inherited from java.lang.Object good enough? When does the choice actually start to matter?
answer
- Persistence context = identity map, one object per row
- Breaks on detach / merge / two sessions / serialization
- hashCode must never change inside a Set
- Business key, assigned UUID, or constant hashCode
- Never mutable fields, never Lombok @Data on entities
basics
~20 sObject.equals compares references. That is correct only while every instance comes from one open persistence context, which guarantees one object per row. As soon as entities are detached, re-loaded in another session, merged, or compared across sessions, two objects represent the same row and reference equality says false — so you override equals/hashCode using a stable identifier.
solid answer
~50 sInside a single open persistence context Hibernate guarantees **one object instance per database row**, so `==` and the inherited `equals` are already correct there — many applications ship with no override at all and are fine. The default breaks the moment the same row is represented by two different instances: an entity loaded in session A compared with the same row loaded in session B, a detached instance compared with the result of `merge()`, an entity serialized into an HTTP session or cache and compared later, or an object put into a `HashSet` in one unit of work and looked up in another. `hashCode` matters as much as `equals`, because `HashSet`/`HashMap` and therefore JPA `Set` associations bucket by hash first. So the rule is: override when entities leave the persistence context or live in hash-based collections; and when you do override, base it on something stable — a business/natural key or an application-assigned id — not on mutable state.
code
java · 8 linesOrder a = em1.find(Order.class, 42L);
Order b = em2.find(Order.class, 42L);
a == b; // false — different objects
a.equals(b); // false with Object.equals, though both are row 42
Order same = em1.find(Order.class, 42L);
a == same; // true — identity map inside one contextgo deeper
Know that Object.equals compares references, that one persistence context returns one object per row, and that detached or re-loaded entities break that. Name one safe basis for equality.
Explain the identity-map guarantee and its boundary, and pick between business key, assigned UUID, and generated-id-with-constant-hashCode with reasons. Mention the hashCode stability contract.
Bring the failure modes you have hit in production: duplicates in a mapped Set, merge() returning a different instance, Lombok-generated equals recursing through a bidirectional association.
Frame it as a modelling decision — assigned identifiers as a design stance that makes entities behave like values outside the ORM, and the cost of that choice on insert batching and index locality.
## What the default actually gives you `java.lang.Object.equals` is reference equality (`this == other`), and `Object.hashCode` is derived from the object's identity. For entities this is not obviously wrong, because a JPA persistence context (Hibernate's `Session`) acts as an **identity map**: for a given entity type and primary key it will return the *same* Java object for the whole lifetime of that context. Load `Order#42` twice in one session and you get one instance, so `a == b` is true and the default `equals` is correct. This is why plenty of code with no override at all works. The question is what happens outside that one-session window. ## Where reference equality breaks 1. **Two sessions.** Load `Order#42` in session A, load it again in session B: two distinct objects for one row. `a.equals(b)` is false under the default. 2. **Detach / merge.** You send an entity to a web layer, it comes back modified, and you call `merge()`. `merge` returns a *managed copy*, not your detached instance. Comparing the argument with the return value under the default gives false. 3. **Serialization.** Entities put in an HTTP session, a distributed cache, or sent over the wire and deserialized are new objects. 4. **Hash-based collections.** A `Set<OrderLine>` mapped as an association, or any `HashSet` you build yourself, uses `hashCode` to pick a bucket and `equals` to resolve collisions. If the same row appears twice as two instances, the set holds two elements — a silent duplicate that can turn into two INSERTs or a broken `contains()`. 5. **Second-level cache / DTO round-trips.** Anything that reconstructs entities from stored state produces fresh instances. ## What "stable identifier" means The hard requirement from the `equals`/`hashCode` contract is that **hashCode must not change while the object is inside a hash-based collection**, and that equality is reflexive, symmetric, transitive and consistent. Entities violate this easily because the most obvious identifier — a database-generated primary key — is `null` before `persist()` and non-null after. An `equals` built on a null id makes every transient instance equal to every other transient instance; a `hashCode` built on it changes at flush time and the object is lost in its bucket. The three workable options are: - **A business/natural key**: an immutable, non-null, unique attribute the domain already has (ISBN, order number, email, an SKU). Best fit when such a key genuinely exists and truly never changes. - **An application-assigned identifier**: generate a `UUID` in the constructor so the id is non-null from birth and never mutates. This is the most mechanical, always-available answer. - **Generated id plus a constant hashCode**: `hashCode()` returns a fixed value (e.g. `getClass().hashCode()` or `31`), and `equals` returns true only when both ids are non-null and equal. Hash stability is preserved by construction; the price is that all instances of that type land in one bucket, which is acceptable for the small sets typical of an aggregate but not for a set with thousands of elements. What is *not* workable is equality over mutable business fields (`name`, `status`, `updatedAt`): changing a field silently changes the object's identity while it sits in a set. ## Practical guidance If your entities never leave a single transaction and you never place them in a `Set`, leaving `equals`/`hashCode` alone is a legitimate, defensible choice — and it is one of the few situations where "do nothing" is the right answer. State that explicitly in an interview; it shows you know *why* the override exists rather than cargo-culting it. Also be aware of two related traps. First, IDE-generated `equals`/`hashCode` (or Lombok's `@Data` / `@EqualsAndHashCode` with no configuration) includes every field, including associations — which can trigger lazy loading or infinite recursion between two sides of a bidirectional link. Second, `equals` must tolerate being handed a Hibernate lazy **proxy** of the same entity, which is a generated subclass: `getClass() != other.getClass()` will then reject an object that represents the same row. ## The short version One session, one object — default equality is fine. Multiple sessions, detachment, serialization, or hash collections — override, and base the override on an identifier that is non-null and immutable from the moment the object exists.
- If the persistence context already guarantees one instance per row, why not just always compare with ==?Because the guarantee is scoped to one open context. The moment an entity is detached, serialized, re-read in another session, or replaced by the managed copy that merge() returns, you hold two objects for one row and == is false. Reference equality is correct but only inside a boundary you cannot enforce for callers.
- Is it acceptable to ship entities with no equals/hashCode override at all?Yes, if the entities never appear in hash-based collections and never leave the transaction that loaded them — the identity map makes the inherited implementation correct. It is a conscious choice, not neglect, and it is safer than a wrong override built on a generated id or mutable fields. Document the assumption so a later @OneToMany Set mapping does not quietly break it.
- What is wrong with Lombok's @Data or @EqualsAndHashCode on an entity?They include every field by default, so equality depends on mutable state and on associations. Touching an association inside equals can trigger lazy loading outside a session or recurse infinitely between both sides of a bidirectional relationship. If you use Lombok on entities, restrict it explicitly to the identifier field.
Inside one session Hibernate is like a coat check that always hands back your exact coat, so 'is it the same object?' works. Across sessions you get an identical coat from a different rack — you need a name tag (stable id), not the coat's physical identity.
saying these in an interview costs you the question
- "Just let the IDE generate equals/hashCode over all fields" — includes mutable state and associations
- "Reference equality is always wrong for entities" — it is correct inside a single persistence context
- Overriding equals but not hashCode (or vice versa), breaking Set and Map behavior
- "equals on the id is always safe" — not when the id is database-generated and null before persist
- Using @Data / @EqualsAndHashCode from Lombok on entities without excluding associations