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().
is the receiver of the
map(n -> () -> {
System.out.println(n);
return null;
})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…