RFR: 8354724: Methods in java.io.Reader to read all characters and all lines [v19]

[Johannes Döbler]

On Wed, 14 May 2025 20:52:00 GMT, Markus KARG <duke at openjdk.org> wrote:

>> There's nothing in the CharSequence interface that requires or indicates that the implementation is or is not immutable. Interfaces only have loosely defined contracts, only the signature of the methods, the caller can not hold any more expectations about the semantics of the implementation.
>> Immutable objects are among the best tools we have for making reliable software. 
>> The caller does not have to have a deep knowledge of the implementation to get predictable results.
>> For most OpenJDK public APIs, the objective is to have well defined semantics with no implementation surprises.
>
> Granted in general, but again, it is not the job of *this particular API* to forbid mutation *iff* the caller and / or producer of the object see a good reason for that. This completely overdesigns the target of *this* API. Callers are no dummies, they can read JavaDocs, and they can `.toString()` on their own *iff* needed. Actually, in 30 years I never heard a Java Programmer say "oops, I did not expect `CharSequence` to mutate". With that attitude we could simply deprecate `CharSequence` for removal...!
> 
> BTW, how will you mutate a `CharSequence` if you don't know its actual implementation? Try-and-error? 🤔 Or with "immutable" do you mean *constant* objects (i. e. *the producer* will not modify it after creation)?
> 
> It is a *good* thing not to know what you have in your hands, as you *do not start* making assumptions (like "it is immutable"). I am fond of getting *away* from those restricted semantics, towards a cleaner "do not assume, do not trust" policy.

> > Maybe a good idea at this point if @mkarg could provide an example of server code benefitting from returning a CharSequence...
> 
> The most simple example is a file server. Incidential fact, just today I wrote a function that simply passes JSON documents received in a REST call forward to another server using another REST call (without parsing it). The document is not changed. It is _inefficient_ to force it into a `String` temporarily. This is not untypical, such use cases exists often in server computing.

Seems to me that in your example `Reader.transferTo(Writer)` would be the better choice instead of reading everything into a String or CharSequence and writing it to the next sink.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2090374558