Community
Participate
Working Groups
I20041214-2000 I'm not sure whether this is bug - if so, javac suffers from the same problem. import java.util.List; class A<E> { public void x(List<String> s) { } } class B extends A/*raw!*/ { public void x(List<String> s) { } } Error message for B#x(..): "Name clash : The method x(List<String>) of type B has the same erasure as x(List<String>) of type A but does not override it" I did not find anything in the JLS which would prevent B.x(..) from overriding A.x(..).
In I20050811-1530, Eclipse does not issue an error any more (javac 1.5.0_04 still errors). In the class files, B#x(..) overrides A#x(..), but the compiler rejects an @Override annotation on B#x(..), which is inconsistent. It could be that JLS3 §4.8, p. 59 defines this, but I'm not completely sure: "The type of a constructor (§8.8), instance method (§8.8, §9.4), or non-static field (§8.3) M of a raw type C that is not inherited from its superclasses or superinterfaces is the erasure of its type in the generic declaration corresponding to C.". Reading this together with §8.2 (the type of a method is an ordered 3-tuple of argument types, return type, throws clause) would suggest that the inherited method from raw A is: public void x(List s) And this method cannot be overridden by public void x(List<String> s) { } Concluding, I'd say eclipse's current behavior is wrong (but used to be correct at the time I filed the then wrongly accusing bug).
The given example is indeed incorrect and the compiler should raise an error. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6322564
Added MethodVerify test79
Reopen to change resolution
As said in comment 2, comment 0 should fail => close bug as INVALID
