RFR 8071477: Better Spliterator implementations for String.chars() and String.codePoints()

[Paul Sandoz]

On Jan 23, 2015, at 8:26 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> The webrev looks good.
> 

Thanks.


> 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):

return StreamSupport.intStream(
        () -> new String.IntCharArraySpliterator(value, 0, count, 0),
        Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED,
        false);

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(() ->
        Spliterators.spliterator(
                new CharIterator(),
                length(),
                Spliterator.ORDERED),
        Spliterator.SUBSIZED | Spliterator.SIZED | Spliterator.ORDERED,
        false);

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.

Paul.