Flexible Constructor Bodies in Java 25

1. Overview

In this tutorial, we’ll look at the new options available to us when writing constructors in Java 25. Following the implementation of JEP 513, we now have greater control over the ordering of the constructor body, offering options for enhanced safety and efficiency in our code.

2. Before Java 25

In earlier versions of Java, constructors for objects had to follow a strict order. The first line in any constructor had to be either super(…), this(…), or another constructor call. This enforced the rule that superclass constructors are called before subclass ones. It’s also worth noting that if we hadn’t explicitly written a call to super() or a similar method, the compiler would have added one for us.

This led to safe object building, but also restricted us from adding potentially useful techniques into our code.

3. Code Setup

Let’s set up some objects to test out the new features with. To start, we could have a  Coffee superclass with two fields representing the key ingredients of a coffee, milk and water:

public class Coffee {
    int water;
    int milk;

    public Coffee(int water, int milk) {
        this.water = water;
        this.milk = milk;
    }

    public int getTotalVolume() {
        return water + milk;
    }
}

So, nothing unexpected here: two fields, a constructor, and a small method to tell us our Coffee’s total volume.

Now, let’s extend our drinks range to include a SmallCoffee. For now, a SmallCoffee is the same as a standard Coffee, apart from the fact that it comes with a topping:

public class SmallCoffee extends Coffee {

    String topping;

    public SmallCoffee(int water, int milk, String topping) {
        super(water, milk);
        this.topping = topping;
    }
}

We’ve added a new String field called topping. In our constructor, we’ve called the superclass constructor with the fields it needs, then instantiated our new topping field.

This is all well and good. However, what if a SmallCoffee has a maximum volume or other restrictions we’d want to place on it? We’d have to check after doing the work of calling the superclass constructor. In the next section, we’ll look at how we can now do that in advance to keep our objects well-formed and efficient.

4. Prologue Checks

From Java 25 onwards, we have the option of adding a Prologue to our constructors. A Prologue is defined as any code that happens before a call to super(…) or this(…). 

Let’s use a Prologue to add a check to our SmallCoffee to ensure we don’t exceed the maximum volume that’ll fit in our small cups:

public SmallCoffee(int water, int milk, String topping) {
    int maxCupVolume = 100;
    int totalVolume = water + milk;
    if(totalVolume > maxCupVolume) {
        throw new IllegalArgumentException();
    }
    super(water, milk);
    this.topping = topping;
}

With this implementation, we check our object is valid upfront and would fail immediately if it’s not.

Before Java 25, we’d have had to perform this check after the call to super(water, milk). This wasted the effort of constructing the superclass if the total volume was too high.

5. Prologue Instantiations

With Prologues, we can instantiate any class variables that are not already instantiated. We can do that in the normal way:

String topping;
public SmallCoffee(int water, int milk, String topping) {
    this.topping = topping;
    super(water, milk);
}

Now we instantiate the topping field before building the superclass.

Let’s write a short test to confirm this all compiles and works as expected:

@Test
public void test() {
    SmallCoffee smallCoffee = new SmallCoffee(30,40, "none");
    assertEquals(70, smallCoffee.getTotalVolume());
}

The passing of this test demonstrates that our Prologue checks and instantiations process correctly. It also proves that we called the super class constructor, and the result is a well-formed SmallCoffee with the expected liquid volume.

6. Limitations

There are limitations to what we can do in the Prologue of our constructor. The main limitation is that code in the Prologue cannot use or refer to the object that is currently being created. We’ll now examine some not permitted examples.

6.1. Using Instance Methods

Firstly, we cannot use the object’s own methods in the Prologue:

public SmallCoffee(int water, int milk, String topping) {
    addRandomTopping();
    super(water, milk);
}

private void addRandomTopping() {...}

This is not allowed as we are trying to call a method from the object that is being created before the call to super(). Calling it after would be fine.

6.2. Using Instance Fields

Secondly, we cannot reference fields from the object in the Prologue:

String name;

public SmallCoffee(int water, int milk, String topping) {
    String nameWithExclamationMark = name + "!";
    super(water, milk);
}

This fails because we try to use the name field before the call to super(). 

Similarly, we cannot assign values to class fields that have already been initialized:

String name = "Flat white";
public SmallCoffee(int water, int milk, String topping) {
    name = "Espresso";
    super(water, milk);
}

This fails when we try to rename SmallCoffee to Espresso. Reassigning variables after the call to the superclass constructor is absolutely fine as usual.

7. Conclusion

In this tutorial, we’ve seen that from Java 25 we have the ability to add in Prologues to our constructors. A Prologue is any code that goes before the call to the next constructor.

We performed checks within our Prologues, ensuring we maintained proper standards within our objects. Also, we instantiated our class fields, as they were not already initialised.

Prologues restrict us from doing much more with them. Mainly, they prevent us from using our class features until we finish creating the class.