EG meeting, 2020-09-09

[Brian Goetz]

> Remi points out that the System class (or, say, Objects) is a place we could put a factory method if we want one but don't want to risk adding it to Object.

Looking at it from the other direction, I am not sure having a nominal 
SimpleIdentityObject class adds much value.  You can of course write a 
do-nothing identity class yourself:

     class WednesdayIdentityClass extends Object { }

Will anyone want to extend SIO?  There's no point, since any concrete 
class that extends Object already becomes an IdentityObject, so they'll 
just extend Object.

Will anyone want to use it as a parameter type / type bound?  I doubt 
it; they'll use IdentityObject.

Will anyone want to use it as a return type?  I don't see much point, 
because there's nothing a SIO can do that Object can't.  The only reason 
we're exposing it is as a replacement for `new Object()`, which we've 
deemed to be an idiom only for getting a unique identity.  If we did 
nothing, people could replace:

     Object lock = new Object();

with

     Object lock = new Object() { };

(and someone would brand it the "identity brace trick".)  But that's a 
little too obscure, so recommending

     Object lock = Objects.newIdentity();

says exactly what you mean.  The precise typestate of the result is an 
implementation detail; the key is that a new identity is dispensed.

> Remi raised another topic: lambda/method ref implementation classes are like value-based classes in that clients shouldn't make assumptions about identity. So they may be relevant to the @ValueBased warnings JEP.

Yes, please.  Despite our best efforts in Lambda, we're already seeing 
whining about "But I depended on the identity of a lambda."