Bug 147647 - [1.5][compiler] Illegal compile error: "the method XXX is ambiguous for the type YYY"
Summary: [1.5][compiler] Illegal compile error: "the method XXX is ambiguous for the t...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.3 M3   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 184190 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-06-18 04:29 EDT by Emilian Abadjiev CLA
Modified: 2007-05-03 01:43 EDT (History)
2 users (show)

See Also:


Attachments
Patch + test case (2.18 KB, patch)
2006-09-18 09:19 EDT, Maxime Daniel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Emilian Abadjiev CLA 2006-06-18 04:29:56 EDT
It seems that there is a problem with generic methods that are covariant and the generic type information is erased. I noticed that Eclipse 3.1.2 cannot event compile java code with generic and methods that have covariant return type. The example bellow demonstrates the problem:

public class RootClass<Y extends Object> {

	public static <T extends Object> RootClass<T> make(Class<T> clazz) {
		return new RootClass<T>();
	}

	public static Object makeObject() {
		return null;
	}
}

public class ChildClass<Y extends String> extends RootClass<Y> {

	public static <T extends String> ChildClass<T> make(Class<T> clazz) {
		return new ChildClass<T>();
	}

	public static void main(String[] args) throws Exception {
		ChildClass.make(String.class); // doesn't work in Eclipse 3.1
		ChildClass.make(getClazz()); // doesn't work in Eclipse 3.2
		ChildClass.make(getClazz().newInstance().getClass()); // works in Eclipse 3.2
	}

	public static Class getClazz() {
		return String.class;
	}
	
}
Comment 1 Olivier Thomann CLA 2006-06-18 19:29:05 EDT
Reproduced with HEAD.
Comment 2 Maxime Daniel CLA 2006-09-13 09:45:22 EDT
Added AmbiguousMethodTest#test018-020, amongst which test019 shows the problem (and is disabled).
Comment 3 Maxime Daniel CLA 2006-09-14 04:24:49 EDT
Added tests 21 and 22.

We seem to fail to recognize that static <T extends String> ChildClass<T> make(Class<T> clazz) is the most specific method for the invocation site.
Comment 4 Maxime Daniel CLA 2006-09-18 09:19:06 EDT
Created attachment 50367 [details]
Patch + test case

Suggested patch: do not use the raw method for most specific method determination when the method happens to be static.
Comment 5 Maxime Daniel CLA 2006-09-18 09:41:12 EDT
Kent, would you please review this patch and tell me what you think?
Comment 6 Kent Johnson CLA 2006-09-18 10:01:05 EDT
Why not:

if (pNext.isRaw && !pNext.isStatic())
Comment 7 Maxime Daniel CLA 2006-09-18 11:12:50 EDT
Speed. I merely inlined what you suggest (and simplified the resulting not different into an equal).
I have noticed that we make explicit calls to isStatic() in other places of the same file and I do not like inlining APIs anyway, so I will gladly go for your suggestion if this is OK performance wise.
Comment 8 Maxime Daniel CLA 2006-09-25 07:48:03 EDT
Released for 3.3M3.
Comment 9 Olivier Thomann CLA 2006-10-30 14:02:16 EST
Verified for 3.3 M3 using warm-up build I20061030-0010
Comment 10 Maxime Daniel CLA 2007-05-03 01:43:35 EDT
*** Bug 184190 has been marked as a duplicate of this bug. ***