RFR [lworld] 8239929: Object.newIdentity() replacement for new Object()

[Florian Weimer]

* Roger Riggs:

> Hi Florian,
>
> On 3/5/20 3:25 AM, Florian Weimer wrote:
>> * Roger Riggs:
>>
>>> To keep it simple and localized, the factory method is in the
>>> IdentityObject interface.
>> With this, this does not compile:
>>
>> public class T {
>>      public static void main(String[] args) {
>>          newIdentity();
>>      }
>> }
>>
>> However, at run time, I assume that all instances of T implement the
>> IdentityObject interface.  I find this somewhat jarring.

> In the use case above, it seems kind of a convenient accident to
> make newIdentity() implicitly visible as a method of T. There
> doesn't seem to be any relationship between T and the use of
> newIdentity().

Do you mean invisible at the Java language layer, but visible at the
JVM layer?  (I think the accident goes in the other direction.)

I agree that there isn't any relationship with the use of
newIdentity().  newIdentity() is useful within both inline and
identity classes.

I wouldn't like to see a repeat of array.length, but in the other
direction.

>> Why don't we expose the class?  For example, HashSet has this:
>>
>>      // Dummy value to associate with an Object in the backing Map
>>      private static final Object PRESENT = new Object();

> In the new model, not every "Object" carries identity so its important 
> to be explicit.
>
> There's preference for static factories instead of constructors;
> it provides more flexibility in the way it is implemented.

On the other hand, the constructor conveys that a fresh object is
being created, something that a static method does not necessary do.
And with records, we stuck to constructors, so the movement to
factories is far from universal.

>> Wouldn't be nice to be able to write this instead?
>>
>>      private static final Marker PRESENT = new Marker();
>>
>> To make it explicit that this is an instance of a special class?
>>
>> And maybe add another class for the other common usage, a lock?

> Application specific types for semantically significant instances is a plus.
> Is very easy today to create new types for applications , but they 
> typically don't take the trouble.
> Using 'Object' for all of them is convenient but is kind of sloppy but 
> very convenient.

I think markers are a large enough category that creating a separate
class (Marker) for them should be considered.  The other category is
monitor-style locks.