In a recent blog post, Reified Generics for Java, Neal Gafter describes the limitations of the current, erasure-based generics implementation in Java:

Generics are implemented using erasure, in which generic type parameters are simply removed at runtime. That doesn't render generics useless, because you get typechecking at compile-time based on the generic type parameters, and also because the compiler inserts casts in the code (so that you don't have to) based on the type parameters...

For a type parameter T, you can't write a class literal T.class. You can't use instanceof to test if an object is of type T. And you can't create an array of T...

But it gets worse. You also can't write class literals for generic types like List<String>.class, or test if an object is an instanceof List<String>, or create an array of List<String>. The implementation of generics using erasure also causes Java to have unchecked operations, which are operations that would normally check something at runtime but can't do so because not enough information is available. For example, a cast to the type List<String> is an unchecked cast, because the generated code checks that the object is a List but doesn't check whether it is the right kind of list.

Gafter explains that the reason generics were implemented this way had to do with the need to preserve backward compatibility with existing code that did not use generics. He then proposes two ways to add reified generics to Java:

It isn't too late to add reified generics to Java. There are two basic approaches. The first uses the language as it exists today but adds the generic type information at runtime. In the ideal world, we wait until every bit of Java code in the world has been modified to use generics safely, and then go through a transition in which we start recording type parameters at runtime by using a new javac and VM. There are two main difficulties with this approach. First, it is not compatible... The second problem is more insidious: lots of existing code uses generics but uses them in an unsafe way. For example, I have seen code that creates an ArrayList<Object>, but later casts it to a List<String> where the author knows that it only contains objects of type String. I would not be surprised to find such code in the JDK. Such code must fail at runtime when generics are reified, so some existing (but working) code would be broken...

The other approach modifies the language so that the declaration of a generic parameter distinguishes reified type parameters from erased ones. It is a pure extension of the language. The existing syntax for generics would continue to designate generics by type erasure, but a newly introduced syntax would be used to declare reified type parameters...

With the latter approach, Gafter envisions a new, reified implementation of collections. New code could reference the reified collection implementation, while old code using the erasure-based implementation would not break.

What do you think of Gafter's proposal?

class MiracleBuilder<T> {

   private Class mClass;

   public MiracleBuilder(Class clazz) { mClass = class; }

   public T buildFromIntegers(Integer[] ints) {
      Class[] argClass = new Class[ints.length];
      for (int i=0; i<argClass.length; i++)
         argClass[i] = Integer.class; 

      return mClass.getConstructor(argClass).newInstance(ints);
    }

}