JDK-8075896 : 18: Generalize capture ivars to support diamond anonymous classes
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-03-24
  • Updated: 2015-12-17
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 :  
Description
The type of an anonymous class expression is the anonymous class type.  While this type can't be named, it can be an inferred type argument and its its (unique) members can be accessed:

Arrays.asList(new Object() { void m() {} }).m(); // ok

Diamond anonymous class expressions, on the other hand, are treated during inference as if their type is the generic supertype.  As a result, their (unique) members cannot be accessed.

Arrays.asList(new ArrayList<>() { void m() {} }).m(); // error

In order to support this usage, inference needs to be updated so that it can talk about the not-yet-defined class alpha whose supertype is ArrayList<beta>.  Here, alpha behaves much like a capture inference variable: it cannot be resolved to one of its bounds, but acts as a stand-in for a specific, unnameable type.

Given these two use cases, there's quite possibly a third, and we could use a more general-purpose mechanism for describing special inference variables that are stand-ins for unnameable types.

(Alternative viewpoint: this is an obscure corner case, and not worth the trouble of perturbing inference.)
Comments
Amplifying the "Alternative viewpoint: this is an obscure corner case, and not worth the trouble of perturbing inference." part: The latest stipulation in the specification for diamond inference (that the non-private methods are to be treated as though they were annotated with @Override) would further appear to sweep this to a even more remote corner.
25-03-2015