Constructor Calls in Inheritance

A building goes up from the foundation: ground floor first, then the first floor, then the second. Objects in a class hierarchy are built the same way. When you create a Director, which extends Manager, which extends Employee, Java builds the Employee part first, then the Manager part, then the Director part. Each constructor first calls its parent's, all the way up to Object.

The Chain

public class Chain {
    static class Employee {
        Employee(String name) {
            System.out.println("1. Employee part ready for " + name);
        }
    }
 
    static class Manager extends Employee {
        Manager(String name) {
            super(name);
            System.out.println("2. Manager part ready");
        }
    }
 
    static class Director extends Manager {
        Director(String name) {
            super(name);
            System.out.println("3. Director part ready");
        }
    }
 
    public static void main(String[] args) {
        new Director("Navika");
    }
}

1. Employee part ready for Navika
2. Manager part ready
3. Director part ready

How it works

1. new Director("Navika") calls Director's constructor.
2. Its first action is super(name), which calls Manager's constructor, whose super(name) calls Employee's, which implicitly calls Object's.
3. Only when a parent constructor finishes does the child's body continue. So the bodies run top-down: Employee, Manager, Director.

Try it yourself: add a print before super(name) in Director, which Java 25 allows. Where does it appear in the output?

The Automatic super()

If a constructor doesn't call this(...) or super(...), the compiler inserts super(), a call to the parent's no-arg constructor. That's fine when the parent has one. When it doesn't, the child fails to compile:

NoSuper.java:2: error: constructor Account in class Account cannot be applied to given types;
class Savings extends Account { Savings() {} }
                                          ^
  required: String
  found:    no arguments

Account only has a constructor that takes a String, so the hidden super() has nothing to call. Fix it by calling the right parent constructor explicitly: Savings() { super("Unknown"); }, or by giving Account a no-arg constructor.

Full Order with Fields and Blocks

Combined with the rules from "Order of Initialization", each level does this before the next level's body runs:

1. Call the parent's constructor (recursively, up to Object).
2. Run this class's field initializers and instance blocks, top to bottom.
3. Run the rest of this constructor's body.

Common Mistakes

Expecting the child's fields to be ready inside the parent's constructor. They still hold default values until the parent finishes.

Forgetting super(...) when the parent has no no-arg constructor. The compile error above.

Calling an overridable method from a parent constructor. The child's override runs before the child's fields are set ("Runtime Polymorphism and Dynamic Method Dispatch" shows the bug).

Interview Corner

Practice

1. Easy: Predict the output if main creates new Manager("Srihitha") instead.
2. Harder: Add an instance block to each of the three classes that prints a message, then predict the full order of six lines before running it.

Key Takeaways