One of the more developer-friendly enhancements in Java 25 is the formalization of Flexible Constructor Bodies, embodied in JEP 513. With this feature, Java relaxes a long-standing restriction: constructors can now include certain statements before the call to super(...) or this(...). In short, we can now run logic (validation, computations, early assignments) earlier in our constructor body, subject to constraints, without breaking the object initialization model.
This article explains how Flexible Constructor Bodies work with prologues and epilogues and illustrates their usage with examples.
1. How Flexible Constructor Bodies Work
Since early Java, constructors followed the top-down rule: the first statement must be this(...) or super(...), with super() inserted implicitly if omitted. While this ensured a consistent initialization order with superclass first and then subclass, it prevented early validation or field initialization and often forced developers into awkward workarounds like static helpers or duplicated logic.
Under the new model, a constructor body is logically split into two phases:
- Prologue: the statements preceding the explicit constructor invocation (
super(...)orthis(...)) - Epilogue: the statements following that invocation
- If no explicit constructor invocation is written, then all statements are considered epilogue, and an implicit
super()is inserted by the compiler.
Thus, a general syntax becomes:
public MyClass(...) {
// — Prologue: statements before constructor call
…
super(...); // or this(...)
// — Epilogue: statements after the constructor call
…
}
2. Examples
Let’s examine a few examples to illustrate how this works and what is now possible.
2.1 Early Parameter Validation
One of the most natural uses of flexible constructor bodies is to validate or sanitize input arguments before delegating to a superclass.
Traditional Workaround (Pre-Java 25)
Before Java 25, we couldn’t put validation logic before super(...). The workaround was to push validation into a static helper or factory method and call it inside the super(...).
public class BankAccount {
protected final String accountNumber;
protected final double balance;
BankAccount(String accountNumber, double balance) {
this.accountNumber = accountNumber;
this.balance = balance;
System.out.println("BankAccount created with accountNumber=" + accountNumber + ", balance=" + balance);
}
}
class SavingsAccount extends BankAccount {
private final double interestRate;
SavingsAccount(String accountNumber, double balance, double interestRate) {
// Validation must be moved to static helper
super(accountNumber, validateBalance(balance));
if (interestRate <= 0 || interestRate > 0.1) {
throw new IllegalArgumentException("Interest rate must be greater than 0 and at most 10%");
}
this.interestRate = interestRate;
System.out.println("SavingsAccount created with interestRate=" + interestRate);
}
private static double validateBalance(double balance) {
if (balance < 100) {
throw new IllegalArgumentException("Savings account requires a minimum opening balance of 100");
}
return balance;
}
}
Because super(...) had to be the first statement, inline validation of balance was not possible, forcing the use of a static helper method validateBalance(...) inside the super(...) call; while interestRate could still be checked afterwards, this separation split the validation logic across different locations and made the constructor less clear.
With Java 25 Flexible Constructor Bodies
Now we can write:
public class BankAccount {
protected final String accountNumber;
protected final double balance;
BankAccount(String accountNumber, double balance) {
this.accountNumber = accountNumber;
this.balance = balance;
System.out.println("BankAccount created with accountNumber=" + accountNumber + ", balance=" + balance);
}
}
class SavingsAccount extends BankAccount {
private final double interestRate;
SavingsAccount(String accountNumber, double balance, double interestRate) {
// — Prologue: validate before calling super —
if (balance < 100) {
throw new IllegalArgumentException("Savings account requires a minimum opening balance of 100");
}
if (interestRate 0.1) {
throw new IllegalArgumentException("Interest rate must be greater than 0 and at most 10%");
}
super(accountNumber, balance);
// — Epilogue: subclass initialization —
this.interestRate = interestRate;
System.out.println("SavingsAccount created with interestRate=" + interestRate);
}
}
In the prologue, the constructor validates the opening balance and interest rate, ensuring that if either is invalid, no BankAccount object is created; only after successful validation does it call super(accountNumber, balance) to initialize the base class, and in the epilogue it assigns the subclass-specific interestRate, achieving fail-fast behavior by rejecting invalid accounts before any superclass logic executes.
2.2 Using Temporary Variables in Constructor Chaining
Constructor chaining often requires passing derived values from one constructor to another. Before Java 25, these computations had to be done in-line, which could hurt readability. With flexible constructor bodies, we can introduce a temporary variable for clarity.
Traditional workaround (pre-Java 25)
public class Student {
private final String username;
private final String fullName;
Student(String username) {
// Computation must be inline inside this(...)
this(username, username.substring(0, 1).toUpperCase() + username.substring(1));
}
Student(String username, String fullName) {
this.username = username;
this.fullName = fullName;
System.out.println("Student created: username=" + username + ", fullName=" + fullName);
}
}
When only a username is provided, a fullName is derived, but before Java 25 this computation had to be written inline within the this(...) call, which reduced readability, especially when the calculation grew more complex.
With Java 25 Flexible Constructor Bodies
public class Student {
private final String username;
private final String fullName;
Student(String username) {
// Prologue: use a temporary variable for clarity
String derivedName = username.substring(0, 1).toUpperCase() + username.substring(1);
// Invocation: call another constructor cleanly
this(username, derivedName);
}
Student(String username, String fullName) {
this.username = username;
this.fullName = fullName;
System.out.println("Student created: username=" + username + ", fullName=" + fullName);
}
}
The prologue computes derivedName once with a clear name, making the chaining call this(username, derivedName) more readable and allowing complex logic to be moved out of inline calls for better clarity and maintainability.
3. Rules and Restrictions
Although Flexible Constructor Bodies give us more freedom, certain rules ensure object initialization remains safe and predictable. The key idea is that the object is not fully constructed until after the call to super(...) or this(...), so code in the prologue must be carefully limited.
No Use of this or Field Reads Before super(...)
We cannot access instance fields or call instance methods in the prologue because the object has not been fully initialized.
class InvalidExample {
int x;
InvalidExample(int v) {
int y = this.x + v; // not allowed — reads uninitialized instance field
super(); // compiler error
}
}
No Instance Method Calls in the Prologue
Calling methods that rely on the partially constructed object is unsafe.
class InvalidMethodCall {
InvalidMethodCall(int v) {
doSomething(v); // not allowed — calls an instance method
super();
}
void doSomething(int v) {
System.out.println(v);
}
}
Calling super Methods or Accessing super Fields
The super(...) constructor call must happen before you can access any super fields or methods.
class Base {
int baseValue = 5;
void printBase() {
System.out.println(baseValue);
}
}
class Derived extends Base {
Derived(int v) {
// System.out.println(super.baseValue); // not allowed in prologue
// super.printBase(); // not allowed in prologue
super(); // constructor invocation
System.out.println(super.baseValue); // allowed in epilogue
super.printBase(); // allowed in epilogue
}
}
Records and Enums
With Flexible Constructor Bodies, records can now use prologue code inside custom constructors (those that call this(...)). Enums, on the other hand, cannot call super(...) since they already extend java.lang.Enum, but they can still use this(...) to call another constructor, which means they too can take advantage of prologue code in that case.
4. Conclusion
In this article, we explored Flexible Constructor Bodies in Java 25, explained how prologues and epilogues work, and outlined the rules with examples. This feature simplifies constructor logic by allowing validation, field assignments, and argument preparation before delegation, while maintaining safe and predictable object initialization.
5. Download the Source Code
This article explored the flexible constructor bodies feature introduced in Java 25.
You can download the full source code of this example here: java 25 flexible constructor bodies
