== vs .equals() in Java
Fast recall
Quick revision
Core answer
== is a Java operator: it compares primitive values or reference identity, depending on its operands. equals() is an instance method whose meaning is defined by the class; Object.equals() uses identity, while String.equals() compares characters. Because it is an instance call, calling value.equals(...) when value is null throws NullPointerException.Whether the candidate understands reference vs value comparison and knows that == on Strings is unreliable because of String pool sharing
Using == to compare String content and getting false negatives on data from forms, files, or databases, or assuming == always compares values
Explain that string literals share references in the pool, making == accidentally pass in tests but fail in production — and use the null-safe "literal".equals(var) pattern
Interview-ready guide
Interview answer
== and equals() answer different questions. The == operator compares primitive values, but with references it tests whether both references denote the same object. The equals() method tests whatever logical equality the class defines. Its inherited default from Object is still identity, so value equality exists only when the class supplies it.
For example, new String("java") == new String("java") is false because the expressions create separate objects, while .equals() returns true because both strings contain the same characters. String pooling can make identity comparisons between literals appear to work, but that does not turn == into a content comparison.
For a possibly null value, I can use Objects.equals(left, right), which handles two nulls and delegates to equals() otherwise. I use == when identity is genuinely intended—such as a null check or comparing enum constants—and a suitable equality method when the values should be logically equal.
== vs .equals() in Java
Direct Answer
== is a Java operator: it compares primitive values or reference identity, depending on its operands. equals() is an instance method whose meaning is defined by the class; Object.equals() uses identity, while String.equals() compares characters. Because it is an instance call, calling value.equals(...) when value is null throws NullPointerException.
Common Mistakes & Pitfalls
- Comparing String content with
==— it checks object identity, not text, soinputName == "admin"returnsfalsefor runtime input even when the characters match, silently breaking logins and lookups. - Being fooled by passing tests — string literals share one object in the pool, so
"hi" == "hi"istrue; this makes==look correct in unit tests, then fail in production on database- or form-sourced strings. - Calling
.equals()on a possibly-null reference —userInput.equals("admin")throwsNullPointerExceptionwhenuserInputis null; flip it to"admin".equals(userInput)so a null returnsfalseinstead. - Overriding
equals()but nothashCode()— your custom class then "works" in anif, but behaves incorrectly inside aHashMaporHashSet, where lookups silently miss.
Check your understanding
Answer these without looking back at the article.
- What happens if you call .equals() on a null reference?
- How does the String pool affect == comparisons?
- How would you implement .equals() in a custom class?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.