Bug 72704 - [compiler][1.5] unexpected IBindings and class files with conflicting method argument types
Summary: [compiler][1.5] unexpected IBindings and class files with conflicting method ...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M6   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-26 13:35 EDT by Markus Keller CLA
Modified: 2005-03-31 06:53 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2004-08-26 13:35:51 EDT
I200408241200

public class Main {
	public static void main(String[] args) {
		new C<Double,Integer>().foo(new Integer(1)); //1
		new C<Double,Integer>().foo(new Double(2));  //2
		new C<Number,Number>().foo(new Integer(3));  //3
	}
}

class B <Tb> {
	void foo(Tb b) {
		System.out.println("B: "+b);
	} 
}

class C <Tb, Tc> extends B<Tb> {
	void foo(Tc c) {
		System.out.println("C: "+c);
	}
}

Running Main produces C: 1, C: 2.0, C: 3.
Hovering over foo(..) at //2 shows "void inherit.B<Tb>.foo(Tb b)".
The ASTView says that the method binding at line //2 is "B<Double>.foo(Double)".
Is this OK since the (erased) C#foo(..) overrides B#foo(..) at run time, but not
at compile time? I'm not really sure here - this would be very C++ish ;-(

However, I think //3 should raise an "ambiguous method invocation" error, since
none of the foo(..) methods is "most specific" in this case.


BTW: Sun's javac 1.5.0-beta3-b62 says:

reference to foo is ambiguous, both method foo(Tb) in
inherit.B<java.lang.Number> and method foo(Tc) in
inherit.C<java.lang.Number,java.lang.Number> match
		new C<Number,Number>().foo(new Integer(3));  //3
                ^

... and after removing the offending third call to foo:

name clash: foo(Tc) in inherit.C<Tb,Tc> and foo(Tb) in inherit.B<Tb> have the
same erasure, yet neither overrides the other
class C <Tb, Tc> extends B<Tb> {
^
Comment 1 Philipe Mulet CLA 2005-02-08 10:17:10 EST
We now issue the nameclash issue correctly.
Kent - pls double check and add regression test.
Comment 2 Kent Johnson CLA 2005-02-08 10:50:22 EST
We correctly generate the name clash but we don't detect the ambiguous error 
(yet).
Comment 3 Kent Johnson CLA 2005-02-16 12:54:37 EST
I cannot see why the 2 methods would be ambiguous... the name clash, which we 
do generate, I can understand but not the ambiguous error.

Can anyone create a testcase with only the ambiguous error?

I've tried to but have yet to do it.
Comment 4 Markus Keller CLA 2005-02-16 13:33:20 EST
Change "class C <Tb, Tc>" to "class C <Tb, Tc extends Number>".

This new C has methods
- foo(Tb), with erasure foo(Object)
- foo(Tc), with erasure foo(Number)
-> they don't clash any more.

Now, with the instantiation new C<Number, Number>(), Tb and Tc become equal at
the  method invocation //3, and the compiler cannot know which foo is meant.
Note that the two foos don't override, since their erasures are different.
Comment 5 Kent Johnson CLA 2005-02-16 13:48:36 EST
thx
Comment 6 Kent Johnson CLA 2005-02-21 15:39:25 EST
Added MethodVerify test043
Comment 7 David Audel CLA 2005-03-31 06:53:51 EST
Verified in I20050330-0500