Idea how to implement VT/VO compatibility in JVM
brian.goetz at oracle.com
Thu Jan 22 16:32:31 UTC 2015
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
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
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
> 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.
More information about the valhalla-dev