Inheritance & Polymorphism — One Reference, Many Behaviors

Classes let you model one type of thing. Inheritance lets one class build on top of another:

• A subclass extends a superclass. It inherits the superclass's fields and methods, and adds its own.
• It can override an inherited method — that is, redeclare it, so its own version replaces the parent's.
• The real prize is polymorphism. When you call an overridden method through a superclass reference, Java runs the version that belongs to the object's actual runtime type.

Picture a loop over an Animal[] that holds a Dog and a Cat: each one speaks in its own voice. The mechanism behind this is called dynamic dispatch. It lets code written against a general type drive specialized behavior it has never even seen.

This lesson also shows you where dispatch stops: at fields and static methods, at casts back to the specific type, at final, and at the methods that every object inherits from Object.

This lesson takes a deeper pass at classes & objects. Every output below was produced by compiling and running the code on Java 25.

You'll be able to: trace the order in which a subclass's constructors run, and fix a missing super(...) call; predict which version runs when you reach an overridden method, a hidden field or a static method through a superclass reference; predict whether a reference cast compiles, succeeds or throws ClassCastException, and guard it with instanceof; name the compiler error for a misspelled override, a narrowed access level, and an override of a final method; choose between inheritance and composition using the "is-a" test.

Table of contents

1. extends: inheriting and adding
2. Overriding and super
3. Dynamic dispatch: polymorphism
4. Reference casting: instanceof and ClassCastException
5. final and the Object methods
6. Mental-model summary
7. Gotcha checklist
8. Check yourself
9. Sources

1. extends: inheriting and adding

A subclass declares extends Superclass, and it automatically gets the superclass's fields and methods. Its constructor calls the superclass constructor with super(...). On top of that, the subclass can add members of its own.

Output:

Rex is an animal
Rex fetches the ball

Analysis.

• Dog inherited name and describe() from Animal, so d.describe() worked even though Dog never defines it.
• Dog added its own fetch().
• Dog's constructor called super(name) to run Animal's constructor, which sets name.
• The arrow in the diagram (<|--) reads "Dog is an Animal."

The superclass part of the object is set up before the subclass part. Before JDK 25, the language enforced this by making super(...) the first statement in the constructor. Since JDK 25, statements may come before super(...), as long as they don't use the object that's being built [3] [15]. Later in this section, you'll see why that matters.

Intuition. Mechanism. new Dog("Rex") creates one object, with room for both the fields declared in Animal and those declared in Dog [17]. Construction runs top-down: the Animal constructor initializes the inherited fields first, and then the Dog constructor finishes the job.

What if you don't write super(...) at all? Then javac inserts super(); — a call to the superclass's no-argument constructor — as the first statement [3]. You can see the order when each constructor prints something:

Output:

1. Animal's constructor
2. Dog's constructor

Dog() never mentions Animal, yet Animal's constructor ran first, because the inserted super(); called it.

Concrete bite. That inserted call only works if the superclass has a no-argument constructor. Animal below has only Animal(String name), so the implicit super(); has nothing to call:

Compiler error:

Main.java:7: error: constructor Animal in class Animal cannot be applied to given types;
    Dog(String name) { }
                     ^
  required: String
  found:    no arguments
  reason: actual and formal argument lists differ in length

The caret points at Dog's body, which is where the invisible super(); sits. The fix is the super(name); from the first example. Note that constructors aren't inherited either: Dog gets no Dog(String) unless it declares one itself [2].

Non-example: a superclass constructor calls an overridden method. Animal's constructor calls describe(), and Dog overrides it. The call runs Dog's version, before Dog's constructor has set name:

Output:

a dog named null

The field was still null, its default value, even though it's final and the constructor sets it. Construction runs top-down, so Animal() ran, and called describe(), before the line this.name = name;.

Since JDK 25, a constructor may assign its own fields before it calls super(...) [15]. Move the assignment up, and the field is ready by the time the superclass needs it:

