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

[Roger Riggs]

On Wed, 14 May 2025 19:41:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> A "pure" `CharSequence` *is* immutable, as it does not have mutation methods. Also, why *should* the result be immutable? If someone wants to return a `StringBuilder` for example (for whatever intent), why shouldn't he allowed to do that? In fact, it would be beneficial to return a `StringBuilder` in some cases, as it is more efficient to modify (*iff* wanted) than a `String`. It should be up to the caller and the provider of the implementation to decide about immutability; this is not the API's discretion.
>
>> 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.

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.

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

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