On Wed, 14 May 2025 17:41:12 GMT, Markus KARG <d...@openjdk.org> wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8354724: "stream" -> "reader"
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24728#discussion_r2089454629
