I think the question is: "cleaner for whom." The parenthetical remarks
"except for Object" are mostly our mess to corral; "new Object()"
working, even when Object is seen to be abstract, will be extremely
confusing for new developers learning what abstract means. It's not
just that reflection would expose this, but the source code and Javadoc
would to. User mental models are a stakeholder in Object too.
On 5/7/2021 6:06 PM, Dan Smith wrote:
I notice a number of times in current design documents that we state a rule and then have
a parenthetical "except for Object, which is special". A lot of this
specialness is due to Object behaving like an abstract class, even though it is not
abstract.
I think we'd have a cleaner design if we just updated Object to be abstract.
Implications:
- The expression 'new Object()' wouldn't normally be allowed, but we plan to
special-case this anyway to produce an instance of IdentityObject.
- Similarly, a 'new java/lang/Object' instruction would normally cause a
InstantiationError, but we plan to special-case it.
- Reflection would expose the ACC_ABSTRACT flag. <shrug>
- The JVM story for opting in to primitive subclasses would need to work for
class Object just as well as other abstract classes. We can design for that.
- As long as this is a preview feature, we might need two different versions of
Object.class, depending on whether --enable-preview is set. But we need to do
that for Integer, etc., anyway, so should be doable.
Am I missing anything that would be particularly disruptive?
