Does Stream.forEach respect the encounter order of sequential streams?

by

Specifications exist to describe the minimal guarantees a caller can depend on, not to describe what the implementation does. This gap is crucial, as it allows the implementation flexibility to evolve. (Specification is declarative; implementation is imperative.) Overspecification is just as bad as underspecification.

When a specification says “does not preserve property X”, it does not mean that the property X may never be observed; it means the implementation is not obligated to preserve it. Your claimed implication that encounter order is never preserved is simply a wrong conclusion. (HashSet doesn’t promise that iterating its elements preserves the order they were inserted, but that doesn’t mean this can’t accidentally happen — you just can’t count on it.)

Similarly, your implication of “that suggests forEach is intended to preserve order for sequential streams” because you saw an implementation that does so in some case is equally incorrect.

In both cases, it seems like you’re just uncomfortable with the fact that the specification gives forEach a great deal of freedom. Specifically, it has the freedom to not preserve encounter order for sequential streams, even though that’s what the implementation currently does, and further that it’s kind of hard to imagine an implementation going out of its way to process sequential sources out of order. But that’s what the spec says, and that’s what it was intended to say.

That said, the wording of the comment about parallel streams is potentially confusing, because it is still possible to misinterpret it. The intent of calling out the parallel case explicitly here was pedagogical; the spec is still perfectly clear with that sentence removed entirely. However, to a reader who is unaware of parallelism, it would be almost impossible to not assume that forEach would preserve encounter order, so this sentence was added to help clarify the motivation. But, as you point out, the desire to treat the sequential case specially is still so powerful that it would be beneficial to clarify further.

More Related Contents:

  1. Custom thread pool in Java 8 parallel stream
  2. Is there a concise way to iterate over a stream with indices in Java 8?
  3. Should I always use a parallel stream when possible?
  4. How to ensure order of processing in java8 streams?
  5. What’s the difference between map() and flatMap() methods in Java 8?
  6. Java 8 lambdas, Function.identity() or t->t
  7. Ignore duplicates when producing map using streams
  8. Can you split a stream into two streams?
  9. Why does parallel stream with lambda in static initializer cause a deadlock?
  10. Adding up BigDecimals using Streams
  11. Java 8 Streams FlatMap method example
  12. Java 8, Streams to find the duplicate elements
  13. Why is Files.lines (and similar Streams) not automatically closed?
  14. How to use a Java8 lambda to sort a stream in reverse order?
  15. Stream.skip behavior with unordered terminal operation
  16. Why does Iterable not provide stream() and parallelStream() methods?
  17. Using streams to convert a list of objects into a string obtained from the toString method
  18. Java 8 Collectors.toMap SortedMap
  19. Java Streams: How to do an efficient “distinct and sort”?
  20. How to group objects when each object could go in multiple groups?
  21. Understanding deeply spliterator characteristics
  22. Why should I use concurrent characteristic in parallel stream with collect?
  23. How to add elements of a Java8 stream into an existing List
  24. How to get a Stream from a float[]
  25. Difference between findAny() and findFirst() in Java 8
  26. Using Java8 Stream to find the highest values from map
  27. Is flatMap guaranteed to be lazy? [duplicate]
  28. How to apply Filtering on groupBy in java streams
  29. Group sequences of values
  30. Java 8 stream map to list of keys sorted by values

Leave a Comment