JDK-8134711 : 18.4: Improve generation of fresh variables
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 8u60
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-08-28
  • Updated: 2016-05-27
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
This began failing with the patch from JDK-8069545.

---

class C<T> {}

<S> C<S> makeC(Function<String,S> f) { return null; }
<T extends Comparable<T>> void eatC(C<T> list) {}

void test() {
    eatC(makeC(x->x));
}

---

Expected: compiles, S = T = String

Actual: error:

error: method eatC cannot be applied to given types;
    eatC(makeC(x->x));
    ^
  required: C<T>
  found: C<Object>
  reason: inferred type does not conform to upper bound(s)
    inferred: Object
    upper bound(s): Comparable<Object>,Object

Comments
Spec analysis: The lambda is not pertinent to applicability (15.12.2.2), so applicability inference (18.5.1) of 'makeC' is trivial. Applicability inference of 'eatC' generates these bounds: { s <: Object, t <: Object, s = t, t <: Comparable<t>, s <: Comparable<t> } For 'eatC' to be applicable, we need to resolve this set of bounds. Resolution (18.4) will try s = t = Object, and that won't work, so it will generate fresh variables -- s = VAR1, t = VAR2. But that doesn't work either -- VAR1 is not the same as VAR2. We should think about making this fallback "generate fresh variables" strategy smarter.
28-08-2015