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

Florian Weimer fw at deneb.enyo.de
Thu Mar 5 18:57:31 UTC 2020

* 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

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

More information about the valhalla-dev mailing list