Add getChars to CharSequence
Martin Buchholz
martinrb at google.com
Mon May 20 17:55:40 UTC 2013
This is __the__ fundamental question of whether to add
CharSequence.getChars at all.
If none of the objects in the jdk can trust any of the others, they will
spend all of their time making defensive copies and unmodifiable wrappers.
This is the reverse side of whether you can trust any collection class to
not retain a pointer to the array returned by toArray.
Alternatively, we could add a security check to every use of getChars, but
that gets in the way of the performance we're trying to achieve here.
On Mon, May 20, 2013 at 5:22 AM, David Holmes <david.holmes at oracle.com>wrote:
> Hi Martin,
>
> I took a look at this in relation to the other StringBuffer bugs.
>
> I have a concern. Looking at this:
>
> @@ -453,12 +438,11 @@
> public AbstractStringBuilder append(CharSequence s) {
> if (s == null)
> return appendNull();
> - if (s instanceof String)
> - return this.append((String)s);
> - if (s instanceof AbstractStringBuilder)
> - return this.append((**AbstractStringBuilder)s);
> -
> - return this.append(s, 0, s.length());
> + int len = s.length();
> + ensureCapacityInternal(count + len);
> + s.getChars(0, len, value, count);
> + count += len;
> + return this;
> }
>
> it seems that you are passing the ABS internal char[] value, directly to
> an external method (s.getChars) which could be overridden to do whatever it
> wants to the passed in array! Am I missing something?
>
> David
> -----
>
>
> On 11/04/2013 10:40 AM, Martin Buchholz wrote:
>
>> I've often wished that CharSequence had getChars methods, as many of the
>> concrete implementations already do.
>> In jdk8 with default methods, this is possible!
>> This will make some of the String code a little nicer and more efficient.
>>
>> Here's a preliminary patch in this direction, that overlaps with some of
>> the work done in
>>
>> 6206780: (str) Forwarding append methods in String{Buffer,Builder} are
>> inconsistent
>> Summary: update StringBuilder & StringBuffer to consistently handle
>> forwarding to AbstractStringBuilder. Some additional cleanup (removal of
>> refs to sub-classes from AbstractStringBuilder)
>>
>> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**getChars/<http://cr.openjdk.java.net/~martin/webrevs/openjdk8/getChars/>
>>
>> If we have consensus that this is a good idea, I can flesh this out.
>>
>>
More information about the core-libs-dev
mailing list