Detailed explanation
In Java, == is an operator, while equals() is an instance method used to test equality. For primitive operands, == compares values according to Java’s type rules; for example, 10 == 10 is true. For object references, == checks identity: whether both references point to the same object, or both are null. Calling this a comparison of “memory addresses” is a useful shortcut, but Java does not expose raw object addresses through this operator. The key distinction is identity versus logical equality.
The equals() method is declared in Object, so every Java object inherits it unless its class overrides it. Object.equals() uses identity, just like == for references. Therefore, saying that equals() always compares content is incorrect. Classes such as String and Integer override it to define value-based equality. String compares its character sequence, while Integer compares its stored integer value with another Integer. A custom class must implement its own equality rules if two separate instances should count as equal based on their fields.
Consider String a = new String("hi"); and String b = new String("hi");. Each new expression creates a separate String object, so a == b is false, but a.equals(b) is true. If you instead write String c = a;, then a == c is true because both variables reference the same object. String literals introduce another detail: identical literals are interned, so String x = "hi"; String y = "hi"; makes x == y true. This does not make == a reliable way to compare string content.
In practical code, use == for primitive comparisons, null checks, and intentional identity checks; use equals() for logical object equality. Calling a.equals(b) throws NullPointerException if a is null, whereas Objects.equals(a, b) handles nulls safely. When overriding equals(), also override hashCode() so equal objects have equal hash codes, as required by hash-based collections. Interviewers usually look for the identity/value distinction, the default Object behaviour, and awareness that interning or wrapper caching can make incorrect == comparisons appear to work.
Key points to remember
- For primitives, == compares values; for object references, it compares identity.
- Object.equals() checks identity unless a class overrides it.
- String and Integer override equals() to provide value-based equality.
- Objects.equals(a, b) provides a null-safe equality check.
- Overriding equals() requires a consistent hashCode() implementation.
Common mistakes candidates make
- Claiming that equals() always compares content, including for custom classes that do not override it.
- Using == for String or wrapper value comparisons because interning or caching made one example pass.
- Overriding equals() without overriding hashCode(), causing unreliable behaviour in HashSet or HashMap.
Likely follow-up questions
What happens when == compares Integer objects?
When both operands are Integer references, == compares identity; cached instances can therefore produce surprising results. If one operand is an int, Java unboxes the Integer for a numeric comparison, which throws NullPointerException if the Integer is null.
What rules must an equals() implementation follow?
It must be reflexive, symmetric, transitive, and consistent while equality-relevant state remains unchanged. For any non-null object x, x.equals(null) must return false, and equal objects must have equal hash codes.
Does equals() compare array contents?
Arrays inherit Object.equals(), so their equals() method compares identity rather than elements. Use Arrays.equals() for element-wise comparison of one-dimensional arrays and Arrays.deepEquals() for nested arrays.
Interview tip: Start with identity versus logical equality, explain the two new String objects, and finish with the default Object.equals() behaviour.