Proposal: Access to Generic Type Parameters at Compile-Time

Joseph D. Darcy Joe.Darcy at Sun.COM
Sun Mar 22 22:44:20 PDT 2009

David Walend wrote:
> I've been hesitating to submit this proposal because I have seen so
> few other people push generics as hard as I do. However, the  
> discussion around method and field literals -- and adding type  
> parameters to Field and Method -- may make it more relevant than I  
> first thought.
> My test for reflection APIs is using the API to convert between a  
> class in memory and bytes in a stream. One common corner case is  
> converting  Map<Key,Value>. I often create a simple class for the  
> chore. If Field becomes parameterized, I'll be using  
> Field<Map<Key,Value>> in that class, and will perhaps be creating  
> specialized classes for different Keys and Values. If the Key or Value  
> types take parameters, the generics will be three layers deep.
> Type parameters on methods that return types with their own type  
> parameters invites developers to wade into the depths of layered  
> generics. This proposal addresses one of the associated pain points.
> I've attempted to write a spec section which I hope is clear. I'm not  
> sure it's wrong.
> What do you think?
> Dave
> David Walend
> david at
> ---
> Access to Generic Type Parameters at Compile-Time
> AUTHOR: David Walend
> This feature allows a developer to gain dot access to the type
> parameters of type parameters in classes and interfaces, similar to
> accessing encapsulated fields in the class, but only in source code.
> For example, given Digraph<Node,Edge>, one could declare  
> Subgraph<ContainerGraph extends Digraph> extends  
> Digraph<ContainerGraph.Node,ContainerGraph.Edge>.
> MAJOR ADVANTAGE: This change will simplify the use of layered generics
> and opens the door to richer general purpose code.
> MAJOR BENEFIT: This change transfers the rote work of resolving
> specified types from the developer to the compiler. Given the
> mechanical nature of the task, that is where the work belongs.
> MAJOR DISADVANTAGE: Generics in Java are already complex; the Java
> Generics FAQ is very large. This change will make it slightly longer,
> and require developers to learn one more (relatively intuitive)
> detail.
> 1) Do nothing.
> 2) Full reification, if done well, would provide similar compile-time
> language-level access beyond the type specifiers. (This option is one
> of the case examples of things too large for project coin.)
> 3) Diminish generics' prominent position in Java by removing the
> compile-time warnings.
> 4) Remove generics from Java.
> My examples are directed graph examples from the JDiraph project on
> The semiring (advanced) example was inspired by Cormen,  
> Leiserson and Rivest, 26.4. I show what the code looks like in JDK5  
> first, then with the access to generic type parameters proposed.
> ---
> SIMPLE EXAMPLE: Given interface Digraph<Node,Edge>, define Paths
> through the Digraph, a Digraph representing a probalistic transitions
> in the dialog, and an instance of Path that represents a conversation.
> JDK5 Syntax -- three type specifiers, one of which requires the
> developer to match the first two by hand:
> interface Path<Node,Edge,ThruGraph extends Digraph<Node,Edge>>
>      extends Digraph<Node,Edge>
>      {
>          Node getHead();
>          ...
>      }


When I see a Java type declared to have more than two type parameters my 
initial reaction is usually "this type isn't using the best 
decomposition of the problem space."


More information about the coin-dev mailing list