Java Inheritance, Polymorphism, Overriding and Sealed Classes (1Z0-831)

Every reference expression has two types: the reference type (the declared type of the variable or expression, known to the compiler) and the object type (the class of the object actually created with new, known only at runtime). The reference type decides what code is allowed to compile; the object type decides which overriding method body runs.

class Instrument {
    String tone() {
        return "plain";
    }
}

class Guitar extends Instrument {
    @Override
    String tone() {
        return "twang";
    }

    void strum() {
        System.out.println("strumming");
    }
}

public class Main {
    public static void main(String[] args) {
        Instrument a = new Guitar();
        System.out.println(a.tone());
        // a.strum();
        if (a instanceof Guitar g) {
            g.strum();
        }
    }
}

This prints twang then strumming. a.tone() compiles because Instrument declares tone(), and runs Guitar's override because the object is a Guitar. Uncommenting a.strum() fails with cannot find symbol: Instrument has no strum(), whatever the object really is. To reach subclass-only members you need a reference of the subclass type — a cast or, more safely, an instanceof pattern as shown.

The same compile-time view applies to checked exceptions. If Fetcher.read() declares throws IOException and an override in DiskFetcher drops the clause, a call through a Fetcher reference still has to catch or declare IOException — the compiler only sees Fetcher's declaration. A call through a DiskFetcher reference does not.

Polymorphism in Java means one call site can run different method bodies depending on the object's class; it works through overriding — a subclass instance method with the same signature (name and parameter types) as an inherited one. A method with the same name but different parameter types is an overload, a separate method that never replaces the inherited one.

A call is resolved in two steps:

1. Compile time — overload resolution. The compiler searches the reference type for methods with that name, picks the most specific signature that fits the argument types, and records that signature.
2. Runtime — dynamic dispatch. The JVM starts at the object's class and walks up the hierarchy to the first class that declares a method with the recorded signature — an override, or the original declaration if nothing overrides it.

class Logger {
    void log(Object o) {
        System.out.print("L-Object ");
    }
}

class ConsoleLogger extends Logger {
    void log(String s) {
        System.out.print("C-String ");
    }
}

public class Main {
    public static void main(String[] args) {
        Logger ref = new ConsoleLogger();
        ConsoleLogger c = new ConsoleLogger();
        ref.log("x");
        c.log("y");
    }
}

This prints L-Object C-String. For ref.log("x") the compiler only sees Logger, whose single log(Object) is chosen; ConsoleLogger does not override log(Object), so Logger's body runs even though the object is a ConsoleLogger and the argument is a String. Through c, both methods are visible and log(String) is more specific.

Put @Override on every intended override. It changes nothing at runtime, but the compiler rejects it when the method does not actually override anything — catching exactly this overload-instead-of-override mistake.

A subclass method with the same signature as an inherited instance method is an override, so it must obey every rule below or the class does not compile — it cannot quietly become a different method.

The reasoning behind all of them is substitutability: code written against the superclass must keep working with any subclass object, so the override can promise more (wider access, a more specific result, fewer failures) but never less.

Overriding Object methods follows the same rules. toString(), equals(Object) and hashCode() are public in Object, so an override declared without public fails to compile.

Only accessible, non-final instance methods can be overridden. private methods are not inherited, final methods are locked, and static methods are hidden rather than overridden.

The private case has a runtime consequence too. If Template.describe() calls its own private key(), that call is bound to Template.key() and is not dispatched, so a subclass that declares its own key() does not change what describe() returns. Calling the subclass method requires a subclass-typed reference.

For a static method, the class whose code contains the call — or the declared type of the reference in front of it — decides which version runs. Calling a static method through an instance reference (t.prefix()) is legal, but the object is ignored. An unqualified static prefix() inside an inherited method of Template always means Template.prefix(), even when that method runs on a subclass object.

Fields are hidden too

Fields are never polymorphic: a subclass field with the same name as an inherited one hides it, the object carries both, and which one an expression reads is fixed at compile time by the reference type (or, for an unqualified name, by the class whose code contains it).

class Shelf {
    String tag = "shelf";

    static String origin() {
        return "Shelf";
    }

    String tag() {
        return tag;
    }
}

class Bookshelf extends Shelf {
    String tag = "book";

    static String origin() {
        return "Bookshelf";
    }

    @Override
    String tag() {
        return tag;
    }
}

public class Main {
    public static void main(String[] args) {
        Shelf s = new Bookshelf();
        System.out.println(s.tag + " " + s.tag() + " " + s.origin());
    }
}

