flexible constructor bodies

the picture

you know the rule "super(...) must be the first statement in a constructor"? it was there from java 1.0, and it made simple things awkward. want to check an argument before handing it to the superclass? you couldn't, so you wrote a static helper and called it inside the super(...) arguments, or you let the superclass do work with a bad value and threw afterwards.

think of building a house. the old rule said the foundation crew (the superclass) has to start before you've even looked at the plans: you can't check the plot, can't measure anything, just pour concrete and hope. the new rule lets you survey the land and check the permits first, as long as you don't try to move furniture into a house that doesn't exist yet.

class Employee extends Person {
    Employee(String rawName) {
        super(clean(rawName));
    }
 
    private static String clean(String raw) {
        if (raw == null || raw.isBlank())
            throw new IllegalArgumentException("no name");
        return raw.strip().toUpperCase();
    }
}

class Employee extends Person {
    Employee(String rawName) {
        if (rawName == null || rawName.isBlank())
            throw new IllegalArgumentException("no name");
        String name = rawName.strip().toUpperCase();
        super(name);
    }
}

same behaviour, but the right side reads top to bottom: check, prepare, construct. compile the right side with --release 24 and javac 25 refuses:

error: flexible constructors is not supported in -source 24

prologue and epilogue

with statements allowed before super(...), a constructor has two halves. the prologue runs before the superclass is constructed, the epilogue after. across a hierarchy that gives a neat order: prologues run from the subclass up, epilogues from the top down:

the real win: fields set before the superclass looks

here's the bug that the old rule made unavoidable. Person's constructor calls show(), an overridable method, and Employee overrides it to print a field of its own. switch between the two orders:

·

·

class Person {
    final String name;
    final int age;
 
    Person(String name, int age) {
        this.name = name;
        this.age = age;
        show();                              // an overridable call: careful
    }
 
    void show() { IO.println(name + ", " + age); }
}
 
class Employee extends Person {
    final String officeId;
 
    Employee(String name, int age, String officeId) {
        if (age < 18) throw new IllegalArgumentException("too young: " + age);
        this.officeId = officeId;            // before super(...): new in java 25
        super(name, age);
    }
 
    @Override
    void show() { IO.println(name + ", office " + officeId); }
}
 
void main() {
    new Employee("ada", 36, "CAM-FORA");
    new Employee("bob", 16, "CAM-FORA");
}

ada, office CAM-FORA
Exception in thread "main" java.lang.IllegalArgumentException: too young: 16

the second new throws before Person ever runs. fail fast, no half-built object, no wasted superclass work. (calling overridable methods from a constructor is still a bad idea, effective java item 19 says so for good reasons. but now the subclass can at least defend itself.)

what the prologue still can't do

the object is allocated (memory, zeroed fields) but not constructed, so anything that could observe it is off limits. every one of these is rejected by javac 25:

what is allowed: locals, arguments, static methods and fields, throwing, and assigning your own fields that don't have an initializer. a lambda in the prologue counts as touching this if it mentions a field, so that's out too.

record Range(int lo, int hi) {
    Range(String text) {                     // "3-7"
        String[] parts = text.strip().split("-");
        this(Integer.parseInt(parts[0]), Integer.parseInt(parts[1]));
    }
}
 
IO.println(new Range(" 3-7 "));