Re: RFR: 8318420 : AbstractPipeline invokes overridden method in constructor
On Wed, 18 Oct 2023 09:45:53 GMT, Viktor Klang wrote: > This PR corrects so that `opIsStateful()` is not invoked as a part of the > java.util.stream.AbstractPipeline constructor—as `opIsStateful()` is intended > to be overridden by subclasses, and as their own constructors have not run > when their superclass constructor runs, this means that `opIsStateful()` > cannot base its return value on any class members of the subclass. > > Since `opIsStateful()` is only needed for parallel streams, we can therefor > defer the invocation of `opIsStateful()` until evaluation-time, and as such > we can remove the need for having an instance field to store the result of > the invocation—making Stream instances potentially a tiny bit smaller, > reducing Stream-construction overhead, while still preserving semantics. Pre-submit test seems unrelated to PR - PR Comment: https://git.openjdk.org/jdk/pull/16239#issuecomment-1770498282
RFR: 8318420 : AbstractPipeline invokes overridden method in constructor
This PR corrects so that `opIsStateful()` is not invoked as a part of the java.util.stream.AbstractPipeline constructor—as `opIsStateful()` is intended to be overridden by subclasses, and as their own constructors have not run when their superclass constructor runs, this means that `opIsStateful()` cannot base its return value on any class members of the subclass. Since `opIsStateful()` is only needed for parallel streams, we can therefor defer the invocation of `opIsStateful()` until evaluation-time, and as such we can remove the need for having an instance field to store the result of the invocation—making Stream instances potentially a tiny bit smaller, reducing Stream-construction overhead, while still preserving semantics. - Commit messages: - Avoids calling opIsStateful() during AbstractPipeline constructor Changes: https://git.openjdk.org/jdk/pull/16239/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16239&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318420 Stats: 24 lines in 1 file changed: 15 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16239.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16239/head:pull/16239 PR: https://git.openjdk.org/jdk/pull/16239
Re: RFR: 8318420 : AbstractPipeline invokes overridden method in constructor
On Wed, 18 Oct 2023 09:45:53 GMT, Viktor Klang wrote: > This PR corrects so that `opIsStateful()` is not invoked as a part of the > java.util.stream.AbstractPipeline constructor—as `opIsStateful()` is intended > to be overridden by subclasses, and as their own constructors have not run > when their superclass constructor runs, this means that `opIsStateful()` > cannot base its return value on any class members of the subclass. > > Since `opIsStateful()` is only needed for parallel streams, we can therefor > defer the invocation of `opIsStateful()` until evaluation-time, and as such > we can remove the need for having an instance field to store the result of > the invocation—making Stream instances potentially a tiny bit smaller, > reducing Stream-construction overhead, while still preserving semantics. Marked as reviewed by psandoz (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/16239#pullrequestreview-1685991329
Re: RFR: 8318420 : AbstractPipeline invokes overridden method in constructor
On Wed, 18 Oct 2023 09:45:53 GMT, Viktor Klang wrote: > This PR corrects so that `opIsStateful()` is not invoked as a part of the > java.util.stream.AbstractPipeline constructor—as `opIsStateful()` is intended > to be overridden by subclasses, and as their own constructors have not run > when their superclass constructor runs, this means that `opIsStateful()` > cannot base its return value on any class members of the subclass. > > Since `opIsStateful()` is only needed for parallel streams, we can therefor > defer the invocation of `opIsStateful()` until evaluation-time, and as such > we can remove the need for having an instance field to store the result of > the invocation—making Stream instances potentially a tiny bit smaller, > reducing Stream-construction overhead, while still preserving semantics. @PaulSandoz Would you be up for reviewing this one? :) - PR Comment: https://git.openjdk.org/jdk/pull/16239#issuecomment-1768085268
