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 <mar...@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:mar...@headcrashing.eu <mar...@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
>
>
