IdentityObject and InlineObject

[Remi Forax]

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