assert new Object().hasIdentity(); assert !new Point().hasIdentity(); But the 'hasIdentity' method can contain arbitrary logic, and doesn't necessarily need to correlate with 'getClass().isIdentityClass()'.
More precisely, we were being held hostage to the nature of interfaces; by using `implements IdentityObject` as our measure of id-ness, we forced legacy Object instances to be instances of some other class, so that Object didn't need to implement the interface.
I don't see a useful way to generalize this to other "both kinds" classes (for example, any class with an instance field must be an identity class or a value class). But since we have to make special allowances for Object one way or another, it does seem plausible that we let 'new Object()' continue to create direct instances of class Object, and then specify the following special rules: - All concrete, non-value classes are implicitly identity classes *except for Object* - The 'new' bytecode is allowed to be used with concrete identity classes *and class Object* - Identity objects include instances of identity classes, arrays, *and instances of Object*; 'hasIdentity' reflects this - [anything else?] There's some extra complexity here, but balanced against the cost of making every Java programmer adjust their model of what 'new Object()' means, and corresponding coding style refactorings, it seems like a win. Thoughts?
Seems like a win.
