Why Does a Java Method Reference with a Return Value Work with the `Consumer` Interface?

Why a Java Method Reference with Return Type Matches the Consumer Interface

Issue

Consider the following code snippet:

Consumer<String>         lambda1 = s -> {};
Function<String, String> lambda2 = s -> s;

Consumer<String>         lambda3 = LambdaTest::consume; // but s -> s doesn't work!
Function<String, String> lambda4 = LambdaTest::consume;

As per the Consumer interface, it is defined as void accept(T t); hence, one may be puzzled by the assignment of lambda3 as the consume method returns a String. Surprisingly, lambda4 is also assigned.

Explanation

This scenario is attributed to the flexible design of method references in Java. It permits the adaptation of a method to a functional interface in the same manner as calling the method directly. In other words, one can invoke any value-returning method and disregard the returned value.

Lambda Expression Distinction

Lambda expressions come in two forms:

1. (args) -> expression: Value compatible if the expression evaluates to a value.
2. (args) -> { statements* }: Void compatible if no code path attempts to return a value.

The expression s -> s is not void compatible because s is not a statement. However, s -> s.toString() can be since method invocations are statements.

Compatible Forms

Expressions that can be used as statements (as per Java Language Specification §14.8) include:

• Method invocations
• Increment/decrement operators
• Assignments
• Class instance creation expressions

Restriction

It's important to note that the form (arg) -> methodReturningVoid(arg) is the only expression form that is not value compatible.

The above is the detailed content of Why Does a Java Method Reference with a Return Value Work with the `Consumer` Interface?. For more information, please follow other related articles on the PHP Chinese website!