This prints shelf book Shelf. s.tag reads Shelf's field because s is declared as Shelf; s.tag() is an overridden instance method, so Bookshelf's body runs and reads Bookshelf's field; s.origin() is static, bound to Shelf.origin().

The trap to watch for is an inherited, not overridden method. If Bookshelf did not override tag(), a call to tag() on a Bookshelf object would run Shelf's body, whose tag was bound to Shelf.tag when Shelf was compiled — it returns "shelf", not the subclass value. Inside Bookshelf, super.tag reaches the hidden field explicitly.

A reference cast never changes the object; it changes the reference type, and it is checked twice. The compiler rejects a cast only when no object could ever satisfy it; the JVM then checks the actual object and throws ClassCastException if it is not an instance of the target type.

public class Main {
    public static void main(String[] args) {
        Object o = "text";
        String s = (String) o;
        System.out.println(s);
        Integer i = (Integer) o;
    }
}

This prints text and then throws ClassCastException: Object could hold an Integer, so the second cast compiles, but this object is a String. Prefer a pattern such as if (o instanceof Integer n), which tests and binds in one step and never throws. Sealed hierarchies tighten the compile-time check further, because the compiler knows every permitted subtype.

Every constructor first runs a superclass constructor: either an explicit super(...) or this(...), or — if neither is written — an implicit no-argument super() inserted by the compiler. Superclass construction therefore completes before the subclass's field initializers and the rest of its constructor body run.

• The compiler generates a default no-arg constructor only for a class that declares no constructors. If the superclass declares only Ledger(String code), a subclass constructor without an explicit super("...") fails to compile (constructor Ledger in class Ledger cannot be applied to given types).
• Constructors are not inherited and cannot be overridden.
• super.method() calls the direct superclass's implementation — the version that class has or inherits — and is how an override extends rather than replaces behaviour. Calls chain naturally (C calls super into B, which calls super into A); there is no super.super.

Because the object already has its final class while the superclass constructor runs, an overridable method called from that constructor dispatches to the subclass override — before the subclass's fields are initialized:

class Engine {
    Engine() {
        System.out.print("Engine ");
        start();
    }

    void start() {
        System.out.print("engine-start ");
    }
}

class Turbo extends Engine {
    int psi = 5;

    Turbo() {
        System.out.print("Turbo ");
        start();
    }

    @Override
    void start() {
        System.out.print("psi=" + psi + " ");
    }
}

public class Main {
    public static void main(String[] args) {
        new Turbo();
    }
}

This prints Engine psi=0 Turbo psi=5. During Engine(), start() runs Turbo's override and sees psi at its default value 0 (a reference field would be null). Only after Engine() returns does psi = 5 run, followed by the rest of Turbo(). This is why constructors should call only private, final or static methods.

Since Java 25 (JEP 513, final), statements may appear before an explicit super(...) or this(...) call. That leading part is the constructor prologue; the code after the call is the epilogue. The prologue is for work that does not need the object to exist yet: validating or transforming arguments, and initializing the class's own fields.

class Sensor {
    Sensor() {
        System.out.print("armed ");
        describe();
    }

    void describe() { }
}

class Thermostat extends Sensor {
    private final double rate;

    Thermostat(double rate) {
        if (rate < 0) {
            throw new IllegalArgumentException("negative");
        }
        this.rate = rate;
        super();
    }

    @Override
    void describe() {
        System.out.print("rate=" + rate);
    }
}

public class Main {
    public static void main(String[] args) {
        new Thermostat(0.5);
    }
}

This prints armed rate=0.5. rate is assigned in the prologue, so when Sensor() calls the overridable describe(), the subclass override already sees the real value — fixing the "default value seen during construction" problem from the previous section. Had this.rate = rate; come after super();, the output would be armed rate=0.0; a negative rate throws before Sensor() runs at all.

Violations are compile errors with specific messages, for example cannot reference a before supertype constructor has been called and cannot assign initialized field 'b' before supertype constructor has been called.

An abstract class is a class declared abstract that cannot be instantiated directly and may declare abstract methods — methods with no body that every concrete subclass must implement. It can hold everything a normal class can: fields, constructors (run via super(...) from subclasses), concrete and final methods.

abstract class Report {
    private final String title;

    Report(String title) {
        this.title = title;
    }

    abstract String body();

    final String render() {
        return title + ": " + body();
    }
}

class Daily extends Report {
    Daily() {
        super("Daily");
    }

    @Override
    String body() {
        return "all good";
    }
}

public class Main {
    public static void main(String[] args) {
        Report r = new Daily();
        System.out.println(r.render());
    }
}

