A developer pointed out on the openjfx-dev mailing list [1] that we have three calls to Stream::peek in javafx.controls that could be a problem if we rely on it being executed. See the java.util.stream package docs [2] for information on why Stream.peek should not be used in cases where we need to rely on the behavior that all elements in the stream are executed.
Optimizations in JDK 17 make it more likely that we could run into problems.
Here are the calls to Stream::peek:
* javafx.scene.control.MultipleSelectionModelBase: Line 745
* javafx.scene.control.ControlUtils: Line 165 & 171
The statement around line 171 in ControlUtils 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.
[1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-September/031811.html
[2] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects
Optimizations in JDK 17 make it more likely that we could run into problems.
Here are the calls to Stream::peek:
* javafx.scene.control.MultipleSelectionModelBase: Line 745
* javafx.scene.control.ControlUtils: Line 165 & 171
The statement around line 171 in ControlUtils 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.
[1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-September/031811.html
[2] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects