compareTo() vs. equals()

Question

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?

Suez

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. – Azal

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 class specification. For example, String's comparison method is consistent with equals, but BigDecimal's comparison method is inconsistent with equals. – Guava

Answer 1

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.

Curb

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. – Kong

Why do you think that equals computes the hashcode? You can see that this is not the case: docjar.com/html/api/java/lang/String.java.html (line 1013). – Curb

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. – Kong

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 – Upland

@Kong 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 – Concealment

@Curb This answer isn't as explanatory as one would expect for a novice. – Radiophotograph

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. – Bronnie

@Curb How do I know when should I decide to use compareTo() or equlas()? As a beginner it's always confusing to me. – Jotting

Answer 2

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.

Language

Answer 3

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.

Packsaddle

Answer 4

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.

Geniegenii

Answer 5

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

Monoicous

Answer 6

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.

Friedman

Answer 7

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.

Brasilin

Answer 8

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

Ulland

Answer 9

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.

Cene

Answer 10

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

Burned

Answer 11

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.

Rookery

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. – Marguerita

Well, my test was against hypotesis that instanceof is performance killer, so the strings were short indeed. – Rookery

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. – Marmalade

Answer 12

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.

Oldie

Answer 13

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.

Lectern

compareTo can take any object as argument. As @apurva jadhav said above, comparable takes a generic argument. If you implement comaparable as Comparable<String>, then you are allowed to use only strings. – Lungan

Answer 14

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.

Inglorious

x.equals(y) does not mean Identity, it means Equality. Identity is compared using x == y for user-defined types in Java. – Thorp

Answer 15

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.

Davenport

Answer 16

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.

Vierno

Answer 17

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.

Baloney

There is no GetHashCode() method. Do you mean hashCode()? – Somatoplasm

Answer 18

• 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.

Byrdie

Answer 19

"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)

Cargo

Answer 20

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.

Lockhart

Answer 21

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.

Urology