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