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
