Java lambda returning a lambda

I haven't yet delved into the exact rules for how type inference works with lambdas. From a general language design standpoint, though, it isn't always possible to write language rules that allow the compiler to figure out everything we think it should. I've been a compiler maintainer for an Ada-language compiler and I'm familiar with many of the language design issues there. Ada uses type inference in a lot of cases (where the type of a construct can't be determined without looking at the entire expression containing the construct, which I think is the case with this Java lambda expression also). There are some language rules that cause compilers to reject some expressions as ambiguous when, in theory, there really is only one possible interpretation. One reason, if I recall correctly, is that somebody found a case where a rule that would have let the compiler figure out the correct interpretation would have required the compiler to make 17 passes through an expression in order to interpret it correctly.

So while we may think a compiler "should" be able to figure something out in a particular case, it may just plain be unfeasible.

You hit a limitation of Java 8’s target typing which applies to the receiver of a method invocation. While target typing works (most of the times) for parameter types it does not work for the object or expression on which you invoke the method.

Here, l.stream(). map(n -> () -> { System.out.println(n); return null; }) is the receiver of the collect(Collectors.toList()) method invocation, so the target type List<Callable<Object>> is not considered for it.

It’s easy to prove that nested lambda expressions work if the target type is know, e.g.

static <T> Function<T,Callable<Object>> toCallable() {
    return n -> () -> {
        System.out.println(n); 
        return null;
    };
}

works without problems and you can use it to solve your original problem as

List<Callable<Object>> checks = l.stream()
    .map(toCallable()).collect(Collectors.toList());

You can also solve the problem by introducing a helper method which changes the role of the first expression from method receiver to a parameter

// turns the Stream s from receiver to a parameter
static <T, R, A> R collect(Stream<T> s, Collector<? super T, A, R> collector) {
    return s.collect(collector);
}

and rewrite the original expression as

List<Callable<Object>> checks = collect(l.stream().map(
    n -> () -> {
        System.out.println(n); 
        return null;
    }), Collectors.toList());

This does not reduce the complexity of the code but can be compiled without any problems. For me, it’s a déjà vu. When Java 5 and Generics came out, programmers had to repeat the type parameters on new expressions while simply wrapping the expression into a generic method proved that inferring the type is no problem. It took until Java 7 before programmers were allowed to omit these unnecessary repetition of the type arguments (using the “diamond operator”). Now we have a similar situation, wrapping an invocation expression into another method, turning the receiver into a parameter, proves that this limitation is unnecessary. So maybe we get rid of this limitation in Java 10…

I ran into this same issue and was able to solve it by explicitly specifying the generic type-parameter to map like so:

List<Callable<Object>> checks = l.stream().
   <Callable<Object>>map(n -> () -> {
      System.out.println(n); 
      return null;
   }).
   collect(Collectors.toList());