[java.lang.fans] - Erasure and Backward Compatibility

[Zhong Yu]

Hi guys. The common justification for erasure is for backward compatibility. This justification is listed in JLS[1], and frequently quoted e.g. [2].

However, I don't understand that justification. It seems to me we can have both reification and raw type. I don't see how adding runtime generic type info would break old non-generic code.

There are still people wanting to add reification in future Java and they are not concerned with this alleged compatability problem.

Can somebody elaborate on this topic a little more? Can you give an actual case where reification could break compatability?

[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.7
[2] http://stackoverflow.com/a/30568821/2158288

Zhong Yu

bayou.io

[Zhong Yu]

The best I can find - 

http://gafter.blogspot.com/2006/11/reified-generics-for-java.html
> Neal Gafter - A hybrid approach is being investigated in which the system records type parameters only when they are available, but I haven't yet seen a workable proposal along these lines.

This is a perfect valid argument within the design team - if someone proposes an approach, it is incumbent on him to present a comprehensive solution, ready to be examined and criticized by others. Apparently such a solution didn't exist (or didn't survive).

However, this is very unsatisfactory to outside observers. It does not sound like a solid argument that erasure is crucial for backward and migration compatibility.

Well, it's all moot now in 2015; but everyday people are popping the question where's the top of the muffin, and the stock answer seems quite vague.

Zhong Yu