Idea how to implement VT/VO compatibility in JVM

[Vitaly Davidovich]

So yeah, be mindful of compatibility with existing code but please don't
let that dominate the evolution of the language. :) But to this day, I find
it crazy that I write source code with type information available, but then
JVM sees Object (or erased upper bound) and has to have machinery to try
and regain that knowledge for optimization purposes.  Sorry, that was a
digression :).

sent from my phone
On Jan 22, 2015 12:57 PM, "Maurizio Cimadamore" <
maurizio.cimadamore at oracle.com> wrote:

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