Output:

a dog named Rex

The code before super(...) can assign fields, check arguments and compute values. It can't read a field or call an instance method of the object, because the object isn't ready yet. javac rejects that with cannot reference … before supertype constructor has been called.

Non-example: a private field is not inherited. Members declared private are not inherited by subclasses [2]. The field still exists inside a Dog object, but Dog's code can't refer to it by name:

Compiler error:

Main.java:6: error: secret has private access in Animal
    String reveal() { return secret; }
                             ^
1 error

To fix it, give the superclass a method that returns the value, or mark the field protected so subclasses can see it (access levels).

Non-example: inheriting only to reuse code. The test for whether to inherit is the "is-a" relationship. A Dog genuinely is an Animal. But the JDK's own java.util.Stack fails this test: it extends Vector, which is a growable list [14]. As a result, every list method comes along for the ride — including insert-at-any-position, which breaks "last in, first out":

Output:

[sneaked in, first, second]
second
sneaked in

add(0, …) slipped an element under the stack, and get(0) read the bottom. A real stack should allow neither. In fact, Stack's own API page recommends using the Deque interface instead [14]. A stack has a list; it isn't one. Holding the list in a private field is called composition, and it exposes only the operations you choose to write.

2. Overriding and super

A subclass overrides an inherited method by redeclaring it with the same signature. For objects of that subclass, its version replaces the superclass's. When you need both, super.method() still reaches the superclass's version.

Output:

Woof
... / Woof

Analysis.

• Dog.speak() overrode Animal.speak(), so d.speak() is "Woof".
• Inside both(), super.speak() called Animal's version ("..."), while a plain speak() called Dog's ("Woof"). Together, they give "... / Woof".

super is your escape hatch back to the parent's behavior. You'll often use it to extend that behavior: "do what the parent does, plus this."

Intuition. Mechanism. An override must have the same signature as the inherited method: the same name and the same parameter types [4]. The @Override annotation asks the compiler to verify that for you. If the method doesn't actually override anything, that's an error [5] — which catches typos and signature mismatches.

Concrete bite. Misspell the method name (or get the parameters wrong), and you've written a new method, not an override. @Override turns that silent mistake into a compile error:

Compiler error:

Main.java:4: error: method does not override or implement a method from a supertype
    @Override
    ^

speakk (note the typo) overrides nothing, so @Override flags it. Without the annotation, this would compile as a brand-new method that nobody ever calls, and speak() would quietly keep the parent's behavior.

Non-example: an override that narrows access. An override must give at least as much access as the method it replaces [6]. Object.toString() is public. If you leave public off, the name and parameters still match, but the override is rejected:

Compiler error:

Main.java:3: error: toString() in Animal cannot override toString() in Object
    String toString() { return "an animal"; }
           ^
  attempting to assign weaker access privileges; was public
1 error

The fix is to declare it public String toString(), as §5 does. The return type, by the way, has one degree of freedom: an override may return a subtype of the original's return type [6].

3. Dynamic dispatch: polymorphism

Now for the payoff. A variable's declared type can be a superclass, while the object it points to is a subclass.

• Assigning a Dog to an Animal variable is called an upcast. It needs no cast syntax, because every Dog is an Animal.
• When you call an overridden method, Java runs the version for the object's actual runtime type — not the declared type. This is dynamic dispatch.

Output:

Rex: Woof
Felix: Meow
Thing: ...

Analysis. Every element is declared as an Animal, yet each a.speak() ran the object's own version: Dog's Woof, Cat's Meow, Animal's .... The loop is written against Animal and knows nothing about Dog or Cat, yet it drives their specialized behavior. That's polymorphism: one interface (speak() on Animal), many implementations, with the actual type choosing between them at run time.

Intuition. Mechanism. Two types are in play at every call, and each one decides one thing:

