On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <d...@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
