== vs equals()

JavaEntryjava

The Question

What is the difference between '==' and the equals() method in Java?

What a Strong Answer Covers

• == compares references/memory addresses
• equals() compares content/value
• equals() can be overridden
• String.equals() compares character content
• primitives use == for value comparison

Senior-Level Answer

In Java, `==` and `equals()` test different things and the distinction is fundamental to writing correct code.

`==` is the identity operator. For primitive types (`int`, `double`, `boolean`, etc.), it compares values directly — `5 == 5` is `true`. For object references, it compares memory addresses: it is `true` only if both variables point to the exact same object in memory.

`equals()` is a method defined on `Object` that tests logical equality. The default implementation in `Object` uses `==` (same reference), but most classes override it to compare content. `String.equals()` compares character sequences. `Integer.equals()` compares numeric values. If you don't override `equals()`, you get reference comparison by default.

The classic example: `String a = new String("hello"); String b = new String("hello");` — `a == b` is `false` (different objects on the heap), but `a.equals(b)` is `true` (same content).

Key practical rules: - Always use `equals()` to compare object content. - Use `==` only to check if two references point to the exact same instance, or to compare primitives. - Never use `==` to compare boxed wrapper types like `Integer` or `Long` unless you know the values fall in the cached range (-128 to 127 for Integer) — and even then, don't rely on caching behavior. - Use `Objects.equals(a, b)` when either operand might be null, to avoid NullPointerException.

For `null`: `null == null` is `true`. Calling `.equals()` on a null reference throws `NullPointerException`. Calling `someObject.equals(null)` should return `false` by contract and does so in all standard library implementations.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Using == to compare String values and being confused by cases where it works (due to the string pool) — this is coincidental, not reliable.
• Forgetting that the default Object.equals() is reference equality, not value comparison.
• Not mentioning Objects.equals() as a null-safe alternative.

Follow-Up Questions

• Why does `==` appear to work correctly for interned strings but fails for strings created with `new`? — Literals share references from the pool; new String() creates a distinct heap object even for identical content.
• If you override equals() to compare two fields, what else must you always override? — hashCode() — the contract requires equal objects to have equal hash codes for hash-based collections to work.
• What does Objects.equals(a, b) do when both a and b are null? — Returns true — it null-checks both operands before delegating to a.equals(b).

Related Questions

• JVM vs JRE vs JDK
• Java Platform Independence
• How JVM Works
• Main Features of Java
• public static void main