JDK-8167316 : 8.4.5: Clean up return-type-substitutable definition
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 8
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-10-06
  • Updated: 2018-11-30
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 :  
JDK-7018313 - 5.1.9: Unchecked conversion during assignment/method invocation is too lax
Relates :  
JDK-8207224 - Javac compiles source code despite illegal use of unchecked conversions
Relates :  
JDK-8167318 - Eliminate redundant Types.returnTypeSubstitutable method
Description
A few problems with return-type-substitutable, as defined in JLS 8:

- It talks about adapting type parameters without first asserting that the two signatures are the same (if not, the operation is undefined)

- It performs unchecked conversion *before* widening; javac and assignment perform it *after* widening

- It asserts R1 == |R2|, while javac checks that R1 <: |R2|

- Cosmetically, "does not have the same signature" is (probably?) more general than needed���we're really asserting that d1 is a proper subsignature of d2, rather than being the same.

For the javac discrepancies, it may be that javac needs to be corrected, but we should look more closely and the motivation for the specified rules.
Comments
JDK-7018313 examines the timing of unchecked conversion during assignment. Comments include this example, which supports doing unchecked conversion *last*: class MyList implements List { ... } // legacy API List<String> ls = new MyList();
06-10-2016