From john.r.rose at oracle.com Thu Jul 1 00:16:30 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Jul 2021 00:16:30 +0000 Subject: [External] : Re: Revisiting default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> Message-ID: > On Jun 30, 2021, at 8:39 AM, Brian Goetz wrote: > > Now, let's talk more about null. Null is a *reference* that refers to no object. For a flattened/direct object (P.val), null cannot be in the value set (it's the wrong "kind"), though we can arrange for a primitive to behave like null in various ways. It's not clear whether this helps or hurts the mental model, since it is distorting what null is. This is a good point, if we can hold onto it. Null is a magic one-off boojum that lives in the space of reference types but makes field references and method calls ?softly and suddenly vanish away?. Having P.val.default.m() throw an NPE (under default exclusion rules TBD) makes the null boojum arise from a non-reference value, but only just long enough to make the method call go away. (Boo?) Dan?s proposals for default exclusion is loads from uninitialized variables (such as fresh array elements) amount to another boojum-like behavior, of making loads go away (unless the variable has been stored into previously). Again, it?s not directly associated with a reference, but it is null-like, and perhaps NPE is the right way to signal the fault. Of course, our familiar null does not show complete boojum behavior, because you can read, write, and print null without yourself vanishing away. Likewise, even if we do some sort of default exclusion, perhaps we will allow defaults to flow in the same (limited) paths that nulls can flow. And in that case, the #nonewnulls crowd would expect that only the one value null would appear, whenever such a value were converted to a reference. Maybe, in some of these schemes, null is not a primitive, but boojums and boxes are the primitives, and null is a (safely) boxed boojum? ? John From john.r.rose at oracle.com Thu Jul 1 00:19:18 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Jul 2021 00:19:18 +0000 Subject: [External] : Re: Revisiting default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> Message-ID: <307294A2-0365-4E79-A4E3-D048DD61B10A@oracle.com> P.S. Wikipedia gives for boojum: ?A fictional animal species in Lewis Carroll's nonsense poem The Hunting of the Snark; a particularly dangerous kind of snark.? ?But if ever I meet with a Boojum, that day, In a moment (of this I am sure), I shall softly and suddenly vanish away? And the notion I cannot endure!? On Jun 30, 2021, at 5:16 PM, John Rose > wrote: Maybe, in some of these schemes, null is not a primitive, but boojums and boxes are the primitives, and null is a (safely) boxed boojum? From kevinb at google.com Thu Jul 1 00:20:21 2021 From: kevinb at google.com (Kevin Bourrillion) Date: Wed, 30 Jun 2021 17:20:21 -0700 Subject: [External] : Re: Revisiting default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> Message-ID: On Wed, Jun 30, 2021 at 8:40 AM Brian Goetz wrote: Of your points, I think this is the controversial one, and it goes straight > to "what is the point of primitive classes." > > You kind of dismiss optimization, but of course a big part of the point is > classes that are more optimizable; if we didn't care about optimization, we > wouldn't bother with primitive classes, we'd just say "write classes." > We might be miscommunicating? Just gonna be candid. This qualitative argument is both of no use, *and* unnecessary, because the quantitative argument is the whole point. I mean: if feature-variation-A actually wipes out 40% of the performance benefit of the whole endeavor, you'd hardly need to convince anyone it's a non-starter, not even *me*. Just like if it wiped out 1% of gains (while preventing many likely bugs) then *you* would hardly need convincing. So, I can't figure out what your purpose in saying this is. The unfortunate bit is that the reason we're stuck with zeroes as the > default value comes from the VM's desire to provide both safety _and_ > performance. Painting with a roller is cheaper than with a brush, but, > more importantly, all-zeroes is the only value the JVM can really give > while promising that some other OOTA value will never be observed, > regardless of races and other timing hazards. > (I was treating customized-default-bits as being off the table, so I'm not sure what this is about?) Now, let's talk more about null. Null is a *reference* that refers to no > object. > But also: "a primitive is a predefined irreducible type!" I sincerely claim that your statement is in the same boat. You're speaking of what has *happened* to be the case in Java, because reasons. However, I think the *concept* of null is more basic; it is just "there is no instance here". Try to do instance stuff, blow up always, that's null. If you say it's *fundamental* to the notion of a primitive/inline type that there is *always* a value there.... okay, but then what you're talking about is *bits*. Yep there are always bits there. But is that what matters to software? What software wants is programs that are first correct and then (as hot on the heels as you like) performant. I've said that primitive types for which all-zeroes isn't *valid* would prefer to surface that value as *null *instead. So I guess my big bold play here is to claim that the primitive type "reference" is just the first *example* of this category, that's all. (I feel very untroubled by seeing "reference" as a primitive type, which is special only in that Java traverses it for you -- lets you see "dereference then member access" as if it is just "member access" -- which it does for obvious and obviously-special reasons.) ... distorting what null is ... > ... muddies what null means ... > One of the things I *very much* like about where this project has gotten to is that the "ret-cons" it requires *aren't even really ret-cons*. - "Primitive" has always meant "inline". It never really meant "predefined"; Java just didn't happen to let you define them. - "Instance" has never really meant "thing on the heap with identity". It always meant "one of a class". Java just didn't happen to have other kinds. - "Null" as a noun was never well-defined, only "null literal" and "null reference". "null reference" has always meant "there is no instance here", and if we *do* define "null value", it will mean the same thing! I think we are better off treating this as a discussion about > initialization safety, rather than nullity, until we have a clear story of > how we want things to behave. > Sure, I'd be very interested in that discussion too. On 6/29/2021 1:54 PM, Kevin Bourrillion wrote: > > Among all the use cases for primitive classes, the ones where the default > value is non-degenerate and expected are the special cases! We use > `Complex` as a go-to example, but if most of what we did with complex > numbers was divide them by each other then even this would be dubious. We'd > be letting an invalid value masquerade as a valid one when we'd rather it > just manifest as `null` and be subject to NPEs > > Clarifications: * "special cases" != "rare" or "exotic" * "dubious" != "bad" or "wrong" Also, reminder that X% of my opinions are wrong -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From john.r.rose at oracle.com Thu Jul 1 00:00:04 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Jul 2021 00:00:04 +0000 Subject: Revisiting default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> Message-ID: <09CAFB4D-8011-4D15-A125-6294EBF89F5E@oracle.com> On Jun 29, 2021, at 2:36 PM, Kevin Bourrillion > wrote: Speaking of orthogonality, there *is* an open question about how we interpret , and this is orthogonal to the question of whether should be the "default default". We've talked about: - It's interchangeable with null - It's null-like (i.e., detected on member access), but distinct - It's a separate concept, and it is an error to ever read it from fields/arrays All still on the table. Oh. Yeah, if you look at all the work we've all poured into how we manage null and its attendant risks, and ongoing work (perhaps charitably assume JSpecify will be successful! :-)), then it's kiiiind of a disaster if there's suddenly a second kind of nullness. #nonewnulls BTW, the combination of #nonewnulls (a principle I whole-heartedly favor) and ?it is an error to ever read it? pencils out some capability to define containers of nullable types but which reject nulls in some way. (Perhaps a subtle way: Perhaps the container starts out null but cannot be read until a different initial value is written.) Such containers would resemble, in certain ways, containers for lazily-computed values. (I.e., they have a dynamically-distinguished undefined state, and they cannot return to that state having left it.) OTOH, a container for a lazily-computed *nullable* value would, in fact, require a second sentinel, not null, to denote the unbound state; making that sentinel escape would create a #newnull, which would be bad. Not sure how to square this circle yet. Another random side-point, this time about `withfield`: It is IMO impractical to perform default exclusion (null detection) for field assignments in primitive class constructors, because the default-ness of `this` is a complicated dynamic property of all the fields together. As a constructor executes, it may temporarily revert `this` to the default value if it zeroes out a field. So the `withfield` instruction should *not* perform default exclusion on `this`. (Of course an excluded default would get checked for on exit from the constructor.) A similar point goes for `getfield`, perhaps, though less strongly, because the Java language would not use it. But the JVMS should probably attach default exclusion either to both `withfield` and `getfield` or neither. This suggests that only method invocations would perform default exclusion. Which reminds me: I think we should allow calls to methods on `this` inside a constructor. (Do we?) A clean way to statically exclude incomplete values of `this` would be to outlaw such self-calls until all final fields are definitely assigned. The current language (for identity classes) computes this point (of complete field assignment) in order to enforce the rule that the constructor cannot return until all final fields have been definitely assigned. For identity classes it would be nice to *warn* on self-calls (or perhaps other uses of `this`) before all finals are DA. For primitives classes we can outlaw such things, of course. Basically, for both primitive and identity class constructors, it is a likely bug if you use `this` (for something other than initializing `this`) before all final fields are DA. And yet some constructors perform additional operations (such as sanity checks) in an object constructor, when the object is in DA and ?almost finished? state. It would be smart, I think, to make the rules in this area, as coherent as possible, for both kinds of classes. IIRC the status quo is that no uses of `this` are legitimate in a constructor body except field writes (of DU fields) and field reads (of DA fields). I think that is too strict, compared to the laxness of the rules for identity classes, and given the usefulness of error checking methods being called from constructors. From brian.goetz at oracle.com Thu Jul 1 12:48:19 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 1 Jul 2021 08:48:19 -0400 Subject: Revisiting default values In-Reply-To: <09CAFB4D-8011-4D15-A125-6294EBF89F5E@oracle.com> References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> <09CAFB4D-8011-4D15-A125-6294EBF89F5E@oracle.com> Message-ID: > > Which reminds me: ?I think we should > allow calls to methods on `this` inside a > constructor. ?(Do we?) ?A clean way to > statically exclude incomplete values of `this` > would be to outlaw such self-calls until all > final fields are definitely assigned. ?The > current language (for identity classes) > computes this point (of complete field > assignment) in order to enforce the rule > that the constructor cannot return until > all final fields have been definitely assigned. FYI: A recent paper on the self-use-from-constructor problem: https://dl.acm.org/doi/10.1145/3428243 From brian.goetz at oracle.com Thu Jul 1 13:06:33 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 1 Jul 2021 09:06:33 -0400 Subject: [External] : Re: Revisiting default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> Message-ID: > > I sincerely claim that your statement is in the same boat. You're > speaking of?what has /happened/?to be the case in Java, because reasons. > > However, I think the /concept/?of null is more basic; it is just > "there is no instance here". Try to do instance stuff, blow up always, > that's null. > > If you say it's /fundamental/?to the notion of a primitive/inline type > that there is /always/?a value there.... okay, but?then what you're > talking about is /bits/. Yep there are always bits there. But is that > what matters to software? What software wants is programs that are > first correct and then (as hot on the heels as you like) performant. I'm saying something slightly different (but I agree it's as much "what happened" as "what is").? Our formulation of ref/val is based on saying "well, the instance *is*, but there are two ways to store it, and nullity is part of the 'how you store it' rather than the 'what it is'."? I think this is a more helpful way to look at it, but of course it's not the only way.? But I want to make sure that we don't select a set of mental models that are locally sane but conflict with each other. > > I think we are better off treating this as a discussion about > initialization safety, rather than nullity, until we have a clear > story of how we want things to behave. > > > Sure, I'd be very interested in that discussion too. By that I mean: framing this not as "this field is null", but instead, "this field is uninitialized, so it is an error to dereference it."? One could argue (well, it would be a stretch) that the following code is not broken: ??? String nullIMeanIt = null; ??? nullIMeanIt.length();? // Gimme an NPE, dammit! It is obviously *silly*, but by "not broken", what I mean is that getting an NPE when you dereference a null pointer is *what null does*.? The bug in most NPEs is a null where we didn't expect it, but usually one that was put there.? When we get a NPE from x.foo(), it is often not the case that we failed to initialize x; we initialized it to something that unexpectedly returned null *as a value*, such as `x = getBar()`.? All the @NonNull stuff is an attempt to get null to go back in the cage, after we let it escape. But I think with no-good-default primitives, it is about not letting the thing escape in the first place.? The difference in practice may be minor, but the difference in the story we are able to tell as a result might be bigger. From john.r.rose at oracle.com Thu Jul 1 19:33:11 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Jul 2021 19:33:11 +0000 Subject: Revisiting default values In-Reply-To: References: <3D227EB1-4D86-4F97-BFCB-A5949C63A717@oracle.com> <741e0451-0b6b-05a7-5fae-f56e5c312092@oracle.com> <09CAFB4D-8011-4D15-A125-6294EBF89F5E@oracle.com> Message-ID: <68413B3A-FA65-4CFD-B158-16E0C23FF9C1@oracle.com> > On Jul 1, 2021, at 5:48 AM, Brian Goetz wrote: > > >> >> Which reminds me: I think we should >> allow calls to methods on `this` inside a >> constructor. (Do we?) A clean way to >> statically exclude incomplete values of `this` >> would be to outlaw such self-calls until all >> final fields are definitely assigned. The >> current language (for identity classes) >> computes this point (of complete field >> assignment) in order to enforce the rule >> that the constructor cannot return until >> all final fields have been definitely assigned. > > FYI: A recent paper on the self-use-from-constructor problem: https://dl.acm.org/doi/10.1145/3428243 > > Nice; it supports virtual calls in a constructor. To me that seems a good stretch goal. A simpler rule would define an ?all initialized? point in the constructor (no DU states, basically) and open the floodgates there. A more complicated set of rules could allow earlier access to partially DU objects, as a compatible extension. In terms of the paper, the initial conservative approach does not allow (or perhaps warns on) any typestate that has a remaining DU in it, while an extended approach would classify accesses according to which DU?s they might be compatible with. An example of the difference would be: primitive class Complex { float re, im, abs, arg; Complex(float re, float im) { this.re = re; this.im = im; if (CONSERVATIVE_AND_SIMPLE) { // we can easily do this today this.abs = Complex.computeAbs(re, im); this.arg = Complex.computeArg(re, im); } else { // later, enhanced analysis can allow this.m() this.abs = this.computeAbs(); this.arg = this.computeArg(); } } } Other observations: The paper seems to formalize and extend the DA/DU rules of Java 1.1 (which I am fond of), under the term ?local reasoning about initialization?. The distinction between objects that are ?hot? (old) and ?warm? (under construction) objects seems to align with some of our discussions about confinement of ?larval? objects before they promote to ?adult?. From mcnepp02 at googlemail.com Fri Jul 2 07:53:26 2021 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Fri, 2 Jul 2021 09:53:26 +0200 Subject: JEP 401 -- reflection and class literals In-Reply-To: <1550290072.7564.1624787885215.JavaMail.zimbra@u-pem.fr> References: <3de06bc5-9d67-18be-e3a3-e7ade4d71a30@oracle.com> <1550290072.7564.1624787885215.JavaMail.zimbra@u-pem.fr> Message-ID: <1c782c70-9870-efb3-2d10-ca5deaf51426@gmail.com> Am 27.06.2021 um 11:58 schrieb Remi Forax: > I disagree on your last bullet point, > I think that less is more in that context, we do not have to have a syntax to express the secondary class exactly like we do not allow Foo.class. > So instead of allowing Point.ref.class and Point.val.class, i think it's better to have no language support given that we can already write Point.class.asPrimitiveObjectClass(). > I do agree that we might not need syntactic sugar for specifying the "byValue-type" of a primitive class, given that the method Class#asPrimitiveObjectClass() will be available. However, using this method in an expression such as: Point.class.getMethod("transform", Point.class.asPrimitiveObjectClass()); looks overly verbose to me. Plus, the method can be invoked on every class, even non-primitive ones. So we might end up seeing useless code like: Point.class.getMethod("parse", String.class.asPrimitiveObjectClass()); So, let me propse something that may strike the right balance between ease-of-use and verbosity, at least for the Java language: The Java Language specification could mandate that each primitive class T shall contain a public final static member of type Class, named "VALUE_TYPE". (specifying auto-generated members for certain types would follow precedent set by Enum-classes, see JLS section 8.9.3: Enum Members) The above code would then look like this, neatly conveying the intent: Point.class.getMethod("transform", Point.VALUE_TYPE); Also, please bear in mind that all the Primitive Type Wrappers currently have such a public final static member named "TYPE". After migrating these wrappers to primitive classes, the "TYPE" members could be deprecated and supplanted by the standard "VALUE_TYPE" members. Additionally, it could then be advertized in JavaDoc that the canonical way of specifying a type-mirror for the legacy primitives should be "[primitive-wrapper-class].VALUE_TYPE" instead of "[primitive-type-name].class". In the long term, we wouldn't be seeing ugly "int.class" anymore, and this would lead to highly consistent code such as: Point.class.getMethod("move", Point.VALUE_TYPE, Integer.VALUE_TYPE); From daniel.smith at oracle.com Fri Jul 2 23:48:12 2021 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 2 Jul 2021 23:48:12 +0000 Subject: Draft JVMS changes for Primitive Objects (JEP 401) Message-ID: Here's a long-overdue refresh of the proposed JVMS changes to support Primitive Objects: http://cr.openjdk.java.net/~dlsmith/jep401/latest (Sorry to dump this on the weekend, not looking for same-day feedback. :-)) I *think* I've captured all the key JVMS-related pieces that we expect to include with JEP 401, but please let me know if I missed something. In a number of areas, there are still open design questions. I've called those out in discussion blocks. Often, I've made a somewhat arbitrary choice for how to resolve the open question, based on my mood at the time. :-) While it's useful to get something down on paper, all of these will be more carefully explored and resolved in the coming months. If you see something *not* called out that you think still needs further discussion, let me know. New term to look out for: "inlinable reference type", which is spec-speak for "Q type". (And its companion, "standard reference type", for "L type".) Why not call it a "primitive value type", like we do in the Java language? Because, unlike the language model, in the JVM it works best to treat all class types as reference types that participate in a single substitutability/subtyping graph, even though the JVM can optimize away the references in many cases. Our generics story leans heavily on the JVM handling types in this way. Given that mismatch, it seems too confusing to try to force the same terminology into the different models. There are supplementary "cleanup" changes included in the bundle, if you're interested in exploring them. Most of these fall under the umbrella of the "Better-defined JVM class file validation" JEP I proposed a few weeks ago, but "JVM Types Cleanup" is new. From daniel.smith at oracle.com Tue Jul 13 23:30:48 2021 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 13 Jul 2021 23:30:48 +0000 Subject: EG meeting, 2021-07-14 Message-ID: The next EG Zoom meeting is Wednesday at 4pm UTC (9am PDT, 12pm EDT). Topics to discuss: "Draft JVMS changes for Primitive Objects (JEP 401)": I shared a revised JVM spec for JEP 401. Some new, tentative ideas here: - "Inlinable reference type" terminology - An ACC_PRIM_SUPER flag - An ACC_ATOMIC flag (formalizing the NonTearable interface) - Support for L descriptors in CONSTANT_Class - A JavaFlags attribute for extra language-only flags - Details for implementing IdentityObject/PrimitiveObject "Revisiting default values": Kevin weighed in on this old thread with some thoughts on nullable primitive value types and default values "JEP 401 -- reflection and class literals": Brian shared some additional thoughts on Class objects and class literals, suggesting we de-emphasize type-modeling Class objects From daniel.smith at oracle.com Mon Jul 19 17:59:03 2021 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 19 Jul 2021 17:59:03 +0000 Subject: Objects.newIdentity update Message-ID: An update on Objects.newIdentity for Java 17: Roger did some work to put the feature together and get it reviewed. https://bugs.openjdk.java.net/browse/JDK-8269096 However, while the implementation is straightforward, for libraries folks not deeply familiar with the Valhalla Project, the concept of a method that does the same thing as 'new Object()' did not seem particularly justified. I think they're especially uncomfortable with the idea of talking about creating an "identity" in a world in which all objects have identity. https://bugs.openjdk.java.net/browse/JDK-8269097 So, not going to work out for this release. We made a bet that it would be a simple, noncontroversial matter to slip in an extra method, but it turns out to be a tougher sell than we thought. Of course, as part of JEP 401, a feature like this will have the surrounding context, with things like the IdentityObject interface, so that it will make a lot more sense. We'll plan for that. From forax at univ-mlv.fr Mon Jul 19 18:45:46 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 19 Jul 2021 20:45:46 +0200 (CEST) Subject: Objects.newIdentity update In-Reply-To: References: Message-ID: <852973258.623995.1626720346083.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "daniel smith" > To: "valhalla-spec-experts" > Cc: "Roger Riggs" > Sent: Lundi 19 Juillet 2021 19:59:03 > Subject: Objects.newIdentity update [I've added Mark in CC] > An update on Objects.newIdentity for Java 17: Roger did some work to put the > feature together and get it reviewed. > > https://bugs.openjdk.java.net/browse/JDK-8269096 > > However, while the implementation is straightforward, for libraries folks not > deeply familiar with the Valhalla Project, the concept of a method that does > the same thing as 'new Object()' did not seem particularly justified. I think > they're especially uncomfortable with the idea of talking about creating an > "identity" in a world in which all objects have identity. > > https://bugs.openjdk.java.net/browse/JDK-8269097 Not all objects have an identity, we have already introduced value based class https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/doc-files/ValueBased.html a long time ago. The JLS also says that lambdas have no identity. First, i believe there is a problem of communication somewhere, the fact that newIdentity() returns new Object() is not important, we all now, and this is especially true for people dealing with the core libraries that implementations change. In a sense, it's normal to have a discussion about what identity means and Object being the root of everything, because introducing Objects.newIdentity() is a move to make current developers more aware of that. We have started that discussion with the introduction of value based class, more recently with JEP 390, Objects.newIdentity() is just the continuation of the logic of delivering features in pieces. With that in mind, not adding Objects.newIdentity() now seems shortsighted. R?mi [1] https://openjdk.java.net/jeps/390 From brian.goetz at oracle.com Mon Jul 19 18:53:00 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Jul 2021 14:53:00 -0400 Subject: Objects.newIdentity update In-Reply-To: <852973258.623995.1626720346083.JavaMail.zimbra@u-pem.fr> References: <852973258.623995.1626720346083.JavaMail.zimbra@u-pem.fr> Message-ID: <451e4688-55dc-43c2-5c7a-1209d974c98c@oracle.com> I understand your frustration, but the claims you make here in defense of "identity" are not right.? Value-based classes can (and currently do) have identity; VBC means that it is a mistake to _depend_ on that identity.? (Same as with Integer boxes.) Similarly, lambdas may have identity, but the system makes no guarantees about the identity of the object that results from evaluating a lambda expression. > Not all objects have an identity, we have already introduced value based class > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/doc-files/ValueBased.html > a long time ago. > > The JLS also says that lambdas have no identity. > > First, i believe there is a problem of communication somewhere, the fact that newIdentity() returns new Object() is not important, > we all now, and this is especially true for people dealing with the core libraries that implementations change. > > In a sense, it's normal to have a discussion about what identity means and Object being the root of everything, because introducing Objects.newIdentity() is a move to make current developers more aware of that. We have started that discussion with the introduction of value based class, more recently with JEP 390, Objects.newIdentity() is just the continuation of the logic of delivering features in pieces. > > With that in mind, not adding Objects.newIdentity() now seems shortsighted. > > R?mi > > [1] https://openjdk.java.net/jeps/390 From daniel.smith at oracle.com Sun Jul 25 16:56:26 2021 From: daniel.smith at oracle.com (Dan Smith) Date: Sun, 25 Jul 2021 16:56:26 +0000 Subject: EG meeting *canceled*, 2021-07-28 Message-ID: <79A73C80-056B-45B2-9028-0794CAC7E410@oracle.com> I'm on vacation this coming week, and I think we can defer any topics to next time. Next meeting: August 11.