Bugzilla – Full Text Bug Listing
| Summary: | computation of inherited methods seems damaged (affecting @Overrides) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Andrew Clement <aclement> | ||||
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, jarthana, manoj.palat, srikanth_sankaran, stephan.herrmann | ||||
| Version: | 4.3 | ||||||
| Target Milestone: | 4.3 M7 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 230308 [details]
Patch containing test and minimal fix
This patch also passes RunJDTCoreTests too.
Thanks for the report, "perfect timing", I just released the back ported version of some of those changes to Kepler M7 (bug 395681). I'll give it a quick check if this fix should also go into Kepler... Yep, Kepler is also affected. I have an even simpler fix under test. While re-running RunJDTCoreTests I have the time to document what happened: in bug 395681 (and bug 388739 for BETA_JAVA8) I implemented a new strategy for collecting a type's super interfaces. As a seed we have the method arguments 'superclass' and 'superInterfaces'. For that traversal I simply forgot to travel the chain of super classes of 'superclass', too. As a result the analysis for TestPointcut couldn't see the super interfaces reachable via the indirect super class StaticMethodMatcher. Andy, the location where you made your changes hits the nail on the head. Jay: I believe this fix is necessary for M7, too. Any objections? The fix is as simple as wrapping one method call in a loop over super classes. From the currently running tests I believe the impact is in the range of reverting 2 or 3 test changes from bug 395681. I'll explain once I know better. OK, after a successful test run, I can report that the only test adjustments needed along with the fix are basically reverting the changes in GenericTypeTest.test0987() f. which are described in bug 388739 comment 1. Since this revert makes ECJ behaviour again 'more similar' to javac, this actually is a good thing, in a way. Test & fix released for 4.3 M7 via commit 97c93635fd2becc366b6b7ff4296a9b379902c15 Andy, please see that I modified also the test: instead of forcing compliance to 1.6 we simply return when called at compliance < 1.6 (as all these tests are called at different compliance levels anyway). Verified for 4.3 M7 Build id: I20130501-2000 |
Not strictly a Java8 bug but it is a problem on BETA_JAVA8. Testcase (I had this in MethodVerifyTest): Map compilerOptions16 = getCompilerOptions(); compilerOptions16.put(JavaCore.COMPILER_CODEGEN_TARGET_PLATFORM, CompilerOptions.VERSION_1_6); compilerOptions16.put(JavaCore.COMPILER_COMPLIANCE, JavaCore.VERSION_1_6); compilerOptions16.put(JavaCore.COMPILER_SOURCE, JavaCore.VERSION_1_6); this.runConformTest( new String[] { "TestPointcut.java", "interface MethodMatcher {\n"+ " boolean matches();\n"+ "}\n"+ "abstract class StaticMethodMatcher implements MethodMatcher { }\n"+ "abstract class StaticMethodMatcherPointcut extends StaticMethodMatcher { }\n"+ "\n"+ "class TestPointcut extends StaticMethodMatcherPointcut {\n"+ " @Override\n"+ " public boolean matches() { return false; } \n"+ "}\n" }, "", null, true, null, compilerOptions16, null); That code should not produce a warning for @Override but it does. It looks like some refactoring was done in MethodVerifier.computeInheritedMethods() in BETA_JAVA8 and the algorithm that collects up the super interfaces fails to collect 'MethodMatcher' in the above example (i.e. an interface on the superclass of the superclass of the class we are interested in). Without knowing about that interface the @Overrides looks like an error. I'll attach a patch in a moment containing the test and my fix (you may choose to fix it differently...).