Object as a concrete class

[Dan Heidinga]

On Fri, Apr 1, 2022 at 9:29 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
> > 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.
>

The alternative - which we've been exploring till now - is to have the
VM do some magic to turn:

0: new  #2                  // class java/lang/Object
3: dup
4: invokespecial #1    // Method java/lang/Object."<init>":()V

into the `new` of a VM-specified Object subclass, and to allow
invoking a super-class constructor on it rather than its own
(remember, the instance is an Object subclass).

That's a lot of magic we can do away with through specification and
some careful API design.  Seems like a win.

The careful API design will be key as I can see a lot of corner cases
related to `obj.getClass().isIdentityClass() != obj.hasIdentity()`.
Do we have a sketch of what the apis for this would look like?  I'm
assuming these are just for expository purposes as isIdentityClass()
really needs to return a trinary value - {true, false, maybe}.

--Dan