Community
Participate
Working Groups
Head from 8/11/2005 With fix for bug 105531 released, the following code now gets rejected: public class X { static <T> T foo(T t1, T t2) { return t1; } public static void main(String[] args) { Number[] n = {}, n2, n3; Float[] f = {}; Number n2 = foo(n, f); } }
Fix for 105531 only affects the following situation: public class X { static <T> T foo(T t1, T t2) { return t1; } public static void main(String[] args) { Number[] n = {}, n2, n3; Float[] f = {}; Number n3 = n != null ? n : f; } } Since plain lub algorithm is used to infer the type of the conditional expression (as used to interesect Number[] and Float[] for generic method inference). So this is wrong since 3.1.0, but revealed for conditional expression with fix for bug 105531.
When writing following code: public class X { static <T> T foo(T t1, T t2) { return t1; } public static void main(String[] args) { Number[] n = {}; Float[] f = {}; String s = foo(n, f); } } Eclipse complains: ---------- 4. ERROR in X.java (at line 10) String s = foo(n, f); ^ Type mismatch: cannot convert from Object&Serializable&Cloneable to String ---------- where javac claims: X.java:10: incompatible types found : java.lang.Number[] required: java.lang.String String s = foo(n, f); Indeed when computing lub(Number[], Float[]), it should infer Number[] rather than Object$Serializable&Cloneable
Improved LUB computation to handle reference array type, considering all supertypes of an array type. Added GenericTypeTest#test805. Fixed
*** Bug 107193 has been marked as a duplicate of this bug. ***
Verified in I20050921-0010 for 3.2M2
Verified for 3.1.1 using M20050923-1430.
