Draft Spec for Flexible Constructor Bodies (JEP 513)

[Stephan Herrmann]

Am 22.04.25 um 16:59 schrieb Remi Forax:
> Hello,
> i'm not sure it's wise to have flexible constructor bodies to be out of preview.

Looking from a distance those seem to fit hand-in-glove, no?

> There is a non trivial interaction with the introduction of strict fields and i 
> am not sure those two should be separated, mostly because with strict fields, 
> initializing a field before the call to super() change its semantics 

I scanned https://openjdk.org/jeps/8350458 but could not find anything that 
looked like changing a field's semantics based on where the field is 
initialized. It looks more like strictly initialized fields _require_ 
initialization during "early larval state", no? So you need JEP 513 to work with 
strictly initialized fields in Java source code, right?

Where should I be looking for that property of strictly initialized fields you 
are referring to?

Stephan

> while with 
> a flexible constructor body, one can already initialize the field before the 
> call to super() without the semantics being changed.
> 
> But i'm sure i'm missing something ...
> 
> regards,
> Rémi
> 
> --------------------------------------------------------------------------------
> 
>     *From: *"Gavin Bierman" <gavin.bierman at oracle.com>
>     *To: *"amber-spec-experts" <amber-spec-experts at openjdk.org>
>     *Sent: *Tuesday, April 22, 2025 3:48:31 PM
>     *Subject: *Draft Spec for Flexible Constructor Bodies (JEP 513)
> 
>     Dear experts,
> 
>     The first draft of a spec covering JEP 513 (Flexible Constructor Bodies) is
>     available at:
> 
>     https://cr.openjdk.org/~gbierman/jep513/latest/ <https://cr.openjdk.org/
>     ~gbierman/jep513/latest/>
> 
>     Feel free to contact me directly or on this list with any comments/corrections.
> 
>     Thanks,
>     Gavin
> 
>         On 22 Apr 2025, at 13:02, Mark Reinhold <mark.reinhold at oracle.com> wrote:
> 
>         https://openjdk.org/jeps/513
> 
>           Summary: In the body of a constructor, allow statements to appear
>           before an explicit constructor invocation, i.e., super(...) or
>           this(...).  Such statements cannot reference the object under
>           construction, but they can initialize its fields and perform other safe
>           computations.  This change allows many constructors to be expressed
>           more naturally.  It also allows fields to be initialized before they
>           become visible to other code in the class, such as methods called from
>           a superclass constructor, thereby improving safety.
> 
>         - Mark
> 
> 
>