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