Hi Markus,
On the surface, its looks constructive.
I suspect that many of these cases will turn into discussions about the
right/best/better way to buffer the characters.
The getChars method only helps when extracting to a char array, many of
the current implementations create strings as the intermediary. The
advantage of the 1 character at a time technique is not needing a
(separated allocated) buffer.
Consider taking a few at a time before launching into the whole set.
$.02, Roger
On 5/11/25 2:45 AM, Markus KARG wrote:
Dear Core Libs Team,
I am hereby requesting comments on JDK-8356679.
I would like to invest some time and set up a PR implementing Chen
Liangs's proposal laid out in
https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, the
text of that JBS is copied below. According to the Developer's Guide I
do need to get broad agreement BEFORE filing a PR. Therefore, I kindly
ask everybody to briefly show consent, so I may file a PR.
Thanks
-Markus
Copy from https://bugs.openjdk.org/browse/JDK-8356679:
Recently OpenJDK adopted the new method CharSequence::getChars(int,
int, char[], int) for inclusion in Java 25. As a bulk reader method,
it allows potentially improved efficiency over the previously
available char-by-char reader method CharSequence::charAt(int).
Chen Liang suggested on March 23rd on the core-lib-dev mailing list to
use the new method within the internal source code of OpenJDK for the
implementation of Appendables (see
https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141521.html).
The idea behind this is that the implementations might be more
efficient then.
A quick analysis of the OpenJDK source code identified (at least) the
following classes which could potentially run more efficient when
using CharSequence::getChars internally, thanks to bulk reading and /
or prevention of internal copies / toString() conversions:
* java.io.Writer
* java.io.StringWriter
* java.io.PrintWriter
* java.io.BufferedWriter
* java.io.CharArrayWriter
* java.io.FileWriter
* java.io.OutputStreamWriter
* sun.nio.cs.StreamEncoder
* java.io.PrintStream
* java.nio.CharBuffer
In the sense of "eat your own dog food", it makes sense to implement
Chen's idea in (at least) those classes. Possibly more classes could
get identified when taking a deeper look. Besides the potential
efficiency improvements, it would be a good show case for the usage of
the new API.
The risk of this change should be low, as test coverage exists, and as
the intended changes are solely internal to the implementation. No API
will get changed. In some cases the JavaDocs will get slightly adapted
where it currently exposes the actual implementation (to not lie in
future).
