Idea how to implement VT/VO compatibility in JVM
Brian Goetz
brian.goetz at oracle.com
Thu Jan 22 18:33:46 UTC 2015
Short answer: yes. (Some of the reasoning for this is reconstructed in
the latest State of the Specialization.)
The key requirement was, and continues to be: gradual migration
compatibility. This has multiple facets:
- It should be practical to generify an existing class (within
reason), rather than throwing it out and starting over
- It should be practical to generify libraries gradually, for example
generifying a superclass separately from a subclass
- Generification of libraries and their clients must not require a
"flag day". It should be possible to generify the library first and
generify the client later (or not).
We have the same requirement now; existing generic classes should be
extendable to any-fied generics, it should not be necessary to any-fy
libraries all at once (though they do have to be any-fied top-down), and
-- most importantly -- existing client code must continue to work
against any-fied libraries.
What is meant by "continue to work" can be subtle, though. For example,
some have balked at the idea that List<?> would continue to mean List<?
extends Object> -- as it always has meant -- is not "continuing to
work", because it's not "what the user thought they meant when they
wrote it ten years ago."
But, yes, the requirement in 5 were centered around gradual migration
compatibility from non-generic to generic; we have the same requirements
when migrating from generic to "any-generic".
On 1/22/2015 12:46 PM, 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
> <mailto: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 <mailto: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
> <https://msdn.microsoft.com/en-us/library/dd469487.aspx> and
> https://msdn.microsoft.com/en-__us/library/dd469484.aspx
> <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 <mailto: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