Request for Comments: Adding bulk-read method "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)"

[Markus Karg]

As Thanksgiving is over, and as work towards 24-RDP1 should mostly be done,
I think it is a good time to resume our now.

 

To kick-off, below I am repeating my last response to Chen. Kindly asking
everybody to chime in, so we can find a feasible and beneficial conclusion
in this area.

 

-Markus

 

 

Von: Markus Karg [mailto:markus at headcrashing.eu] 
Gesendet: Sonntag, 27. Oktober 2024 09:44
An: 'core-libs-dev'
Betreff: Request for Comments: Adding bulk-read method
"CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)"

 

>Hi Markus,

>Should we drop the srcBigin/srcEnd parameters, as they can be replaced by a
subSequence(srcBegin, srcEnd) call?

Chen, I do understand your idea and while originally I had the same in mind
(it really is appealing!), I came up with a draft using the original
String.getChars() signature instead, due to the following drawbacks:

*	There might exist (possibly lotsof) CharSequence.getChars(int, int,
char[], int) implementations already, as this problem (and the idea how to
solve it) is anything but new. At least such implementations are String,
StringBuilder and StringBuffer. If we come up with a different signature,
then none of these already existing performance boosters will get used by
Reader.of(CharSequence) automatically - at least until they come up with
alias methods. Effectively this leads to (possibly lots) of alias methods.
At least it leads to alias methods in String, StringBuilder, StringBuffer
and CharBuffer. In contrast, when keeping the signature copied from
String.getChars, chances are good that (possibly lots of) implementations
will instantly be supported by Reader.of(CharSequence) without alias
methods. At least, String, StringBuilder and StringBuffer will be.
*	Since decades people are now very used to
StringBuilder.getChars(int, int, char[], int), so (possibly a lot of) people
might simply expect us to come up with that lengthy signature. These people
might be rather confused (if not to say frustrated) when we now force them
to write an intermediate subSequence(int, int) for something that was "such
simple" before.
*	Custom implementations of CharSequence.subSequence could come up
with the (performance-wise "bad") idea of creating copies instead of views.
At least it seems like AbstractStringBuilder is doing that, so chances are
"good" that custom libs will do that, too. For example, because they need it
for safety. Or possibly, because they have a technical reason that enforces
a copy. That would (possibly massively, depending on the actual class) spoil
the idea of performance-boosting this RFC is all about.

-Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241201/92c992a0/attachment.htm>