Sybex CSG 17 - Chapter 8 - Page 450 - Summary possible errata

[Tim Mousaw]

The summary gives the full syntax of a lambda expression as:

(String a, String b) -> { return a.equals(b); }

It then goes on to describe the syntax of the short form and gives the lambda as:

a -> a.equals(b)

While this could be valid assuming b is defined in an instance variable, static variable, local variable, or method parameter (for local variable and method parameter, only if final or effectively final) in code that is omitted, it seems more logical to think the authors intended to show the abbreviated form of the previous full syntax. That is:

(a, b) -> a.equals(b)

[Campbell Ritchie]

In the second case, it is likely that b is a variable declared outwith the λ, and yes, a parameter or local variable does have to be effectively final, but maybe that is what the authors intended. We might be more confident with a bit more context please.
Many people believe there should be no such thing as a static variable, using static fields only for constants.

[Tim Mousaw]

The relevant paragraphs are as follows:

Lambda expressions, or lambdas, allow passing around blocks of code. The full syntax look like this:

(String a, String b) -> { return a.equals(b); }

The parameter types can be omitted. When only one parameter is specified without a type, the parentheses can also be omitted. The braces and return statement can be omitted for a single statement making the short form as follows:

a -> a.equals(b)

While I understand this shows the most abbreviated form, it begs the question of where b comes from. And using the same body as the full syntax may lead to one believing the latter is intended to be the short form of the former. It may be more straightforward to use a different body (e.g. a -> a.toUpperCase())

[Mike Simmons]

I agree, Tim.  It seems that by trying to re-use similar code, they've created a more confusing situation that doesn't quite fit.  There's also more than just one "long form" and one "short form" - e.g. these are also possible, and equivalent to the first version:

(a, b) -> { return a.equals(b); }

(String a, String b) -> a.equals(b)

(a, b) -> a.equals(b)

For a one-argument version, perhaps it would be easier to just replace b with a literal of some sort, and skip the "where did b come from?" confusion:

a -> a.equals("YES")

[Piet Souris]

@Tim
just a petite practice-question:
can you replace:

a -> a.equals("Yes");

by

"Yes"::equals;

?

[Tim Mousaw]

@Piet
Yes, that's perfectly legal. You're taking an instance of a String and calling the equals method on it with a method reference. If used in a stream method like filter assuming strings in a collection it would filter for all Strings that were Yes (case sensitive, or else you should have used "Yes"::equalsIgnoreCase).

[Campbell Ritchie]

Beware: tangent!

Why might Piet's method reference be better than Mike's? Apart from being shorter, that is.

[Piet Souris]

@Tim
Indeed. What I wanted to bring into memory (always handy for the OCPJP) is that

b::someMethod

stands for

element -> b.someMethod(element)

Here we had

a -> a.someMethod(b)

and if that method is commutative, which the equals-method should be (but there is an exception, see Campbells reply), then that is equivalent to

a -> b.someMethod(a)

or

b::someMethod