RefObject and ValObject

[John Rose]

I think this hangs together very well.

For legacy bytecode (only), the JVM has to be willing to do
these one-time fudges:

- rewrite new java/lang/Object to new java/lang/RefObject
- rewrite invokespecial java/lang/Object.<init>()V to
   invokespecial java/lang/RefObject.<init>()V

The verifier can observe these rewrites, but it may also
take this additional step, for legacy code only:

- widen the type of new java/lang/RefObject to plain Object

(…which would prevent the verifier from passing the
new RefObject to a method that actually takes RefObject.
Not sure that step is useful; it's a "one hand clapping" type
of move, which in practice won't be observable.)

— John

> On Apr 15, 2019, at 8:23 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> 
>> Your idea of treating Object as abstract is, I believe, a sound one (which doesn't need any extra rule) - but we might have to figure out some story for anonymous inner classes of the kind `new Object() { ... }`.
> 
> After thinking about it for all of five minutes, I think this may have broken the logjam (or, at least the current logjam.). We’ve been asking ourselves whether RO/VO are classes or interfaces, when we didn’t really consider abstract classes.  Which we didn’t consider because we had assumed that the concrete-ness of Object was nailed down. Let’s assume it’s not.  
> 
> Then we have:
> 
>     abstract class Object { }
>     abstract class RefObject <: Object { }
>     abstract class ValObject <: Object { }
> 
> Existing classes that extend Object are silently reparented to RefObject, both at compile time and runtime.  This may have some small .getSuperclass() anomalies but this seems pretty minor.  Same with anon classes of Object.  Inline classes implicitly extend ValObject.  
> 
> We add a method `Object::newInstance` (name to be bikeshod later.). We start warning in the compiler on `new Object`, to motivate migration to `Object::newInstance`.  Runtime rewrites these too.  
> 
> There are some minor behavioral compatibility issues here, but they seem pretty minor, and in the end, we end up with a hierarchy that describes the way we want users to see the type system.  
> 
>