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




More information about the core-libs-dev mailing list