Demo: the broken HashSet and the equals/hashCode fix

Written Explanation

The plan

Do the steps in order, and run the program after each one.

For this demo we use three versions of the class. In your own project you would edit one class step by step; here they are separate so all results appear in one run.

What the set promises

The Java documentation defines the set's behavior in terms of equality: add puts an element in only when no element already inside is equal to it (by Objects.equals), and contains asks the same question. It also says the set is backed by a hash table, which is why the hash code matters. So the promise is "no equal duplicates", but the machinery needs a consistent hashCode to keep that promise. Our experiment tests exactly that gap between the promise and the machinery.

For the lab, record each experiment in a small table, with three columns: the version of Money, the set size, and the result of contains for an equal copy. Writing down the numbers before explaining them keeps the explanation honest: you explain what you observed, not what you expected.

Step 1 and 2: no overrides

class Money1 {
    final long cents; final String currency;
    Money1(long c, String cur) { cents = c; currency = cur; }
}

HashSet<Money1> s1 = new HashSet<>();
s1.add(new Money1(100, "SAR"));
s1.add(new Money1(100, "SAR"));
System.out.println("no overrides: " + s1.size());

The set sees two different objects: the default equals is identity and the default hashCode follows identity. The business sees one amount entered twice.

Step 3 and 4: only equals (the planted mistake)

class Money2 {
    final long cents; final String currency;
    Money2(long c, String cur) { cents = c; currency = cur; }
    @Override public boolean equals(Object o) {
        return o instanceof Money2 m && cents == m.cents && currency.equals(m.currency);
    }
}

Now new Money2(100, "SAR").equals(new Money2(100, "SAR")) is true. It feels fixed. Run it and the set still has two elements. Why? The hashCode is still the identity-based default, so the two equal objects return different hash codes. The set uses the hash code to decide where to look, finds nothing to compare in that place, and never calls equals at all. The contract was broken: equal objects with different hashes.

Step 5 and 6: add hashCode and toString

class Money3 {
    final long cents; final String currency;
    Money3(long c, String cur) { cents = c; currency = cur; }
    @Override public boolean equals(Object o) {
        return o instanceof Money3 m && cents == m.cents && currency.equals(m.currency);
    }
    @Override public int hashCode() { return Objects.hash(cents, currency); }
    @Override public String toString() { return "Money[" + cents + " " + currency + "]"; }
}

Equal objects now produce the same hash code, so the set places them together and then equals identifies the duplicate.

Step 7: a mutable field in hashCode

class MutableMoney {
    long cents; final String currency;     // cents can change
    // constructor, equals and hashCode over cents and currency
}

Put one in a set, change cents, then call contains on the same object. The object is still stored, but filed under its old hash. The new hash points elsewhere, so the lookup fails.