equals/hashCode Interdependence

## The two methods and what they mean Every Java object inherits two methods from `java.lang.Object`: - **`equals(Object o)`** — answers "is this object *logically the same* as that one?" The default implementation is **reference identity**: `a.equals(b)` is true only when `a` and `b` are literally the *same* object in memory (the same as `a == b`). You override it when two *separate* objects should count as equal — e.g. two `Point(1,2)` instances. - **`hashCode()`** — returns an `int` that acts as a fast, lossy "summary" of the object. The default returns a number derived from the object's identity (historically its memory address), so two distinct objects almost always get *different* hash codes. ## The contract that binds them The Javadoc of `Object` states a **contract**: > If two objects are equal according to `equals()`, then calling `hashCode()` on each **must** produce the **same** integer. (The reverse is NOT required: two *unequal* objects MAY share a hash code — that's a *collision*, and it's allowed.) When you override `equals()` to compare by fields but leave `hashCode()` inherited, you break this contract: two objects that are now `equals()`-equal can still return the two *different* identity-based hash codes they inherited. The compiler does not catch this — it's a silent logic bug. ## Why hash-based collections care A **hash table** (the engine inside `HashMap` and `HashSet`) stores entries in an array of *buckets*. To store or find a key it does **two steps**: 1. **Hash step:** call `key.hashCode()`, reduce it (e.g. modulo the array length) to pick **one bucket**. 2. **Equality step:** scan only the entries *in that bucket*, calling `equals()` on each, to find the exact match. This two-step design is what makes lookups average O(1) instead of O(n): you never scan the whole table, only one small bucket. Now suppose you stored `new Point(1,2)` and later call `set.contains(new Point(1,2))`. The two Points are `equals()`-equal but, with the broken setup, have **different** hash codes. Step 1 sends the lookup to a *different bucket* than where the stored Point lives. Step 2 scans that (wrong, probably empty) bucket, never finds the entry, and `equals()` is **never even called** on the stored Point. So: - `contains()` / `get()` return **false / null** for an object that *is* equal to a stored one — the object is effectively **unretrievable**. - `HashSet` can end up holding **two objects that are equal**, because `add()` uses the same broken lookup to decide "is this a duplicate?" and concludes it isn't. ## The fix Override **both** methods, **using the same set of fields** in each. If `equals()` compares `x` and `y`, then `hashCode()` must be computed from `x` and `y` too (e.g. `return Objects.hash(x, y);`). Then equal objects always hash identically, the lookup reaches the right bucket, and the collection behaves correctly. ## Key intuition to keep `hashCode()` decides *where to look*; `equals()` decides *which one it is*. Get the "where" wrong and the "which" never runs.