From angelos.bimpoudis at oracle.com Wed Apr 2 14:51:59 2025 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Wed, 2 Apr 2025 14:51:59 +0000 Subject: Draft JEP for Third Preview of Primitive Types in Patterns, instanceof, and switch Message-ID: Dear experts, A draft JEP for the third preview of primitive types in patterns, instanceof, and switch is now available and submitted. We propose to preview it for a third time with no changes relative to JDK 24. https://openjdk.org/jeps/8349215 To recall, this feature drops restrictions around switch and instanceof. During the evolution of this feature we established new terminology and functionality to safeguard against loss of information or other exceptional cases across all types, uniformly. One of the goals of this feature is to not introduce new conversions, rather to safeguard against all existing ones. Re-previewing as is for the third time gives us the opportunity to examine Chapter 5 of the JLS holistically and identify opportunities that could pave the road to other potential language features, e.g., constant patterns, null-restricted value class types etc. Thank you, Angelos -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Apr 2 15:49:48 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Apr 2025 17:49:48 +0200 (CEST) Subject: Draft JEP for Third Preview of Primitive Types in Patterns, instanceof, and switch In-Reply-To: References: Message-ID: <309767259.204096949.1743608988887.JavaMail.zimbra@univ-eiffel.fr> > From: "Angelos Bimpoudis" > To: "amber-spec-experts" > Sent: Wednesday, April 2, 2025 4:51:59 PM > Subject: Draft JEP for Third Preview of Primitive Types in Patterns, instanceof, > and switch > Dear experts, > A draft JEP for the third preview of primitive types in patterns, instanceof, > and switch is now available and submitted. We propose to preview it for a third > time with no changes relative to JDK 24. > https://openjdk.org/jeps/8349215 > To recall, this feature drops restrictions around switch and instanceof. During > the evolution of this feature we established new terminology and functionality > to safeguard against loss of information or other exceptional cases across all > types, uniformly. One of the goals of this feature is to not introduce new > conversions, rather to safeguard against all existing ones. Re-previewing as is > for the third time gives us the opportunity to examine Chapter 5 of the JLS > holistically and identify opportunities that could pave the road to other > potential language features, e.g., constant patterns, null-restricted value > class types etc. There is another dependency, in Valhalla, at some point we will want to "merge" primiitive types and values types, primitive types becoming a subset of value types. There are nice ideas floating around, but as far as i know, that part is not fully fledged, so if we move too quickly here, the primitive type patterns of today may become a problem of tomorrow. > Thank you, > Angelos regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Tue Apr 22 13:12:27 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 22 Apr 2025 13:12:27 +0000 Subject: Draft Spec for Module Import Declarations (JEP 511) In-Reply-To: <20250417120719.54FE3811E46@eggemoggin.niobe.net> References: <20250417120719.54FE3811E46@eggemoggin.niobe.net> Message-ID: Dear experts, The first draft of a spec covering JEP 511 (Module Import Declarations) is available at: https://cr.openjdk.org/~gbierman/jep511/latest/ Feel free to contact me directly or on this list with any comments/corrections. Thanks, Gavin On 17 Apr 2025, at 13:07, Mark Reinhold wrote: https://openjdk.org/jeps/511 Summary: Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Tue Apr 22 13:14:48 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 22 Apr 2025 13:14:48 +0000 Subject: Draft Spect for Compact Source Files and Instance Main Methods (JEP 512) In-Reply-To: <20250417120722.47AF8811E48@eggemoggin.niobe.net> References: <20250417120722.47AF8811E48@eggemoggin.niobe.net> Message-ID: <13345D40-0DCF-4ED0-872C-EE4F1708FE24@oracle.com> Dear experts, The first draft of a spec covering JEP 512 (Compact Source Files and Instance Main Methods) is available at: https://cr.openjdk.org/~gbierman/jep512/latest/ Feel free to contact me directly or on this list with any comments/corrections. Thanks, Gavin On 17 Apr 2025, at 13:07, Mark Reinhold wrote: https://openjdk.org/jeps/512 Summary: Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Tue Apr 22 13:48:31 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 22 Apr 2025 13:48:31 +0000 Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <20250422120226.00091812497@eggemoggin.niobe.net> References: <20250422120226.00091812497@eggemoggin.niobe.net> Message-ID: 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 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: From forax at univ-mlv.fr Tue Apr 22 14:59:01 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 22 Apr 2025 16:59:01 +0200 (CEST) Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: References: <20250422120226.00091812497@eggemoggin.niobe.net> Message-ID: <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> 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" > To: "amber-spec-experts" > 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 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: From forax at univ-mlv.fr Tue Apr 22 17:24:42 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 22 Apr 2025 19:24:42 +0200 (CEST) Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1541882085.240996873.1745342682709.JavaMail.zimbra@univ-eiffel.fr> > From: "Chen Liang" > 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 on behalf of Remi Forax Sent: Tuesday, April 22, 2025 9:59 AM To: Gavin Bierman Cc: amber-spec-experts 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" To: "amber-spec-experts" 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 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: From stephan.herrmann at berlin.de Tue Apr 22 17:59:33 2025 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 22 Apr 2025 19:59:33 +0200 Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> 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" > *To: *"amber-spec-experts" > *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/ ~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 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 > > > From forax at univ-mlv.fr Tue Apr 22 20:59:12 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 22 Apr 2025 22:59:12 +0200 (CEST) Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> Message-ID: <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Stephan Herrmann" > To: "amber-spec-experts" > Sent: Tuesday, April 22, 2025 7:59:33 PM > Subject: Re: Draft Spec for Flexible Constructor Bodies (JEP 513) > 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? yes, it's the other way around, if you take a look to a code, the same code with strict field and without strict fields do not offer the same publication guarantee. > > Where should I be looking for that property of strictly initialized fields you > are referring to? Let's take an example, class Foo { int x; Foo(int x) { this.x = x; super(); } } // thread 1 global = new Foo(3); // thread 2 var foo = global; if (foo != null) { System.out.println(foo.x); } the question is what are the values that can be printed, with flexible constructor bodies, it's 0 or 3, with strict fields, it's only 3. So you have no way to understand the behavior of the code just by looking at it. > > Stephan R?mi > >> 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" >> *To: *"amber-spec-experts" >> *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/ > ~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 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 >> >> From john.r.rose at oracle.com Tue Apr 22 21:15:59 2025 From: john.r.rose at oracle.com (John Rose) Date: Tue, 22 Apr 2025 14:15:59 -0700 Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> On 22 Apr 2025, at 13:59, Remi Forax wrote: > if you take a look to a code, the same code with strict field and without strict fields do not offer the same publication guarantee. > >> >> Where should I be looking for that property of strictly initialized fields you >> are referring to? > > Let's take an example, > > class Foo { > int x; > > Foo(int x) { > this.x = x; > super(); > } > } > > // thread 1 > global = new Foo(3); > > // thread 2 > var foo = global; > if (foo != null) { > System.out.println(foo.x); > } > > the question is what are the values that can be printed, with flexible constructor bodies, it's 0 or 3, with strict fields, it's only 3. > > So you have no way to understand the behavior of the code just by looking at it. That?s fine, but any change in behavior would be due to strict fields, as a feature. The behavioral difference you point out (0 vs. 3) is in the noise, since either outcome is valid in the JMM, under current rules (or with no strict fields present). Note that SF (strict fields) add more determinism. That is not a flaw in layers of the language added previously, including FCB (flexible constructor bodies). The new layer (SF) will be a improvement over something that was already good. Overall, I don?t see any reason we can?t add this in two layers, FCB first, and then SF. And I see plenty of reasons to do this. The main reason to split the work is the fact that SF requires deep cuts to the VM, while FCB requires no VM changes at all. ? John P.S. The reason strict fields would make the above code more deterministic is that the presence of a strict field causes the VM to add a mid-construction fence, after the strict field is set and before /this/ becomes accessible. Thus, 0 becomes impossible. This mid-construction fence is the same kind of operation as the post-construction fence which the JMM calls the ?freeze? operation. The basic effect of strict fields is to maneuver a JMM freeze operation into the gap between the last initialization of a strict field and the first point at which /this/ might become visible. Certain new structural rules that the VM enforces for strict fields will ensure that there IS such a gap present. None of that is required for FCB. From forax at univ-mlv.fr Tue Apr 22 22:09:23 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 23 Apr 2025 00:09:23 +0200 (CEST) Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> Message-ID: <998777013.241076590.1745359763400.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "John Rose" > To: "Remi Forax" > Cc: "Stephan Herrmann" , "amber-spec-experts" > Sent: Tuesday, April 22, 2025 11:15:59 PM > Subject: Re: Draft Spec for Flexible Constructor Bodies (JEP 513) > On 22 Apr 2025, at 13:59, Remi Forax wrote: > >> if you take a look to a code, the same code with strict field and without strict >> fields do not offer the same publication guarantee. >> >>> >>> Where should I be looking for that property of strictly initialized fields you >>> are referring to? >> >> Let's take an example, >> >> class Foo { >> int x; >> >> Foo(int x) { >> this.x = x; >> super(); >> } >> } >> >> // thread 1 >> global = new Foo(3); >> >> // thread 2 >> var foo = global; >> if (foo != null) { >> System.out.println(foo.x); >> } >> >> the question is what are the values that can be printed, with flexible >> constructor bodies, it's 0 or 3, with strict fields, it's only 3. >> >> So you have no way to understand the behavior of the code just by looking at it. > > That?s fine, but any change in behavior would be due to strict > fields, as a feature. The behavioral difference you point out > (0 vs. 3) is in the noise, since either outcome is valid in > the JMM, under current rules (or with no strict fields present). 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. > > Note that SF (strict fields) add more determinism. That is not > a flaw in layers of the language added previously, including > FCB (flexible constructor bodies). The new layer (SF) will be > a improvement over something that was already good. True, but because being strict or not is not reflected in the language, you have no way to know if you are under the FCB or the SF semantics. > > Overall, I don?t see any reason we can?t add this in two layers, > FCB first, and then SF. And I see plenty of reasons to do this. > The main reason to split the work is the fact that SF requires > deep cuts to the VM, while FCB requires no VM changes at all. The reason is that i want to know if a code is correct or not just by looking at it, that's a big reason why we can write concurrency algorithms in Java, because it does not have to have fear of a compilation option. But because FCB and SF has no language difference, if SF is not introduced at the same time as FCB, it means that i can not know if a Java code has a publication problem or not. Same example, slightly modified, lets say the field can store a reference, lass Foo { String s; Foo(String s) { this.s = s; super(); } } var foo = global; if (foo != null) { System.out.println(foo.s.length()); } Does this code can produce a NPE or not ? The answer is: if FCB and SF are not released at the same time, it depends. I would like to avoid that even if it means that FCB is delayed by several releases, for me, being able to reason on a Java code is more important than delivering a feature earlier *. > > ? John > R?mi * obviously, the other parts of FCB, i.e not the field initialization before the call to super() can be delivered before the field initialization part. From chen.l.liang at oracle.com Tue Apr 22 23:47:44 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 22 Apr 2025 23:47:44 +0000 Subject: [External] : Re: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <1541882085.240996873.1745342682709.JavaMail.zimbra@univ-eiffel.fr> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <1541882085.240996873.1745342682709.JavaMail.zimbra@univ-eiffel.fr> Message-ID: 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 Sent: Tuesday, April 22, 2025 12:24 PM To: Chen Liang Cc: amber-spec-experts Subject: [External] : Re: Draft Spec for Flexible Constructor Bodies (JEP 513) ________________________________ From: "Chen Liang" To: "amber-spec-comments" Cc: "Remi Forax" 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 on behalf of Remi Forax Sent: Tuesday, April 22, 2025 9:59 AM To: Gavin Bierman Cc: amber-spec-experts 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" To: "amber-spec-experts" 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 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: From archie.cobbs at gmail.com Wed Apr 23 17:02:42 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 23 Apr 2025 12:02:42 -0500 Subject: [External] : Re: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <1541882085.240996873.1745342682709.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Tue, Apr 22, 2025 at 6:54?PM Chen Liang wrote: > 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. > I don't claim to be an impartial observer, but in my opinion this issue should not be a show-stopper for finalization of FCB. My rationale: 1. Canonical record constructors already limit what you can do before super(): namely, anything that you can do within a super() call parameter list. So this is not a new problem. 2. This restriction does become more acute with strict fields, but that just means it may need to be addressed along with strict fields (i.e., later). There are simple answers, e.g., allowing a parameterless "super" keyword to demarcate the prologue/epilogue boundary, and which would syntactically mirror the parameterless constructor declaration. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.herrmann at berlin.de Wed Apr 23 21:38:25 2025 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Wed, 23 Apr 2025 23:38:25 +0200 Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <998777013.241076590.1745359763400.JavaMail.zimbra@univ-eiffel.fr> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> <998777013.241076590.1745359763400.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1f32a2d1-9e79-4e51-a4ce-c83cc1c6386b@berlin.de> 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 From gavin.bierman at oracle.com Thu Apr 24 10:08:44 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Thu, 24 Apr 2025 10:08:44 +0000 Subject: [External] : Re: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <1541882085.240996873.1745342682709.JavaMail.zimbra@univ-eiffel.fr> Message-ID: > On 23 Apr 2025, at 18:02, Archie Cobbs wrote: > > 1. Canonical record constructors already limit what you can do before super(): namely, anything that you can do within a super() call parameter list. So this is not a new problem. I think Chen?s issue has been resolved... but just to add for correctness that canonical record constructor bodies are not permitted to contain a constructor invocation. From forax at univ-mlv.fr Thu Apr 24 13:34:09 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 24 Apr 2025 15:34:09 +0200 (CEST) Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <1f32a2d1-9e79-4e51-a4ce-c83cc1c6386b@berlin.de> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> <998777013.241076590.1745359763400.JavaMail.zimbra@univ-eiffel.fr> <1f32a2d1-9e79-4e51-a4ce-c83cc1c6386b@berlin.de> Message-ID: <1805704168.242315658.1745501649694.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Stephan Herrmann" > To: "amber-spec-experts" > 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 From archie.cobbs at gmail.com Thu Apr 24 14:25:50 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 24 Apr 2025 09:25:50 -0500 Subject: [External] : Re: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <1541882085.240996873.1745342682709.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hi Gavin, On Thu, Apr 24, 2025 at 5:08?AM Gavin Bierman wrote: > > On 23 Apr 2025, at 18:02, Archie Cobbs wrote: > > 1. Canonical record constructors already limit what you can do before > super(): namely, anything that you can do within a super() call parameter > list. So this is not a new problem. > > I think Chen?s issue has been resolved... but just to add for correctness > that canonical record constructor bodies are not permitted to contain a > constructor invocation. You're right, and what I wrote wasn't clear. I should have said: "Canonical record constructors already restrict what you can do before super() because they don't allow super() invocations; in particular, they disallow anything that you would normally be able to do within a super() call parameter list. So this is not a new problem." Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Mon Apr 28 20:01:06 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 28 Apr 2025 20:01:06 +0000 Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <1805704168.242315658.1745501649694.JavaMail.zimbra@univ-eiffel.fr> References: <20250422120226.00091812497@eggemoggin.niobe.net> <603673507.240787276.1745333941690.JavaMail.zimbra@univ-eiffel.fr> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> <998777013.241076590.1745359763400.JavaMail.zimbra@univ-eiffel.fr> <1f32a2d1-9e79-4e51-a4ce-c83cc1c6386b@berlin.de> <1805704168.242315658.1745501649694.JavaMail.zimbra@univ-eiffel.fr> Message-ID: > On Apr 24, 2025, at 6:34?AM, Remi Forax wrote: > >> Perhaps we should be asking: who will emit the ACC_STRICT_INIT flag, and when? > > 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. > 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. Let me clarify how we've been thinking in recent Valhalla work about the path toward an eventual strict-by-default world in the language: 1) With value classes, we introduce the concept of strictly-initialized fields in the JVM, enforce rules that value class sources require early initialization of their fields, and provide an "early-by-default" interpretation of these classes (early instance field initializers, implicit 'super()' at the end of constructors). Potentially, we can also subject record classes to these behaviors, with some small compatibility risk. [See https://openjdk.org/jeps/401#Value-object-initialization] 2) At the same time, we introduce some *warnings* to encourage a style of programming in identity classes that could support early-by-default compilation in the future. [See https://openjdk.org/jeps/401#Encouraging-early-initialization-of-identity-classes] 3) At some later point, we provide a language feature (mechanism TBD) to allow identity classes to opt in to the value class early-by-default rules. In a class that opts in, a field that is early-initialized is treated as ACC_STRICT_INIT, and a field that is late-initialized is not. (It might be an error or warning to try to mix initialization timings of a single field.) Where does support for early assignment in constructor bodies fit in? It's a hard prerequisite to (1), because that is the only way to initialize a value class field. It's also important for (2), because one way to address warnings about 'this' dependencies is to add a 'super()' call to the constructor, and then put the 'this'-dependent code after that call (but keep the rest of the code early). Note that (2) has no semantic impact, so it's something we can readily impose on every class. And then the idea is that (3) allows programmers to opt in to subtly different semantics (like the memory model effects you've illustrated); a program that has addressed the warnings by then won't need to make any additional source changes. Of course this is not the only possible way to approach the problem, but there are some good reasons to arrange things like this: - (1) comes with early initialization requirements, but we don't want to tie the semantic changes of (3) to getting value classes out the door. Frankly, (3) is a can of worms and I'm not sure where it will lead. So there needs to be some space between (1) and (3). - (1) encourages class authors to think about construction timing and 'this' dependencies, and so it's a good opportunity to get them to consider those things throughout their code?hence tying (1) and (2) together. (One piece of this that isn't clear to me, and that we need to discuss further, is where '!'-typed fields fit in?they also require early initialization and ACC_STRICT_INIT. Maybe using '!' on a field is one form of the opt-in described in (3). Or maybe that's too indirect. TBD...) From forax at univ-mlv.fr Tue Apr 29 16:13:18 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 29 Apr 2025 18:13:18 +0200 (CEST) Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: References: <20250422120226.00091812497@eggemoggin.niobe.net> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> <998777013.241076590.1745359763400.JavaMail.zimbra@univ-eiffel.fr> <1f32a2d1-9e79-4e51-a4ce-c83cc1c6386b@berlin.de> <1805704168.242315658.1745501649694.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <850252565.250473285.1745943198451.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "daniel smith" > To: "Remi Forax" > Cc: "Stephan Herrmann" , "amber-spec-experts" > Sent: Monday, April 28, 2025 10:01:06 PM > Subject: Re: Draft Spec for Flexible Constructor Bodies (JEP 513) >> On Apr 24, 2025, at 6:34?AM, Remi Forax wrote: >> >>> Perhaps we should be asking: who will emit the ACC_STRICT_INIT flag, and when? >> >> 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. > >> 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. > > Let me clarify how we've been thinking in recent Valhalla work about the path > toward an eventual strict-by-default world in the language: > > 1) With value classes, we introduce the concept of strictly-initialized fields > in the JVM, enforce rules that value class sources require early initialization > of their fields, and provide an "early-by-default" interpretation of these > classes (early instance field initializers, implicit 'super()' at the end of > constructors). Potentially, we can also subject record classes to these > behaviors, with some small compatibility risk. [See > https://openjdk.org/jeps/401#Value-object-initialization] > > 2) At the same time, we introduce some *warnings* to encourage a style of > programming in identity classes that could support early-by-default compilation > in the future. [See > https://openjdk.org/jeps/401#Encouraging-early-initialization-of-identity-classes] > > 3) At some later point, we provide a language feature (mechanism TBD) to allow > identity classes to opt in to the value class early-by-default rules. In a > class that opts in, a field that is early-initialized is treated as > ACC_STRICT_INIT, and a field that is late-initialized is not. (It might be an > error or warning to try to mix initialization timings of a single field.) > > Where does support for early assignment in constructor bodies fit in? It's a > hard prerequisite to (1), because that is the only way to initialize a value > class field. It's also important for (2), because one way to address warnings > about 'this' dependencies is to add a 'super()' call to the constructor, and > then put the 'this'-dependent code after that call (but keep the rest of the > code early). > > Note that (2) has no semantic impact, so it's something we can readily impose on > every class. And then the idea is that (3) allows programmers to opt in to > subtly different semantics (like the memory model effects you've illustrated); > a program that has addressed the warnings by then won't need to make any > additional source changes. > > Of course this is not the only possible way to approach the problem, but there > are some good reasons to arrange things like this: > > - (1) comes with early initialization requirements, but we don't want to tie the > semantic changes of (3) to getting value classes out the door. Frankly, (3) is > a can of worms and I'm not sure where it will lead. So there needs to be some > space between (1) and (3). > > - (1) encourages class authors to think about construction timing and 'this' > dependencies, and so it's a good opportunity to get them to consider those > things throughout their code?hence tying (1) and (2) together. > > (One piece of this that isn't clear to me, and that we need to discuss further, > is where '!'-typed fields fit in?they also require early initialization and > ACC_STRICT_INIT. Maybe using '!' on a field is one form of the opt-in described > in (3). Or maybe that's too indirect. TBD...) Hello Dan, thanks for taking the time to reply. The problem of (2), is that if you emit a warning, people will want to change the code but they need (3) for that. 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(); } } But this feature requires to change the VM to add a memory barrier for Object.() *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. 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). Now, you want to add a warning for helping people to move to a world with early initialization of fields, FCM has to support early field initializations. So for me, FCM has to have the same restrictions has for value types, all early initialized fields have to be final, the call to super has to be the last call to the constructor. And then later, if the VM changes are okay, we can revisit those restrictions. R?mi As a side note, '!' is STRICT_INIT_FIELD + nullcheck, so the field has to be initialized before the super call, we can keep the constraint that super() has to be the last statement but given that the field can be "not final", we need at least the VM to insert a memory freeze at the end of the constructor (like with final). From daniel.smith at oracle.com Tue Apr 29 18:35:57 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 29 Apr 2025 18:35:57 +0000 Subject: Draft Spec for Flexible Constructor Bodies (JEP 513) In-Reply-To: <850252565.250473285.1745943198451.JavaMail.zimbra@univ-eiffel.fr> References: <20250422120226.00091812497@eggemoggin.niobe.net> <8ee3dad1-44d9-4dfc-af87-2d142d66139c@berlin.de> <1450345326.241047605.1745355552927.JavaMail.zimbra@univ-eiffel.fr> <6C77C9AD-F4BA-4221-B9A7-FE9A21FE8074@oracle.com> <998777013.241076590.1745359763400.JavaMail.zimbra@univ-eiffel.fr> <1f32a2d1-9e79-4e51-a4ce-c83cc1c6386b@berlin.de> <1805704168.242315658.1745501649694.JavaMail.zimbra@univ-eiffel.fr> <850252565.250473285.1745943198451.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <86B7BD5A-4690-4F07-A6B1-86775D8FD115@oracle.com> > 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.() *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.)