Idea how to implement VT/VO compatibility in JVM

[Vitaly Davidovich]

I guess my overarching point is this use of ? and coding to erasure,
although works, is just a byproduct of current erasure.  Let's think of it
this way: when java 20 is out, do you want it to still be carrying baggage
and be crippled in some way because it needed to support the language as it
existed < java 9/10? I get backcompat is important and a "feature" of java,
but it would be unfortunate if that keeps the language from evolving to
higher levels.

sent from my phone
On Jan 22, 2015 9:14 AM, "Maurizio Cimadamore" <
maurizio.cimadamore at oracle.com> wrote:

> 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
>>
>
>