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

[Markus KARG]

On Thu, 15 May 2025 06:27:36 GMT, Johannes Döbler <duke at openjdk.org> wrote:

>> 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.

If the source is a `Reader` **and** target is a `Writer`, yes. But what if it is a native piece of hardware, like an IoT device, which produces / consumes `CharSequence`?

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

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