A guide to constructors in Java

Constructors look like the easiest topic in the language, and that's why interviewers love them. The basic questions ("what's a default constructor?") take ten seconds. Then come the ones that need a mental model: what does this code print, across a parent and child with static blocks and instance blocks? Why does a subclass field read null inside the parent's constructor? What happens to the object if the constructor throws?

For this lesson, we'll focus on every kind of constructor (default, no-arg, parameterised, overloaded, copy, private), chaining with this(...) and super(...), the exact initialisation order and the <init> bytecode behind it, and the production traps: overridable calls, leaking this and exceptions.

01Picture it first: building floors from the foundation up

Think of constructing a building. You can't fit out the third floor before the foundation is poured and the first two floors stand. Java objects are built the same way: Object is the foundation, each parent class is a floor, and your class is the top floor. Calls go down first, bodies run on the way back up.

The diagram below follows new PriorityOrder("asha"), a subclass of the Order class we'll write in a moment, through its this(...) and super(...) hops down to Object, then shows the constructor bodies completing in reverse.

Fig. 1

Calls travel down from PriorityOrder(String) through this to PriorityOrder(String, int), through super to Order(long, String), through this to Order(long, String, List) and through an implicit super to Object; then bodies run back up in numbered order, Object first and the original constructor last

Notice two things. Every constructor begins by handing control to another constructor, so the first code that actually finishes is Object(). And the constructor you called is the last one to complete.

02Constructors under the hood

Default and no-arg constructors

If a class declares no constructor at all, javac writes one for you: no parameters, the same access as the class, and a body that only calls super(). That's the default constructor. A no-arg constructor you write yourself is not "default" in the JLS sense, even though people use the words interchangeably.

class Customer {
    private final String email;
    Customer(String email) { this.email = email; }
}

class PremiumCustomer extends Customer {
    PremiumCustomer() { }            // implicit super() here
}

Customer c = new Customer();         // ?

Both lines fail with constructor Customer in class Customer cannot be applied to given types; required: String. Declaring Customer(String) removed the free no-arg constructor, so new Customer() has nothing to call. And PremiumCustomer() gets an implicit super() as its first statement, which needs that same missing constructor. The fix is to call super(email) explicitly or add a no-arg constructor to Customer.

Overloading and chaining with this(...)

Overloaded constructors are normal overloads: same name, different parameter lists. The habit worth building is to funnel every overload into one canonical constructor with this(...), so validation lives in one place.

public class Order {
    private final long id;
    private final String customer;
    private final List<String> items;
    private int quantity = 1;                         // field initialiser

    public Order(long id, String customer, List<String> items) {   // canonical
        if (id <= 0) throw new IllegalArgumentException("id must be positive");
        this.id = id;
        this.customer = Objects.requireNonNull(customer);
        this.items = new ArrayList<>(items);          // defensive copy
    }

    public Order(long id, String customer) {
        this(id, customer, List.of());                // delegate, don't duplicate
    }

    public Order(Order other) {                       // copy constructor
        this(other.id, other.customer, other.items);
    }
}

The rules, all enforced by the compiler in Java 21:

• this(...) or super(...) must be the first statement, and you can't have both. If you write neither, super() is inserted.
• A cycle (Order() calls this(1), which calls this()) is rejected: recursive constructor invocation.
• Arguments to this(...) and super(...) can't refer to instance fields or instance methods, because the object isn't initialised yet. Static methods are allowed, which is a useful trick we'll use below.

Java 25 relaxed the first rule: with flexible constructor bodies (JEP 513, previewed from Java 22), you can run statements such as argument validation before super(...), as long as they don't read this.

Copy constructors

The Order(Order other) constructor above is a copy constructor: it builds a new object from an existing one. Because it goes through the canonical constructor, items gets its own ArrayList, so changing one order's items never leaks into the copy. If you assigned this.items = other.items instead, both orders would share one list: a shallow copy. Effective Java (Item 13) prefers copy constructors and copy factories over clone(), because they don't need Cloneable, work with final fields and don't throw checked exceptions. The full story is in Deep copy vs shallow copy in Java.

Private constructors

A private constructor means "only code inside this class (and its nestmates) can call new". It's how you build:

• Utility classes that should never be instantiated, like java.util.Collections.
• Static factories such as Order.of(...) or List.of(...), which can cache, return subtypes and have descriptive names (Effective Java Item 1).
• Singletons, with the instance held in a static field.

Enum constructors are implicitly private, which is why you can never new an enum.

03Initialisation order, exactly

This is the output question you'll see in almost every Java screen.

class BaseService {
    static { System.out.println("1. BaseService static block"); }
    { System.out.println("3. BaseService instance block"); }
    BaseService() { System.out.println("4. BaseService constructor"); }
}

class PaymentService extends BaseService {
    static { System.out.println("2. PaymentService static block"); }
    private final String region = log("5. PaymentService field initialiser");
    { System.out.println("6. PaymentService instance block"); }
    PaymentService() { System.out.println("7. PaymentService constructor"); }

    static String log(String msg) { System.out.println(msg); return msg; }
}

new PaymentService();   // prints: lines 1 to 7, in order
new PaymentService();   // prints: lines 3 to 7 only

I numbered the lines in the order they print, which gives the answer away on purpose: the numbers are the rule. The timeline below lays out the phases.

Fig. 2

A timeline with a once-per-class phase where BaseService static then PaymentService static blocks run, followed by a per-object phase where the BaseService instance block and constructor run, then the PaymentService field initialiser, instance block and constructor body; a second new skips the static phase

Notice:

