Lambda expression and method overloading doubts

Question

OK, so method overloading is-a-bad-thing™. Now that this has been settled, let's assume I actually want to overload a method like this:

static void run(Consumer<Integer> consumer) {
    System.out.println("consumer");
}

static void run(Function<Integer, Integer> function) {
    System.out.println("function");
}

In Java 7, I could call them easily with non-ambiguous anonymous classes as arguments:

run(new Consumer<Integer>() {
    public void accept(Integer integer) {}
});

run(new Function<Integer, Integer>() {
    public Integer apply(Integer o) { return 1; }
});

Now in Java 8, I'd like to call those methods with lambda expressions of course, and I can!

// Consumer
run((Integer i) -> {});

// Function
run((Integer i) -> 1);

Since the compiler should be able to infer Integer, why don't I leave Integer away, then?

// Consumer
run(i -> {});

// Function
run(i -> 1);

But this doesn't compile. The compiler (javac, jdk1.8.0_05) doesn't like that:

Test.java:63: error: reference to run is ambiguous
        run(i -> {});
        ^
  both method run(Consumer<Integer>) in Test and 
       method run(Function<Integer,Integer>) in Test match

To me, intuitively, this doesn't make sense. There is absolutely no ambiguity between a lambda expression that yields a return value ("value-compatible") and a lambda expression that yields void ("void-compatible"), as set out in the JLS §15.27.

But of course, the JLS is deep and complex and we inherit 20 years of backwards compatibility history, and there are new things like:

Certain argument expressions that contain implicitly typed lambda expressions (§15.27.1) or inexact method references (§15.13.1) are ignored by the applicability tests, because their meaning cannot be determined until a target type is selected.

from JLS §15.12.2

The above limitation is probably related to the fact that JEP 101 wasn't implemented all the way, as can be seen here and here.

Question:

Who can tell me exactly what parts of the JLS specifies this compile-time ambiguity (or is it a compiler bug)?

Bonus: Why were things decided this way?

Update:

With jdk1.8.0_40, the above compiles and works fine

Answer 1

I think you found this bug in the compiler: JDK-8029718 (or this similar one in Eclipse: 434642).

Compare to JLS §15.12.2.1. Identify Potentially Applicable Methods:

…

• A lambda expression (§15.27) is potentially compatible with a functional interface type (§9.8) if all of the following are true:

  • The arity of the target type's function type is the same as the arity of the lambda expression.

  • If the target type's function type has a void return, then the lambda body is either a statement expression (§14.8) or a void-compatible block (§15.27.2).

  • If the target type's function type has a (non-void) return type, then the lambda body is either an expression or a value-compatible block (§15.27.2).

Note the clear distinction between “void compatible blocks” and “value-compatible blocks”. While a block might be both in certain cases, the section §15.27.2. Lambda Body clearly states that an expression like () -> {} is a “void compatible block”, as it completes normally without returning a value. And it should be obvious that i -> {} is a “void compatible block” too.

And according to the section cited above, the combination of a lambda with a block that is not value-compatible and target type with a (non-void) return type is not a potential candidate for the method overload resolution. So your intuition is right, there should be no ambiguity here.

Examples for ambiguous blocks are

() -> { throw new RuntimeException(); }
() -> { while (true); }

as they don’t complete normally, but this is not the case in your question.

Answer 2

This bug has already been reported in the JDK Bug System: https://bugs.openjdk.java.net/browse/JDK-8029718. As you can check the bug has been fixed. This fix syncs javac with the spec in this aspect. Right now javac is correctly accepting the version with implicit lambdas. To get this update, you need to clone javac 8 repo.

What the fix does is to analyze the lambda body and determine if it's void or value compatible. To determine this you need to analyze all return statements. Let's remember that from the spec (15.27.2), already referenced above:

• A block lambda body is void-compatible if every return statement in the block has the form return.
• A block lambda body is value-compatible if it cannot complete normally (14.21) and every return statement in the block has the form return Expression.

This means that by analyzing the returns in the lambda body you can know if the lambda body is void compatible but to determine if it's value compatible you also need to do a flow analysis on it to determine that it can complete normally (14.21).

This fix also introduces a new compiler error for cases when the body is neither void nor value compatible, for example if we compile this code:

class Test {
    interface I {
        String f(String x);
    }

    static void foo(I i) {}

    void m() {
        foo((x) -> {
            if (x == null) {
                return;
            } else {
                return x;
            }
        });
    }
}

the compiler will give this output:

Test.java:9: error: lambda body is neither value nor void compatible
    foo((x) -> {
        ^
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

I hope this helps.

Answer 3

Lets assume we have method and method call

void run(Function<Integer, Integer> f)

run(i->i)

What methods can we legally add?

void run(BiFunction<Integer, Integer, Integer> f)
void run(Supplier<Integer> f)

Here the parameter arity is different, specifically the i-> part of i->i does not fit the parameters of apply(T,U) in BiFunction, or get() in Supplier. So here any possible ambiguities are defined by parameter arity, not types, and not the return.

---

What methods can't we add?

void run(Function<Integer, String> f)

This gives a compiler error as run(..) and run(..) have the same erasure. So as the JVM can't support two functions with the same name and argument types, this can't be compiled. So the compiler never has to resolve ambiguities in this type of scenario as they are explicitly disallowed due the rules preexisting in the Java type system.

So that leaves us with other functional types with a parameter arity of 1.

void run(IntUnaryOperator f)

Here run(i->i) is valid for both Function and IntUnaryOperator, but this will refuse to compile due to reference to run is ambiguous as both functions match this lambda. Indeed they do, and an error here is to be expected.

interface X { void thing();}
interface Y { String thing();}

void run(Function<Y,String> f)
void run(Consumer<X> f)
run(i->i.thing())

Here this fails to compile, again due to ambiguities. Without knowing the type of i in this lambda it is impossible to know the type of i.thing(). We therefore accept that this is ambiguous and rightly fails to compile.

---

In your example:

void run(Consumer<Integer> f)
void run(Function<Integer,Integer> f)
run(i->i)

Here we know that both of functional types have a single Integer parameter, so we know that the i in i-> must be an Integer. So we know that it must be run(Function) that is called. But the compiler doesn't try to do this. This is the first time that the compiler does something that we don't expect.

Why does it not do this? I'd say because it is a very specific case, and inferring the type here requires mechanisms that we have not seen for any of the other above cases, because in the general case they are unable to correctly infer the type and choose the correct method.