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
