Bug 354229

Summary:	[compiler][1.7] Name clash error not being reported by ecj.
Product:	[Eclipse Project] JDT	Reporter:	Satyam Kandula <satyam.kandula>
Component:	Core	Assignee:	Srikanth Sankaran <srikanth_sankaran>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jarthana, srikanth_sankaran
Version:	3.8
Target Milestone:	3.8 M5
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Satyam Kandula

2011-08-09 06:17:14 EDT

This is a FUP of bug 353089. It is a slight modification of the test given there. 
###
import java.util.*;

interface A {
int get(List<String> l);
}

interface B  {
int get(List<Integer> l);
}

interface C  extends A, B { 
//int get(List l);      // name clash error here
}
#########
Here, javac7 reports error, but javac5, javac6 and ecj doesn't. 

According to Srikanth, this is probably not a bug, because any class that implements C, could override 'get' with a raw type 'List'.

Comment 1 Srikanth Sankaran

2011-12-19 04:00:27 EST

Here is another example which we compile alright and which javac7 doesn't:


interface X {
	<T> T e(Action<T> p);
}
interface Y {
	<S, T> S e(Action<S> t);
}
interface E extends X, Y {
	
}

class Action<T> {
	
}

Per 8.4.2, this should not compile, since the two methods don't have the
same signature, neither is a subsignature of another and so they are not
override equivalent. But their erasure is the same and so should lead
to a name clash error, but doesn't.

Comment 2 Srikanth Sankaran

2011-12-19 04:01:52 EST

See that we complain for:


interface X {
	<T> T e(Action<T> p);
	<S, T> S e(Action<S> t);
}

Comment 3 Srikanth Sankaran

2012-01-03 07:11:53 EST

(In reply to comment #0)

> According to Srikanth, this is probably not a bug, because any class that
> implements C, could override 'get' with a raw type 'List'.

That is true, however, JSR335 EDR makes a point about this exact same
scenario and makes a persuasive case that this should be an error the
reasoning being generics aware code should not encourage use of raw types.

Comment 4 Srikanth Sankaran

2012-01-05 04:19:10 EST

Fix and tests released via commit id: c36a6a2b662267e56067d121b7f34ae48cbcb692.

(In reply to comment #0)

> Here, javac7 reports error, but javac5, javac6 and ecj doesn't. 

Accordingly, we now report an error only for compliance level >= 7.

Comment 5 Jay Arthanareeswaran

2012-01-23 05:07:48 EST

Verified for 3.8M5 using I20120122-2000

A question: The code specified in comment #2 still produces error in 1.5 and 1.6 compliance level. Is it because the JSR335 you were referring to doesn't include this case? The behavior is in line with Javac, though.

Comment 6 Srikanth Sankaran

2012-01-23 05:14:34 EST

(In reply to comment #5)
> Verified for 3.8M5 using I20120122-2000
> 
> A question: The code specified in comment #2 still produces error in 1.5 and
> 1.6 compliance level. Is it because the JSR335 you were referring to doesn't
> include this case? The behavior is in line with Javac, though.

JSR 335 is futuristic (JDK8 plan item) and its reference is incidental
here. i.e the code does not become legal/illegal on account of this JSR.
I happened to mention only because, in the spec, there is a passing
reference to some of the test cases in this bug (nearly identical ones).
to develop some of the theme items of the JSR.

Historically we have tried to maintain compatibility as also in
this case. That should explain how the pre-existing behavior in
comment#2 came about.

Comment 7 Stephan Herrmann

2013-03-10 14:41:47 EDT

*** Bug 348377 has been marked as a duplicate of this bug. ***