JDK-7013614 : inference: failure of 15.12.2.8 should trigger backtracking in overload resolution
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: unknown
  • Submitted: 2011-01-20
  • Updated: 2013-04-26
  • Resolved: 2013-04-26
Related Reports
Relates :  
JDK-6313164 - javac generates code that fails byte code verification for the varargs feature
Description
The following legal Java program doesn't compile:

class Test {
<Z extends Number> Z m(String o) { return null; }
<Z extends String> Z m(Object o) { return null; }

{ String s = m(null); } //error in javac
}

Reading JLS 3rd, section 15.12.2.2, method m(String) is not applicable - (because there's no instance of the type-variable Z satisfying the constraints imposed by the expected return type, as described in JLS 15.12.2.8). Hence, the applicability check fails and, method resolution discovers another suitable candidate, namely m(Object). javac seems to never get there.
Comments
We decided that overload resolution should be kept independent for the target-type. This means an overload candidate cannot be discarded based on the fact that the target-type would produce a bad inference constraint.
26-04-2013
EVALUATION Now, this is a difference in how type-inference work in javac w.r.t. the JLS. It has always been there (JDK 5/6 behaves in the same way). More specifically, javac ends up selecting m(String) during overload resolution (because it's the most specific, if we look at the signatures) - after resolution, javac attempts to instantiate the return type of the selected method to the target type String using 15.12.2.8 - this fails (bound of Z is Number, expected type is String, so no glb() exists here). Since we already passed the most specific phase, we are technically out of method resolution, and the only alternative javac has at this point is to fail with an error.
20-01-2011