Static fields in specialized classes
Brian Goetz
brian.goetz at oracle.com
Tue Oct 14 01:21:39 UTC 2014
I think you're making some assumptions about the goals here which are
not accurate. You talk about "reification" like we're going to drop
existing generics and adopt something like what C# did. That's not
what's going on.
(The elephant analogy is apt, since it seems that everyone has their own
idea of what reified generics means... :)
So, to be clear, reified generics isn't the primary goal here. (It so
happens that specialized generics *are* reified, but that's a
side-effect of the implementation strategy rather than the goal, and
actually a semi-problematic one at that.)
On 10/13/2014 7:04 PM, Vitaly Davidovich wrote:
> The issue is that since java doesn't reify generics, users know that
> there's just one type.
No, there's many types, there's one *class*. The Java language has a
type system, and the VM has a type system, and they're different.
Under specialized generics, there is one class for all reference types
(same game as before), and one specialization for each primitive/value
instantiation. (This is not unlike what C# does under the hood; it
compiles one set of native code for erased references, and one set per
unique struct instantiation.)
> My argument is that if there's reification, then
> generic classes take on a different meaning (to me)
There's nothing wrong with this argument if you were starting from a
blank sheet of paper. You could define things to work however you want.
But that's not what we're doing here; we're doing that in the context
of Java having had erased generics for ten years (and people only
recently wrapping their heads around how generics work.) We're not
going to pull the rug out from under users like that.
(Remember, even if we did try to do some sort of full blown reification,
we'd *still* have to deal with erasure, as old classfiles that
instantiate erased instances would have to keep working.)
More information about the valhalla-dev
mailing list