One of our requirements has been that 'new Object()' must be re-interpreted (both at compile time and run time) to instantiate some other class—Object is effectively abstract. The motivation here is that every class instance must be identified as an identity object or a value object, and the mechanism for that is the corresponding class declaration. But if 'Object' were an identity class, then no value class could extend it.
That is, this code needs to work: assert new Object() instanceof IdentityObject; assert new Point(1,2) instanceof ValueObject; *However*, as Remi was eager to pursue awhile ago, in a world in which class modifiers, not superinterfaces, convey the identity/value distinction, we're no longer so closely tied to class declarations, and it becomes easier to make Object a special case. This code still needs to work: 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()'. So we could have a world in which some objects are instances of a concrete class that is neither an identity class nor a value class, but where those objects are still identity objects. 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?
