RefObject and ValObject

[Brian Goetz]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20190415/4cf16865/attachment-0001.html>