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

Peter Levart peter.levart at gmail.com
Thu May 28 15:19:45 UTC 2015

On 05/28/2015 04:44 PM, Jason Mehrens wrote:
> Peter,
> Have we considered just embracing CharBuffer.wrap(CharSequence, int, int) work as way to support the old substring behavior? If you dig through the code, that creates a java.nio.StringCharBuffer which is a view of the wrapped string. We could then optimize all of the friend classes to special case CharBuffer and use the bulk get methods.  The nice thing is that there should be no way to create a malicious CharBuffer which should fix the concern mentioned here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/017174.html.
> Regards,
> Jason

Thanks Jason for pointing me to this. So all we need is specialization 
in StringBuilder and perhaps StringJoiner (to not make the String from 
CharSequence immediately if it is a StringCharBuffer). I'll try to 
prepare that specialization patch to see what it takes...

Regards, Peter

>> 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