EG meeting, 2020-09-09

[Gernot Neppert]

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

Shouldn't that rather be:

   IdentityObject lock = Objects.newIdentity();

Otherwise you would still get lots of warnings when trying to use the lock
for synchronization.

BTW, I'm still campaigning for java.lang.IdentityAware as the name for the
new interface :)

Am Mi., 9. Sept. 2020 um 20:18 Uhr schrieb Brian Goetz <
brian.goetz at oracle.com>:

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