Difference between String#equals and String#contentEquals methods

The String#equals() not only compares the String's contents, but also checks if the other object is also an instance of a String. The String#contentEquals() only compares the contents (the character sequence) and does not check if the other object is also an instance of String. It can be anything as long as it is an implementation of CharSequence which covers a.o. String, StringBuilder, StringBuffer, CharBuffer, etc.

To put it easily: String.contentEquals() is the smarter brother of String.equals(), because it can be more free in the implementation than String.equals().

There are some reasons why there is a separate String.contentEquals() method. The most important reason I think is:

• The equals method has to be reflexive. That means that: x.equals(y) == y.equals(x). This implies that aString.equals(aStringBuffer) would have to be the same as aStringBuffer.equals(aString). This would require the Java API developers to make some special implementation for Strings in the equals() method of StringBuffer, StringBuilder and CharSequence as well. This would be a mess.

This is where String.contentEquals comes in. This is a standalone method that does not have to follow the strict requirements and rules for Object.equals. This way, you can implement the sense of "equal content" more freely. This allows you to make intelligent comparisons between a StringBuffer and a String, for example.

And to say what exactly the difference is:

• String.contentEquals() can compare the contents of a String, a StringBuilder, a StringBuffer, a CharSequence and all derived classes of these. If the parameter is of type String, then String.equals() get executed.

• String.equals() only compares String objects. All other object types are considered as not equal.

• String.contentEquals() can compare StringBuffer and StringBuilder in an intelligent way. It does not call the heavy toString() method, which copies the whole content to a new String object. Instead, it compares with the underlying char[] array, which is great.

This answer was already posted by dbw but he deleted it but he had some very valid points for the difference while comparing execution time, what exceptions are thrown,

If you look at the source code String#equals and String#contentEquals it is clear that there are two overridden methods for String#contentEquals one which take StringBuilder and other CharSequence.
The difference between them,

1. String#contentEquals will throw NPE if the argument supplied is null but String#equals will return false
2. String#equals compares the content only when the argument supplied is instance of String otherwise it will return false in all other cases but on the other hand String#contentEquals checks the content of all the objects which implement interface CharSequence.

3. You can also tweak the code so that String#contentEquals return the wrong result or result you want by overriding equals method of the argument passed as shown below but you can not do those tweaks with String#equals.
   Below code will always produce true as long as s contains any string which is 3 character long

       String s= new String("abc");// "abc";    System.out.println(s.contentEquals(new CharSequence()     {        @Override        public CharSequence subSequence(int arg0, int arg1) {            // TODO Auto-generated method stub            return null;        }        @Override        public int length() {            // TODO Auto-generated method stub            return 0;        }        @Override        public char charAt(int arg0) {            // TODO Auto-generated method stub            return 0;        }        @Override        public boolean equals(Object obj)         {           return true;        }    }));

4. String#contentEquals will be slower then String#Equals in the case when argument supplied is instance of String and the length of both String is same but contents are not equal.
   Example if the string are String s = "madam" and String argPassed = "madan" then s.contentEquals(argPassed) will take almost double execution time in this case as compared to s.equals(argPassed)

5. If the content length are not same for both the strings then function String#contentEquals will have better performance then String#Equals in almost all possible cases.

One more point to add to his answer

6. String#contentEquals of a String object will also compare to the StringBuilder contents and provide the appropriate result while String#Equals will return false