(CR#6553074) Unnecessary array copy in AbstractStringBuilder.indexOf(String)? (original) (raw)

Mike Duigou mike.duigou at oracle.com
Mon Nov 19 22:16:49 UTC 2012

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

More information about the core-libs-dev mailing list