✅ 1. @IntrinsicCandidate public native int hashCode();

🔍 What is hashCode()?

• hashCode() is a native method in Java that returns an integer hash code for the object.

• It's defined in Object class as:

  public native int hashCode () ; 
• native keyword means:
  → Its implementation is not in Java, but in C/C++ and is handled by the JVM.

💡 Why is it needed?

• It is primarily used in hash-based collections like:
  • HashMap
  • HashSet
  • Hashtable
• These collections use the hash code to quickly find or store objects.

🔧 How does it work (default behavior)?

• By default, hashCode() returns a number that is typically derived from the object’s memory address.

  System.out.println( new Object ().hashCode()); // some int like 12345678   
• But you can override it in your class to provide a custom logic, especially when overriding equals().

✅ 2. public boolean equals(Object obj) { return (this == obj); }

🔍 What is equals()?

• The equals(Object obj) method is used to compare two objects for equality.
• This is the default implementation in the Object class.

💡 What does this == obj mean?

• == checks whether both references point to the exact same object in memory.
• So, equals() by default is reference comparison, not content comparison.

Example:

• If you don’t override equals(), your class will compare by reference.
• If you override equals(), you can compare based on content or business logic.

🔄 hashCode() & equals() – Together

These two are tightly coupled in Java, especially in hash-based collections.

✅ Contract:

• If two objects are equal (equals() returns true), then they must have the same hash code.
• But the reverse is not always true — two objects can have the same hash code but not be equal (called a hash collision).

🧪 Example:

Now, new Employee(1, "Nitesh") and new Employee(1, "Nitesh") will be treated as equal and will have the same hash code — perfect for use in HashSet.

🧠 Summary

🚫 When You Don't Override hashCode() and equals() in a Child Class

📍 By default:

If your custom class does not override equals() and hashCode(), it inherits them from the Object class, where:

• equals() → compares object references (memory addresses)
  i.e. obj1 == obj2
• hashCode() → returns a hash based on memory address, via a native implementation in the JVM.

📦 Example:

Even though p1 and p2 have the same content, they are not considered equal and have different hash codes, because we didn’t override equals() and hashCode().

🔗 Relationship (Context) Between Them When Not Overridden:

📉 Real-World Problem Without Overriding:

Why?
HashSet calls:

1. hashCode() to find the bucket
2. equals() to check equality

But both are comparing reference, so it thinks they are different objects.

✅ When You Should Override

To make objects compare by logical content, override both:

• equals() → define logical equality
• hashCode() → generate hash code based on significant fields

Now:

🧠 Final Summary: Context When Not Overridden

✅ 1. What is getClass()?

🔍 Definition:

• getClass() is a final native method defined in the Object class.
• It returns a Class<?> object that represents the runtime class of the current object.

🔁 Syntax:

🔬 Breakdown of the Declaration

💡 Why is getClass() useful?

✅ It gives runtime class information — even in polymorphic code.

Even though obj is declared as Object, getClass() still knows the real type.

📘 Example Usage:

🧪 Simple usage:

String name = "Nitesh" ; Class<?> cls = name.getClass(); System.out.println(cls.getName());         // java.lang.String System.out.println(cls.getSimpleName());   // String   

🔍 Practical uses:

• Reflection API (used by frameworks like Spring, Hibernate)
• Debugging/logging (identify object types)
• Serialization/deserialization
• Dynamic loading (e.g., Class.forName("..."))

🤔 Why final and native?

🔐 final

• Because allowing subclasses to override getClass() would break the JVM's type safety and behavior.
• It must always return the actual runtime class — overriding would allow faking it.

⚙️ native

• The JVM needs to know the object's class internally, and this info is stored in the object's header.
• So, getClass() simply fetches this info directly from the memory structure using native code.

🧠 Summary Table:

📦 Real World Example:

🔁 Output:

Even though num is of type Number, getClass() returns Integer.

🔎 Method Declaration:

@IntrinsicCandidate protected native Object clone () throws CloneNotSupportedException;

✅ Purpose of clone()

The clone() method is used to create and return a copy of the current object. It's a shallow copy by default, unless you manually implement deep copying.

🧠 Why clone() is needed?

When you assign an object like this:

Person p1 = new Person("Nitesh");
Person p2 = p1;
 

You are not copying the object. You are copying the reference (both point to the same memory).

But in some cases (e.g., undo operations, version control, simulation), you need a copy of the object with independent memory — that's where clone() comes in.

🧩 clone() Keyword Explanation

⚠️ Exception: CloneNotSupportedException

This is a checked exception, which is thrown when:

Your class does not implement the Cloneable interface, but you're trying to call clone().

