RFR 8071477: Better Spliterator implementations for String.chars() and String.codePoints()
paul.sandoz at oracle.com
Fri Jan 23 20:51:23 UTC 2015
On Jan 23, 2015, at 8:26 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> The webrev looks good.
> However I have a question regarding the spec of CharsSequence.chars/codePoints(). It says
> * <p>If the sequence is mutated while the stream is being read, the
> * result is undefined.
> But it looks like ABS.chars/codePoints() "predefine/fix" the size of the resulting stream when
> the stream is being created/initialized.
No, because a supplier of a spliterator is used (as is the case for the CharSequence implementations):
() -> new String.IntCharArraySpliterator(value, 0, count, 0),
Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
the "value" and the "count" will be obtained when the terminal operation executed not when the Stream is created and returned.
> The possible corner case is that the "size/length" of
> ABS is changed between the stream is created and read?
> I would assume the CharSequence default implementation will go after the real size, even
> a "length()" is passed in as an estimated size during creation, but the optimized implementation
> will only return the length/size of char/cp when the stream is created. A behavior change?
For CharSequence.chars() the length() is taken as the exact size:
return StreamSupport.intStream(() ->
Spliterator.SUBSIZED | Spliterator.SIZED | Spliterator.ORDERED,
and (like above) is called when the terminal operation executes. So it's equivalent behaviour regarding when the snapshot of the sequence length is obtained.
More information about the core-libs-dev