Idea how to implement VT/VO compatibility in JVM

[Stephen Colebourne]

On 22 January 2015 at 13:26, Stéphane Épardaud <stef at epardaud.fr> wrote:
> You can see that at compile-time I don't have any idea about which value
> types I could encounter, so the only instantiation of `T` I will have is
> `Object`, never `value Date` which may pop up there, and since (unboxed)
> value types don't have any common superclass I can't traverse collections of
> them without knowing at compile-time what type they are. Which is not
> possible for frameworks.

Stephane is making a key point that is critical to the success of
value types as a project. Almost every piece of framework logic that
navigates around an arbitrary object structure will have code that
queries if an object is a Collection/Map and performs specific
processing, for example:
https://github.com/JodaOrg/joda-beans/blob/master/src/main/java/org/joda/beans/ser/SerIteratorFactory.java#L77
https://github.com/JodaOrg/joda-beans/blob/master/src/main/java/org/joda/beans/ser/xml/JodaBeanXmlWriter.java#L176

I'm sure its easy to find other examples in similar projects. Note
that this is a key problem to the Beans v2.0 MetaModel stuff I've been
looking at.

It seems necessary to make List<value> is in some way related to
List<Object>, just like a value can be boxed to an object. Doing so
should take existing libraries that accept Collection<?> and loop over
it, and allow them to accept Collection<value>. It seems to me that
anything else is token backward compatibility, rather than real
backwards compatibility. As indicated in other messages, you don't
always know what T is at compile time.

Stephen