Summary: | [1.5][compiler] Name clash when extending a raw superclass and overriding a method with parameterized type as parameter type | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
Component: | Core | Assignee: | Kent Johnson <kent_johnson> |
Status: | VERIFIED INVALID | QA Contact: | |
Severity: | minor | ||
Priority: | P3 | CC: | martinae |
Version: | 3.1 | ||
Target Milestone: | 3.2 M6 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Markus Keller
2004-12-15 11:39:09 EST
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 |