Static fields in specialized classes

[Brian Goetz]

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