Finding the spirit of L-World

[Brian Goetz]

> class Object { ... }
> class RefObject extends Object { ... }
> class ValObject extends Object { ... }

Let’s talk about this one some more.  There are some obvious practical benefits of bringing these key concepts into the type system.  The first is that talking about ref vs value can be done with tools we already have:

    if (x instanceof RefObject) { synchronized(x) { … } }

    void m(ValObject vo) { … }

    class Foo<T extends ValObject> { … }

rather than inventing new ways to talk about “ref only” or “val only”.  

Another is that ref- or val-specific behavior has an obvious place to live, and can be implemented with tools we already have (e.g., final methods.)  

A third is that all objects are no longer created equally; having the “top types” reflect this will help users learn and understand this.  

A minor benefit is we no longer need an ACC_VALUE flag; we can just trigger off of “extends ValObject”.  


So, what are the costs and risks?  

 - JVMs have to rewrite hierarchies so when a class is loaded that extends Object, it is rewritten to extend RefObject.  
 - Existing code that relies on .getSuperclass() == Object.class might break.  
 - Inheritance hierarchies get one deeper, making searches of superclass chains one longer.  

Any others?