Community
Participate
Working Groups
Using HEAD (3.3M3), the following code doesn't compile: [ interface I<E> { } class Y<E> {} public class X<E extends Y<E>> implements I<E> { public static <E extends Y<E>> X<E> bar(X<E> s) { return null; } public static <E extends Y<E>> X<E> bar(I<E> c) { return null; } public static <E extends Y<E>> X<E> foo(X<E> s) { X<E> result = bar(s); return result; } } ] We report: ---------- 1. ERROR in D:\tests_sources\X.java (at line 17) X<E> result = bar(s); ^^^ The method bar(X<E>) is ambiguous for the type X<E> ---------- 1 problem (1 error) javac 1.5.0_09 and 1.6b104 compile it without an error.
The following doesn't compile either: public class Foo { private enum Type { A, B, C } public static void test() { EnumSet<Type> set = EnumSet.allOf(Type.class); EnumSet<Type> set2; set2 = EnumSet.copyOf(set); } }
*** Bug 165074 has been marked as a duplicate of this bug. ***
Released AmbiguousMethodTest#test044, active in R3_2_maintenance branch, inactive in HEAD branch.
Created attachment 54414 [details] Exploratory patch The idea is to rawify only bounds that use type arguments in their definition, in order to stop recursive behaviors. Here, when creating the tiebreak method for <E extends Y<E>> X<E> foo(X<E> p), E would be substituted by Y#RAW (whereas in a concrete case like T extends Y<String> T would still be substituted by Y<String>). Do not release this patch as it is know (privileged speed).
Created attachment 54477 [details] Fix for this bug and bug 165620 + new test case This new patch: - is cleaner than the previous one; - gets the modifications operated to fix 165620; - adds a test for the multi variables case (AmbiguousMethodTest#46). The multi variables case seems to be covered by what the second patch for bug 165620 proposed. Only added a supplementary test.
I don't believe this problem is restricted to static methods, see bug 159711. If we replace test23 with the following, we'll see that instance methods have the same issues as static methods : public void test023() { this.runConformTest( new String[] { "X.java", "import java.util.*;\n" + "public class X {\n" + " public static void staticFoo(Collection<?> p) {\n" + " System.out.print(1);\n" + " }\n" + " public static <T extends List<?>> void staticFoo(T p) {\n" + " System.out.print(2);\n" + " }\n" + " public void foo(Collection<?> p) {\n" + " System.out.print(1);\n" + " }\n" + " public <T extends List<?>> void foo(T p) {\n" + " System.out.print(2);\n" + " }\n" + " public static void main(String[] args) {\n" + " staticFoo(new ArrayList<String>(Arrays.asList(\"\")));\n" + " new X().foo(new ArrayList<String>(Arrays.asList(\"\")));\n" + " }\n" + "}" }, "22"); }
None of the tests included in the latest patch fail if the fix for bug 159711 is removed. Are we on the right track or should we start over with the above test23() ?
We do not have a problem choosing between these 2 methods: void foo(Collection<?> p) {} void foo(List<?> p) {} but we do with these: void foo(Collection<?> p) {} <T extends List<?>> void foo(T p) {} in this case, List#RAW is compatible with Collection<?> but we turn it down in Scope.isAcceptableMethod() because of a hierarchy check (line 2505) that looks odd.
(In reply to comment #8) > We do not have a problem choosing between these 2 methods: > > void foo(Collection<?> p) {} > void foo(List<?> p) {} > > but we do with these: > > void foo(Collection<?> p) {} > <T extends List<?>> void foo(T p) {} > > in this case, List#RAW is compatible with Collection<?> but we turn it down in > Scope.isAcceptableMethod() because of a hierarchy check (line 2505) that looks > odd. > I believe this one is tracked by bug 121024 (not digged into it, but the upper bound for the second method would be Object, which is not a Collection; if so, the suggestion for bug 121024 to keep more information into upper bounds should help).
Released for 3.3 M4 in HEAD stream
(In reply to comment #8) > We do not have a problem choosing between these 2 methods: > > void foo(Collection<?> p) {} > void foo(List<?> p) {} > > but we do with these: > > void foo(Collection<?> p) {} > <T extends List<?>> void foo(T p) {} > > in this case, List#RAW is compatible with Collection<?> but we turn it down in > Scope.isAcceptableMethod() because of a hierarchy check (line 2505) that looks > odd. > The following test case passes (for us and javac): public class X { void foo(Collection<?> p) {} <T extends List<?>> void foo(T p) {} public static void main(String[] args) { List l = null; new X().foo(l); } } interface Collection<T> {} interface List<T> {} Could you please be more specific?
Created attachment 55018 [details] Better patch (thx to kent)
Verified for 3.3M4 with I20061211-1119
*** Bug 168167 has been marked as a duplicate of this bug. ***
