issue with fix for JDK-8064464

Maurizio Cimadamore maurizio.cimadamore at
Mon Nov 24 22:01:39 UTC 2014

Hi Liam,
the JLS defines an operand of a conditional expression to be 
numeric/boolean in case it is a method call with the following wording:

"A method invocation expression (§15.12) for which the chosen most 
specific method (§ has return type boolean or Boolean.
*Note that, for a generic method, this is the type 
**/before/**instantiating the method's type arguments.*"

(oddly, the statement in bold only appears in the section on boolean 
conditionals, and not in the one about numeric conditionals, but I 
believe that's a mistake - i.e. the same statement should be present on 

This seems to suggest that your example should not compile, as the 
uninstantiated method return type would be T, which is not a numeric type.

However, this seems like a case where the analysis could be improved a 
bit - as far as I recall, this rule is mostly there to prevent excessive 
speculative type-checking during classification of the conditional 
expression; so it seems like taking into account explicit type 
parameters could be doable (although maybe tricky to specify). I'll 
leave this with Dan for further evaluation.


On 24/11/14 19:37, Liam Miller-Cushon wrote:
> The fix for JDK-8064464 [1] [2] prevents the following code from 
> compiling (it works fine with 8u25 and 7u67). Is this deliberate?
> abstract class Test {
>   abstract <T> T e();
>   abstract int f();
>   void m(boolean flag) {
>     String.valueOf(flag ? f() : this.<Integer>e());
>   }
> }
> $ javac
> error: reference to valueOf is ambiguous
>     String.valueOf(flag ? f() : this.<Integer>e());
>           ^
>   both method valueOf(Object) in String and method valueOf(int) in 
> String match
> [1]
> [2]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the compiler-dev mailing list