RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer
Markus KARG
duke at openjdk.org
Sat Mar 22 18:26:11 UTC 2025
On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> wrote:
> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
Alternative C: `sealed interface TrustedCharSource permits String, AbstractStringBuilder, CharBuffer { void getChars(int, int, char[], int) }`
As a mix of Alternative A and Alternative B we could provide a sealed interface, allowing the fast-path implementation *solely* for the JRE-internal `CharSequence` implementations, while all custom implementations go with `.subsequence(int, int).getChar(char[], int)`.
This solution would allow to have best possible performance for the JRE-internal classes, while custom classes can be accessed safely but (possibly very) slowly only.
Personally still voting for Alternative A, but if I am the only one, I'd rather go with C than B.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2745399414
More information about the core-libs-dev
mailing list