RFR: 8341566: Adding factory for non-synchronized CharSequence Reader [v4]

[Markus KARG]

On Tue, 8 Oct 2024 13:23:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> For `chars()` or `codePoints()`, I believe calling `length()` or not was a matter of implementation convenience instead of the assumption that `length()` can change during calls. Note implementation methods in the anonymous class in `codePoints()` cache the length in local variables. Maybe they just don't want the extra field overhead in the objects they construct.
>
>> @AlanBateman WDYT?
> 
> It's good question as a CharSequence's length can change over time, e.g. StringBuilder. This scenario comes up regularly with InputStreams and Readers connected to files as the file may be growing and shrinking as bytes are read. It would not be surprising to read to EOF/-1 and to not read any further chars, even if the underlying sequence has grow.

I have updated the source code so that it looks up `cs.length()` live each time. Nevertheless, this does not necessarily imply any predictable outcome due to the natur of an interface: Custom implementations could concurrently replace already read characters, but we need to step on with `next` for each `read()`/`skip()`, and `CharSequence` itself does not provide any read cursor means (like files have with `position()`). Because of that, I have added a warning in the JavaDocs, paraphrased from `CharSequence::chars` and `CharSequence::codePoints`: `If the sequence is concurrently modified then the result is undefined.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792267271