forEachOrdered's semantic

[Paul Sandoz]

On Jun 15, 2013, at 6:21 AM, Tristan Yan <tristan.yan at oracle.com> wrote:

> "If the stream source is unordered then this degenerates to the same as the regular unordered forEach" - Does it mean we can't guarantee same order even we do forEachOrder in stream which source is unordered?

Correct, because there is no order in which to guarantee.

It's an implementation detail that any is order is imputed. 

A HashSet implementation does not guarantee an order when traversing it's elements. It happens to be an implementation detail that one can impute an order when sequentially operating on an instance, but there is no future guarantees that will be the case for the same instance, or a new instance with the same content, or a new run of the same program.

So while you might see the same results produced when evaluating sequentially (from an arbitrary imputed order) it's just an implementation detail. When evaluating in parallel there are various tricks we can do to reduce memory and/or increase performance if we know an input lacks order.

Here is a little quiz:

  Set<String> s = IntStream.range(0, 100).map(Integer::toString).collect(toSet());
  Set<String> ss = s.parallelStream().limit(10).collect(toSet());

How is the set "s" related to the set "ss" ?

(Use the lambda code base to run the above.)

Paul.