• The declared type decides, at compile time, which methods you may call at all.
• For an instance method, the object's class decides, at run time, which override runs [7].

That's why the loop's Animal reference can invoke Dog.speak(). But the first rule has a bite of its own: Dog's extra method is out of reach through an Animal variable, even when the object really is a Dog:

Compiler error:

Main.java:14: error: cannot find symbol
        System.out.println(a.fetch());
                            ^
  symbol:   method fetch()
  location: variable a of type Animal
1 error

The compiler looked for fetch() in Animal, the declared type, and didn't find it. §4 shows you how to reach it.

Concrete bite. The dynamic rule applies to methods, not fields. A field access is resolved by the declared type, at compile time:

Output:

Woof
animal

a.speak() dispatched dynamically to Dog ("Woof"), but a.kind read Animal's field ("animal"). Java uses only the declared type to pick the field, never the object's class [8].

Dog's kind hides Animal's, and both fields exist side by side in the object. Hiding a field like this is a code smell precisely because it causes this kind of confusion. Override methods; don't hide fields.

Non-example: a static method does not dispatch. A static method belongs to the class, not to an object. So a subclass's static method with the same signature hides the parent's, rather than overriding it [9]. Just like a field, it's picked by the declared type:

Output:

Woof
animal

a.kind() compiled, but it ran Animal.kind(). Call a static method through its class name instead (Dog.kind()), and the code says exactly what it does.

4. Reference casting: instanceof and ClassCastException

You met casts on numbers in Numbers & Arithmetic, and instanceof paired with a cast in equals & hashCode. On references, a cast changes only the declared type. It never changes the object itself.

• An upcast (Dog to Animal) is always safe, so it happens automatically.
• A downcast (Animal to Dog) needs the cast syntax, (Dog) a. It's a promise that the object is a Dog, and the JVM checks that promise at run time [10].
• a instanceof Dog asks the same question without the risk. It's true when the object could be cast to Dog, and false for null [12].

Guard the downcast with instanceof, and fetch() is back within reach:

Output:

Woof, then fetches the ball
Meow, and no fetch

Analysis. The Dog passed the instanceof test, so the cast was safe, and d.fetch() compiled because d is declared as a Dog. The Cat failed the test, so the code never attempted the cast. Meanwhile, a.speak() dispatched as usual; the cast was needed only for fetch().

Intuition. Mechanism. A downcast gets checked twice. First, the compiler rejects any cast between two types that no object could belong to at once. Then the JVM checks the object's class at the moment of the cast. If the object isn't a Dog (or a subclass of Dog), the cast throws a ClassCastException [11].

Concrete bite. This cast compiles, because an Animal could be a Dog. But this particular one is a Cat:

Output (prints about to cast, then a thrown exception):

about to cast
Exception in thread "main" java.lang.ClassCastException: class Cat cannot be cast to class Dog (Cat and Dog are in unnamed module of loader 'app')

The message names both classes: the object's actual class (Cat) and the cast's target (Dog). The failure happens at run time, on line 9 — far from the line that put a Cat into a.

Non-example: a cast between unrelated types. A Dog can never be a String. Both are classes, and neither one extends the other, so the compiler refuses the cast outright:

Compiler error:

Main.java:7: error: incompatible types: Dog cannot be converted to String
        String s = (String) d;
                            ^
1 error

A cast can't turn an object into a different class of object. If you want text from a Dog, call a method that builds it, such as toString().

5. final and the Object methods

Putting final on a method forbids overriding it, so no subclass can change that behavior. Meanwhile, every class other than Object has a superclass — and if you don't write extends, that superclass is Object itself [1]. So every object already comes with methods like toString, equals, and hashCode, which you override to give them meaning.

Output:

Animal(Rex)
unknown

Analysis.

• System.out.println(a) called the overridden toString(), giving Animal(Rex).
• Object's default would have printed the class name, an @, and the hash code in hexadecimal [13] — something like Animal@1b6d3586.
• species() is final: you can use it, but it's locked against overriding.

Overriding toString/equals/hashCode is how your types get readable printing and correct value equality. You inherit these methods from Object whether you ask for them or not.

Intuition. Mechanism. Object is the root of every class hierarchy, so its methods are always there to override. A final method, on the other hand, can't be overridden or hidden: the compiler rejects any attempt [16]. Its behavior is fixed for the whole hierarchy.

Concrete bite. Try to override a final method, and it won't compile:

Compiler error:

Main.java:2: error: species() in Dog cannot override species() in Animal
class Dog extends Animal { @Override String species() { return "dog"; } }
                                            ^

Animal.species() is final, so Dog can't override it — the lock holds. javac's next line spells out the reason: overridden method is final.

Non-example: extending a final class. Putting final on a class forbids subclasses altogether [1]. String is one such final class:

Compiler error:

Main.java:1: error: cannot inherit from final String
class Shout extends String { }
                    ^
1 error

To add behavior to text, write a class that has a String field (composition), or write a static helper method.

6. Mental-model summary

7. Gotcha checklist

✅ Check yourself

One check per objective. Answer before you open anything.

Woof
Meow
Tweet
Woof / animal

📚 Sources

1. The Java Language Specification, Java SE 25, §8.1.4 "Superclasses and Subclasses" (the default direct superclass is Object; a final class may not be named in extends) — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.1.4
2. The Java Language Specification, Java SE 25, §8.2 "Class Members" ("Members of a class that are declared private are not inherited"; constructors are not members) — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.2
3. The Java Language Specification, Java SE 25, §8.8.7 "Constructor Body" (the implicit super();; the prologue and the early construction context) — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.8.7
4. The Java Language Specification, Java SE 25, §8.4.2 "Method Signature" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.4.2
5. The Java Language Specification, Java SE 25, §9.6.4.4 "@Override" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-9.html#jls-9.6.4.4
6. The Java Language Specification, Java SE 25, §8.4.8.3 "Requirements in Overriding and Hiding" (return-type-substitutable; "at least as much access") — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.4.8.3
7. The Java Language Specification, Java SE 25, §15.12.4.4 "Locate Method to Invoke" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.12.4.4
8. The Java Language Specification, Java SE 25, §15.11.1 "Field Access Using a Primary" ("only the type of the Primary expression … is used in determining which field to use") — https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.11.1
9. The Java Language Specification, Java SE 25, §8.4.8.2 "Hiding (by Class Methods)" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.4.8.2
10. The Java Language Specification, Java SE 25, §5.1.6 "Narrowing Reference Conversion" (may require a test at run time) — https://docs.oracle.com/javase/specs/jls/se25/html/jls-5.html#jls-5.1.6
11. The Java Language Specification, Java SE 25, §15.16 "Cast Expressions" (ClassCastException "if a cast is found to be impermissible at run time") — https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.16
12. The Java Language Specification, Java SE 25, §15.20.2 "The instanceof Operator" (the null reference gives false) — https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.20.2
13. java.lang.Object, Java SE 25 API (toString: getClass().getName() + '@' + Integer.toHexString(hashCode())) — https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Object.html
14. java.util.Stack, Java SE 25 API (extends Vector; Deque "should be used in preference to this class") — https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Stack.html
15. JEP 513: Flexible Constructor Bodies (JDK 25) — https://openjdk.org/jeps/513
16. The Java Language Specification, Java SE 25, §8.4.3.3 "final Methods" — https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.4.3.3
17. The Java Language Specification, Java SE 25, §12.5 "Creation of New Class Instances" (room for "all the instance variables that may be hidden") — https://docs.oracle.com/javase/specs/jls/se25/html/jls-12.html#jls-12.5

Your Turn

Before you move on, check your understanding with the coach — explain the idea, apply it, weigh the trade-offs, then defend your reasoning.