Java Generics Unsound?

(quoted with permission)

In my opinion, it is both a bug in the compiler and a result of the design of the language:

Primarily, this is a bug in the compiler. When the erased version of a method overrides another method that is different — they have different signatures! — the compiler should not allow it. Because of the bridge method, which through erasure gets the same signature as
the original method in the superclass and therefore overrides it, delegates to method in the subclass (and performs the required type cast in the process), Java essentially abandons nominal subtyping here and creates a kind of structural subtyping between the methods that were originally unrelated. Structural subtyping doesn’t even exist in Java! (Update: I have realized that it’s not really structural subtyping, but it has its appeal to me. The two methods are forced into a subtyping relationship just because of the way “they fall into place”, and in structural subtyping, one type is a subtype of another if “things just fall into place” right. The Java subtyping has definitely changed, and it appears as if by accident the compiler attempts to do something like structural subtyping — produced by the name clash — and fails).

Via the bridge method, there now is a structural subtyping relationship between the two methods int A.compareTo(Object o) and int
B.compareTo(B b). With structural subtyping, as with any subtyping relation, the parameter types need to be contravariant, and here they clearly are not. B is a subclass of A, so the parameter of B‘s method should be a superclass of the parameter of A‘s method, but the exact opposite is the case.

This is a really interesting problem, because it is not only a bug or an oversight in the compiler, it is not only a problem with the language design and erasure, it completely changes the subtyping relation for Java!

The Java compiler must recognize this result of creating the bridge
method and generate a compiler error, much like in the following example, where return types of the same method foo (and because of the resulting structural subtyping behavior, B‘s methods in Hiromasa’s example is overriding A‘s method!) in two classes in a nominal superclass-subclass, A and B, relationshipare not covariant:

class A{
public Integer foo() { return 0; }
}
class B extends A {
// Error: foo() in B cannot override foo() in A;
// attempting to use incompatible return type
public Object foo() { return null; }
}

Just as much as the compiler should have recognized the result of creating the bridge method, the language design using erasure is at fault. There is no obvious reason except for Java’s method lookup mechanism why Hiromasa’s code should generate a compiler error or a ClassCastException. Under normal circumstances, methods are allowed to
be overloaded, as this example demonstrates:

class A{
public void bar(Object o) {
System.out.println("A");
}
}
class B extends A {
public void bar(B b) {
System.out.println("B");
}
public static void main(String[] argv){
A a = new A(); B b = new B();
a.bar(a); // A
a.bar(b); // A
b.bar(a); // A
b.bar(b); // B
}
}

Erasure has forced Sun to do all sorts of compromises and — as this case demonstrates — create strange corner cases that should work but don’t. Just a few days ago, I discovered that generic classes cannot extend (or rather implement, but the compiler error message says “extend”) Throwable. Java’s erasure makes it impossible to throw generified exceptions! After erasure, it’s not possible anymore to distinguish a MyException<T1> from a MyException<T1>.

I must admit that a couple of years ago, I couldn’t quite understand what was so bad about erasure. First-class genericity is cool, sure, but generics with erasure worked, right? No. I’m finding out more and more often that they don’t.