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.iva...@oracle.com]
*Gesendet:* Donnerstag, 5. Oktober 2023 14:16
*An:* Markus Karg; core-libs
*Cc:* client-libs-...@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().
