JDK-8170885 : 18.4: Avoid inferring capture variables during resolution
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 8,9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-12-07
  • Updated: 2016-12-07
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 :  
Relates :  
Description
Longstanding inference behavior of javac (in releases 5-8) is to avoid upper/lower bounds that mention inference variables by, instead, mapping those variables to their bounds during reduction. This leads to various unspecified failures and has been addressed���see JDK-8033718 and JDK-8039214.

javac's interest in avoiding capture variables is reasonable, though. Various programs that used to compile no longer will after the fix���see JDK-8075793. While we've reverted to the old behavior under "-source 7" and previous, going forward it makes sense to try to infer types that are not capture variables when possible.

Proposed reconciliation of spec and implementation: Follow JLS on reduction. During resolution, if the lower bound that would produce the instantiation is a capture variable, try using the variable's upper bound instead; and if the upper bound that would produce the instantiation is a capture variable, try using the variable's lower bound (if any) instead. If the attempt fails, revert to the capture variable.

A more powerful, and maybe more consistent, approach is to use upward and downward projection here, as in JDK-8016196.
Comments
Should create a companion javac bug if we decide to do this. Should also consider rolling back JDK-8075793, since it will be redundant (if the strategy is applied to all source versions, that is).
07-12-2016