Re: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5]

2022-11-21 Thread Markus KARG
On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote: >> Markus KARG has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull request contains one >> new commi

Re: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5]

2022-11-21 Thread Markus KARG
On Mon, 21 Nov 2022 07:48:01 GMT, Markus KARG wrote: > While we are at it, would you be willing to change the member variables `e` > to `private final` and the `in` to `private`? From what I can see, I don't > see any other class accessing these package private fields. Fixed in 8d29831 :-) --

Re: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5]

2022-11-20 Thread Markus KARG
On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote: > While we are at it, would you be willing to change the member variables `e` > to `private final` and the `in` to `private`? From what I can see, I don't > see any other class accessing these package private fields. Good catch, will do lat

Re: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5]

2022-11-20 Thread Jaikiran Pai
On Sun, 20 Nov 2022 17:41:28 GMT, Markus KARG wrote: >> There is no need to use a temporary Vector within the constructor of >> SynchronizedInputStream, as more efficient (non-synchronized) alternative >> code (like List.of) will do the same in possibly less time. While the >> optimization is

Re: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5]

2022-11-20 Thread Markus KARG
> There is no need to use a temporary Vector within the constructor of > SynchronizedInputStream, as more efficient (non-synchronized) alternative > code (like List.of) will do the same in possibly less time. While the > optimization is not dramatic, it still makes sense to replace Vector unless