Method overriding and super

In inheritancea subclass got its parent's fields and methods for free. That is a fine deal when the inherited behavior is exactly what you want. But often it is almost right and not quite. A Dog is an Animal, yes, but it does not make a generic animal noise. It barks. This lesson is about a subclass saying: thank you for the method, I will take it from here.

The inherited method is almost right#

Here is where inheritance left off. An Animal can speak, and a Dog inherits that ability without writing a single new line. Watch what a dog actually says.

Both lines print the same thing. The dog inherited speakword for word, so it makes the generic noise. That is correct inheritance and it is also useless: nobody believes a dog says “Some generic animal sound”. The dog should stay an Animal in every other way and answer speak differently.

Key idea

Inheritance gives you the parent's behavior for free. Overriding lets you swap out one piece of that behavior while keeping the rest.

Overriding: redefine the method in the subclass#

To change what a dog says, write a method in Dog with the same name, the same parameters and the same return type as the one in Animal. When a subclass redefines an inherited method like this, it overridesthat method. The dog's version wins for dogs, and the animal's version still stands for plain animals.

Now the two lines differ. a.speak() runs the Animal version and prints the generic sound. d.speak() runs the Dog version and prints Woof. The Dog still inherits everything else from Animal; only the one method was replaced. The parent's speak is not deleted or damaged, and plain animals still use it.

Calling back to the parent with super#

Sometimes you do not want to throw the parent's work away. You want to add to it. A cat makes its own sound, but suppose we still want the generic animal sound tucked inside the cat's answer. Java has a keyword for reaching the version you just overrode: super.

Inside an overriding method, super.speak() means “run the speakthat my parent class has, not my own”. Without super, writing speak()there would call the cat's own version again, which would call itself again, and so on until Java gives up with a StackOverflowError. The superprefix skips your own version and goes to the parent's.

Trace it by hand. c.speak() enters the Cat version. It builds a string starting with "Meow (", then reaches super.speak(), which jumps up to Animal.speak() and gets back "generic sound". The pieces join into Meow (generic sound), and that is what prints. The cat extended the parent's behavior instead of replacing it.

Key idea

Override to replace. Override and call superto extend. Replacing throws the old behavior away; extending wraps your own work around the parent's.

Here is that receipt, scrambled. Order matters inside the override: the parent's lines come first, then the extra one.

Putting it together: Animal, Dog, Cat#

Here is the full cast in one program. Dog replaces speak outright. Cat extends it with super. A plain Animal keeps the original. Press Run and step through. Watch each speak() call land in a different method body even though all three calls look alike.

The output is three different lines: Some animal sound, then Woof!, then Meow (Some animal sound). Three objects share one method name and behave three different ways. Each object decides which body runs, based on what it actually is.

The @Override safety net#

Overriding depends on matching the name and parameters exactly, and a small slip means you do not override at all. Here is a Dog whose author meant to override speak() but swapped two letters in the name. Decide what it prints before you run it.

It prints Some generic animal sound. Java treats spaek as a brand new method with its own name, so a Dog now has two methods: the speak() it inherited and an unrelated spaek(). The call d.speak() finds the inherited one. There is no error and no warning, just the wrong sound. A wrong parameter list or a capital letter in the wrong place fails in the same silent way.

The fix is a one-word note to the compiler called an annotation. Writing @Override on the line above a method tells Java: this method is meant to override one from a parent class, so please check. If it does not override anything, the program does not compile, and the silent bug turns into an error you can fix in seconds. Here is the same dog with the annotation added, and what javac says about it:

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

The compiler points straight at the annotation. (From Java 26 on, the message also names the method: spaek() in Dog does not override or implement a method from a supertype.) Fix the spelling to speak and the program compiles and barks.

Here is the cat from earlier with the annotation in place. Write every override this way from now on.

The rules an override must follow#

Matching the name and the parameters is the main rule. The compiler checks two more, and both come up early in real code.

• The return type must match the parent's. A void speak() cannot override a String speak(). An override may also return a more specific type, such as a Dog where the parent returns an Animal. That is called a covariant return type, and you will rarely need it at first.
• An override cannot be less visible than the method it replaces. If the parent's method is public, the override must be public too. A protected method may become public in a subclass, but never private.

toString: a method every class inherits#

The second rule bites the first time you override a method you did not write yourself. Every class extends Object, as you saw in inheritance, and Object gives every object a toString() method that turns it into text. Whenever you print an object, println calls its toString(). Object's version gives the class name, an @ and a number, something like Book@1b6d3586, and the number usually changes from one run to the next. Override toString and your objects print something useful instead.

Step through it. Each println calls your toString(), and so does joining a book to a string with +. The two lines are Dune by Frank Herbert and On the shelf: Dune by Frank Herbert.

Notice the public in front. Object declares toString as public, so an override has to be public as well. A method with no access word at all, like the speak() methods on this page, is less visible than that, and javac rejects it:

