Summary: | [1.5][compiler] Implementation of abstract method is described as "override" | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Victor Toni <victor.toni> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 3.1 | ||
Target Milestone: | 3.1 M7 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Victor Toni
2005-04-06 08:33:23 EDT
Interesting discussion. This warning is intending to flag cases where @Override would be legal to use, but somehow is missing. Even if at some point, methods are overriding abstract methods, you could imagine that at some later stage the abstract methods are removed, and then the @Override annotations would help you finding obsolete code. Also, @Override is added, no compiler is complaining about it being invalid, which validates our current behavior. Thanks for the interesting ;-) Regarding abstract methods it is not sure that the implementation becomes obsolete. This may be only the case if it was used _only_ by the super class. But the proposed behaviour would be different to a class implementing a given interface (aren't methods in interfaces implicit abstract?). The implemented method in the class wouldn't "need" the override and therefore if the interface changes there won't be any hint that a method _may_ be obsolete. Surely the code still works, but I try to code with as much warnings turned on as possible and this was a point where I found it wasn't appropriate. I hear you. When I said obsolete, understand that the assumption it overrides something is now stale. So it could remain, but is no longer mandated per some contract. As I said, if this annotation was made illegal when used at that point, then I would adjust the warning accordingly. My main point is that an "Override" should indicate a possible semantic change for a method. An overriden method may change pre- or post-condition of an already existing method. But the most important point is that in an overriding method one should be able to call super.methodName(); http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#35821 says: A method whose declaration does not indicate how it is implemented must be declared abstract. Other links: http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#30820 http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#78651 I played a bit with different files and think now that there should be a clear separation between declaration and implementation: a) A method declaration in an Interface overriding a method declaration of a super Interface should issue a warning if @Override is missing. b) An abstract method declaration in a Class overriding a method declaration of an implemented Interface should issue a warning if @Override is missing. c) A method implementation in a Class overriding a method implementation of a super Class should issue a warning if @Override is missing. ----------------- a) and b) are currently not implemented |