What Is Constructor Chaining in Java? A 2026 Guide – 2

Every time you write new SomeClass(), more happens behind the scenes than a single constructor running. If that class extends another class, or if its own constructor calls a different constructor in the same class, you’re looking at constructor chaining: a sequence of constructor calls that all fire before your object is considered fully built. It’s one of those Java fundamentals that’s easy to use by accident and genuinely useful once you understand it on purpose.

This guide covers what constructor chaining actually is, the two keywords that drive it, the rules the compiler enforces around it, and where it fits now that records have given Java a second, more restricted way to initialize objects.

What Is Constructor Chaining, Exactly?

Constructor chaining is the process of one constructor invoking another, either in the same class or in a parent class, before it runs its own body. It happens in two situations. The first is deliberate: a constructor explicitly calls a sibling constructor to avoid repeating setup logic. The second is automatic: whenever you create an instance of a subclass, Java has to run a constructor of the base class first, because a subclass object isn’t valid until its inherited state exists.

That second case is why chaining and inheritance are so tightly linked. When you instantiate a derived class, the base class’s constructor runs before the derived class’s own constructor body executes, every single time, whether you asked for it or not.

Two Ways to Chain: this() and super()

Java gives you exactly two keywords for this, and they’re not interchangeable:

• this(…) calls another constructor in the same It’s how you avoid duplicating field-assignment logic across overloaded constructors.
• super(…) calls a constructor in the immediate parent It’s how a subclass makes sure its inherited state gets initialized properly before it adds its own.

Chaining Within the Same Class: this() in Action

Here’s a class with three constructors, each one narrower than the last, chained together with this():

public class Employee {

    // No-argument constructor
    Employee() {
        this(2023);
        System.out.println(“In default constructor of Employee class”);
    }

    // Constructor with an int parameter
    Employee(int employeeId) {
        this(“Ankush”);
        System.out.println(“In parameterized constructor with int parameter: ” + employeeId);
    }

    // Constructor with a String parameter
    Employee(String employeeName) {
        System.out.println(“In parameterized constructor with String parameter: ” + employeeName);
    }

    public static void main(String[] args) {
        Employee employeeObj = new Employee();
    }
}

Output:

In parameterized constructor with String parameter: Ankush
In parameterized constructor with int parameter: 2023
In default constructor of Employee class

Notice the order: it reads almost backwards from how you’d expect. new Employee() calls the no-arg constructor, which immediately calls this(2023), which immediately calls this(“Ankush”). Java runs the innermost call first and then unwinds back up the chain, printing each message as it returns. The constructor that does the least chaining runs its own print statement first, not last.

Chaining Across Classes: super() in Action

Now the same idea, but across an inheritance boundary:

// Parent class
class Employee {

    Employee() {
        System.out.println(“In default constructor of Employee class”);
    }

    Employee(String employeeName) {
        System.out.println(“In parameterized constructor of Employee class with String parameter: ” + employeeName);
    }
}

// Derived class
public class SoftwareDeveloper extends Employee {

    SoftwareDeveloper() {
        super(“Ankush”);
        System.out.println(“In default constructor of SoftwareDeveloper class”);
    }

    public static void main(String[] args) {
        SoftwareDeveloper softwareDeveloperObj = new SoftwareDeveloper();
    }
}

Output:

In parameterized constructor of Employee class with String parameter: Ankush
In default constructor of SoftwareDeveloper class

When SoftwareDeveloper() runs, its very first statement, super(“Ankush”), hands control to the parent class’s parameterized constructor. That constructor finishes and prints its line first. Only then does execution return to SoftwareDeveloper() to run the rest of its own body. The parent always finishes initializing before the child adds anything on top.

The Rules That Keep Chaining Predictable

A handful of compiler-enforced rules make all of this deterministic rather than a source of bugs:

this() can only call a constructor in the same class, never a parent’s. super() can only call the immediate parent’s constructor, never a grandparent’s directly (each class is responsible for chaining to its own parent). Whichever one you use has to be the very first statement in the constructor body, which also means this() and super() can never both appear in the same constructor. And if you write a constructor with neither, the compiler inserts an implicit super() call to the parent’s no-argument constructor for you, silently, which is why a subclass fails to compile if its parent has no accessible no-arg constructor and the subclass doesn’t explicitly call one of the parameterized ones.

Where This Fits in 2026: Records and Compact Constructors

Constructor chaining hasn’t changed since Java 17, but it now shares the stage with a second, more constrained initialization model: records, which were finalized back in Java 16 and have only become more central to idiomatic Java through the current Java 25 LTS release.

A record’s canonical constructor (the one matching its component list) and its shorthand, the compact constructor, cannot use this() or super() at all. Instead, the compiler automatically assigns every field for you at the end of the constructor body, which is what makes records so terse for simple data carriers. If you add a secondary, non-canonical constructor to a record, it’s held to a stricter rule than ordinary classes: its first statement must delegate to the canonical constructor via this(…), every field still has to get set, and there’s no super() path to a parent, since a record implicitly extends java.lang.Record and can’t extend anything else.

The upshot for 2026: classic constructor chaining with this() and super() is still exactly how you’ll write any class with real inheritance or multiple constructors. Records simply trade that flexibility for guaranteed, boilerplate-free initialization when a class is really just an immutable bundle of data, and they borrow the same chaining vocabulary (this(…)) in a narrower form when they need it.

The Takeaway

Constructor chaining is what guarantees that every layer of an object’s state gets initialized before the next layer builds on top of it, whether that chaining happens explicitly through this() and super() or implicitly because the compiler inserted it for you. Once you can read a chain and predict its execution order, a lot of “why did this print in a weird order” debugging sessions stop being mysterious. And if you’re reaching for records in newer code, it’s worth knowing that they lean on the same mechanism, just with the compiler holding the wheel more tightly.