📦 How to use clone() properly?

🔧 Step-by-Step:

1. Implement Cloneable interface (marker interface — no methods).
2. Override the clone() method from Object.
3. Call super.clone() inside it.
4. Catch or declare CloneNotSupportedException.

🔀 Shallow vs Deep Cloning

✅ Example: Shallow Cloning

🌊 Deep Cloning Example

If the object contains references (like a List, or nested objects), you must manually deep clone them.

🧠 Summary Table

❓Why only protected?

• So it’s not publicly accessible by default — it enforces controlled cloning.
• You must explicitly override and expose it if you want it to be used outside.

🔄 Alternative to clone()

Some developers avoid clone() due to complexity and prefer:

• Copy constructors
• Builder patterns
• Serialization cloning (deep copy via byte streams)

✅ Original toString() in Object class

🧠 What does this return?

It gives a string representation of the object in this format:

ClassName @HashCodeInHex

Example:

Person p = new Person (); System.out.println(p.toString()); // e.g., com.demo.Person@1a2b3c

🔍 Breakdown of parts

1️⃣ getClass().getName()

• Gets the fully-qualified class name at runtime.
• Example: com.mycompany.model.Employee

2️⃣ hashCode()

• A 32-bit integer that usually represents the object's memory address (by default).
• Can be overridden for logical equality.

3️⃣ Integer.toHexString(int i)

• Converts the int (from hashCode()) to a hexadecimal string.
• Makes it compact and looks like memory representation (like C/C++ pointer).

🚀 Benefits of toString()

🔁 Edge Case Analysis (Your Main Question)

Let’s explore all combinations of overriding:

✅ Case 1: Neither toString() nor hashCode() overridden

Output:

Example:

→ Default behavior, shows technical object info.

✅ Case 2: Only hashCode() overridden

Output:

→ You changed how the hash is calculated, so it affects the toString() output.

🔴 But still not human-friendly — just custom number in hex.

✅ Case 3: Only toString() overridden

Output:

→ Much more readable and meaningful for logs, UIs, etc.

Hashcode is still default, but unused unless you call hashCode() explicitly.

✅ Case 4: Both toString() and hashCode() overridden

Output:

→ Full control over both:

• hashCode() for hashing, collections, equality.
• toString() for display, logging.

🤔 Why Override toString()?

➕ Pros:

• Easier debugging (System.out.println(obj) gives readable output)
• Clearer logs
• Better error messages
• Frameworks (like Spring, Hibernate) use it for logging objects

🧱 Best Practice for toString():

💣 What Happens If You Don’t Override?

If you don’t override:

• Logs and debug messages are hard to interpret
• Framework logs become cryptic
• You see object references like MyClass@7852e922 (useless for business logic)

🧠 Summary Table

✅ Conclusion:

• Always override toString() when your class is used in logs, UI, or debugging.
• Override hashCode() when you also override equals() (important for collections like HashSet, HashMap).
• They both serve different purposes:
  • toString() = display
  • hashCode() = identity & hashing

✅ Original Method in Object Class: how it works, why it was deprecated, real use cases, and modern alternatives.

💡 What is finalize()?

• finalize() is a method in java.lang.Object that was intended to be called by the Garbage Collector (GC) before reclaiming memory from an object.
• You could override it to release system resources, close streams, or do cleanup.

🧠 How It Used to Work

1. When an object became eligible for garbage collection, the JVM would:
   • Check if the object overrides finalize()
   • Call finalize() once only before destroying the object
   • Then collect (free) the object’s memory
2. You could override it like this:

⚠️ Why finalize() is Deprecated (Since Java 9)

❌ Unreliable:

• No guarantee finalize() will be called at all.
• The timing is unpredictable.

🐢 Performance Overhead:

• Finalized objects take longer to collect — they go through an extra phase.

😨 Risky Behavior:

• If finalize() throws an exception and doesn’t call super.finalize(), GC can break.
• Holding onto objects in finalize() can resurrect them, delaying collection (memory leak risk).

🔥 Example of Dangerous Use

This object won’t be garbage collected, leading to memory leaks!

✅ Modern Replacement (Post-Java 9+)

Use try-with-resources or AutoCloseable:

Instead of relying on finalize(), use this:

This ensures deterministic cleanup of resources like files, DB connections, etc.

🧪 Example: Before vs After

✅ Old (Deprecated):

✅ Modern (Recommended):

🔚 Summary

🧠 Final Thought

Never use finalize() in new code.

If you're maintaining legacy code that still uses it:

• Remove it if it's not essential.
• Migrate cleanup logic to AutoCloseable.

→ Rest Other method of Object class will take in multithreading→