RFR: 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer

Markus KARG duke at openjdk.org
Sat Mar 15 23:32:58 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.

> Regarding your actual question, 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 PR is actually all about.

Kindly asking for more comments! Something I am missing? Some good reason to *not* adopt my proposal?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2727054654


More information about the core-libs-dev mailing list