131

When testing for equality of String's in Java I have always used equals() because to me this seems to be the most natural method for it. After all, its name already says what it is intended to do. However, a colleague of mine recently told me had been taught to use compareTo() == 0 instead of equals(). This feels unnatural (as compareTo() is meant to provide an ordering and not compare for equality) and even somewhat dangerous (because compareTo() == 0 does not necessarily imply equality in all cases, even though I know it does for String's) to me.

He did not know why he was taught to use compareTo() instead of equals() for String's, and I could also not find any reason why. Is this really a matter of personal taste, or is there any real reason for either method?

Micha Wiedenmann
  • 19,979
  • 21
  • 92
  • 137
Thomas Lötzer
  • 24,832
  • 16
  • 69
  • 55
  • 11
    Strictly speaking at a micro-optimization level, which we should never prematurely speak at, `.equalsIgnoreCase()` is the fastest comparison if it is appropriate, otherwise `.equals()` is what you want. –  Sep 29 '11 at 04:40
  • 4
    This is an old question, but it contains a nugget I wanted to highlight: "`compareTo() == 0` does not necessarily imply equality in all cases". This is absolutely correct! This is exactly what the phrase "consistent with equals" means in the Java API specifications, for example in the [Comparable](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Comparable.html) class specification. For example, String's comparison method is consistent with equals, but BigDecimal's comparison method is *inconsistent* with equals. – Stuart Marks Feb 21 '20 at 16:57

21 Answers21

118

A difference is that "foo".equals((String)null) returns false while "foo".compareTo((String)null) == 0 throws a NullPointerException. So they are not always interchangeable even for Strings.

waxwing
  • 18,547
  • 8
  • 66
  • 82
  • 6
    I think you should also mention this. equals computes the hashcode. The hashcode of two different strings, although rare, can be the same. But when using compareTo(), it checks the strings character by character. So in this case two string will return true if and only if their actual contents are equal. – Ashwin Jun 06 '12 at 05:23
  • 34
    Why do you think that equals computes the hashcode? You can see that this is not the case: http://www.docjar.com/html/api/java/lang/String.java.html (line 1013). – waxwing Jun 06 '12 at 09:04
  • 3
    you are right. I thought that equals and hashcode go hand in hand(equals checks whether both have the same hash code). Then why is it necessary to override both these methods if you decide to override any one of them. – Ashwin Jun 07 '12 at 07:35
  • 3
    It is necessary to override hashcode when we override equals because if the class uses hash-based collections, including HashMap, HashSet, and Hashtable the class wont function properly – varunthacker Jul 06 '12 at 15:29
  • 5
    @Ashwin It is necessary because if .equals returns true, the hashcodes should also be equal. However if hashcodes are equal it doesn't imply .equals should return true – Alan May 13 '15 at 00:22
  • @waxwing This answer isn't as explanatory as one would expect for a novice. – unrealsoul007 May 15 '15 at 09:51
  • This difference is the case because in the source code for String .equals() there is an instanceof check that determines if the given Object argument is a String or not. null will fail this test and the equals function returns false immediately. compareTo() will fail in this case because it lacks this type checking. – TheArchon Feb 26 '16 at 02:55
  • @waxwing How do I know when should I decide to use compareTo() or equlas()? As a beginner it's always confusing to me. –  Jun 24 '16 at 06:02
40

The 2 main differences are that:

  1. equals will take any Object as a parameter, but compareTo will only take Strings.
  2. equals only tells you whether they're equal or not, but compareTo gives information on how the Strings compare lexicographically.

I took a look at the String class code, and the algorithm within compareTo and equals looks basically the same. I believe his opinion was just a matter of taste, and I agree with you -- if all you need to know is the equality of the Strings and not which one comes first lexicographically, then I would use equals.

Kaleb Brasee
  • 51,193
  • 8
  • 108
  • 113
32

When comparing for equality you should use equals(), because it expresses your intent in a clear way.

compareTo() has the additional drawback that it only works on objects that implement the Comparable interface.

This applies in general, not only for Strings.

Alex Weitz
  • 3,199
  • 4
  • 34
  • 57
