Community
Participate
Working Groups
The following code is accepted by Eclipse (3.2 M1 - I20050808-2000): public class X { <T extends Runnable, U extends T & Runnable> T foo() { return null; } } Whereas javac rejects it: javac 1.5.0_04-ea X.java:4: a type variable may not be followed by other bounds <T extends Runnable, U extends T & Runnable> T foo() { return null; } ^ 1 error
The spec has no such restriction. Suspecting a bug in javac.
Added GenericTypeTest#test852
The JLS allows this scenario
*** Bug 113070 has been marked as a duplicate of this bug. ***
Reopening. The spec actually explicitly rejects it, see section 4.4. [...] Type variables have an optional bound, T & I1 ... In. The bound consists of either a type variable, or a class or interface type T possibly followed by further interface types I1 , ..., In. [...]
Added proper check when connecting type variables. Fixed. Tuned test suites, and added GenericTypeTest#test857.
The spec says bound looks like: (TypeVariable) | ((Class|Interface) (& Interface)*)
*** Bug 104109 has been marked as a duplicate of this bug. ***
*** Bug 99983 has been marked as a duplicate of this bug. ***
Backported to 3.1 maintenance stream.
Verified for 3.1.2 in M20060109-0800.
Verified for 3.2M4 in I20051215-1506
*** Bug 125445 has been marked as a duplicate of this bug. ***
*** Bug 132348 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > *** Bug 132348 has been marked as a duplicate of this bug. *** Bug 132348 is not same case as Bug 106466 and has been marked as duplicate. public class X { <T extends Runnable, U extends T & Runnable> T foo() { return null; } } This is the base case for 106466 which is a wrong declaration that duplicates the Runnable bound. But Bug 132348 reported that the next declaration is legal but eclipse 3.2 reports it as illegal. public class X<T, U extends T & Runnable> { //whatever... } Just have a look at the spec for a while, then follow my conclusions at the end. I could be mistaken, but it seems to me a right interpretation of the spec definition. Taken from java specs: 4.4 Type Variables A type variable (§4.4) is an unqualified identifier. Type variables are introduced by generic class declarations (§8.1.2) generic interface declarations (§9.1.2) generic method declarations (§8.4.4) and by generic constructor declarations (§8.8.4). TypeParameter: TypeVariable TypeBoundopt TypeBound: extends ClassOrInterfaceType AdditionalBoundListopt AdditionalBoundList: AdditionalBound AdditionalBoundList AdditionalBound AdditionalBound: & InterfaceType Type variables have an optional bound, T & I1 ... In. The bound consists of either a type variable, or a class or interface type T possibly followed by further interface types I1 , ..., In. If no bound is given for a type variable, Object is assumed. It is a compile-time error if any of the types I1 ... In is a class type or type variable. The erasures (§4.6) of all constituent types of a bound must be pairwise different, or a compile-time error occurs. The order of types in a bound is only significant in that the erasure of a type variable is determined by the first type in its bound, and that a class type or type variable may only appear in the first position. ------------------------------------- As the spec says, a type variable have an optional bound, U has T as an optional bound, that agrees with the spec as it says "The bound consists of either a type variable, or a class or interface type T". My type parameter is U, and has an optional bound T. T is a type parameter, allowed by the spec as seen in the previous sentence. And a bound can be followed only by futher interface types: "possibly followed by further interface types I1 , ..., In.". So, in this case AnyInterface is an interface so it's a legal extra bound for U, that extends T and has to implement Runnable. None of the restrictions especified after this statement forbids this declaration so, according to the spec this is a legal declaration and Eclipse is not handling it properly.
Re: comment 15, pls see bug 132348 for explanation.
