Idea how to implement VT/VO compatibility in JVM

Maurizio Cimadamore maurizio.cimadamore at
Thu Jan 22 14:14:13 UTC 2015

I think both Stephane (and you) and Vitaly have a point; such dynamic 
frameworks have two alternatives:

* keep working the way they do now - which implies List<val T> is 
related to List<?>/List
* let them be generified, and then use reflection (on steroids) to let 
the right thing happen at runtime


On 22/01/15 13:58, Stephen Colebourne wrote:
> On 22 January 2015 at 13:26, Stéphane Épardaud <stef at> 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:
> 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

More information about the valhalla-dev mailing list