JDK-8035713 : javac, inconsistent inference output for javac8 -source 7
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2014-02-24
  • Updated: 2015-12-10
  • Resolved: 2015-12-10
Related Reports
Duplicate :  
JDK-8078249 - Inference regression with JDK 8 and -source 7
Relates :  
JDK-8054937 - 5.1.10: Fresh capture variables sometimes can't conform to bounds
Description
This code:

class Test {
    class K<T> {}

    <P extends K<P>> void f(String s) {
        P p = foo(s);
    }

    <U extends K<U>> U foo(String s) {
        return null;
    }
}

compiles with javac7 and javac8 but not with javac8 source 7

reported in compiler-dev: http://mail.openjdk.java.net/pipermail/compiler-dev/2014-February/008519.html
Comments
We may resolve JDK-8054937 in an interesting way by improving the spec, but JLS 7 (the spec for "-source 7") cannot be changed. Given that the JLS 7 inference spec leads to a malformed type, it's completely reasonable for javac to reject the program in "-source 7" mode. So I don't think there's anything to be done here.
10-12-2015
Per JLS 8: In 18.5.1, 'foo(s)' gives us bounds: B0 = { u <: Object, u <: K<u> } B2 = { u <: Object, u <: K<u> } Resolution can succeed (with u = a fresh variable Z extends K<Z>), so the method is applicable. In 18.5.2, we check [u --> P]: B3 = { u <: P, u <: Object, u <: K<u> } Resolution chooses u=P, and the dependency u <: K<u> is satisfied by P <: K<P>, so the return type of the invocation is P. Actual javac behavior seems to match this. ---------- Per JLS 7: 15.12.2.7 does nothing interesting, and u is left unresolved. 15.12.2.8 checks [P >> u] and [u << K<u>], which yields { u <: P, u <: K<u> } Because "Ti [u] appears as a type argument in any Uk [K<u>]", u is inferred as a type variable: X extends P, K<X> Now we've encountered a situation like JDK-8054937, where X claims to be both a K<P> and a K<X>. Strictly speaking, this is a malformed type, but 15.12.2.8 is not clear about what to do if the type is malformed, and javac seems to support these kinds of types sometimes anyway (per JDK-8054937). So an argument can be made for success or failure, pending clarification of the spec. It's not clear from the error message, though, that this is the place where javac is getting hung up...
05-08-2015
Release team: Approved for deferral.
25-02-2014