Community
Participate
Working Groups
This is a bug in the type inferrer. It seems to be related to bug #114087. The following code can be compiled by Eclipse 3.2M4: class Foo { static <T, U extends java.util.List<T>> void foo() { return; } } public class EclipseCompilerBug { { Foo.foo(); } } javac complains with the following error: de\ingo_homann\test\EclipseCompilerBug.java:20: incompatible types; inferred type argument(s) java.lang.Object,java.lang.Object do not conform to bounds of type variable(s) T,U found : <T,U>void required: void Foo.foo();
Don't set the target milestone. This indicates in which build the problem is fixed, not in which build the problem occurs.
1. I wonder if this isn't a bug in javac 2. When inferring, we find: <Object,List<T>>, where I would expect: <Object,List<Object>>
15.2.2.8: No expected return type (using assignment conversion). Additional constraint from type variable bounds: List<T> >> U 15.2.2.7: A >> F where A: List<T>, F: U First bullet says, if F = Tj --> Tj <: A is implied (p.457) i.e. U <: List<T> Constraints are resolved, see p.466 (15.2.2.8), and U = glb(List<T>) --> U = List<T> At the end, T remains unresolved; and thus get inferred to be Object. (the spec doesn't explicitly tell about need to substitute U inferred value List<T>, but presumably this is an omission). In the end, it should yield: T = Object, U = List<Object>
In order to notice issue between List<T> and List<Object>, here is a testcase: class Foo { static <T, U extends java.util.List<T>> U foo() { return null; } } public class X { { String s = (String) Foo.foo(); } }
Interestingly, the following variation doesn't seem handled well either by javac (replace List<T> with List<U>): class Foo { static <T, U extends java.util.List<U>> U foo() { return null; } } public class X { { String s = (String) Foo.foo(); } } but this time, it goes further in inference, failing only the bound check in the end; which makes me feel it has holes in this area. Now, our compiler doesn't quite handle this scenario either; yielding U = List<List<U>> which isn't much better. I feel the spec is incomplete when inference brings back types referring to original type variables (List<T> or List<U>). Either these are tolerated providing they are not resolving self references (List<T>) or they are all rejected for simplicity.
Javac and spec bugs got confirmed, they should be: compiler: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369605 spec: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369608
defer post 3.2
Reviving
*** Bug 156765 has been marked as a duplicate of this bug. ***
*** Bug 158531 has been marked as a duplicate of this bug. ***
*** Bug 174447 has been marked as a duplicate of this bug. ***
Regression tests are: GenericTypeTest#test0880-0883
javac 1.7 doesn't report any error. Should not this be closed as NOT_ECLIPSE or INVALID?
(In reply to comment #14) > javac 1.7 doesn't report any error. > Should not this be closed as NOT_ECLIPSE or INVALID? (In reply to comment #6) > Javac and spec bugs got confirmed, they should be: > compiler: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369605 > spec: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6369608 Indeed. javac fixed the compiler bug in 7(b109). Resolving as NOT_ECLIPSE.
Verified for 3.7M5 using I20110124-1800
