On Tue, 3 Mar 2026 07:32:29 GMT, Alan Bateman <[email protected]> wrote:
>> Liam Miller-Cushon has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains 25
>> additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/master' into strlen
>> - Update copyright year, and add bug number
>> - Merge remote-tracking branch 'origin/master' into strlen
>> - Rename to encodedLength
>> - Rename to getEncodedLength
>> - Merge remote-tracking branch 'origin/master' into strlen
>> - Rename getBytesLength to getByteLength
>> - Update javadoc to refer to 'this {@code String}', not 'the given String'
>> - Clarify that "It" in the javadoc means "This method"
>> - Remove paragraph break
>> - ... and 15 more: https://git.openjdk.org/jdk/compare/8f6875df...d0301f0b
>
> src/java.base/share/classes/java/lang/String.java line 2114:
>
>> 2112: *
>> 2113: * @apiNote This method provides equivalent or better performance
>> than {@link #getBytes(Charset)
>> 2114: * getBytes(cs).length}. This method may allocate memory
>> to compute the length for some charsets.
>
> I think it would be better to drop "This method may allocate memory to
> compute the length for some charsets" from the apiNote. Just looks very out
> of place in String docs that never speak of memory usage.
I have removed it, thanks.
The idea was to try to set expectations that this may perform better than
`getBytes(cs).length` but is not guaranteed to, and in particular isn't
guaranteed to avoid allocating the encoded `byte[]` to run in constant space.
But "equivalent or better performance" already gives the implementation
latitude to fall back to `getBytes(cs).length`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2876913597
