-
Bug
-
Resolution: Unresolved
-
P4
-
5.0, 7, 8
It is not clear whether the following two signatures are "the same" or not:
public static <T1 extends Cloneable & Iterable<String>> void foo(T1 x)
public static <T2 extends Iterable<String> & Cloneable> void foo(T2 x)
The condition that must be satisfied, from 8.4.2, is "the bounds of corresponding type variables are the same".
This could be interpreted as having the same (unordered) set of bounds, or as having the same (ordered) list of bounds.
javac prefers the set interpretation when determining overriding relationships, although it is internally inconsistent at times (seeJDK-8013089, JDK-8013846).
In fact, javac seems take this even a step further, by determining whether the intersection types suggested by the two lists of bounds are structurally equivalent -- e.g., T extends Object & Runnable & Cloneable == T extends Runnable & Cloneable.
A risk of being to narrow in the definition of "the same" is that two declarations that "obviously" appear to be the same won't be related. A risk of being too broad is that erasure is no longer consistent between signatures that are "the same" (as inJDK-8013089).
public static <T1 extends Cloneable & Iterable<String>> void foo(T1 x)
public static <T2 extends Iterable<String> & Cloneable> void foo(T2 x)
The condition that must be satisfied, from 8.4.2, is "the bounds of corresponding type variables are the same".
This could be interpreted as having the same (unordered) set of bounds, or as having the same (ordered) list of bounds.
javac prefers the set interpretation when determining overriding relationships, although it is internally inconsistent at times (see
In fact, javac seems take this even a step further, by determining whether the intersection types suggested by the two lists of bounds are structurally equivalent -- e.g., T extends Object & Runnable & Cloneable == T extends Runnable & Cloneable.
A risk of being to narrow in the definition of "the same" is that two declarations that "obviously" appear to be the same won't be related. A risk of being too broad is that erasure is no longer consistent between signatures that are "the same" (as in
- relates to
-
JDK-8067848 javax.lang.model.util.Types.capture changes order of type variable bounds
- Open
-
JDK-8013846 javac fails to reject semantically equivalent generic method declarations
- Resolved
-
JDK-7028828 15.12.2.5: Confusion in rules for maximally specific method disambiguation
- Closed
-
JDK-8013089 javac fails to generate bridge for override with reordered intersection
- Closed