Idea how to implement VT/VO compatibility in JVM

Vitaly Davidovich vitalyd at gmail.com
Thu Jan 22 17:46:53 UTC 2015


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


More information about the valhalla-dev mailing list