<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi Markus,<br>
<br>
You posted it to the wrong list, it belongs on core-libs-dev.<br>
<br>
-- <br>
Regards,<br>
Alexey<br>
<br>
<div class="moz-cite-prefix">On 10/06/2023 12:35, Markus Karg wrote:<br>
</div>
<blockquote type="cite" cite="mid:000001d99b8f$b6e1a4d0$24a4ee70$@eu">
<meta name="Generator" content="Microsoft Word 12 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#172B4D;background:white">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:</span><span style="color:#172B4D"><br>
<br>
<span style="background:white">* Files.readString(Path) -
Fast, convenient, uses JLA.newStringNoRepl, only works
with files (not with sockets or other sources).</span><br>
<span style="background:white">* new
String(inputStream.readAllBytes()) - Fast, complex,
enforces dealing with an array in user code, cannot use
JLA.newStringNoRepl.</span><br>
<span style="background:white">*
bufferedReader.lines().collect(StringBuilder::new,
StringBuilder::append, StringBuilder::append).toString();
- Complex, enforces dealing with a stream in user code,
doesn't use JLA.newStringNoRepl.</span><br>
<span style="background:white">*
reader.transferTo(stringWriter); stringWriter.toString();
- Medium convient, medium performance, synchronized as it
relies on StringBuffer instead of StringBuilder.</span><br>
<span style="background:white">* Custom loop using char[] of
various default sizes (some 8k, some 16k, some
configurable) - Slow, complex, doesn't use
JLA.newStringNoRepl.</span><br>
<span style="background:white">* etc.</span><br>
<br>
<span style="background:white">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.</span><br>
<br>
<span style="background:white">I think we can do better,
hence I'd like to propose the introduction of a new
Reader::readString method. The benefits are:</span><br>
<span style="background:white">* Guidance. The introduction
of this method is a clear signal to all application
programmers to use *this* one by default.</span><br>
<span style="background:white">* Convenience. It couldn't be
any easier for the caller.</span><br>
<span style="background:white">* Performance. OpenJDK
committers can optimize it for both, convenience, speed,
reduced GC stress, and memory consumption, at the very
same time.</span><br>
<span style="background:white">* 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().<o:p></o:p></span></span></p>
</div>
</blockquote>
<br>
</body>
</html>