Re: Value types - compatibility with existing “value objects”

[John Rose]

On Jan 8, 2015, at 10:09 AM, Paul Benedict <pbenedict at apache.org> wrote:
> 
> Value types are "final" which means it won't be possible to subclass.
> However, I am disappointed with this restriction because I would like to
> use inheritance as an easy way of composing value types. Brian, what are
> your thoughts about this?

To me this sounds like disappointment with physics.  Let me try to explain why.  If we are designing data structures which can be efficiently packed into memory without pointers or headers, then you give stuff up, and pointer polymorphism is one of the things you give up.  It's explicitly called out in the values doc:

> The decision to limit or prohibit subclassing and subtyping of value
> types is necessary to avoid pointer polymorphism.  Abstract super
> types (like the interface `Comparable`) are only considered because
> they cannot be instantiated.

For a discussion of pointer polymorphism (and several other things we are hashing out here) see the section titled "Life without pointers".

It is an interesting design exercise to work out how to add back inheritance into value types, and it can be done (maybe later in Java 11 or 12?), but it is decidedly non-trivial given the design goals of values.  Pointer polymorphism (what inheritance is built from) requires pointers and headers, and those are exactly what we are removing from values.

As a design pattern, you can create fixed-sized values with variable-sized extensions referred to via pointers to normally polymorphic objects (with normal headers). This doesn't need JVM support, and may never.  I think the most interesting answer to "what will I do with values that don't inherit" is to create design patterns in which fixed-sized values delegate variable behavior via their fields.  Maybe the ultimate answer will be, as with inner classes, varargs, and lambdas, to watch how users hand-roll their patterns, and then add tasteful support for common patterns into the source-to-bytecode translation (javac, the JLS).

— John