Description Manoj N Palat 2019-06-03 02:44:04 EDT

From https://bugs.openjdk.java.net/browse/JDK-8170361

Better disambiguation for functional expression

Overload resolution was completely restructured in Java SE 8 to allow deeper interactions with type inference. In Java SE 8, not all the argument expressions in a method call are subject to the applicability test; only those that are pertinent to applicability. Lambda and method references can belong to both categories; explicit lambdas and exact method refs are pertinent to applicability, whereas implicit lambdas and inexact method refs are not.

When an expression is not pertinent to applicability, the precision of the applicability test is much reduced - such expressions are not subject to the full test (i.e. compatibility against target), but are subject to a much looser check, called potential compatibility, which verifies only that:

the arity of the lambda/method reference matches that of the target function type
a value (resp. void)-compatible lambda/method reference is used against a value (resp. void)-compatible function type
Specifically, the compiler is not allowed to do:

attribution of the lambda body
overload resolution of the method reference
And as a result, the compiler's ability to rule out inapplicable candidates is severely impaired. This was a deliberate compromise to avoid brittleness (i.e., errors in a lambda body could drive overload resolution decisions, and therefore changes in the body of a lambda could affect overload resolution decisions) and to avoid a combinatorial explosion of the cost of type checking. However, there are minor improvements that can be made within these constraints, that enables better applicability checking. This would enable us to eliminate some accidental ambiguity errors that tend to come up quite regularly in real Java code. Consider the following example:

m(Predicate<String> ps) { ... }
m(Function<String, String> fss) { ... }

m(s -> false) //ambiguous
For the user, it's obvious which overloaded method should be selected here - the lambda returns false, so a Function<String, String> is clearly incompatible. But for the compiler, the lambda is not pertinent to applicability, both methods are applicable, none is more specific, and so an ambiguity error ensues.