Object Class Methods — toString, hashCode, equals, clone, finalize
Fast recall
Quick revision
Core answer
hashCode() when overriding equals() — equal objects must have equal hash codes (HashMap silently loses data if broken). toString() = override for readable logs. clone() = avoid (shallow, bypasses constructor, requires Cloneable) — use copy constructors. finalize() = never use (deprecated Java 9, removed Java 18) — use try-with-resources. Java records auto-generate equals() + hashCode() from all components.Whether the candidate understands the equals/hashCode contract and its consequences for collections, knows why clone() is broken by design, and can explain why finalize() was deprecated — not just listing the methods
Overriding equals() without overriding hashCode() — objects that are logically equal end up in different HashMap buckets, causing silent data loss. Using clone() without understanding shallow vs deep copy semantics
Explain the equals/hashCode contract with a concrete HashMap failure scenario. Mention that Java records auto-generate equals/hashCode from all fields. Know that finalize() was deprecated in Java 9 and removed in Java 18 — replaced by Cleaners and try-with-resources
Interview-ready guide
Interview answer
Every Java class inherits from Object. The five methods interviewers focus on are toString(), equals(), hashCode(), clone(), and finalize().
equals/hashCode — the contract that causes production bugs
- Override
equals()withouthashCode()and HashMap silently loses data:put()stores in one bucket,get()with a logically equal key looks in a different bucket, returnsnull - Fix: always override both together using the same fields;
Objects.hash(name, age)is the standard pattern - Use a
recordwhen possible — it generates both correctly from all components automatically
toString()
- Override it so logs show
Person{name=Alice, age=30}instead ofPerson@1a2b3c - Lombok
@ToStringor records handle this automatically
clone() and finalize() — avoid both
clone()bypasses constructors, returnsObjectrequiring a cast, and shares mutable internals; use copy constructorsfinalize()was deprecated in Java 9 and removed in Java 18 — unpredictable GC timing, potential object resurrection; usetry-with-resourcesfor cleanup
I recommend using Java records for any class used as a map key — they generate correct equals() and hashCode() automatically, eliminating the most common source of silent data loss.
Object Class Methods — toString, hashCode, equals, clone, finalize
Direct Answer
Always override hashCode() when overriding equals() — equal objects must have equal hash codes (HashMap silently loses data if broken). toString() = override for readable logs. clone() = avoid (shallow, bypasses constructor, requires Cloneable) — use copy constructors. finalize() = never use (deprecated Java 9, removed Java 18) — use try-with-resources. Java records auto-generate equals() + hashCode() from all components.
Common Mistakes & Pitfalls
Overriding equals() without overriding hashCode() — objects that are logically equal end up in different HashMap buckets, causing silent data loss. Using clone() without understanding shallow vs deep copy semantics
Check your understanding
Answer these without looking back at the article.
- What is the equals/hashCode contract and what exactly breaks in a HashMap when you violate it?
- Why does overriding equals() without hashCode() cause silent data loss rather than an exception?
- Why is clone() considered broken — what are the safer alternatives?
- Why was finalize() deprecated in Java 9 and removed in Java 18 — what should you use instead?
- How do Java records auto-generate equals and hashCode and why is that implementation correct?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.