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."
