Meeting today: IdentityObject

Remi Forax forax at
Wed May 5 17:50:25 UTC 2021

There is a 3rd way, uses the TypeRestriction attribute to still be binary backward compatible.

Let suppose that we have a way to say that javac needs to use TypeRestriction when generating a specific type in the class file
  import ...

  __restrict__ java.lang.IdentityObject __to__ java.lang.Object;


----- Mail original -----
> De: "Remi Forax" <forax at>
> À: "valhalla-spec-experts" <valhalla-spec-experts at>
> Envoyé: Mercredi 5 Mai 2021 16:39:01
> Objet: Meeting today: IdentityClass

> If it's possible, i would like to discuss about IdentityClass again.
> As noted in the last draft, adding IdentityClass automatically at runtime is not
> a compatible change if tests that uses Class::getInterfaces() are not written
> correctly,
> and sadly, a lot of tests are written that way. I'm guilty to having written
> those tests too.
> I don't believe that the solution is to tweak the reflection because adding
> IdentityClass at runtime is already a hack and introducing a hack² (hack square
> hack) is usually where we should stop before anyone sanity goes under the bus.
> The purpose of IdentityClass is
> - to have a classfile for the javadoc describing the behavior of all identity
> class
> - to be used as type or bound of type parameter.
> Apart the result of Class::getInterfaces() being hardcoded, IdentityClass has to
> other issues, as javadoc container, given that IdentityClass is inserted by the
> VM, it means there is no place in the Java code where someone can click to see
> the javadoc in an IDE, we have the same issue with java.lang.Record currently,
> the class is added by javac automatically and unlike java.lang.Enum, there is
> no method useful on java.lang.Record (equals/hashCode and toString are defined
> directly on the record) so very few of my student where able to understand why
> a record with a NaN value was equals to itself.
> But there is a more serious issue, using IdentityClass is not backward
> compatible with Object.
> When we have introduced IdentityClass, one scenario was to be able to declare
> that the type parameter corresponding to the keys (K) to only support identity
> class.
> This is not possible using IdentityClass because the erasure of K will be
> IdentityClass instead of Object (IdentityClass also appears when the compiler
> will to a lub, so the common class of String and URI will be computed as
> IdentityClass instead of Object leading to source compatibility issues).
> I think at that point, we should go back to our blackboard and see if there is
> no other solution.
> I see two, one is to do *nothing* and do not add a type saying that only
> identity class is a corner case after all,
> the other is to piggyback on erasure not unlike Scala does, i.e. IdentityClass
> is a fake class that is erased to Object at runtime.
> regards,
> Rémi

More information about the valhalla-spec-observers mailing list