Idea how to implement VT/VO compatibility in JVM

Maurizio Cimadamore maurizio.cimadamore at oracle.com
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

Maurizio

On 22/01/15 13:58, Stephen Colebourne wrote:
> 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



More information about the valhalla-dev mailing list