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

[Markus KARG]

On Sat, 26 Oct 2024 16:26:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Sorry for belated mail response, but I think we should design the API to not take source start/end. I think JIT can escape analysis the new String in practice.

Chen, thank you for chiming in! There is nothing to be sorry, I was just posting *drafts* so far! 🙂 

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.

> Hi Markus, I recommend to continue the discussion on the mailing list instead of on GitHub. Note that GitHub pull requests are only forwarded to the mailing list when it's ready for review, and this proposal is way too early. (And the CSR is too early, too: we should agree on an API surface, such as exception contracts, first)
> 
> Sorry that no one has responded to you yet, but many engineers are busy with other areas, such as pushing the JEPs (as you see, we have a huge number of candidate/submitted JEPs right now, and JDK 24 RDP1 is just 6 weeks away). They are monitoring your core-libs thread, stay assured!

@liach Agreed with all you say, but actually: I **did not expect** any response - in particular on a weekend!

I do not know why apparently people started to *review* the **draft** documents. I just filed it for no other purpose than *taking note of its existence*. 🤔  I thought it is pretty clear to everybody that draft means **"do not review"**. At least this is how I used draft documents in the past 30 years. 🙂

So it seems there was a misunderstanding here regarding my **drafts**. My intention ever was and still is to first finish the discussion *about alternatives (A)...(E)* **on the core-lib mailing list** *first*. My PR and CSR **drafts** are *intentionally* in draft state, which means, they are **not open for review** yet (there is **no** `rfr` label) and solely serve as my public storage for ideas-in-progress in lieu of out-of-band media. The detail discussion you started regarding *details of the PR* was a bit too early IMHO (and surprised me, and actually your duplicate question in the PR confused me), as it is not even decided that we actually go with proposal A, so why discussing *details* of exactly *that* already (my conclusion was, you like to prepare it for the case it becomes the finalist of the mailing list discussion)? Maybe I misunderstood your intent, and you actually wanted to propose alternative (F), then sorry for me not seeing that in the first place.

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

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