RFR: 8077242: Add default method CharSequence.getChars(int srcBegin, int srcEnd, char dst, int dstBegin)
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:
> 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,
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:
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.
More information about the core-libs-dev