JDK-7030833 : 4.9: Missing well-formedness rules for type variable bound
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 7
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2011-03-24
  • Updated: 2015-09-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
4.4 (Type Variables) constrains the structure of a variable bound (a class or type variable can only appear in the first position) and provides some limitations on the possible combinations of types (the variable cannot subtype two parameterizations of an interface; no two erasures can be the same (redudant?)).  But there exist stronger restrictions on a class or interface type whose "bound" (its extends/implements clauses) is the same as a particular intersection.  For example, the return types of two override-equivalent member methods of a class must be directly related.

It is unclear whether this inconsistency is intentional.  Other parts of the spec seem to assume that the guarantees made for class and interface members apply to variable bounds: 4.9 (Intersection Types) maps intersection types to (supposedly well-formed?) class declarations in order to determine members; 15.12.2.5 (Choosing the Most Specific Method) selects a method that has "the most specific return type".  There are probably other cases.

If any additional restrictions are added, they should go in 4.4, not 4.9.  It's nonsensical to mandate a compile-time error based on the format of an intersection type when programs never contain intersection types.  If there are well-formedness conditions on intersections, it is the specification's job to guarantee, possibly via *other* compile-time checks, that these conditions are met when it produces intersections.  (The existing "a compile-time error occurs" in 4.9 does not belong there.)

Here's a test case documenting current compiler behavior:

public class Intersection {

  interface I1 { I1 m(); }
  interface I2 { I2 m(); }

  interface I3 extends I1, I2 {} // error in javac6, javac7, ecj36

  <T extends I1 & I2> T mi() { return null; } // error in javac6*, javac7

  interface J1 { void m(Iterable<String> arg); }
  interface J2 { void m(Iterable<Integer> arg); }

  interface J3 extends J1, J2 {} // error in javac7

  <T extends J1 & J2> T mj() { return null; } // error in javac7

  // * Error in javac6 only if the interface declarations are moved outside of this class
}

Comments
Worth noting that it _is_ possible for a type to have two methods with the same signature but different return types -- you can get there via substitution. In that case, 15.12.2.5 has to account for the unusual set of members, presumably by reporting an ambiguity error (actual spec text is unclear). JDK-7034913 illustrates this in its comment section, along with various other examples of parameterized types with "bad" pairs of member methods.
23-04-2014

EVALUATION Given: interface I1 { I1 m(); } interface I2 { I2 m(); } <T extends I1&I2> void test(T t) { Foo f = t.m(); } There are three possible interpretations: 1) The type variable declaration is illegal (as in javac) 2) t.m() has type I1&I2 3) t.m() is ambiguous (as in ecj) #2 is a problem, because it introduces intersections in inference where they couldn't occur before: interface J1 { <S,T> S m(); } interface J2 { <S,T> T m(); } <T extends J1&J2> void test(T t) { Foo f = t.m(); } #3 is unattractive, because there's no precedent for reporting an ambiguity error based on the return type. So we'll go with #1. JLS 4.4 should say that a bound T&I1&..&In is legal iff, for the intersection type T&I1&..&In, the class type synthesized in 4.9 is legal.
25-03-2011