Community
Participate
Working Groups
The @Override annotation semantics are currently being debated and will likely be refined in upcoming versions of the reference implementation of the compiler. JDT should implement the new semantics as soon as they stabilize. (Opening this bug to anchor test cases in preparation for the changes.)
Created attachment 41553 [details] Test cases: one new, plus some comments changed The proposed changes may include tolerating the following case (entered as - inactive - AnnotationTest#200 in the attached patch): interface I { void foo(); } class X implements I { @Override public void foo() {} } We would probably not mandate such decoration though, since it would make the normal 'class implements interface' coding much heavier. This would hence call for a new definition for the cases in which we complain if the annotation is not present (assuming the current definition is 'could bear @Override but does not'). Marked a few test cases as probably impacted by this bug as well.
One more test case: //https://bugs.eclipse.org/bugs/show_bug.cgi?id=141931 // variant of test200 public void _test201() { this.runConformTest( new String[] { "I.java", "public interface I {\n" + " void foo();\n" + "}\n", "X.java", "abstract class X implements I {\n" + "}\n", "X.java", "class Y extends X {\n" + " @Override\n" + " public void foo() {}\n" + "}\n", }, ""); }
adopting
Created attachment 52296 [details] Proposed patch Patch for 3.3
Released for 3.3M3 (HEAD) Should backport fix to 3.2.2, since mandated for compliance 1.6. In 3.2.x should avoid changing error catalog as done in 3.3 stream (superclass message should thus be reused, no addition on IProblem). Maxime - pls backport fix. Also should enter a FUP bug for 3.3, so as to add complementary option for missing @Override diagnosis, so as to also suggest missing @Override when implementing interface methods as well (when source 1.6 only), suboption would be off by default.
Reopening for addressing in 3.2.2 stream. Maxime - pls also release your test changes. I did add AnnotationTest#test214, with some variations of your original testcase in comment 1 only.
Released AnnotationTest#215 in HEAD to account for the case reported in comment #2. Other significant test changes have already been released in HEAD. Now needs to backport.
Created attachment 52323 [details] Backport to 3.2.2 (fix plus test cases)
Released for 3.2.2.
New behavior is only available in 1.6 mode.
Verified for 3.3 M3 using build I20061030-0010
This change has caused bug 163192. I'm not sure how stable problemIDs are in general, but this should maybe be added to the build notes or the API changes document.
In 1.6, a new problem got introduced since the compiler error message must differ (to mention supertypes in general, vs. only superclass in the past). Maybe the quickfix implementation needs to check for all supertypes as wel... ? +1 for better documenting this in build notes.
Maxime - pls make sure our build notes reflect this change in proper What's new section.
Tuned a bit David's contribution to the N&N of HEAD (thx David) then impacted 3.2 maintenance as well.
verified for 3.2.2 using build M20070112-1200
