Community
Participate
Working Groups
3.6M3 Follow up of bug 293615 While working on this bug, I found out several cases where eclipse reports a name clash while javac reports none. In org.eclipse.jdt.core.tests.compiler.regression.MethodVerifyTest test001a(), test001c(), test002a(), test002c(), test003a() are a few of them. In these cases though the difference in behavior seems long standing (going back to at least till 3.4.2) and not a recent regression. See bug# 293615 comment#9 for some background on how eclipse name clash algorithm differs from javac's. The fix for 293615 bridged some of the differences. The current one is raised to address the others. A full fix would involve analysing the bridge/synthetic methods generated for super classes also - something that is complicated by our throwing out synthetic methods in some cases (e.g BinaryTypeBinding)
See that these tests elicit an error message of the form "The type J<T> must implement the inherited abstract method I<A>.foo(A)". Once this missing method's implementation is given, javac 5,6,7 all complain about a name clash very much akin to eclipse. So we can conclude that name clashes are not reported by javac in the presence of other errors and are reported only in cases of classes complete otherwise. So there is no bug here and there is no occasion to change eclipse behavior. Resolving as INVALID.
Verified for 3.6M6.
Verified.