RFR: 8077242: Add default method CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) (original) (raw)

Peter Levart peter.levart at gmail.com
Thu May 28 11:37:45 UTC 2015

On 05/10/2015 01:40 AM, Ivan Gerasimov wrote:

Thanks Martin for quick reply!

On 10.05.2015 1:17, Martin Buchholz wrote:

Martin can you recollect if there were any concerns?

It's absolutely true that I dropped the ball on this in jdk8, discouraged by David's message here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/017174.html Ah, yes. I see the problem. I'm not going to suggest a general solution, but would it make sense to at least create an overloaded method AbstractStringBuilder.append(String str, int start, int end)? Here's a draft webrev for this proposal: BUGURL: https://bugs.openjdk.java.net/browse/JDK-8077242 WEBREV: http://cr.openjdk.java.net/~igerasim/8077242/01/webrev/ Sincerely yours, Ivan

Hi Ivan and others,

I think it would be nice to give users back an official way to handle sub-strings as views without copying the characters. After offset & length were dropped from String, String.substring and String.subSequence started copying characters. That's ok for small sub-sequences, but unacceptable for large. If there was an explicit API that allowed old behaviour it could be used in scenarios where this has performance advantage. Here's what I'm thinking about:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ArrayCharSequence/webrev.01/

I know that this somehow conflicts with the efforts of JEP 254: Compact Strings - as it assumes that internal String.value character array can be shared between a String and an ArrayCharSequence, but above proposal could be tweaked to accommodate that too: instead of ArrayCharSequence(String, ...) constructors, there could be an internal or public implementation of a special ConstantLengthCharSequence that was used for the purpose of String sub-sequence views only. In that case the ArrayCharSequence as a public class could be dropped all together and new public String method(s) introduced:

public CharSequence toCharSequenceView(); // and/or public CharSequence subSequenceView(int start, int end);

...that returned private implementation of a ConstantLengthCharSequence.

I wonder how the above proposal when combined with StringJoiner based solution of optimizing String.replace compares with your index-array based specialized solution.

Regards, Peter

More information about the core-libs-dev mailing list