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