Hello, Rémi! People don't use forEachOrdered not because they don't care about order, but because they don't care about parallelism and forEach does the same (for sequential stream) with a shorter name. Similar to foldLeft. Currently people often use reduce instead of missing foldLeft, feeding reduce with non-associative operation, identity element violating identity properties and specifying a bogus combiner, because they just don't care about parallelism. Here are some examples:
https://github.com/TheDIM47/RestSample/blob/1cc0c6f9f4c6a1980b608ddcbc743dcb3f17eeb9/src/main/java/com/juliasoft/rest/CalculatorService.java#L20 .reduce(values[0], (x, y) -> x - y); -- associativity is clearly violated https://github.com/mary-mogreen/java8_training/blob/8b0bb9e87905def30757b7d8aedbb950b936b24d/src/ch02/ex10/StreamUtils.java#L19 .reduce(0.0, (x, y) -> {count.incrementAndGet();return x + y;}); -- op has side-effect and will definitely yield the wrong result in parallel Well it's hard to search through github as it's filled with student projects. Nevertheless people sometimes recommend to use reduce when no combiner is possible: https://stackoverflow.com/a/43660838 Note that answer is upvoted and accepted, so you may expect that similar code appears in the wild. Some libraries even provide a "convenient" no-combiner which throws: https://github.com/poetix/protonpack/blob/0ba7e9d4eb63de3e7d40755c562e9a64b05ea927/src/main/java/com/codepoetics/protonpack/collectors/CollectorUtils.java#L125 Also people often try to use non-associative op in reduce and wonder why it works incorrectly in parallel: https://stackoverflow.com/q/32799937 https://stackoverflow.com/q/33375335 You may only guess how many people use reduce incorrectly in real projects. Were foldLeft alternative present, people would use it and their code would be correct (though not so fast) even when .parallel() is specified. Sometimes people ask questions where the answer would be "Use foldLeft... ah, it doesn't exist": https://stackoverflow.com/q/30736587 With best regards, Tagir Valeev. On Wed, Aug 16, 2017 at 7:56 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > Yes, > reconsidering old decision is healthy, but you need provide some data/good > reason > to explain what has changed. > By example, I'm curious about the number of occurrences of forEachOrdered in > the wild, given that fold left (a kind of reduce) will be even less used > than a forEachOrdered (a kind of forEach). > > Rémi > > > > On August 14, 2017 2:58:18 AM GMT+02:00, Tagir Valeev <amae...@gmail.com> > wrote: >> >> Hello, Remi! >> >> Yes, I know. But times change and old decisions could be reconsidered. >> After all, forEachOrdered was included and its semantics is essentially the >> same as in foldLeft with respect to parallel streams. >> >> With best regards, >> Tagir Valeev. >> >> 14 авг. 2017 г. 2:45 AM пользователь "Remi Forax" <fo...@univ-mlv.fr> >> написал: >>> >>> Hi Tagir, >>> foldLeft (and foldRight) were intentionally not included in the Stream >>> API because as you know, their semantics is too strong to be useful for >>> parallel streams. >>> >>> regards, >>> Rémi >>> >>> ----- Mail original ----- >>> > De: "Tagir Valeev" <amae...@gmail.com> >>> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> >>> > Envoyé: Dimanche 13 Août 2017 15:27:36 >>> > Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation >>> >>> > Please review the preliminary implementation for Stream foldLeft and >>> > foldRight operations: >>> > >>> > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/ >>> > >>> > This implementation has no tests yet. Before writing them I'd like to >>> > be sure that this enhancement could be accepted in general (or >>> > probably foldLeft is accepted and foldRight is not?) Could anybody >>> > sponsor it when it will be complete? >>> > >>> > Thank you in advance! >>> > >>> > Tagir Valeev. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
