AW: RFC: 8309726: Reader::readString

[Markus Karg]

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/20231008/af0f4a33/attachment-0001.htm>