Why Does `filter()` Seem Non-Lazy After `flatMap()` in Java Streams?

Why is filter() not "Completely" Lazy after flatMap() in Java Streams?

In Java 8 streams, intermediate operations like filter() and flatMap() are lazy, meaning they do not execute until a terminal operation like findFirst() is called. However, when filter() follows flatMap(), this laziness is not fully realized, leading to unexpected behavior.

Consider this code example:

Stream.of(1, 2, 3)
        .filter(i -> {
            System.out.println(i);
            return true;
        })
        .findFirst()
        .get();

The output shows that only the first element is printed, indicating that filter() is lazy and short-circuits when the condition is met. In contrast:

Stream.of(1, 2, 3)
        .flatMap(i -> Stream.of(i - 1, i, i + 1))
        .flatMap(i -> Stream.of(i - 1, i, i + 1))
        .filter(i -> {
            System.out.println(i);
            return true;
        })
        .findFirst()
        .get();

Surprisingly, all elements are printed. Even though filter() meets its condition immediately, it continues to process subsequent elements of the stream.

The Reason

This behavior is due to the Java Streams implementation. After flatMap(), the stream no longer contains the original elements. Instead, it contains a sequence of flattened elements generated by flatMap(). When filter() follows, it operates on these flattened elements, not the original stream.

The implementation of forEachWithCancel(), which is used in findFirst(), continuously calls tryAdvance() on the spliterator until the sink requests cancellation or the spliterator is exhausted. In the case of flatMap(), the spliterator continues to advance without any possibility of early termination, even when filter() has already found a match.

Fix

This issue has been addressed in Java 10 and backported to Java 8. The implementation now allows for early termination in flatMap() when a short-circuiting operation like filter() is used.

Conclusion

Understandably, it can be confusing why filter() behaves as if it's not lazy after flatMap(). The underlying Java Streams implementation dictates this behavior, which was later addressed in Java 10 and backported to Java 8. This understanding is crucial for handling such scenarios efficiently.

The above is the detailed content of Why Does `filter()` Seem Non-Lazy After `flatMap()` in Java Streams?. For more information, please follow other related articles on the PHP Chinese website!