Draft Spec for Flexible Constructor Bodies (JEP 513)

Stephan Herrmann stephan.herrmann at berlin.de
Wed Apr 23 21:38:25 UTC 2025


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


More information about the amber-spec-observers mailing list