On Feb 19 2013, at 10:50 , Alan Bateman wrote: > On 19/02/2013 05:27, Mike Duigou wrote: >> : >> >> http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/ >> >> From our current testing we found that applications currently using >> subSequence() failed if the equals(), hashCode() and toString() >> implementations did not exactly match String. Additionally we had to change >> String.equals() so that it recognizes can return "true" for matching >> instances of String.SubSequence. >> > I'm not sure about this either, especially with String.equals clearly > specifying that the argument must be a String.
Yes, this patch is rather skanky in that it provides special "not normally something anyone should ever do" handling for String.SubSequence in String.equals(). This patch is an exploration of how far we could go to improve the performance of String.subSequence but it would certainly come at a definite cost. Creating this implementation has revealed usage patterns that are surprising and problematic (even with this patch). > The updates to AbstractStringBuilder append and insert seems unrelated, I > assume you did measurements. Just wondering about separating them out as a > separate patch? They certainly could be separated out. The changes in AbstractStringBuilder bring performance of: StringBuilder.append(string, lower, upper); in line with or improve upon: StringBuilder.append(string.substring(lower, upper)); This change was generated in response to this comment from Martin Desruisseaux which seems entirely reasonable optimization: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010667.html If I update this patch I will add Ulf suggestion of adding AbstractStringBuilder as a third instanceof case. Mike