starblue
  • 55,348
  • 14
  • 97
  • 151
20

compareTo has do do more work if the strings have different lengths. equals can just return false, while compareTo must always examine enough characters to find the sorting order.

robinr
  • 4,376
  • 2
  • 20
  • 18
12

In String Context:
compareTo: Compares two strings lexicographically.
equals: Compares this string to the specified object.

compareTo compares two strings by their characters (at same index) and returns an integer (positive or negative) accordingly.

String s1 = "ab";
String s2 = "ab";
String s3 = "qb";
s1.compareTo(s2); // is 0
s1.compareTo(s3); // is -16
s3.compareTo(s1); // is 16
daboross
  • 716
  • 10
  • 23
VirtualLogic
  • 706
  • 1
  • 10
  • 25
10

compareTo() not only applies to Strings but also any other object because compareTo<T> takes a generic argument T. String is one of the classes that has implemented the compareTo() method by implementing the Comparable interface.(compareTo() is a method fo the comparable Interface). So any class is free to implement the Comparable interface.

But compareTo() gives the ordering of objects, used typically in sorting objects in ascending or descending order while equals() will only talk about the equality and say whether they are equal or not.

ManuPK
  • 11,623
  • 10
  • 57
  • 76
apurva jadhav
  • 101
  • 1
  • 2
9

equals() can be more efficient then compareTo().

A very important difference between compareTo and equals:

"myString".compareTo(null);  //Throws java.lang.NullPointerException
"myString".equals(null);     //Returns false

equals() checks if two objects are the same or not and returns a boolean.

compareTo() (from interface Comparable) returns an integer. It checks which of the two objects is "less than", "equal to" or "greater than" the other. Not all objects can be logically ordered, so a compareTo() method doesn't always make sense.

Note that equals() doesn't define the ordering between objects, which compareTo() does.

Now I advise you to review the source code of both methods to conclude that equals is preferable over compareTo that involves some Math calculations.

Jaimin Patel
  • 4,559
  • 3
  • 32
  • 35
6

It appears that both methods pretty much do the same thing, but the compareTo() method takes in a String, not an Object, and adds some extra functionality on top of the normal equals() method. If all you care about is equality, then the equals() method is the best choice, simply because it makes more sense to the next programmer that takes a look at your code. The time difference between the two different functions shouldn't matter unless you're looping over some huge amount of items. The compareTo() is really useful when you need to know the order of Strings in a collection or when you need to know the difference in length between strings that start with the same sequence of characters.

source: http://java.sun.com/javase/6/docs/api/java/lang/String.html

Scott M.
  • 7,313
  • 30
  • 39
5

equals() should be the method of choice in the case of the OP.

Looking at the implementation of equals() and compareTo() in java.lang.String on grepcode, we can easily see that equals is better if we are just concerned with the equality of two Strings:

equals():

1012  public boolean equals(Object anObject) {
1013 if (this == anObject) {
1014 return true;
1015 }
1016 if (anObject instanceof String) {
1017 String anotherString = (String)anObject;
1018 int n = count;
1019 if (n == anotherString.count) {
1020 char v1[] = value;
1021 char v2[] = anotherString.value;
1022 int i = offset;
1023 int j = anotherString.offset;
1024 while (n-- != 0) {
1025 if (v1[i++] != v2[j++])
1026 return false;
1027 }
1028 return true;
1029 }
1030 }
1031 return false;
1032 }

and compareTo():

1174  public int compareTo(String anotherString) {
1175 int len1 = count;
1176 int len2 = anotherString.count;
1177 int n = Math.min(len1, len2);
1178 char v1[] = value;
1179 char v2[] = anotherString.value;
1180 int i = offset;
1181 int j = anotherString.offset;
1183 if (i == j) {
1184 int k = i;
1185 int lim = n + i;
1186 while (k < lim) {
1187 char c1 = v1[k];
1188 char c2 = v2[k];
1189 if (c1 != c2) {
1190 return c1 - c2;
1191 }
1192 k++;
1193 }
1194 } else {
1195 while (n-- != 0) {
1196 char c1 = v1[i++];
1197 char c2 = v2[j++];
1198 if (c1 != c2) {
1199 return c1 - c2;
1200 }
1201 }
1202 }
1203 return len1 - len2;
1204 }

