Proposal: Add a type token class for representing generic types

[John Rose]

On Jan 4, 2017, at 2:17 PM, Brian Goetz <Brian.Goetz at Oracle.COM> wrote:
> 
> Now, this isn't a slam-dunk indictment, but its a concern.

This is a special case of source-reflection, and as such shares
the basic design degrees of freedom:  Given a fragment of
source code, the compiler probably has a nice internal AST
for it, but how much of that AST do we want to feed through
to runtime?  Source locations?  Source text?  Internal compiler
data derived and decorated onto the AST (probably not)?
Types?  Which types?  Annotations?  Which?  Etc., etc.

VM type descriptors come in (at least) two forms, and both are
significantly different from source types.

So there's a lot to design here.  I think the prototyping work
should proceed by supporting specific use cases as javac
extensions which generate code via indy (or condy, when we
get that).  We need a fairly representative set of worked examples
of use cases, with prototypes, before we can generalize to answer
the question, "what's in a type token".

Gunnar's use cases appear to rely on existing obscure behavior
of reflecting over inner classes.  That's barely specified, often
surprising, and not a suitable foundation for answering the above
questions.

A better foundation would be a mechanism (forthcoming) for uttering
today's JVM constant pool constants in Java code, such as MH and
MT constants.  That mechanism should be extensible, enough to
support the needed prototypes of (various formulations of) type tokens.

Meanwhile, the Valhalla stuff is likely to be driven by a balanced
set of tradeoffs regarding translation strategy of reified generics
supporting the "any" keyword on type variables.  And also of the
details of value types.  Those requirements almost certainly will
force us to shape yet another type system for the VM, and/or a
moderate extension of the existing type system(s).

HTH
— John