• Static blocks run once per class, parent before child, during class initialisation. The second new skips them.
• Field initialisers and instance blocks run in source order, as one sequence. Swap the region line and the instance block, and lines 5 and 6 swap.
• They run after the parent constructor finishes and before your constructor's body. That's the whole reason a parent can't see a child's initialised fields.

What javac puts in <init>

There's no separate "instance initialiser phase" in the JVM. javac copies every field initialiser and instance block, in source order, into each constructor right after its super(...) call. Constructors that start with this(...) don't get a copy, otherwise the code would run twice. Here's javap -c -p Order for the class above, trimmed:

Order(long, String, List);                       // starts with super(): gets the copy
   0: aload_0
   1: invokespecial #1   // Method java/lang/Object."<init>":()V
   4: aload_0
   5: iconst_1
   6: putfield      #7   // Field quantity:I     <- "quantity = 1" lands here
   9: aload_0 ...        //                         then the body: id, customer, items

Order(long, String);                             // starts with this(...): no copy
   0: aload_0 ...
   6: invokespecial #36  // Method "<init>":(JLjava/lang/String;Ljava/util/List;)V

The diagram makes the copying visible.

Fig. 3

On the left, Java source for Order with a field initialiser, an instance block and two constructors; on the right, two generated init methods: the canonical one contains the super call, then the copied initialiser and block, then its body; the delegating one contains only the this call

Two more bytecode facts that come up. new and <init> are separate instructions, and the verifier tracks the object as uninitialised between them: you can't call methods on it or store it in a field until invokespecial <init> returns. And a constructor's return type in the descriptor is always V (void), which is why "constructors return the object" is wrong; new produced the reference before the constructor ran.

04Real world: half-built objects in production

public final class PriceFeedClient {
    private final Set<String> symbols;

    private PriceFeedClient(Set<String> symbols) {
        this.symbols = Set.copyOf(symbols);           // only state, no side effects
    }

    public static PriceFeedClient start(EventBus bus, Set<String> symbols) {
        PriceFeedClient client = new PriceFeedClient(symbols);
        bus.register(client);                         // published after construction
        return client;
    }
}

The same reasoning covers starting a thread in a constructor, adding this to a static registry, or handing it to an executor. Construction should set fields; side effects come after.

Another real one: JPA, Jackson and many serialisers need a no-arg constructor (JPA requires it to be public or protected). Add a convenience constructor to an entity, the compiler-provided default disappears, and the app fails at startup or on first load with "No default constructor for entity". Declare the no-arg one explicitly, protected if you don't want callers to use it.

05Advanced: overridable calls, exceptions and the rules list

Calling an overridable method from a constructor

abstract class Notification {
    Notification() {
        System.out.println("Sending: " + render());   // overridable call
    }
    abstract String render();
}

class SmsNotification extends Notification {
    private final String phone;
    SmsNotification(String phone) { this.phone = phone; }
    @Override String render() { return "SMS to " + phone; }
}

new SmsNotification("+91-98xxxxxx01");   // prints: Sending: SMS to null

Even a final field reads null. Virtual dispatch works from the very start, so render() runs the child's override, but the child's constructor body hasn't run yet: the field still holds the default that new wrote. The diagram shows the moment.

Fig. 4

Two stacked frames: the Notification constructor is running and calls render, which dispatches to SmsNotification.render; at that moment the SmsNotification part of the object still has phone equal to null because its constructor body has not started; the output is Sending: SMS to null

Exceptions in constructors

If a constructor throws, new never hands the reference to the caller, so normally the half-built object is unreachable and gets collected. Two exceptions to "normally": if the constructor already leaked this (see above), the broken object lives on. And in a non-final class, an attacker's subclass could override finalize() to capture this after the parent's validation threw: the finalizer attack. Finalization is deprecated for removal since Java 18 (JEP 421), but the defensive patterns are still worth knowing: make the class final, or validate before Object's constructor runs, because an object only becomes finalizable after Object() completes.

public class Account {
    private final long balancePaise;

    public Account(long balancePaise) {
        this(validate(balancePaise), null);          // static check runs before super()
    }

    private Account(long balancePaise, Void unused) {
        this.balancePaise = balancePaise;
    }

    private static long validate(long b) {
        if (b < 0) throw new IllegalArgumentException("negative balance");
        return b;
    }
}

A constructor may declare checked exceptions, and a subclass constructor must then declare them too, because it can't wrap super(...) in a try.

Constructor rules, side by side

One trick question hides in that table: public void Order() {} compiles, but it's a method named Order, not a constructor, so new Order() still uses the default constructor and never runs it.

06How to say it in the interview

When I ask about constructors, I'm listening for four things: the default constructor rule, the chaining rule (this or super first, super() implied), the exact initialisation order with a reason behind it (field initialisers live inside <init> after super), and awareness of the traps: overridable calls and leaking this. Candidates who mention the null from an overridden method, or the final-field visibility guarantee, stand out.

no ctor written  -> default: no-arg, class's access, calls super()
any ctor written -> default gone (JPA/Jackson need explicit no-arg)
first stmt: this(...) | super(...) | implicit super()   (Java 25: JEP 513 relaxes)
order: static parent -> static child            (once, <clinit>)
       parent ctor done -> child fields + {} in source order -> child body
javac: field inits + {} copied into each <init> that calls super, not this(...)
bytecode: new -> dup -> invokespecial <init>  (returns V)
copy ctor: new Order(other), defensive-copy mutable fields
private ctor: utility, static factory, singleton; enum ctors implicitly private
traps: overridable call in ctor -> child fields null
       leaking this -> half-built object, breaks final-field guarantee (JLS 17.5)
       throw in ctor -> no reference returned; finalizer attack -> final class
not inherited; no static/final/abstract; void Order() is a method