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

[Chen Liang]

This API seems tricky again... I don't wish to see patterns like:

cs.getChars(begin, end, dest, 0);
if (charSequence.getClass().getModule() != Object.class.getModule()) {
    dest = dest.clone();
}

to ensure the safety of the copy.

Also in this pattern, the dest array is often a shared cache array; sharing
such a cache array to arbitrary charsequence implementations is almost
always inherently unsafe, and this makes destBegin argument pointless as
such a call pollutes the whole dest array.

Regards,
Chen Liang

On Sun, Feb 9, 2025 at 12:50 PM Markus KARG <markus at headcrashing.eu> wrote:

> 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 <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/20250209/8dea295d/attachment.htm>