In JDK 7 we added support for enhanced method resolution diagnostics. The support is generally working very well, allowing for arbitrarily complex method diagnostics to be composed out of smaller parts, leading to very informative error messages.

However, with Project Lambda there is a growing concern over verbosity of such error messages. Consider the following case:

void m(Runnable r) { ... }

m(()->1);

The method call is ill-typed as we are trying to pass a lambda that returns a value to a SAM whose descriptor has a void return type.

This is what we get with current compiler implementation:

Test.java:10: error: method m in class Test cannot be applied to given types;
        m(()->1);
        ^
  required: Runnable
  found: ()->1
  reason: argument mismatch; bad return type in lambda expression
      int cannot be converted to void

There are several problem with this error message:

*) the problem is reported as a method resolution failure - while this is technically correct, many users would expect a simpler diagnostic that only talks about the lambda expression

*) The actual issue 'int cannot be converted to void' is nested two levels into the method resolution diagnostic, making it hard to diagnose what the problem actually is.

*) The message does not look similar to what you get in a similar example where the lambda is assigned to a variable of type Runnable - in that case the error is much more compact, as shown below:

Test.java:10: error: incompatible types: bad return type in lambda expression
        m(()->1);
              ^
    int cannot be converted to void


It would be great if we could somehow generate the same diagnostics in both cases.