Draft Spec for Flexible Constructor Bodies (JEP 513)

[Remi Forax]

----- Original Message -----
> From: "Stephan Herrmann" <stephan.herrmann at berlin.de>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.org>
> Sent: Wednesday, April 23, 2025 11:38:25 PM
> Subject: Re: Draft Spec for Flexible Constructor Bodies (JEP 513)

> Am 23.04.25 um 00:09 schrieb forax at univ-mlv.fr:
>> [...]
>> 
>> This is fine from the VM POV because the VM sees the strictness of the fields,
>> this is not fine from the language POV because you have no way to see if a
>> field is strict or not.
> 
> Perhaps we should be asking: who will emit the ACC_STRICT_INIT flag, and when?
> 
> If no tool emits the flag then the answer is: you'll always see FCB semantics :)
> 
> If only fields of value classes will (in some future) be thusly marked, then
> this is how you see the difference.
> 
> There might also be tools in the chain that detect which fields statically fit
> the bill of strict initialization, and then they will perhaps insert that flag?
> Such a tool could also spit out a report about which fields violate the rules of
> strict initialization, so there you get your alerts about "unsafe" code. You
> could even write your own annotation that will guide your tool by saying: I want
> this field to be strictly initialized, please check if that's possible, and if
> so please insert the flag.
> 
> Or such annotation would some day become a standard, or ...
> 
> IOW, the new flag and its evaluation in the VM doesn't look like a semantic
> change per se, its just an enabler for whoever opts in to the concept, no?
> 
> The proposed coupling of FCB and SF might perhaps make sense if assigning a
> field in a constructor prologue should be the gesture to tell the compiler:
> please make this ACC_STRICT_INIT. I don't see any plans in that direction. Are
> there?
> 
> Stephan

yes,
making the early field initialization part of FCB muddy our chances to later uses early initialization as a signal for the compiler to declare the field as ACC_STRICT_INIT.

And I would rather not add another bytecode capability that is not fully available in Java the language.

It's too easy to say we will figure out later how to introduce it in Java. But it has the stupid side effect that in practice most of the tools that consume bytecode will only carve an exception for the way Java the language uses that feature. A good example of that is to see how many tools that consume bytecode fails on constant dynamic.

So i would prefer to have a real plan on how Java will use ACC_STRICT_INIT. For now, we have not ruled out to use early initialization as a signal, so i would like to keep that option open, even if that means going back to the original proposal of FCB, and only releasing that.

Rémi