Community
Participate
Working Groups
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; } }
Reproduced with HEAD.
Added AmbiguousMethodTest#test018-020, amongst which test019 shows the problem (and is disabled).
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.
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.
Kent, would you please review this patch and tell me what you think?
Why not: if (pNext.isRaw && !pNext.isStatic())
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.
Released for 3.3M3.
Verified for 3.3 M3 using warm-up build I20061030-0010
*** Bug 184190 has been marked as a duplicate of this bug. ***