Bug 294839

Summary:	Eclipse reports name clash error where javac reports none
Product:	[Eclipse Project] JDT	Reporter:	Srikanth Sankaran <srikanth_sankaran>
Component:	Core	Assignee:	Srikanth Sankaran <srikanth_sankaran>
Status:	VERIFIED INVALID	QA Contact:
Severity:	normal
Priority:	P3	CC:	amj87.iitr, jarthana
Version:	3.5
Target Milestone:	3.6 M6
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Srikanth Sankaran

2009-11-11 00:30:30 EST

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)

Comment 1 Srikanth Sankaran

2010-02-22 01:31:41 EST

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.

Comment 2 Ayushman Jain

2010-03-08 04:29:46 EST

Verified for 3.6M6.

Comment 3 Jay Arthanareeswaran

2010-03-08 04:59:33 EST

Verified.