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