Summary: | [1.5][compiler] Unoptimal lub computation | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Philipe Mulet <philippe_mulet> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | markus.kell.r |
Version: | 3.1 | ||
Target Milestone: | 3.1.1 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Philipe Mulet
2005-08-13 09:39:15 EDT
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. |