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

[Chen Liang]

On Tue, 8 Oct 2024 12:46:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> The question is: Would that make any sense in the end?
>> 
>> Consider the example of `StringBuffer`, which is a `CharSequence`. Wouldn't something like the following be a logical use of `Reader.of(CharSequence)`, where you create a `Reader` for the underlying sequence (which is not yet populated) and then keep reading through the `Reader` until the underlying sequence's data is finished?
>> 
>> 
>> final StringBuffer sb = new StringBuffer();
>> try (final Reader reader = Reader.of(sb)) {
>>     final ContentGenerator cg = new ContentGenerator(sb);
>>     Thread.ofPlatform().start(cg);
>>     int numRead = 0;
>>     while (numRead != -1) {
>>         final char[] content = new char[1024];
>>         numRead = reader.read(content); // wait for content
>>     }
>> }
>> 
>> private class ContentGenerator {
>>     final StringBuffer sb;
>>     ContentGenerator(StringBuffer sb) {
>>         this.sb = sb;
>>     }
>> 
>>     @Override
>>     run() {
>>         while (true) {
>>             String foo = getSomeContent(); // maybe blocking
>>             sb.append(foo);
>>         }
>>     }
>> }
>
>>  I cannot image any scenario where such a program would result in useful outcome.
> 
> An additional point of reference is the current default implementation of CharSequence's `public default IntStream chars()`, which returns an IntStream of char values from the sequence and the implementation of which doesn't consider the `length()` to be fixed.

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.

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

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