I’ve read Neal Gafter’s blog on the subject and am still unclear on a number of points.
Why is it not possible to create implementations of the Collections API that preserve type information given the current state of Java, the JVM and existing collections API? Couldn’t these replace the existing implementations in a future version of Java in a way where backwards compatibility is preserved?
As an example:
List<T> list = REIList<T>(T.Class);
Where REIList is something like this:
public REIList<T>() implements List {
private Object o;
private Class klass;
public REIList(Object o) {
this.o = o;
klass = o.getClass();
}
... the rest of the list implementation ...
And the methods use Object o and Class klass to get the type information.
Why would preserving generic class information require language changes rather than just a JVM implementation change?
What am I not understanding?
Advertisement
Answer
The whole point is that reified generics have support in the compiler for preserving type information, whereas type erased generics don’t. AFAIK, the whole point of having type erasure in the first place was to enable backwards compatibility (e.g. lower versioned JVMs could still understand generic classes).
You can explicitly add the type information in the implementation, as you have above, but that requires additional code every time the list is used, and is pretty messy in my opinion. Also, in this case, you still don’t have runtime type checking for all of the list methods unless you add the checks yourself, however reified generics will ensure the runtime types.