From daniel.smith at oracle.com Wed Sep 3 00:55:00 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 3 Sep 2025 00:55:00 +0000 Subject: Eg meeting *canceled*, 2025-09-03 Message-ID: <5EC05FEA-6C92-4CC9-A205-D33596FF1BC9@oracle.com> Nothing new this time, meeting canceled. From daniel.smith at oracle.com Wed Sep 17 00:36:46 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 17 Sep 2025 00:36:46 +0000 Subject: Eg meeting *canceled*, 2025-09-17 Message-ID: <4CD116A4-22F3-4301-88EA-53A2E182501C@oracle.com> Well, still working internally on some design issues, nothing new to discuss, so no meeting tomorrow. I would *like* to produce some documents that we could discuss here, perhaps in the near future, stay tuned... From daniel.smith at oracle.com Fri Sep 26 22:57:53 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 26 Sep 2025 22:57:53 +0000 Subject: Updated specs for Value Classes Message-ID: Please see these spec change documents, revised to align with current plans for the Value Classes and Objects JEP. https://cr.openjdk.org/~dlsmith/jep401/jep401-20250926/specs/value-objects-jls.html https://cr.openjdk.org/~dlsmith/jep401/jep401-20250926/specs/value-objects-jvms.html I've also revised the JEP in the last couple of months, which you can view here: https://openjdk.org/jeps/401 Some highlights: - Clarified the presentation of how == works, with extensive discussion in the JEP - Instance fields can be both written and read in early construction - Record classes adopt the same early construction behavior as value classes - Memory model rules to ensure correct values are read from value and record class fields (and, eventually, other strict fields) - New verifier rules disallowing acmp/ifnull on uninitialized types A linked JVMS document covers the Strict Field Initialization JEP, although I still have some work to do to refresh and polish that one. From forax at univ-mlv.fr Tue Sep 30 06:21:49 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 30 Sep 2025 08:21:49 +0200 (CEST) Subject: Updated specs for Value Classes In-Reply-To: References: Message-ID: <783638553.2081479.1759213309925.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "daniel smith" > To: "valhalla-spec-experts" > Sent: Saturday, September 27, 2025 12:57:53 AM > Subject: Updated specs for Value Classes > Please see these spec change documents, revised to align with current plans for > the Value Classes and Objects JEP. > > https://cr.openjdk.org/~dlsmith/jep401/jep401-20250926/specs/value-objects-jls.html > https://cr.openjdk.org/~dlsmith/jep401/jep401-20250926/specs/value-objects-jvms.html > > I've also revised the JEP in the last couple of months, which you can view here: > > https://openjdk.org/jeps/401 > > Some highlights: > > - Clarified the presentation of how == works, with extensive discussion in the > JEP > - Instance fields can be both written and read in early construction Hello Dan, this one seems too clever for me. I find that it make it hard to explain how things work apart from explaining the cleverness. First, even without this feature, the fact that this.x = x is allowed but not IO.println(this) is already a challenged to explain correctly. Now, we can write IO.println(this.x) but still not IO.println(this), I do not know how to explain that without explaining the trick the compiler does. Also, the trick starts to break when by example lambdas or inner classes are involved value class Point { private final double x, y; Point(double x, double y) { this.x = x; IO.println(this.x); var lambda = (DoubleSupplier) () -> this.x; var innerClass = new DoubleSupplier() { @Override public double getAsDouble() { return this.x; // BTW Point.this.x raises a different error ?? } }; this.y = y; super(); } } For me, we are going a step too far here, yes it's convenient but it makes the semantics is more blurry. > - Record classes adopt the same early construction behavior as value classes > - Memory model rules to ensure correct values are read from value and record > class fields (and, eventually, other strict fields) > - New verifier rules disallowing acmp/ifnull on uninitialized types > > A linked JVMS document covers the Strict Field Initialization JEP, although I > still have some work to do to refresh and polish that one. regards, R?mi From daniel.smith at oracle.com Tue Sep 30 17:54:00 2025 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 30 Sep 2025 17:54:00 +0000 Subject: Updated specs for Value Classes In-Reply-To: <783638553.2081479.1759213309925.JavaMail.zimbra@univ-eiffel.fr> References: <783638553.2081479.1759213309925.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <61C50411-DD23-4E41-BBFC-379895891652@oracle.com> On Sep 29, 2025, at 11:21?PM, Remi Forax wrote: - Instance fields can be both written and read in early construction Hello Dan, this one seems too clever for me. I find that it make it hard to explain how things work apart from explaining the cleverness. First, even without this feature, the fact that this.x = x is allowed but not IO.println(this) is already a challenged to explain correctly. Now, we can write IO.println(this.x) but still not IO.println(this), I do not know how to explain that without explaining the trick the compiler does. Sounds like your concern is particularly to do with 'this'? So if these were unqualified field refs, it wouldn't be so confusing? (Aside: this reminds me that I didn't address 15.8.3, need to adjust the rule for 'this.x' expressions!) The rule is, basically: in the early construction phase of an object, you can use the fields, but not 'this' or its methods, because the object isn't safe for sharing yet. I would not try to explain this in terms of proxy locals. And then once somebody gets that basic rule, you can clarify the fine print: - Inherited fields can't be accessed, have to let the superclass initialize them - 'this.x' is just an alternate way to reference a field 'x', but the compiler understands that it's a field ref, not a generalized use of 'this' (building on the precedent of DA/DU and field initializer restrictions) - Lambdas and inner classes capture 'this' to get to fields, so that *does* qualify as a generalized, illegal use of 'this' For me, we are going a step too far here, yes it's convenient but it makes the semantics is more blurry. If we were to roll back to disallowing field references entirely in early construction, I would agree that is a cleaner bright line. It would undermine our mechanism for value class creation, but it would be a less complex restriction. But our choice here isn't about doing that, it's about allowing field refs on the LHS of assignments, or everywhere. The LHS of assignment approach still requires you to explain all the fine print rules I listed above. It just adds *another* restriction. Between those two (field ref must be LHS of assignment vs. field ref can be allowed in any form of expression if it conforms to the other restrictions), I find removing the LHS restriction to be a *simplifying* move. -------------- next part -------------- An HTML attachment was scrubbed... URL: