RFC: 8309726: Reader::readString

[Aleksei Ivanov]

Hi Markus,

I see. I didn't know there was a feature which automatically sends 
emails about submitted enhancements. It's the first time I see such an 
email.

You changed the component from client-libs to core-libs in JDK-8309726, 
which is correct, but the email had already been sent.

-- 
Regards,
Alexey

On 08/10/2023 14:14, Markus Karg wrote:
>
> Aleksei,
>
> thank you for reposting to the "right" mailing list, and everybody 
> thank you for contribution to this discussion, but please note that it 
> was *not me* who posted to the "wrong" list: In fact, I just opened 
> this issue https://bugs.openjdk.org/browse/JDK-8309726, and it was 
> *the OpenJDK infrastructure* which in turn posted to the "wrong" list. 
> I am not aware who is in charge to fix this, but *I* cannot change 
> this behvior. Maybe the one in charge is reading this and can fix it?
>
> Thanks
>
> -Markus
>
> *Von:*Aleksei Ivanov [mailto:alexey.ivanov at oracle.com]
> *Gesendet:* Donnerstag, 5. Oktober 2023 14:16
> *An:* Markus Karg; core-libs
> *Cc:* client-libs-dev at openjdk.org
> *Betreff:* Re: RFC: 8309726: Reader::readString
>
> Hi Markus,
>
> You posted it to the wrong list, it belongs on core-libs-dev.
>
> -- 
> Regards,
> Alexey
>
> On 10/06/2023 12:35, Markus Karg wrote:
>
>     By analyzing several existing applications I noticed that many of
>     them need to read a String from an input source (be it an input
>     stream or a reader), and there are a lot of solutions applied
>     which all are more or less suboptimal:
>
>     * Files.readString(Path) - Fast, convenient, uses
>     JLA.newStringNoRepl, only works with files (not with sockets or
>     other sources).
>     * new String(inputStream.readAllBytes()) - Fast, complex, enforces
>     dealing with an array in user code, cannot use JLA.newStringNoRepl.
>     * bufferedReader.lines().collect(StringBuilder::new,
>     StringBuilder::append, StringBuilder::append).toString(); -
>     Complex, enforces dealing with a stream in user code, doesn't use
>     JLA.newStringNoRepl.
>     * reader.transferTo(stringWriter); stringWriter.toString(); -
>     Medium convient, medium performance, synchronized as it relies on
>     StringBuffer instead of StringBuilder.
>     * Custom loop using char[] of various default sizes (some 8k, some
>     16k, some configurable) - Slow, complex, doesn't use
>     JLA.newStringNoRepl.
>     * etc.
>
>     Checking back with the particular authors of these applications I
>     noticed that what they all miss is (a) guidance which solution is
>     "best" (mostly thinking in speed, but also in reduced GC stress
>     and memory consumption), (b) something convenient like
>     Files.readString() but working with any reader implementation, not
>     just with files.
>
>     I think we can do better, hence I'd like to propose the
>     introduction of a new Reader::readString method. The benefits are:
>     * Guidance. The introduction of this method is a clear signal to
>     all application programmers to use *this* one by default.
>     * Convenience. It couldn't be any easier for the caller.
>     * Performance. OpenJDK committers can optimize it for both,
>     convenience, speed, reduced GC stress, and memory consumption, at
>     the very same time.
>     * Optimizable. Each Reader implementation can choose an algorithm
>     fitting best its own needs, while java.io.Reader itself provides a
>     convenient default implementation based on a loop over this.read().
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20231011/f11a368a/attachment.htm>