This prints Daily: all good: the abstract class fixes the algorithm in render() and leaves one step to the subclass.

• An abstract method ends with a semicolon; giving it a body fails to compile.
• An abstract method must be overridable, so abstract cannot be combined with private, static or final; any access other than private is fine.
• A class with an abstract method must itself be abstract. An abstract class may also have no abstract methods at all.
• A concrete (non-abstract) subclass must implement every inherited abstract method, or it fails: X is not abstract and does not override abstract method m() in Y. An abstract subclass may leave them for its own subclasses.
• A class cannot be both abstract and final.
• new Polygon() on an abstract class is a compile error, but Polygon p = new Hexagon(); is the normal way to use one. (An anonymous subclass, new Polygon() { ... }, also works.)

A sealed class or interface lists exactly which types may directly extend or implement it, with sealed ... permits A, B. Each permitted subtype must directly extend it and must declare how the hierarchy continues:

A permitted subtype of a sealed interface may also be an interface, which is then sealed or non-sealed (interfaces cannot be final). Permitted subtypes must live in the same module, or in the same package when the code is in the unnamed module; the permits clause may be omitted when they are declared in the same source file.

Records in hierarchies. A record's direct superclass is always java.lang.Record, so a record cannot use extends; it is implicitly final, so nothing can extend it and it cannot be abstract; it may implement any interfaces. That makes records the usual leaves of a sealed interface.

Exhaustiveness. Because the compiler knows every permitted subtype, a pattern switch over a sealed type needs no default when every subtype is covered:

sealed interface Payment permits Card, Cash, Voucher { }

record Card(String number) implements Payment { }

record Cash(int cents) implements Payment { }

non-sealed class Voucher implements Payment { }

class GiftVoucher extends Voucher { }

public class Main {
    static String label(Payment p) {
        return switch (p) {
            case Card c -> "card";
            case Cash(int cents) when cents > 1000 -> "big cash";
            case Cash c -> "cash";
            case Voucher v -> "voucher";
        };
    }

    public static void main(String[] args) {
        System.out.println(label(new GiftVoucher()) + " "
                + label(new Cash(5000)) + " " + label(new Cash(5)));
    }
}

This prints voucher big cash cash. GiftVoucher is matched by case Voucher v, which covers the whole non-sealed branch. Rules for these switches:

• A guarded case (when ...) does not count towards exhaustiveness; an unguarded case for the same type is still needed (here case Cash c), otherwise the switch expression does not cover all possible input values.
• Covering one subclass of a non-sealed subtype does not cover the subtype; only a case for the non-sealed type itself (or a supertype) does.
• A case that can never match because an earlier case already covers it is a compile error (dominated), so specific cases go before general ones.
• Record patterns such as Cash(int cents) deconstruct components and can nest, which makes recursive evaluation over a sealed tree concise.
• If the hierarchy changes after the switch was compiled, an unmatched value throws MatchException at runtime rather than slipping through.

Every class inherits equals(Object), hashCode() and toString() from Object; the defaults compare identity, return an identity-based hash and print the class name with a hash. Value classes override them — and must override them with the exact Object signatures, all public.

import java.util.HashSet;
import java.util.List;
import java.util.Set;

class Isbn {
    private final String code;

    Isbn(String code) {
        this.code = code;
    }

    @Override
    public boolean equals(Object o) {
        return o instanceof Isbn other && code.equals(other.code);
    }

    @Override
    public int hashCode() {
        return code.hashCode();
    }

    @Override
    public String toString() {
        return "Isbn[" + code + "]";
    }
}

public class Main {
    public static void main(String[] args) {
        Set<Isbn> set = new HashSet<>(List.of(new Isbn("978")));
        System.out.println(set.contains(new Isbn("978")) + " " + set);
    }
}

This prints true [Isbn[978]]: a different Isbn object with the same code is found in the set.

The contract. Objects that are equal by equals must return the same hashCode(). Hash-based collections (HashSet, HashMap) use the hash to pick a bucket and then equals(Object) to compare inside it, so both must be overridden consistently. Overriding only hashCode() leaves identity equality in place — two value-equal objects are both kept. Overriding only equals breaks lookups because equal objects usually land in different buckets.

The overload trap. public boolean equals(Coord other) does not override anything; it overloads equals(Object). It is chosen only when the compiler sees a Coord argument; a call with an Object-typed argument, and every collection method (contains, indexOf, remove), calls equals(Object) and gets identity comparison. Adding @Override turns this silent bug into a compile error.

Records generate all three methods from their components; you may still override them explicitly, using the same public signatures.