[External] : Re: Draft Spec for Flexible Constructor Bodies (JEP 513)

[Chen Liang]

Hi Remi,

Even with strict fields, fields initialized before super calls can still be non-strict. It is just that if a field is definitely assigned before super constructor invocation, they can be trivially marked strict.

However, one problem with FCB I see that can block its finalization is its lack of support for records - records must not have a superconstructor invocation, and as a result, records cannot have early construction field assignments, because without an explicit invocation, per JLS, the canonical constructor body will be late construction; and such a body can use "this", which makes it incompatible to simply reinterpret a canonical constructor body as in an early construction context.

Regards, Chen
________________________________
From: forax at univ-mlv.fr <forax at univ-mlv.fr>
Sent: Tuesday, April 22, 2025 12:24 PM
To: Chen Liang <chen.l.liang at oracle.com>
Cc: amber-spec-experts <amber-spec-experts at openjdk.java.net>
Subject: [External] : Re: Draft Spec for Flexible Constructor Bodies (JEP 513)

________________________________
From: "Chen Liang" <chen.l.liang at oracle.com>
To: "amber-spec-comments" <amber-spec-comments at openjdk.org>
Cc: "Remi Forax" <forax at univ-mlv.fr>
Sent: Tuesday, April 22, 2025 5:21:22 PM
Subject: Re: Draft Spec for Flexible Constructor Bodies (JEP 513)

Hi Rémi,
>From valhalla development, we find that strict fields has a dependency on flexible constructor bodies, but flexible constructors are not tied down by strict fields (like strict fields aren't tied down by value objects). The early construction context allows Java programs to write code that can more smoothly transition to use strict fields without constructor code updates, so delivering flexible constructors early seems fine to me.

>From the development POV, i agree, but from the users perspective, we have a 3 phases change instead of 2, so it's harder to understand.

With flexible constructor bodies not in preview in Java 25:
phase 1: now, fields can not be initialized before a super() call
phase 2: fields are initialized before a super() call
phase 3: fields initialized before a super() call are strict

If flexible constructor bodies and strict fields are delivered at the same time:
phase 1: fields can not be initialized before a super() call
phase 2: fields can be initialized before super() and are strict


Regards,
Chen Liang

regards,
Rémi

________________________________
________________________________
From: amber-spec-observers <amber-spec-observers-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Tuesday, April 22, 2025 9:59 AM
To: Gavin Bierman <gavin.bierman at oracle.com>
Cc: amber-spec-experts <amber-spec-experts at openjdk.org>
Subject: Re: Draft Spec for Flexible Constructor Bodies (JEP 513)

Hello,
i'm not sure it's wise to have flexible constructor bodies to be out of preview.

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 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/

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20250422/50a3e701/attachment-0001.htm>