Hi Brian, really nice write-up. I've not a lot to say apart about IdentityObject and InlineObject because I fully agree on the major points (and i've promised to not tak about == but wait and see instead). 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 - class at runtime for instanceof The main drawbacks of Brian's proposal are: - IdentityObject needs to be injected dynamically by the VM. - replacing occurrences of Object by IdentityObject (in IdentityHashMap by example) is not a binary backward compatible change. - new Object() needs to be deprecated (for removal?) and replaced by IdentityObject.newIdentityObject. 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). - synchronized emit a warning if the the argument is not typed as an IdentityObject. If IdentityObject is erased to Object, - IdentityObject.java exists as support for documentation. - it doesn't need to be injected dynamically by the VM anymore - because IdentityObject is still present in the generic signature, it can be used as bound of generic type parameter - replacing some occurrences of Object by IdentityObject is backward compatible - IdentityObject can not be used in instanceof or cast, but the compiler can suggest to use if (!(o instanceof InlineObject)) instead. I believe this solution is less disruptive and provide a better way to introduce IdentityObject and InlineObject in a backward compatible way. regards, Rémi
