Making Object abstract

[Gernot Neppert]

A lot of thinking has gone into the effort of making Object abstract.
And why is this huge effort undertaken? Because the valhalla-ready Java 
specification is supposed to state that every class implements exactly 
one of either "IdentityObject" or "PrimitiveObject".

I'm wondering: can't we simply relax that requirement to

"Every class implements either IdentityObject or PrimitveObject, except 
for java.lang.Object, which implements none of these".

Yes, java.lang.Object would still be a special-case, but a much less 
painful one.
Using "Object monitor = new Object()"; would continue to work indefinitely.

The implications for compile-time checks would not be affected at all. 
With both proposals:

- a future compile could issue warnings if "synchronized" is used on a 
variable for which it cannot determine that it references an 
IdentityObject.
- likewise for invoking "wait()", "notify()" etc.

Only the *runtime* behaviour would be affected.

Under the current proposal:

- Invoking a "synchronized" statement on an Object not implementing 
"IdentityObject" shall throw a RuntimeException.

With my proposal:

- Invoking a "synchronized" statement on an Object implementing 
"PrimitiveObject" shall throw a RuntimeException.

Also on the plus-side of my propsal: only when you actually ship 
valhalla will you have to offer the method "public static IdentityObject 
newIdentityObject()". There's no need for a migration path.

Am 16.06.2021 um 23:50 schrieb John Rose:
> On Jun 2, 2021, at 7:57 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> A minor bikeshed comment: We're asking users to change their `new Object()` to `IdentityObject.newIdentity()`, and they may ask "why do I have to say 'Identity' twice"?  (And by ask, I mean grumble, because we're already asking them to change their working code.)
>>
>> After a few minutes of thought, I think it might be a better fit to put this at Objects::newIdentity.  The methods in Objects are conveniences that users could write themselves, which this basically is -- there's nothing special about this method, other than having a preferred alternative to `new Object()` which users will understand.  So parking this where the Object conveniences go seems slightly lower friction.
> I think this is OK.
>
> As a stretch move, I think we can even retro-upgrade
> the type checking of Objects::newIdentity with type
> variable trickery, when IdentityObject becomes real.
>
> Please see:
>
> https://bugs.openjdk.java.net/secure/attachment/95170/Foo.java
> https://bugs.openjdk.java.net/browse/JDK-8268919
>
> — John