Questions on Template Classes proposal

[Brian Goetz]

Some quick answers…


> Where in the template class file are holes allowed? "almost anywhere in the constant pool”

The constant pool is divided into “segments”, and the holes are a property of the segment.  In the original doc, the constraint was that the holes were the first N constants in the segment.  An alternate way to do this is how M3 did it, where there was a “table of contents” early in the classfile, which enumerated the segments, and identified the holes that go with each.  

Whether a hole is defined by a constant pool entry or an entry in a segment table is largely a “syntax” choice.  

Since each segment is associated with a number of holes, and classes/members are associated with segments, it stands to reason that we need to type-check the relationship between the number and kinds of holes in a segment, and an attempt to specialize the class or method defined in that segment. If I have a segment with two holes of kind “TYPE”, its probably an error to instantiate it with three type parameters, or parameters that are not of kind TYPE.  (Though there may be some need to support mismatches for reasons of compatible evolution.)  


Where we would previously reference a class (Constant_Class, or LFoo; descriptor), we instead need a way to reference a species.  The M3 document showed one way to do this; a ParamType constant, which captures the template name and the parameters.  Then, a species is allowed basically anywhere a class was previously — in descriptor strings, in Constant_Class, as the operand of a new/checkcast/instanceof, as the owner of a Field or Method ref, etc.  
> 
> What about the user mode assumption that: if Foo extends Bar, Foo<Point> is a subclass of Bar<Point>

This is handled by the translation scheme.  If Foo<T> extends Bar<T>, then the superclass of Foo<T> will be Bar<T>. In M3, we’d write this as ParamType[Bar, TypeVar[0//Object]], which means that when Foo is specialized with a real type T, the super type is Bar<T>, and when Foo is specialized with erased, the suer type is erased Bar.  

> Is it the case that a specialization could always have two segments

As the proposal is written, a specialized class would have at least two segments — the “true constants” segment, and the “specialized class” segment.  The intent, though, is that nested generic members (methods, and maybe even inner classes) would have their own segment too.  And segments inherit holes from their parents.  

Note too that compilers often desugar one member into more than one; if a generic method has a lambda in it, that lambda will get its own method, but it should go into the segment for the generic method, not the class.  Then the right things happen automatically.  

Bringing inner classes into a single template may sound like a radical move, but its a powerful one; inner classes share so much with their enclosing class, that being able to inherit holes and constants from the class would result in lots more sharing.  

> Why extend super-interfaces to Constant_Dynamic? When would the BSM be invoked? Is the intent here to allow superinterfaces with holes - couldn't that be handled via a template type species? 

John is looking ahead here to a feature we would like to have.  Suppose I have an interface like Comparable.  And suppose I want to create a Box<T> type, and I want to lift the comparability of T onto Box<T>.  That is, if T is ordered, then I can derive an order on Box<T> from the order on T.  And I would like that to be reflected as a conditional super type.  I might express that in Java code like:

    class Box<T>
        <when T extends Comparable<T>> implements Comparable<Box<T>> { … }

 Having a bootstrap that comes up with the list of supertypes as  function of the type parameters allows such things to be represented.  

> Relationship between: raw type, template class, erased species

There are two questions embedded here: 
 - are the above all types, and if so what is their subtyping relationships, 
 - what is the relationship between the _members_ of these various types

Our working story is that in the VM, there are _class_ and_species_ types.  From a template class, we derive a class type and a mechanism for deriving the species types from their type parameters.  The compiler translates uses of wildcard and raw types as the class.  The Class is a super type of all the species of that template.  

Separately, the compiler ensures (through the translation model) that the _class_ has all the same members as the erased species.  So for any member m in the erased species, call sites / access sites for c.m will link, where c is of the class type.  


> proposal is that the template class is not instantiable

Yes but … 

Old code (and maybe new) will have `new Foo` byptecodes in them; we’d like to redirect these to instantiate the erased species.  

> Request from vm runtime
> in the specialized class file, we need both the name/UTF8 string AND the Constant_Class to have a place to store the passed-in resolved type parameter

Yes, definitely.  M3 sidestepped this as a prototyping move, but we need to meet this head-on, and its a nasty problem.