Idea how to implement VT/VO compatibility in JVM

Vitaly Davidovich vitalyd at
Thu Jan 22 14:05:52 UTC 2015

But List<value> is not and cannot be List<Object> - I'm guessing you mean

sent from my phone
On Jan 22, 2015 8:59 AM, "Stephen Colebourne" <scolebourne at> 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