Draft Spec for Flexible Constructor Bodies (JEP 513)

[Dan Smith]

> On Apr 29, 2025, at 9:13 AM, forax at univ-mlv.fr wrote:
> 
> The problem of (2), is that if you emit a warning, people will want to change the code but they need (3) for that.

You're misunderstanding. The warnings say "you've got an unexpected dependency on 'this' here, if that's what you intend, put it after an explicit 'super()' call". You need language support for the right code shapes in a constructor that explicitly calls 'super()' (that's what JEP 513 proposes to deliver).

(3) is about changing the timing of initializers and constructors with an *implicit* super call. (2) doesn't need that, it just prepares code to be able to smoothly adopt it when it comes later.

> Let me go from the other direction, with SF, we have a very potent feature,
> a code that for example starts a thread in the constructor is now valid, something I never though it was possible.
> 
> public class Foo {
>  private final String s;
> 
>  public Foo() {
>    this.s = s;
>    super();  // memory freeze
>    new Thread(() -> /* use this.s here */).start();
>  }
> }
> 

(This particular code probably doesn't do what you want, because the thread 'start()' acts as a synchronization point, per 17.4.4. But of course there are many other ways to leak 'this' to an already-running thread during construction.)

> But this feature requires to change the VM to add a memory barrier for Object.<init>() *and* be sure that those changes have no negative impact on performance.
> 
> Because of the perf part, there is a non-zero chance that this feature never exists.

I agree that for strict fields to have the appropriate guarantees, there need to be some memory model changes to address their initialization.

I'm not seeing a connection to JEP 513, which doesn't make bytecode any more expressive than it was before, and which doesn't imply anything about strict fields (which don't exist as a feature yet).

Even if, as you worry, at some point in the future we decide to re-interpret this code to have a strict field, and with it new memory effects—the change in memory model would be fully compatible with the non-strict old model (it just might add more constraints). Does the re-interpretation come with meaningful performance costs? Don't know, but if it does, it doesn't seem like we'd pursue this approach.

(Anyway, the point of my mail was that I don't think we expect to pursue an approach that automatically re-interprets fields to be strict, in any case, without some other opt in besides initialization timing.)

> For value type, we currently allow early initialization of fields with two restrictions:
> - all fields must be final
> - the call to super() has to be the last call of the constructor.
> 
> With those restrictions the VM does not have to be changed because the memory freeze due to the final fields is done at the same time as the call to super() (at the end of the constructor).

To put this in context of my mail, we're talking about (1).

It is not my expectation that 'super()' must be the last call of the constructor. We intend to allow an explicit 'super()' call in the value class constructor after the fields have been initialized, as allowed by JEP 513, and then permit subsequent code. (Not setting the value class's instance fields, but potentially other setup actions.)

The memory model requirements of strict fields and 'super()' calls will need to be addressed in the strict fields JEP, which is a prerequisite to JEP 401.

The JVM will be fully capable of initializing strict fields before a 'super()' call, and then executing other code afterwards, with appropriate memory model constraints. I don't see this as being a major concern, but if it is, it's something that needs to be addressed before strict fields and value classes become finalized. (Even if the language disallowed code after 'super()', which I don't anticipate, this is not a bytecode shape we would try to enforce with verification, so we'd need the memory model to account for it.)