Why Does Every Class Extend Object?

Every class in Java extends java.lang.Object, whether you write extends Object or not. It is the root of the type hierarchy, and it exists so that every object — no matter how simple — has a common set of operations and a common runtime type. Because java.lang is imported automatically, Object is always in scope.

The methods it supplies fall into four groups. Identity and type: getClass returns the runtime class, and it is final so nobody can lie about it. Equality: equals and hashCode define how an object compares and how it is bucketed in a hash-based collection; the default implementations use identity. Rendering: toString returns a description of the object, and its default form is the class name and the identity hash code in hex. Lifecycle: clone and finalize, the latter of which is deprecated for removal because it is unreliable.

The methods it supplies fall into four groups. Identity and type: the getClass method returns the runtime class, and it is final so nobody can lie about it. Equality: equals and hashCode define how an object compares and how it is bucketed in a hash-based collection, and the default implementations use identity. Rendering: toString returns a description of the object, and its default form is the class name followed by the identity hash code in hex. Lifecycle: clone and finalize, the latter of which is deprecated for removal because it is unreliable.

Two practical points follow from this. Because equals defaults to identity, a class that represents a value rather than a thing — a domain object, a record, a data transfer object — must override equals and hashCode together, or it will behave wrongly in a HashMap. And because the default toString prints an identity hash, logging an object without overriding it gives you output that changes between runs and tells you nothing, which is why overriding toString is one of the first things to do with a new class.

One more subtlety: getClass is final, but equals is not. That is deliberate — an equals that checks getClass cannot be extended symmetrically, whereas one that uses an instanceof test and a canEqual-style hook can.

public class Main {
    public static void main(String[] args) {
        // A String is an Object too.
        Object anything = "a string is an Object too";
        System.out.println("toString   : " + anything.toString());
        System.out.println("hashCode   : " + anything.hashCode());
        System.out.println("equals self: " + anything.equals(anything));
        System.out.println("getClass   : " + anything.getClass().getName());

        // The default toString is rarely what you want, so classes override it.
        System.out.println("default    : " + new Point(1, 2));
    }
}

class Point {
    private final int x;
    private final int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public String toString() {
        return "Point(" + x + ", " + y + ")";
    }
}

Two practical points follow from this. Because equals defaults to identity, a class that represents a value rather than a thing — a domain object, a record, a DTO — must override equals and hashCode together, or it will behave wrongly in a HashMap. And because the default toString prints an identity hash, logging an object without overriding it gives you output that changes between runs and tells you nothing, which is why overriding toString is one of the first things to do with a new class.

One more subtlety: getClass is final, but equals is not. That is deliberate — an equals that checks getClass() cannot be extended symmetrically, whereas one that uses instanceof and a canEqual-style hook can.

Object.equals is the default implementation every class inherits, and it compares identity — whether two references point at the same object. Object.hashCode is the default hash, derived from the identity, and it is consistent with that equals. Neither is wrong; they are simply the wrong choice for a class that represents a value.

java.util.Objects adds static helpers that solve two problems. Objects.equals(a, b) calls a.equals(b) but checks for null first, so a null left-hand side yields false instead of a NullPointerException. Objects.hashCode(a) computes a combined hash code for several fields, giving you a hash that is consistent with a hand-written equals in one line instead of a block of arithmetic.

public class Main {
    public static void main(String[] args) {
        String a = new String("x");
        String b = new String("x");

        // String overrides equals, so value equality holds.
        System.out.println("a.equals(b)            : " + a.equals(b));

        Object o1 = new Object();
        Object o2 = new Object();
        System.out.println("Object identity equals  : " + o1.equals(o2));

        String maybeNull = null;
        try {
            System.out.println(maybeNull.equals(a));
        } catch (NullPointerException e) {
            System.out.println("null receiver -> NullPointerException");
        }

        // Objects.equals is null safe on both sides.
        System.out.println("Objects.equals(null, a) : " + java.util.Objects.equals(maybeNull, a));
        System.out.println("Objects.equals(a, null) : " + java.util.Objects.equals(a, maybeNull));
        System.out.println("Objects.equals(a, b)    : " + java.util.Objects.equals(a, b));

        // Objects.hashCode matches the equals contract.
        System.out.println("hash codes equal        : "
                + (java.util.Objects.hashCode(a) == java.util.Objects.hashCode(b)));
    }
}

The output shows the contrast between the two styles. The direct call on a null receiver throws, while the helper returns false. And the hash-code comparison confirms the contract that every hash-based collection depends on: equal objects must have equal hash codes, otherwise a HashMap cannot find them.

The other helper worth knowing is Objects.requireNonNull, which throws a NullPointerException with a message of your choosing if the argument is null. Used as a guard at the top of a method it documents the precondition and fails fast, which is far better than a NullPointerException from somewhere deeper in the method.