Idea how to implement VT/VO compatibility in JVM

Thu Jan 22 17:57:11 UTC 2015

This is an old classic:

http://gafter.blogspot.co.uk/2004/09/puzzling-through-erasure-answer.html

Maurizio

On 22/01/15 17:46, Vitaly Davidovich wrote:
> By the way, is it fair to say that one of the main reasons generics were
> implemented with erasure back in Java 5 was also for backcompat reasons? If
> so, here we are many years down the road, with lots more code, patterns,
> familiarity, etc to preserve, where that decision is making it harder to
> evolve the language (and where reification, or at least some form of it, is
> going to be done anyway, but at higher cost now potentially).  Just saying
> :)
>
> On Thu, Jan 22, 2015 at 12:19 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> I hear you Brian, and by no means think I have THE answer.
>>
>> On the other hand, we've seen some impassioned defense of "I want to keep
>>> being able to use List<?> (or raw List)" on this list -- and .NET doesn't
>>> even have an analogue of these types, you have to use generic methods to
>>> abstract over types.  So while one might find the .NET type system
>>> "better", we must acknowledge it doesn't provide Java developers with the
>>> tools they're used to.  (You could argue this is a feature rather than a
>>> bug; in a world with no existing code or developer experience, this might
>>> be true, but that's not the world we're in right now.)
>>
>> I'm not sure "tools they're used to" is all that meaningful, IMHO.  Erased
>> generics were added, no precedent in java prior to that.  Lambdas were
>> added, no precedent to that beforehand.  JMM was revised, no precedent.
>> Fork join added.  Streams added.  Value types will be added.  By
>> definition, things will not always be "what people are used to" unless the
>> language doesn't adapt and progress.  Again, just my opinion of course.
>>
>> And this is the essential tension; a solution that retains compatibility
>>> (not necessarily just with existing code, but people's existing
>>> expectations of how it works) is necessarily going to result in a "worse"
>>> language going forward.  There's no magic solution here (though there are
>>> bad solutions), the art is putting the pain where it is felt least.
>>
>> What does compatibility mean in this particular context? I argue that
>> "code compiles" is a low barrier here -- value types are a completely new
>> concept to java, and calling "old" code that simply took Collection<?> is
>> not necessarily backcompat, for the reasons I mentioned.  Also, as I
>> mentioned above, there's nothing wrong with re-learning things to adjust
>> expectations when new things are added.
>>
>> See, I don't want a "worse" language just to drag along historical
>> artifacts :) The language is going to outlive (if it remains relevant and
>> "refreshed") the vast majority of existing libs/frameworks/etc that are
>> being alluded to in this thread.  I'm not saying java should be evolved
>> recklessly nor carelessly nor ignorant of existing code, but I'd say the
>> bar for "we're going to make the language/type system/compiler/JVM/etc a
>> bit 'worse' for the sake of framework/lib/code Y" has to be very high.
>>
>>
>> On Thu, Jan 22, 2015 at 11:32 AM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>> Thanks Vitaly, explicating how things are done on .NET is highly
>>> constructive, even if we can't just "do what they did."
>>>
>>> On the other hand, we've seen some impassioned defense of "I want to keep
>>> being able to use List<?> (or raw List)" on this list -- and .NET doesn't
>>> even have an analogue of these types, you have to use generic methods to
>>> abstract over types.  So while one might find the .NET type system
>>> "better", we must acknowledge it doesn't provide Java developers with the
>>> tools they're used to.  (You could argue this is a feature rather than a
>>> bug; in a world with no existing code or developer experience, this might
>>> be true, but that's not the world we're in right now.)
>>>
>>> And this is the essential tension; a solution that retains compatibility
>>> (not necessarily just with existing code, but people's existing
>>> expectations of how it works) is necessarily going to result in a "worse"
>>> language going forward.  There's no magic solution here (though there are
>>> bad solutions), the art is putting the pain where it is felt least.
>>>
>>> Anyone who thinks they have "the" answer to this problem obviously
>>> doesn't understand the problem.  So for those trying to contribute: it
>>> would be more helpful if, rather than coming at it from an "I have the
>>> answer" perspective, try something more like "I might have a small piece of
>>> an answer."  Being in such a mental place is far more likely to result in
>>> real contribution!
>>>
>>>
>>> On 1/22/2015 10:11 AM, Vitaly Davidovich wrote:
>>>
>>>> Ok, got you.  It's detected at runtime just like dereferencing a null or
>>>> indexing outside the bounds of an array -- nothing sound about these, but
>>>> java's a safe language so has the safeguards.
>>>>
>>>> By the way, the issue of List<T> not being covariant with List<super of
>>>> T>
>>>> was also a drag sometimes in .NET where you knew you weren't mutating the
>>>> list and only wanted to read the values (which is safe).  So, C# has the
>>>> in/out keywords when you define the generic type (only works on
>>>> interfaces
>>>> and delegates) -- compiler then checks your signatures:
>>>> https://msdn.microsoft.com/en-us/library/dd469487.aspx and
>>>> https://msdn.microsoft.com/en-us/library/dd469484.aspx.
>>>>
>>>> I hate to keep tooting .NET's horn on this list, but I am impressed with
>>>> how they've addressed these various issues.
>>>>
>>>> On Thu, Jan 22, 2015 at 9:46 AM, Stéphane Épardaud <stef at epardaud.fr>
>>>> wrote:
>>>>
>>>>   On 01/22/2015 03:42 PM, Vitaly Davidovich wrote:
>>>>>
>>>>>> Ok can we first agree that List <T> is NOT List <Object>? :) That's
>>>>>> unsound since you can't add any Object in there if things are
>>>>>> reified.  I
>>>>>> think you guys mean List <?>.
>>>>>>
>>>>>>
>>>>>>    Well, that what I meant by "variance issues aside". It is unsound but
>>>>>>
>>>>> detected at runtime. This is already a limitation of List in Java at
>>>>> compile-time, I'm not proposing to fix it.
>>>>>
>>>>>