Java Lambda表达式语法的清晰度-省略参数数据类型

Question

In this official Oracle tutorial: https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html

Under the Syntax of Lambda Expressions, it explicitly states: "Note: You can omit the data type of the parameters in a lambda expression."

It does not say "often" or "frequently", it reads as though you can categorically always do this. Can someone clarify this matter for me and either state whether that statement made by Oracle is correct or not. If it is not then it's pretty bad coming from Oracle themselves, but it would be nice to see a couple of examples of circumstances when the parameter types cannot be inferred.

Answer 1

This means that under most situations, the compiler automatically sees what you arguments are, for example:

Stream.of(new Object())
    .map(o -> o.toString())
    .map(o -> o.toCharArray())
    .flatMap(o -> Arrays.stream(o))
    .foreach(o -> System.out.println(o));

While we give no hints to the parameters of the lamba expressions, the compiler will see the following types for the arguments:

Stream.of(new Object())
    .map((Object o) -> o.toString())
    .map((String o) -> o.toCharArray())
    .flatMap((char[] o) -> Arrays.stream(o))
    .foreach((char o) -> System.out.println(o));

Both versions compile correctly under the java 8 compiler.

---

There are also moment when the compiler cannot do this, this happens when you walk against the limitations of the compiler, the following example is posted by Alexis C :

Stream.of(new SimpleEntry<>("a", 1)).sorted(
       Comparator.comparing(s -> s.getKey()).reversed())

In this example, the knows sorted( requires a Comparator<? super SimpleEntry> , but gets confused by the call to Comparator.reversed() because the return type of that method is affected by the input, while a lamba usually looks ahead to see what type it must transform in. By "unnaking" the lamba, we force it to become our wanted result.

Stream.of(new SimpleEntry<>("a", 1)).sorted(
       Comparator.comparing((Map.Entry<String, Integer> s) -> s.getKey()).reversed())

---

This bug happens in all situations where these conflicting look-ahead and look-behind systems are used, another example I created:

public static void main(String ... args) {
    Function<Number, char[]> func = 
       convert(o->o.toString(), o->o.toCharArray()).andThen(Function.identity());
}

public static <A, B, C> Function<A, C> convert(Function<A, B> c1, Function<B, C> c2) {
    return t -> c2.apply(c1.apply(t));
}

The above fails to compile, until we make this of it:

public static void main(String ... args) {
    Function<Number, char[]> func = 
       convert((Number o)->o.toString(), o->o.toCharArray()).andThen(Function.identity());
}

public static <A, B, C> Function<A, C> convert(Function<A, B> c1, Function<B, C> c2) {
    return t -> c2.apply(c1.apply(t));
}