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

[Markus KARG]

As recently announced, kindly inviting everybody to contribute / review 
/ comment on https://github.com/openjdk/jdk/pull/21730. Thank you!

-Markus Karg


Am 09.02.2025 um 19:34 schrieb Markus KARG:
>
> Thank you, everybody. As no more comments arrived in the past eight 
> weeks, I assume that there is implicit agreement with my latest 
> arguments (see below), so next I will provide a PR to continue 
> discussion with real Java code at hand.
>
> -Markus
>
>
> Am 01.12.2024 um 19:23 schrieb 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, StringBuilderand 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, StringBufferand 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, StringBuilderand StringBufferwill 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.subSequencecould come up
>>     with the (performance-wise "bad") idea of creating *copies*
>>     instead of views. At least it seems like AbstractStringBuilderis
>>     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/20250209/fb35ef55/attachment-0001.htm>