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

[Markus KARG]

On Wed, 14 May 2025 17:52:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 500:
>> 
>>> 498:      * @since 25
>>> 499:      */
>>> 500:     public String readAllAsString() throws IOException {
>> 
>> Still thinking that declaring `CharSequence` instead of `String` would be beneficial. In case a `Reader` implementation reads from I/O, the implementation could so return a block of native memory without turning it into a Java `String` just for sake of fulfilling the API. In case of servers for example, the information often is passed-through from one I/O source to another I/O sink *unmodified*, which means, the `String` then is turned into *a new* native memory block again; double native memory used *plus* on-heap memory used, without any benefit. Can we please provide I/O APIs which do *not* enforce duplicate copying to and from `String` in such scenarios? 😃
>
> I think this is just a convenience API. A CharSequence-returning API would suit better if it supports arbitrarily long lengths (assuming such a length is in the range of int), while String has implementation limits on lengths and is allowed to fail for this API with OOME. If we make this a CharSequence-returning API that fails with OOME for String implementation limits, I don't think this will please anybody.

As being a server developer for decades I need to say that I would love to have this not for convenience but for the performance reasons explained above, and that `int` length is perfect to speed up 99,9% of all cases. So we should not forget about `CharSequence` hastily.

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

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