== vs equals() and hashCode() in Java, Explained

In Java, == compares references (are these the same object?) while equals() compares values (are these objects meaningfully equal?) — and the moment you override equals(), you must override hashCode() too. Getting this wrong silently breaks HashMap and HashSet, which is why it’s one of the most-asked Java interview topics. It’s a Phase 4 fundamental from the Java roadmap.

== compares references

== checks whether two variables point to the same object in memory:

String a = new String("hi");
String b = new String("hi");
a == b;            // false — two different objects
a.equals(b);       // true  — same value

For primitives (int, boolean), == compares values directly and is correct. For objects, == only asks “is it literally the same object?” — rarely what you mean.

equals() compares values

equals() defines meaningful equality. Object’s default equals() just does ==, so you override it to compare the fields that matter:

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (!(o instanceof Point p)) return false;
    return x == p.x && y == p.y;     // value equality
}

Now two Point(3, 4) objects are equal even though they’re different objects.

The hashCode() contract

Here’s the rule people forget: if you override equals(), you must override hashCode(), and equal objects must return equal hash codes.

@Override
public int hashCode() {
    return Objects.hash(x, y);       // consistent with equals()
}

Why it matters: hash-based collections work in two steps — hashCode() picks a bucket, then equals() confirms the match. If two “equal” objects have different hash codes, they land in different buckets and the collection can’t find them.

Set<Point> seen = new HashSet<>();
seen.add(new Point(3, 4));
seen.contains(new Point(3, 4));   // false if hashCode() not overridden!

This is the bug: override equals() but not hashCode(), and your objects mysteriously “vanish” from sets and maps. See the Collections framework.

Strings and the pool

Strings make == especially treacherous because of the string pool: identical string literals may share one object, so == sometimes appears to work — then fails for strings built at runtime:

String a = "hi";
String b = "hi";
a == b;                        // true — both from the pool
String c = new String("hi");
a == c;                        // false — c is a new object
a.equals(c);                   // true — always use equals() for strings

Always compare string contents with equals().

The full equals contract

A correct equals() is:

• Reflexive: x.equals(x) is true.
• Symmetric: x.equals(y) ⇔ y.equals(x).
• Transitive: if x=y and y=z, then x=z.
• Consistent: repeated calls give the same result.
• Consistent with hashCode: equal objects share a hash code.

Common mistakes

• Overriding equals() but not hashCode() — the silent HashMap/HashSet bug.
• Using == to compare strings or objects — compares identity, not value.
• A hashCode() inconsistent with equals() — uses different fields, breaking lookups.
• Hand-writing both when a record would generate them correctly — let the language do it for data classes.

Where this fits

==, equals(), and hashCode() are Phase 4 of the Java roadmap, essential to object-oriented Java and to using the Collections framework correctly.

The contract and correct implementations are drawn out in Java in One Month and the job-ready Java in Three Months; the deeper details — hash distribution, immutability, and identity at scale — are in Java for Staff Engineers.

== for identity, equals() for value, and always override hashCode() alongside equals() — that pairing keeps your collections honest.