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.go...@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.  
> 
> 

Reply via email to