On Tue, 8 Oct 2024 13:23:23 GMT, Alan Bateman <al...@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
