IdentityObject and InlineObject

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 6 Décembre 2019 22:04:08
> Objet: Re: IdentityObject and InlineObject

>> As we briefly talk last Wednesday, i believe there is a less disruptive way to
>> add IdentityObject in the language.
>> 
>> Let see if we can do better, there are three reasons to have IdentityObject (and
>> InlineObject)
>> - documentation (support for javadoc)
>> - bound for generic type parameter
> 
> (or type for regular parameter)
> 
>> The only way to solve the point 2 is to have a different view at compile time
>> and at runtime.
>> For that,
>> - the compiler should see IdentityObject as a valid super type of every identity
>> classes.
>> - the compiler erase IdentityObject to java.lang.Object (in particular,
>> IdentityObject.newIdentityObject() return type is erased to Object).
> 
> It is tempting to erase IdentityObject to Object, but then:
> 
>    Object o = new Point(0,0);
>    if (o instanceof IdentityObject)
>        sync(o) { … }
> 
> If we erase IdentityObject to Object, then we cannot do the runtime test
> accurately. 

you can:
  Object o = new Point(0,0);
  if (!(o instanceof InlineObject))
    sync((IdentityObject)o) { … }

> 
> Here’s another place where this erasure game is painful:
> 
>    void m(Object o) { … }
>    void m(IdentityObject o) { … }

You see it as painful, i see it as a feature, it means that i can replace Object by IdentityObject and still be binary backward compatible.

And this example is not a good one because introducing overloads that have a subtyping relationship is hard to get right. You may not have the same behavior depending if something is typed as Object or as IdentityObject even if it's the same class at runtime. Not the kind of code you want to use.

> 
> So, reframing:
> - IF we are willing to give up runtime checks and overloading, THEN we can erase
> InlineObject to Object, because the remaining users are merely about things
> like type bounds, which can be checked at compile time and erased.

No, if you willing to remain binary backward compatible with existing code when you introduce IdentityObject, then it should be erased.

> 
> So you are basically asking: how important are these things, and are they worth
> injecting the extra interface?

No, injecting is fun but I value binary backward compatibility more.

Rémi