Thanks for pointing this out. We don't use parallel streams for the
cases in question, so we don't have the concurrency concerns that the
stream docs point out. However, we should take a look and make sure that
the call to peek can't be optimized out, since I expect some
applications will start running with JDK 17 as soon as it is released
(in less than 2 weeks).
I filed a bug to investigate this:
https://bugs.openjdk.java.net/browse/JDK-8273349
-- Kevin
On 9/3/2021 2:27 AM, dev.in...@mailbox.org wrote:
Hey all,
recently I stumbled over the problem of non-executing stream operations, especially
`Stream.peek(Consumer<? super T> action)`, for more Info see [1]. With JDK 17
this behaviour is even extended (e.g. skip() preserves the SIZED attribute of a
stream, making optimizations possible).
Out of curiosity I searched the sources at HEAD of peek(...) usages and found
two problematic classes:
* javafx.scene.control.MultipleSelectionModelBase: Line 745
* javafx.scene.control.ControlsUtil: Line 165 & 171
Especially the statement around line 171 in ControlsUtil is a candidate which might be
"optimized" to not execute the peek(...) at all, while the inline comment
states the call to peek is crucial.
I don't know what the roadmap says about updating to JDK17, but it might
already be a problem and I wantend to raise attention to this.
Best Regards,
Armin
[1]
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects
