Community
Participate
Working Groups
Consider the code in the attached test and the comments therein. The first column of the table lists the 'combine' variants enabled (the others are supposed to be commented out), the second and third columns the outcome of the compiler invocation and the fourth one a possible workaround in the form of a modification of the call to 'combine' in the test method. The case of the lone #3 is a failure of inference since it can be be cured by a cast: both javac and ecj infer OO<String,Object> and complain, even though it is glaringly obvious that this is also (by inheritance) a TO<String> and therefore acceptable. In all the other cases the ecj error is: --------------------------------------------------------------------- 1. ERROR in Bug5.java (at line 32) put(Integer.class, combine(FUNC2, FUNC1)); ^^^^^^^ The method combine(Bug5.TT, Bug5.TO<? super Object>) is ambiguous for the type Bug5 --------------------------------------------------------------------- which I am not sure what to make of but looks like a failure to resolve overloaded methods. Intuitively I would say that there is no problem here since #1 is more specialized than #2, which itself is more specialized than #3 and thus the lower-ranked one should be picked and there is no ambiguity. Moreover it seems to me that there is a contradiction in the case of #1+#3: since ecj considers #3 inapplicable, that leaves it with #1 alone and thus you would think there is no ambiguity.
Created attachment 87961 [details] The test case
Simplified testcase which should compile: interface OO<T,E> {} interface TO<T> extends OO<String,T> {} interface TT extends TO<String> {} public class X { <E, T> TO<T> combine(final TO<? super E> x, final OO<E, T>[] y) { return null; } void foo(TT tt, TO<? super Object>[] too) { combine(tt, too); } }
Added GenericTypeTest#test1269-1283
Created attachment 88422 [details] Proposed patch There were 2 issues. 1. Tiebreak algorithm miscomputed intersection types, where no intersection was mandated in the end. This was fooling type argument containment check. 2. Type argument containment (4.5.1.1) did not allow: ? super Object <= Object (not described in the spec, but makes sense)
Released for 3.4M5. Fixed
Verified for 3.4M5 using build I20080204-0010
Released fix in 3.3.x maintenance branch (post 3.3.2)
