On Mon, 30 Aug 2021 14:26:23 GMT, Сергей Цыпанов
<[email protected]> wrote:
>> No, I don't think so. The only use of this I can find is at line 1298 which
>> effectively adds a substring: `putStringAt(dstOffset, (String) s, start,
>> end);`
>
> What about lines 582, 1003 and 1175? E.g. 582
>
> public AbstractStringBuilder append(String str) {
> if (str == null) {
> return appendNull();
> }
> int len = str.length();
> ensureCapacityInternal(count + len);
> putStringAt(count, str); // couldn't it be putStringAt(count,
> str, 0, len);
> count += len;
> return this;
> }
>
> Doing this here and in other places allows to rid `private void
> putStringAt(int index, String str)` completely and reduce one nested method
> call, right?
I think you've got the wrong idea: We _want_ to use `putStringAt(int, String)`
now since it can call into `String.getBytes(String, int, byte)`, which has a
simpler and more efficient implementation than `String.getBytes(String, int,
int, byte, int)`, since it avoids a couple of `<< coder` operations. This makes
up for most of the improvement between my initial and the current version of
this patch.
(There's also no nested delegation from `putStringAt(int, String)` to
`putStringAt(int, String, int, int)` in my proposed patch.)
-------------
PR: https://git.openjdk.java.net/jdk/pull/5291
