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

Markus KARG duke at openjdk.org
Tue Oct 8 12:10:59 UTC 2024


On Tue, 8 Oct 2024 11:54:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - renamed source to cs; cs is final; close sets boolean; no adouble reference to source
>>  - Fixed Typo: 'resect' -> 'respect'
>>  - Improved wording: 'The returned reader supports the {@link #mark mark()} operation'
>>  - Improved wording: 'Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence'
>>  - test for generic read(char, int, int) case
>>  - Remove useless test
>
> src/java.base/share/classes/java/io/Reader.java line 174:
> 
>> 172: 
>> 173:         return new Reader() {
>> 174:             private final int length = cs.length();
> 
> Hello Markus, as far as I can see, a  `CharSequence` is allowed to have a non-fixed `length()` (typically allowed to increase?). Is there a reason why the length is captured at construction time instead of being evaluated during the read operations of the `Reader`?

As the anonymous class MUST NOT be used with be used with multiple threads, I always have seen the `CharSequence` as *fixed/static* text in the moment the `Reader` is getting used. But indeed, technically one could interleave `Reader::read()` invocations by `CharSequence.append()` (or even worse, `CharSequence.delete()`) invocations. The question is: Would that make *any* sense in the end? I mean, what happens if one has `read()` text that in the next step gets `delete()`'d? I cannot image *any* scenario where such a program would result in *useful* outcome.

<fun>The fact that nobody so far (before you) brought up this question seems to proof that nobody (besides you) would write such a program. 😄 </fun>

So I would plea for clearly saying in the JavaDocs that `cs` MUST NOT be modified before `close()` is called. Every other solution implies strange side effects and slower and error-prone implementation of both, anoynous reader *and* test.

@AlanBateman WDYT?

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

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


More information about the core-libs-dev mailing list