Idea how to implement VT/VO compatibility in JVM

[Vitaly Davidovich]

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