I didn't attempt to evaluate that or refactor it in this round. Something for a
future patch. A simplification/refactoring patch for indexOf/lastIndexOf would
certainly be welcome.
Mike
On Nov 19 2012, at 13:12 , Ulf Zibis wrote:
> Hi,
>
> I'm wondering, if we still need
> 1739 static int indexOf(char[] source, int sourceOffset, int sourceCount,
> 1740 char[] target, int targetOffset, int targetCount,
> 1741 int fromIndex) {
> since bug 6924259: Remove offset and count fields from java.lang.String.
>
> I guess we only need
> 1739 static int indexOf(char[] source, int sourceCount,
> 1740 char[] target, int fromIndex) {
> anymore.
>
> -Ulf
>
> Am 19.11.2012 18:49, schrieb Mike Duigou:
>> By amazing coincidence a review for fixing this was issued last week:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012266.html
>>
>> Additional review would be welcome. :-)
>>
>> The patch will probably be ready for push before the end of the month.
>>
>> Mike
>>
>> On Nov 19 2012, at 07:46 , Martin Desruisseaux wrote:
>>
>>> Hello all
>>>
>>> I noticed that AbstractStringBuilder.indexOf(String, int) is implemented as
>>> below:
>>>
>>> public int indexOf(String str, int fromIndex) {
>>> return String.indexOf(value, 0, count,
>>> str.toCharArray(), 0, str.length(), fromIndex);
>>> }
>>>
>>> The call to str.toCharArray() creates a copy of the String.value char[]
>>> array. This copy doesn't seem necessary since the above String.indexOf(...)
>>> method doesn't modify the array content. Shouldn't AbstractStringBuilder
>>> passes directly the reference to the String internal array instead, maybe
>>> using package-privated access to the array?
>>>
>>> Admittedly the cloned array is usually small, but the call to
>>> indexOf(String, int) is often done in a loop.
>>>
>>> Martin
>>>
>>
>
