This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I don't know why Mark Reinhold showed this example while he was talking about type reification (see the photo: the title of the slide is "Language Futures: Reification").
Type erasure was an unfortunate idea that made it into Java, only because raw types needed to be supported for backward compatibility. Type erasure has lead to a number of warts, like the impossibility of creating arrays of a concrete parameterized type. Other languages, Scala for example, are also bothered by type erasure; in Scala there is an ugly workaround (manifests) to get generic type information at runtime.
In my opinion, generics should never have been implemented with type erasure - and now it is much harder to add type reification to Java because everything has to stay backward compatible. It would be nice if we could get rid of type erasure in Java and the JVM, but it's not going to be easy.
I fully agree on type erasure. Without it, it would (probably) even be possible to instantiate instances and arrays (new T anyone?) of generic types. I even made up a syntax for the first:
In this example, Integer can only be used with doSomething1 and doSomething3. It misses the constructors required for doSomething2 and doSomething4 and therefore cannot be used there.