JDK-6644562 : 4.9: Simplify membership of single-bound intersection types
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 7
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2007-12-20
  • Updated: 2024-04-12
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
tbdUnresolved
Related Reports
Relates :  
JDK-6557960 - 4.4: Allow array type as bound of type variable
Relates :  
JDK-7120669 - 4.9: Clarify well-formedness for intersection types & bounded type variables
Relates :  
JDK-8039222 - 5.1.10: Define glb for non-class types
Relates :  
JDK-6711619 - javac doesn't allow access to protected members in intersection types
Relates :  
JDK-6904536 - Generics support broken in Java 7-b40
Relates :  
JDK-6946211 - Multiple generic types cause weaker access privileges error on clone()
Relates :  
JDK-6531075 - Missing synthetic casts when accessing fields/methods of intersection types including type variables
Description
As part of the JLS fix for allowing array types as bounds, 6557960 improves the definition of members of an intersection type. In addition, JLS 4.4 can define membership of a single bound rather simply, without intersection types:

  ***The members of a type variable X with bound T are the non-private members of T.***
  // If T is a type variable, we'd better not have a supertype chain including X!

  The members of a type variable X with bound T & I1..In are the members of the intersection type T & I1..In ... 
  // As in 3ed
Comments
EVALUATION A simplified explanation for the membership of type variables is welcome. There is a general difficulty with private members of a type variable's bounds. Formally such members do not become members of the type variable itself, though javac and Eclipse traditionally made them members and code has come to rely on that: class Test { private int count = 0; <Z extends Test> void m(Z z) { count = z.count; // Legal in javac 1.6, illegal in javac 1.7 due to fix for 6711619 } } Peter submitted a similar test: class A { static class B { private String f; } abstract static class Builder<T extends B> { abstract T getB(); { ((B)getB()).f.hashCode(); getB().f.hashCode(); // error: f has private access in A.B } } } Since intersection types are constructed by inheritance, and private members are never inherited, it is tricky to re-specify intersection types to have private members. Nonetheless, it would be the compatible thing to do.
20-12-2007