Usage of Stream::peek in Project
Kevin Rushforth
kevin.rushforth at oracle.com
Fri Sep 3 22:44:11 UTC 2021
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.infeo at 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
More information about the openjfx-dev
mailing list