super Keyword

Extending, Not Just Replacing, Inherited Behavior

Overriding a method (Lesson 18.1) completely replaces the superclass's version — but often a subclass wants to run the original logic too, and add something on top of it, rather than throwing it away entirely. super.method() calls the superclass's version of a method explicitly, from inside an override. A Climber should still do everything RobotPart's stop() does (Lesson 17.1), and then engage its brake:

public class Climber extends RobotPart
{
    public Climber(String name) { super(name); }

    @Override
    public void stop()
    {
        super.stop();            // runs RobotPart's stop() first
        log("brake engaged");    // then adds Climber's own step
    }
}

You've seen this once already: Lesson 17.4's Intake.toString() called super.toString() and added to its result.

super has two distinct uses: super(...), which calls a superclass constructor from inside a constructor (Lesson 17.2); and super.method(), which calls a superclass method from anywhere inside a subclass method body. Where super(...) may go depends on the Java version: on Java 25, only statements that don't use the object being built may come before it; on Java 17, it must be the constructor's very first statement.

How Method Lookup Actually Works

Every object remembers the actual class it was created with. A method call on that object starts looking there first; if the method isn't found in that exact class, Java searches up the chain — parent, grandparent, and so on — until it finds a match (which it always will, or the code wouldn't have compiled in the first place).

RobotPart part = new Climber("Left Climber");
part.stop();
// prints:
// [Left Climber] stopped
// [Left Climber] brake engaged

Calling part.stop() starts in Climber.stop(), because the object is a Climber; when execution reaches super.stop(), it runs RobotPart.stop(), which logs stopped, then returns to finish the rest of Climber.stop()'s body, which logs brake engaged.

A Subtlety: super Only Affects the One Call It's Written On

super.someMethod() only changes which version of that specific call runs — it doesn't change how any other method call inside the same method resolves. Any call made without super (an unqualified call, or one through this) still dispatches based on the object's actual runtime type, even from inside inherited code. RobotPart's stop() calls log(...): if Climber also overrode log(), then the log("stopped") call inside RobotPart.stop() — reached through super.stop() — would run Climber's log(), not RobotPart's. The override "wins" everywhere except the one spot super explicitly overrides it.

Common Pitfalls

• Forgetting super.method() must be called explicitly — it never happens automatically the way super() does for constructors. Overriding a method completely discards the superclass's version unless the override calls super.method() itself.
• Confusing the two super forms. super(...) (no method name) only ever calls a constructor, and only from inside a constructor — first on Java 17, and after only object-free statements on Java 25; super.method() calls a named method, and can appear anywhere inside a method body.
• Assuming super.method() changes every call inside that method to use the superclass's versions. It only affects the one call written with super — any other method call inside that same superclass method still resolves against the object's real runtime type.

Key Takeaways

• super.method() explicitly calls the superclass's version of a method, letting a subclass extend rather than fully replace inherited behavior.
• Method lookup starts at the object's actual class and searches upward through its ancestors until a match is found.
• super(...) (constructors) and super.method() (methods) are two distinct, unrelated uses of the same keyword.
• A super.method() call only affects that one call — any other unqualified method call inside still dispatches to the object's real runtime type.

Derived from csawesome-2026: unit-5-inheritance-optional/5.04-super-keyword.md (CSA 5.4) Deck context: mechacoder-test/src/lessons/java-2.js, slide 5 ("Polymorphism: Many Forms")