Why doesn't String.equals check for equality of char[] value?

Question

I was looking at the source for java.lang.String and noticed the equals method doesn't check whether the char[] backing each String is the same object. Wouldn't this improve compare times?

Supposed improvement contained in this rewritten version:

public boolean equals(Object anObject) {
       if (this == anObject) {
           return true;
       }
       if (anObject instanceof String) {
           String anotherString = (String)anObject;
           int n = count;
           if (n == anotherString.count) {
               char v1[] = value;
               char v2[] = anotherString.value;
               int i = offset;
               int j = anotherString.offset;
               /** Begin Optimization **/
               if(v1==v2 && i==j){
                   return true;
               }
               /** End Optimization **/
               while (n-- != 0) {
                   if (v1[i++] != v2[j++])
                       return false;
               }
               return true;
           }
       }
       return false;
   }

I believe this would improve performance in the case that the two Strings were obtained using String.substring, and possibly even interned Strings.

Does anybody know if there's a reason they chose not to implement it this way?

Update: For anybody who might not know a lot about the implementation of String, there are cases other than the String pool where two String objects can have the same char[] value, int offset, and int count.

Consider the following code:

String x = "I am a String, yo!";
String y = x.split(" ")[3];
String z = x.substring(7,14);

You would end up with a situation like this:

Also apparently the value-sharing feature of Strings has been done away with in Java 7u6 in order to satisfy some benchmarks. So if you spent time making your code run in decent time (or at all) by using String.substring() rather than String concatenation, you're SOL.

Answer 1

Well, you'd need to check the char[], the offset and the count (string length). Since the char[] is only created from within the String class, the only way for all three of those to be equal would be for a String to create a doppelgänger from itself. You can get it to do that (e.g. new String("why?")), but it's not a common use case.

<speculative> I'm not even sure if it would speed anything up. The vast majority of the time, the check will fail, meaning that it's doing extra work for no benefit. That could be offset by branch prediction, but in that case, the few times the check passes, it'll invalidate guesses made by that branch prediction, which could actually slow things down. In other words, if the JVM/CPU tries to optimize for the common case, you'll usually gain nothing, and you'll actually hurt yourself in the rare case (which is what you're trying to optimize). If it doesn't try to optimize that common case, you hurt yourself in most comparisons for the sake of a fairly rare set of comparisons. </speculative>

Answer 2

In Java 7 (see this article), substring() no longer uses the same backing array for the returned String. you would still need to check each character. Basically, String backing char[] are never shared, so you can't

this.value == other.value

Answer 3

I don't understand this question.
The char[] is an internal member of String. If 2 String references are the same (should be since you should be using intern strings) the char[] would be the same.
But for different instances why would you expect the char[] to be the same reference? Strings are immutable and it is not possible for 2 different String objects to share a reference to the same backed array.
Additionally it does not even make sense to use this conditional check even for substring.
I was not aware of the change in Java 7 mentioned in one of the answers but it would be wrong to check for equality of the backed array in this case.
A String object is not only the backing array but its current offset, length etc.
So 2 String objects as a result of substring may be backed by the same char array but can very well contain different (sub)-strings as a content - different offsets in the same char array

Answer 4

Doing such a check on the backing character array will most likely be redundant and is not required.

There are two instances where backing character array object could be identical objects(as other pointed substring method always creates a new backing character array).

Defining a string literal

String a = "Hello";
a.equals("Hello"); // Backing array of "Hello" string literal 
                   // will be same as that of variable a

In this case equals method will determine that the String are equal at the following line even before checking the backing char array.

if (this == anObject) { // From String.equals method
    return true;
}

Using String copy constructor to create another String object

Note that the following code block has no practical value and could never be done in a real code.

String a = "Hello;
String b = new String(a);
a.equals(b);

So rather than doing an extra check to determine if character arrays are same, it is safe to assume they will always be different if the String objects are different.