I think what that endpoint will want is that operations taking CharSequence has a string or stringbuilder/buffer fast path. You just need to design the rewrite so that all CharSequence paths can support the string/stringbuffer/builder fast paths. I think what that means is the actual getChars call should be done in a shared private method, so the callers can, in the future, determine if their char sequence can support that fast path and avoid calling the getChars path. ________________________________ From: Markus KARG <[email protected]> Sent: Wednesday, April 8, 2026 11:32 AM To: Chen Liang <[email protected]>; 'core-libs-dev' <[email protected]> Subject: Re: [External] : Re: 8377939: Improving efficiency of StreamEncoder::append(CharSequence) and StreamEncoder::(CharSequence, int, int)
I will look into such conflicts as soon as there are some. Currently there are none. Can you point me to that work in progress so I can take proceed? Am 07.04.2026 um 17:26 schrieb Chen Liang: Hi Markus, I think there are other proposed enhancements to StreamEncoder that conflicts with your proposal of using char[] - one I heard of proposes using LATIN1 byte[] of a String directly to avoid redundant costs from expanding to char, given often times the output char set is often UTF-8 too. I think you may need to figure out a way to handle such conflicts; most likely your optimization would have to yield to the LATIN1 passthrough optimization when they conflict. Regards, Chen ________________________________ From: core-libs-dev <[email protected]><mailto:[email protected]> on behalf of Markus KARG <[email protected]><mailto:[email protected]> Sent: Sunday, March 1, 2026 3:28 AM To: 'core-libs-dev' <[email protected]><mailto:[email protected]> Subject: [External] : Re: 8377939: Improving efficiency of StreamEncoder::append(CharSequence) and StreamEncoder::(CharSequence, int, int) Chen, I developed this code after you triggered me to do so one year ago, and would like to contribute it now. As Alan told me back then, I must not file a Pull Request without prior discussion on the core-libs mailing list. As nobody responded so far, I kindly ask for your personal agreement on the mailing list to proceed with a PR, so we can progress towards your proposed usage of CharSequence::getChars() within OpenJDK itself. A short public confirmation that you like to see such a PR would be enough IMHO. Thank you! -Markus Am 21.02.2026 um 17:32 schrieb Markus KARG: > Core-Lib Devs, > > as proposed in https://bugs.openjdk.org/browse/JDK-8377939 I would > like to improve efficiency of StreamEncoder::append(CharSequence) (and > in turn OutputStreamWriter::append(CharSequence)) for non-String and > non-CharBuffer values, which seems to be safe and simple: > > * No API or behavior is changed. > * StreamEncoder is final and is only used internally of OpenJDK, and > is not leaked. > * AFAIK the proposed change has no side effects other than being > potentially more efficient. > * Only few classes make actual use of StreamEncoder; > OutputStreamWriter is probably the most popular one, and immediately > provides potential benefit to I/O-bound applications dealing with > StringBuilder-crafted output. > > I have meanwhile coded the change (see diff at > https://github.com/openjdk/jdk/compare/master...mkarg:jdk:StreamEncoder-uses-CharsSequence-getChars)<https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...mkarg:jdk:StreamEncoder-uses-CharsSequence-getChars)__;!!ACWV5N9M2RV99hQ!JCOIF7stnz9JaDW2Buefa2nqGH9PpvUezC1h2tHmxCv0q5C8aHQvkxqELwuPfSQ5XFZXq3thg7AqjDgkuTnNHM8$> > and tested it successfully using OpenJDK Github Actions (see result at > https://github.com/mkarg/jdk/actions/runs/22259626078)<https://urldefense.com/v3/__https://github.com/mkarg/jdk/actions/runs/22259626078)__;!!ACWV5N9M2RV99hQ!JCOIF7stnz9JaDW2Buefa2nqGH9PpvUezC1h2tHmxCv0q5C8aHQvkxqELwuPfSQ5XFZXq3thg7AqjDgk4NCWg4Q$>. > > Are you fine with me opening a Pull Request on Github? > > Thanks! > > -Markus >