Main.java:19: error: toString() in Book cannot override toString() in Object
    String toString() {
           ^
  attempting to assign weaker access privileges; was public
1 error

“Weaker access privileges” means “less visible”. The fix is the one word public.

1public class Main {
2    public static void main(String[] args) {
3        Player ada = new Player("Ada", 91);
4        Player grace = new Player("Grace", 88);
5 
6        System.out.println(ada);
7        System.out.println(grace);
8        System.out.println("Winner: " + ada);
9    }
10}
11 
12class Player {
13    private String name;
14    private int score;
15 
16    Player(String name, int score) {
17        this.name = name;
18        this.score = score;
19    }
20 
21    // TODO: override toString so a player prints as: Ada has 91 points
22}

Overriding versus overloading#

Overriding and overloading sound alike, and people mix them up all the time. Both involve methods that share a name, but they are different ideas. One question keeps them apart: do the parameter lists match?

• Overloading is several methods with the same name but different parameter lists. You met it in methods: area(int side) and area(int width, int height) are two overloads. Java picks one by looking at the arguments you pass, and it decides while compiling, before the program runs.
• Overriding is one method, with the same name and parameters, redefined in a subclass. There is a parent version and a child version. Java picks one by looking at the object's actual class, and it decides while the program runs.

Here is overloading on its own, with no inheritance in sight. One class has three methods named show, each taking a different parameter type. Step through it and watch which show each call jumps into.

It prints int: 42, String: hello and double: 3.5. Java matched each call to an overload by the type of its argument: 42 is an int, "hello" is a String and 3.5 is a double.

Who decides which version runs?#

This page keeps saying “the object decides”. Here is exactly what that means. When you call thing.speak(), the compiler checks the declared type of thing to make sure it has a speak() at all. Which version runs is settled later, while the program runs: Java looks at the object thingpoints to at that moment, finds that object's class, and runs that class's version of speak. This choice at run time is called dynamic dispatch.

The clearest way to see it is to point a parent-typed variable at a child object. Put a row of animals in one array whose declared type is Animal, then call speak() on each in one ordinary loop. The loop body never mentions Dog or Cat, yet each call lands in the right method.

Every slot of zoo is declared as an Animal, so the loop can treat them all the same way. But when zoo[i].speak() runs, Java checks the real object in that slot. Slot 0 holds a plain animal, so it prints Thing says .... Slot 1 holds a dog, so it prints Rex says Woof. Slot 2 holds a cat, so it prints Lily says Meow (...). The loop has one method call, and Java chooses its version object by object as the program runs.

Dynamic dispatch also applies when the call is written inside the parent's own code. Below, Animal has a describe() method that calls speak(), and Dog overrides only speak(). Decide what the two lines print.

The second line is Rex says Woof. describe() lives in Animal and Dog never touched it, yet the speak() inside it ran the dog's version. A bare call like speak() inside a method means this.speak(), a call on the object the method is running for, and here that object is a Dog. Wherever the call is written, the object decides. Open it in the playground and step through: the second describe() jumps from Animal's code into Dog's speak().

Key idea

An ordinary call to an overridden method runs the object's own version, wherever the call is written and however the variable is declared.

1public class Main {
2    public static void main(String[] args) {
3        Account basic = new Account();
4        basic.withdraw(300);
5 
6        Account teen = new TeenAccount();
7        teen.withdraw(300);
8        teen.withdraw(50);
9    }
10}
11 
12class Account {
13    int balance = 500;
14 
15    void withdraw(int amount) {
16        balance = balance - amount;
17        System.out.println("Withdrew " + amount + ", balance " + balance);
18    }
19}
20 
21class TeenAccount extends Account {
22    // TODO: override withdraw. Over 100: print "Limit is 100" and stop.
23    // Otherwise: let Account's withdraw do the work.
24}

Overloads look at the variable, overrides look at the object#

The two kinds of choice can meet in one program. Below, Keeper has two overloads of feed: one for any Animal and one for a Dog. The variable a holds a dog, but its declared type is Animal. Guess which feed the call lands in, then step through and watch.

It prints feed(Animal) runs, then Woof. The overload is picked while compiling, and all the compiler knows about a is its declared type, Animal, so feed(Animal) runs even though the object is a dog. The override is picked while the program runs, from the real object, so speak() barks.

The same rule holds for classes you did not write. Object is the parent of every class, so an Object variable can hold any object, a String included. Below, word and thing point at the very same string.

The first call prints String: hello and the second prints Object: hello. The object is the same both times. Only the declared type of the variable changed, and that alone decided which overload ran.

Further reading#

• Overriding and Hiding Methods, the dev.java tutorial on the rules for an override, including return types and access
• Polymorphism, the dev.java tutorial, with its section on using the keyword super
• The Override annotation in the Java SE 25 API documentation
• Inheritance, Overriding, and Hiding, section 8.4.8 of the Java Language Specification