Errata

A Functional Approach to Java

Errata for A Functional Approach to Java

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Page Chapter 2: Functional Java
throughout the chapter

Throughout Chapter 2 "Functional Java" the `java.util.function` package is incorrectly referred to as `java.util.functional`.

Note from the Author or Editor:
Thanks!
This is already fixed in a later version.

 Matthew Janssen  Oct 26, 2022  May 16, 2023
Page Chapter 3: Immutability
Sub-section: Immutable Collections

"Also, they’re only shallowly immutable, meaning that you can add or remove any elements, ..." should instead be "... you can't add or remove any elements ..."

Note from the Author or Editor:
Thanks!
This is already fixed in a later version.

 Naufal B  Oct 31, 2022  May 16, 2023
Page Immutable Collections
https://learning.oreilly.com/library/view/a-functional-approach/9781098109912/ch03.html#:-:text=Instead%20of%20being,to%20the%20elements

unmodifiableList should be List.copyOf

Something like:
@Test
public void CopyOfTest(){

List<String> modifiable = new ArrayList<>();
modifiable.add("blue");
modifiable.add("red");

List<String> unmodifiable = List.copyOf(modifiable);
// throws UnsupportedOperationException
// unmodifiable.clear();

// throws UnsupportedOperationException
// unmodifiable.add("green");


assertThat(unmodifiable.size(), equalTo(2));

modifiable.add("green");
assertThat(modifiable.size(), equalTo(3)); // hmm - do whatever with the original. Does not bother us

assertThat(unmodifiable.size(), equalTo(2)); // That's better
}

You're welcome :D

Note from the Author or Editor:
Thanks!
This is already fixed in a later version.

 Volker  Jan 06, 2023  May 16, 2023
Page p. 30
Section "Bound non-static method references", first code sample

I have some issues understanding the following code section:
```
// LAMBDA BASED ON EXISTING OBJECT
Predicate<LocalDate> isAfterNowAsLambda = date -> $.isAfter(now);

// BOUND NON-STATIC METHOD REFERENCES
Predicate<LocalDate> isAfterNowAsRef = now::isAfter;
```

1. The $ character does not seem to be valid Java, the line does not compile and $ is never explained. Did you mean "date -> date.isAfter(now);" instead?

2. I understand that the expression "now::isAfter" is equivalent to "now.isAfter(lambdaArgument)". But that is the exact opposite of 1. In 1, you test if "date" is after "now", now you test if "now" is after "date". So these two lines are not equivalent, but opposites?

3. The variable name "isAfterNowAsRef" is at least misleading, because you test if "now" is after a given value, not if a given value is after "now". So it should be "isBeforeOrEqualToNowAsRef" instead?

Note from the Author or Editor:
The correct code example:


var now = LocalDate.now();

// LAMBDA BASED ON EXISTING OBJECT
Predicate<LocalDate> isNowAfterAsLambda = date -> now.isAfter(date);

// BOUND NON-STATIC METHOD REFERENCE
Predicate<LocalDate> isNowAfterAsRef = now::isAfter;

 Fabian Hartmann  Apr 30, 2024  Jun 28, 2024
Page 30
1st paragraph

Predicate<LocalDate> isAfterNowAsLambda = date -> $.isAfter(now);

should be

Predicate<LocalDate> isAfterNowAsLambda = $-> $.isAfter(now);

Note from the Author or Editor:
Thank you for submitting the errata.

Even though you're correct that the variable name was wrong (date vs. $), the lambda variant isn't mirroring the reference method variant.

The correct example code would be:

Predicate<LocalDate> isNowAfterAsLambda = date -> now.isAfter(date);

// BOUND NON-STATIC METHOD REFERENCE
Predicate<LocalDate> isNowAfterAsRef = now::isAfter;

 Xin Jin  May 19, 2024  Jun 28, 2024
Page 41
2nd paragraph

The second paragraph of page 41 says

The Consumer<T> interface is similar to the Java 5+ Callable<V> found in the java.util.concurrent package, except the latter throws a checked Exception.

This is wrong since Consumer<T> has a SAM with signature

void accept(T t)

while Callable<V> has a SAM with signature

V call() throws Exception

Consumer accepts an input while Callable does not. I think the paragraph is meant for the next section which is about Suppliers. The following paragraph makes sense.

The Supplier<T> interface is similar to the Java 5+ Callable<V> found in the java.util.concurrent package, except the latter throws a checked Exception.

Note from the Author or Editor:
You're right with your description of the error, the paragraph in question of Consumer<T> is supposed to belong to Supplier<T>.

 Jorick Caberio  Jul 01, 2023  Feb 02, 2024
Page 42
2nd paragraph

Integer result = over9000.test(1_234);

should be

boolean result = over9000.test(1_234);

Note from the Author or Editor:
Thank you for submitting the errata.

This issue was fixed in the 2nd edition reprint.

 Xin Jin  May 19, 2024  Feb 02, 2024
Page 43
Code sample

Following snippet of code has a compilation error. Parameter V should not have a comma before variable name v:

@FunctionalInterface
public interface TriFunction<T, U, V, R> {
R accept(T t, U u, V, v);
}

Should be corrected as:

@FunctionalInterface
public interface TriFunction<T, U, V, R> {
R accept(T t, U u, V v);
}

I have created a pull request for the same.

Note from the Author or Editor:
That's correct, the comma is superfluous

 Praveen A Kulkarni  Nov 21, 2023  Feb 02, 2024
Page 250
Example 10-2

The type parameter in the book is U but it should be R

@Override
default R apply(T t) {
try {
return applyThrows(t);
} catch (Exception e) {
throw new RuntimeException(e);
}
}

Note from the Author or Editor:
The error description is correct, thanks for submitting the errata.

The method signature must match the generic types used in the interface declaration, so the SAM should return R instead of the (non-existent) U.
The code repository, however, uses U throughout.
It doesn't matter which letter is actually used as long as it's consistent.
Still, R might be easier to identify as "returned typed."

 Jorick Caberio  Aug 23, 2023  Feb 02, 2024