The Object Class: `equals`, `hashCode`, `toString`

toString(): the easy one

@Override
public String toString() {
    return "Student{name='" + name + "', rollNumber=" + rollNumber + "}";
}

Now printing works, and so does string concatenation, and so does the debugger, and so does every log line.

equals(): what “the same” means

The default compares object identity, so two distinct objects with identical contents are not equal.

A correct equals() has a standard shape, and every part of it is there for a reason:

@Override
public boolean equals(Object o) {
    if (this == o) return true;                       // 1. same object: fast path
    if (o == null || getClass() != o.getClass()) return false;   // 2. wrong type or null
    Student other = (Student) o;                      // 3. now the cast is safe
    return rollNumber == other.rollNumber              // 4. compare the identifying fields
            && Objects.equals(name, other.name);
}

The five rules equals() must follow

The contract is written into Object’s documentation, and collections rely on all five.

Symmetry is the one that breaks in real code, usually via inheritance. If Student.equals accepts any subclass but GraduateStudent.equals requires an exact type, then student.equals(grad) is true and grad.equals(student) is false. A HashSet containing both then behaves differently depending on insertion order, which is a horrible thing to debug.

Using getClass() != o.getClass() rather than instanceof keeps symmetry safe, and that is why the template above uses it.

hashCode(): the one people skip

Of everything in this section, this part matters most. Skipping hashCode produces a bug that looks impossible.

Override equals alone and run the three failures from the top of this section:

set size (want 1): 2          <- the duplicate got in
contains         : false      <- cannot find something it contains

Meanwhile a List works perfectly:

List.contains with equals only: true

That inconsistency is the clue. List.contains walks every element calling equals, so it needs nothing else. HashSet does something much cleverer, and the cleverness has a requirement.

So a HashSet answers “do you contain this?” in the same time on a million elements as on ten. It does not search. It works out where the answer would be.

The bucket number provides direct indexed access into an internal table, using the array semantics from Section 4.2. Java does not expose a physical address during this operation.

Now the failure is visible. Your two equal students are distinct objects, so their inherited identity hash codes may differ. Step 2 can send them to different buckets, which means step 4 never compares them. Your correct equals() is never called.

The contract

If two objects are equal, they must have the same hash code.

One sentence. Everything else follows.

The reverse is not required. Two unequal objects may share a hash code, which is called a collision. Collisions are unavoidable, because a hash code is an int with about four billion values and there are infinitely many possible objects. Collisions cost speed, not correctness, and equals resolves them.

Writing hashCode()

The easy way, and the right default:

@Override
public int hashCode() {
    return Objects.hash(rollNumber, name);      // same fields as equals. Always.
}

The classic manual version, which you will read in older code:

@Override
public int hashCode() {
    int result = 17;
    result = 31 * result + rollNumber;
    result = 31 * result + (name == null ? 0 : name.hashCode());
    return result;
}

The rule that matters more than the algorithm: use the same fields in hashCode as in equals. Every time. Different fields means the contract breaks, and the breakage is silent.

The bug that eats data

Here is the worst one, and it follows directly from everything above.

Map<Unit, String> map = new HashMap<>();
Unit key = new Unit(1);
map.put(key, "value");

System.out.println(map.get(key));       // "value"

key.id = 99;                            // change a field used in hashCode

System.out.println(map.get(key));       // null
System.out.println(map.containsKey(key));  // false
System.out.println(map.size());         // 1

Read those last three lines again.

The map still says it holds one entry. It cannot find it. It cannot remove it. The value sits in the bucket the key hashed to when you put it in, and every later lookup computes the new hash and looks somewhere else.

No exception. No warning. The data is in memory, counted, and permanently unreachable.