When one of the strings is a prefix of another, the performance of compareTo() is worse as it still needs to determine the lexicographical ordering while equals() won't worry any more and return false immediately.

In my opinion, we should use these two as they were intended:

  • equals() to check for equality, and
  • compareTo() to find the lexical ordering.
prk
  • 338
  • 1
  • 4
  • 10
3

equals() checks whether two strings are equal or not.It gives boolean value. compareTo() checks whether string object is equal to,greater or smaller to the other string object.It gives result as : 1 if string object is greater 0 if both are equal -1 if string is smaller than other string

eq:

String a = "Amit";
String b = "Sumit";
String c = new String("Amit");
System.out.println(a.equals(c));//true
System.out.println(a.compareTo(c)); //0
System.out.println(a.compareTo(b)); //1
Community
  • 1
  • 1
2

This is an experiment in necromancy :-)

Most answers compare performance and API differences. They miss the fundamental point that the two operations simply have different semantics.

Your intuition is correct. x.equals(y) is not interchangeable with x.compareTo(y) == 0. The first compares identity, while the other compares the notion of 'size'. It is true that in many cases, especially with primitive types, these two co-align.

The general case is this:

If x and y are identical, they share the same 'size': if x.equals(y) is true => x.compareTo(y) is 0.

However, if x and y share the same size, it does not mean they are identical.

if x.compareTo(y) is 0 does not necessarily mean x.equals(y) is true.

A compelling example where identity differs from size would be complex numbers. Assume that the comparison is done by their absolute value. So given two complex numbers: Z1 = a1 + b1*i and Z2 = a2 + b2*i:

Z1.equals(z2) returns true if and only if a1 = a2 and b1 = b2.

However Z1.compareTo(Z2) returns 0 for and infinite number of (a1,b1) and (a2,b2) pairs as long as they satisfy the condition a1^2 + b1^2 == a2^2 + b2^2.

Vitaliy
  • 8,044
  • 7
  • 38
  • 66
2

Equals can be more efficient then compareTo.

If the length of the character sequences in String doesn't match there is no way the Strings are equal so rejection can be much faster.

Moreover if it is same object (identity equality rather then logical equality), it will also be more efficient.

If they also implemented hashCode caching it could be even faster to reject non-equals in case their hashCode's doesn't match.

2
String s1 = "a";
String s2 = "c";

System.out.println(s1.compareTo(s2));
System.out.println(s1.equals(s2));

This prints -2 and false

String s1 = "c";
String s2 = "a";
System.out.println(s1.compareTo(s2));
System.out.println(s1.equals(s2));

This prints 2 and false

String s1 = "c";
String s2 = "c";
System.out.println(s1.compareTo(s2));
System.out.println(s1.equals(s2));

This prints 0 and true

equals returns boolean if and only if both strings match.

compareTo is meant to not just tell if they match but also to tell which String is lesser than the other, and also by how much, lexicographically. This is mostly used while sorting in collection.

2

String.equals() requires invoking instanceof operator while compareTo() requires not. My colleague has noted large performance drop-down caused by excessive numbers of instanceof calls in equals() method, however my test has proved compareTo() to be only slightly faster.

I was using, however, Java 1.6. On other versions (or other JDK vendors) the difference could be larger.

The test compared each-to-each string in 1000 element arrays, repeated 10 times.

Danubian Sailor
  • 1
  • 38
  • 145
  • 223
  • 1
    I guess you must have used very short strings, all of the same length and with high diversity at the first character to get a result where `compareTo()` is faster than `equals()`? But for most sets of real world data `equals()` is much faster than `compareTo() == 0`. `equals()` shines if the strings have a common prefix but different lengths or if they are actually the same object. – x4u Jun 03 '11 at 12:08
  • Well, my test was against hypotesis that instanceof is performance killer, so the strings were short indeed. – Danubian Sailor Jun 03 '11 at 12:25
  • If your string are random and mostly differ in length then the more obvious choice should be equals() method over compareTo() as in most of the cases it will immediately return false if they are not equal in length. – sactiw Jan 18 '14 at 13:07
