Model 3 classfile design document

[Brian Goetz]

Having discussed the classfile representation and sketched out some 
plausibility arguments about how the VM can efficiently manage 
specialization, let's step back and look at the consequences for what 
this means for the language (both Java and other languages.)

Type -> Class mapping.  With erased generics, all parameterizations 
Foo<T> map to a single class Foo.  In the Model 3 model, the classfile 
for Foo is essentially a template; we can request parameterizations of 
Foo via the ParamType constant (the Class constant Class[Foo] becomes 
retconned to mean ParamType[Foo, erased].)


Reflection.  In the current prototype, Foo<int> and Foo<String> are 
distinct classes; each will respond with distinct .getClass() results.  
We don't yet have a means to express that Foo<int> and Foo<String> are 
different "species" of Foo; instead each get their own class mirror. 
Reflective operations like Foo<int>.class.getName() currently yield ugly 
results.  Lots of open questions here.


Reification. The question on everyone's mind will be: are we "finally 
getting reified generics"?  And the answer is: sort of.  (This question 
also comes with a lot of baggage; there are a lot of people who assume 
that erasure is somehow "smelly" and therefore bad, and so of course 
reification must be better. But erasure is a pragmatic compromise, and 
the alternative is not always better.  Let's try and leave the baggage 
at the door for now.)

To add to the confusion, not everyone means the same thing by "reified 
generics".  To some, reification means "types are checked at runtime"; 
to others, it may merely mean "types are reflectively available at 
runtime."  Even within the first category, there's a range of what sort 
of type checking we might mean, since the VM type system may not be 
exactly the same type system as the language-level type system -- and 
for good reason.  (What if we ask for a reified ArrayList<? extends 
List<? extends Foo> & Serializable>?  Do we get runtime subtype checking 
for wildcards and intersections every time we try to put something in 
this List?  Would we even want that?  Are we sure such checks are 
decidable?)

In Model 3, specialization is clearly a form of reification; when we 
specialize ArrayList to E=int, the backing store is an int[], and 
therefore we get all the type checking that entails.  We can clearly 
layer additional support for reflectively exposing the bindings of type 
parameters in a number of ways.

The Model 3 classfile design explicitly admits both reified and erased 
generics at the VM level, by allowing a concrete type descriptor *or* 
the 'erased' token as a type parameter to a ParameterizedType.  (Note 
that 'erased' is not a type, it is merely an allowed type 
parameterization -- similar to wildcards in in the Java language.)  
There is nothing in the classfile design that encodes the rule 
"reference parameterizations are erased"; that's the choice of the 
language compiler.  In this way, we can consider any non-erased 
parameterization to be reified; a ParamType[ArrayList, LString] will 
throw ArrayStoreException at runtime if you try to cram something other 
than a String into it.

So, does that mean generics are reified?  Sort of...  For multiple 
reasons (including, but not exclusively compatibility), the current plan 
is for the Java language to continue to use erasure for reference 
parameterizations of generics.  But other languages are free to use full 
reification where it suits them (and if their Java interop requirements 
let them.)  If someone uses reflection to reflect over a List<String> 
and ask for its type parameter, it will come back as "erased" 
(reflection has to support this answer anyway, if only for compatibility 
with legacy code.)


So the punchline is, at the Java language, generics are erased *and* 
reified; generics over references are erased (as they are today) and 
generics over values are reified.  I suspect people will be about as 
jarred by this as they were by erasure in the first place; I expect 
we'll get some degree of "You idiots, you ran 99 yards only to fumble 
the ball on the 1 yard line."  But looking past this (which is mostly 
the above-mentioned baggage), the model seems sound enough; existing 
reference generics work as they always have, and new value generics work 
"better" (in that there are additional things you can do with them.)

In fact, it gives us a chance to be more honest about erasure, because 
"erased" can appear as a first-class member of the programming model.  I 
believe much of the complaints about erasure stem from the fact that it 
is inevitably a surprise when you first discover it.





On 1/22/2016 11:52 AM, Brian Goetz wrote:
> Please find a document here:
>
> http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html 
>
>
> that describes our current thinking for evolving the classfile format 
> to clearly and efficiently represent parametric polymorphism.  The 
> early concepts of this approach were outlined in my talk at JVMLS last 
> year; this represents a refinement of those ideas, and a reasonable 
> "stake in the ground" description of what seems the most sensible way 
> to balance preserving parametric information in the classfile without 
> imposing excessive runtime costs for loading specializations.