2

There are certain things which you need to keep in mind while overriding compareTo in Java e.g. Compareto must be consistent with equals and subtraction should not be used for comparing integer fields as they can overflow. check Things to remember while overriding Comparator in Java for details.

Seema Kiran
  • 191
  • 1
  • 2
2
  1. equals can take any Object as a parameter but compareTo can only take String.

  2. when cometo null,compareTo will throw a exception

  3. when you want to know where the diff happen,you can use compareTo.

oers
  • 18,436
  • 13
  • 66
  • 75
littletiger
  • 651
  • 1
  • 8
  • 14
  • compareTo can take any object as argument. As @apurva jadhav said above, comparable takes a generic argument. If you implement comaparable as Comparable, then you are allowed to use only strings. – Gaurav Kumar Mar 30 '15 at 18:54
1

Equals -

1- Override the GetHashCode method to allow a type to work correctly in a hash table.

2- Do not throw an exception in the implementation of an Equals method. Instead, return false for a null argument.

3-

  x.Equals(x) returns true.

  x.Equals(y) returns the same value as y.Equals(x).

  (x.Equals(y) && y.Equals(z)) returns true if and only if x.Equals(z) returns true.

Successive invocations of x.Equals(y) return the same value as long as the object referenced by x and y are not modified.

x.Equals(null) returns false.

4- For some kinds of objects, it is desirable to have Equals test for value equality instead of referential equality. Such implementations of Equals return true if the two objects have the same value, even if they are not the same instance.

For Example -

   Object obj1 = new Object();
   Object obj2 = new Object();
   Console.WriteLine(obj1.Equals(obj2));
   obj1 = obj2; 
   Console.WriteLine(obj1.Equals(obj2)); 

Output :-

False
True

while compareTo -

Compares the current instance with another object of the same type and returns an integer that indicates whether the current instance precedes, follows, or occurs in the same position in the sort order as the other object.

It returns -

Less than zero - This instance precedes obj in the sort order. Zero - This instance occurs in the same position in the sort order as obj. Greater than zero - This instance follows obj in the sort order.

It can throw ArgumentException if object is not the same type as instance.

For example you can visit here.

So I suggest better to use Equals in place of compareTo.

Prabhat Jain
  • 346
  • 1
  • 8
1
  • equals: required for checking equality and restricting duplicates. Many classes of Java Library use this in case they wanted to find duplicates. e.g. HashSet.add(ob1) will only add if that doesn't exist. So if you are extending some classes like this then override equals().

  • compareTo: required for ordering of element. Again for stable sorting you require equality, so there is a return 0.

fedorqui
  • 275,237
  • 103
  • 548
  • 598
1

"equals" compare objects and return true or false and "compare to" return 0 if is true or an number [> 0] or [< 0] if is false here an example:

<!-- language: lang-java -->
//Objects Integer
Integer num1 = 1;
Integer num2 = 1;
//equal
System.out.println(num1.equals(num2));
System.out.println(num1.compareTo(num2));
//New Value
num2 = 3;//set value
//diferent
System.out.println(num1.equals(num2));
System.out.println(num1.compareTo(num2));

Results:

num1.equals(num2) =true
num1.compareTo(num2) =0
num1.equals(num2) =false
num1.compareTo(num2) =-1

Documentation Compare to: https://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html

Documentation Equals : https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#equals(java.lang.Object)

David Hackro
  • 3,652
  • 6
  • 41
  • 61
0

Here one thing is important while using compareTo() over equals() that compareTo works for the classes that implements 'Comparable' interface otherwise it will throw a NullPointerException. String classes implements Comparable interface while StringBuffer does not hence you can use "foo".compareTo("doo") in String object but not in StringBuffer Object.

Pratik
  • 79
  • 1
  • 8
-1

I believe equals and equalsIgnoreCase methods of String return true and false which is useful if you wanted to compare the values of the string object, But in case of implementing compareTo and compareToIgnoreCase methods returns positive, negative and zero value which will be useful in case of sorting.

Micha Wiedenmann
  • 19,979
  • 21
  • 92
  • 137