27

It came to my attention that there a several ways to compare strings in Java.

I just got in the habit ages ago to use equalsIgnoreCase to avoid having problems with case sensitive strings.

Others on the other hand prefer passing everything in upper or lower case.

From where I stand (even if technically I'm sitting), I don't see a real difference.

Does anybody know if one practice is better than the other? And if so why?

Paul T.
  • 714
  • 1
  • 9
  • 20
Jason Rogers
  • 19,194
  • 27
  • 79
  • 112
  • Neither approach is correct if your goal is to properly compare Unicode strings. You'd need a Unicode library like [ICU4J](http://site.icu-project.org/download), see http://stackoverflow.com/a/6996550 and also http://stackoverflow.com/a/34966206. – glts Jan 23 '16 at 17:09

8 Answers8

54

Use equalsIgnoreCase because it's more readable than converting both Strings to uppercase before a comparison. Readability trumps micro-optimization.

What's more readable?

if (myString.toUpperCase().equals(myOtherString.toUpperCase())) {

or

if (myString.equalsIgnoreCase(myOtherString)) {

I think we can all agree that equalsIgnoreCase is more readable.

Asaph
  • 159,146
  • 25
  • 197
  • 199
  • 4
    Yes but... this is a little bit of a straw man. If you're working with strings where the case doesn't matter then chances are you would've prepped the strings long before the comparison. Say you are matching a user entered word against a dictionary. You'd have the dictionary in a particular case and you'd convert the user string once. – CurtainDog Dec 15 '10 at 04:41
  • @CurtainDog: If you're searching a dictionary, surely you don't want to use `equals` *or* `equalsIgnoreCase` at all. Doing so kind of implies that you're looping through items in the dictionary which wouldn't perform well. Wouldn't you rather use a more suitable data structure like a `HashMap`? – Asaph Dec 15 '10 at 04:50
  • Don't think you can get away from using `equals` if you have a `HashMap` ;) But you are right, the second form is more readable, it's just that (1) I don't see the first form (as written) in the wild much; and (2) there is a place for both forms (where the first form would be comparing strings that have already been prepared for comparison) – CurtainDog Dec 15 '10 at 05:28
  • 1
    @CurtainDog: If you have a dictionary of words (keys) and definitions (values) in a `HashMap`, you use `HashMap.get(Object key)` to retrieve an item from the dictionary. No need for `equals`. Maybe the JVM uses `equals` under the hood to resolve collisions in the `HashMap` but that's all transparent to the high level programmer. – Asaph Dec 15 '10 at 05:41
  • 1
    @Asaph still, equals *is* used, which was the point of that remark so long ago. – Victor Zamanian Jul 08 '16 at 08:39
13

equalsIgnoreCase avoids problems regarding Locale-specific differences (e.g. in Turkish Locale there are two different uppercase "i" letters). On the other hand, Maps only use the equals() method.

koljaTM
  • 10,064
  • 2
  • 40
  • 42
  • I looked this up in the OpenJDK source to make sure, as javadoc does not seem to mention locales. The method compares the strings char by char. If two chars are not the same in upper case, they are compared in lower case which is apparently needed for the Georgian alphabet. This makes equalsIgnoreCase slightly less performant, but more correct. – Dennie Nov 19 '14 at 11:31
  • 3
    so when converting from lower case to upper case in Turkish, how does one deal with the choice? – Adam Jul 03 '15 at 18:24
  • 1
    You need to specify Locale. e.g.: `"turkish".toUpperCase(Locale.ENGLISH)` – Alican Balik May 24 '18 at 11:20
  • @koljaTM Yeah, there are two different uppercase "i" letters... but there are also two different lowercase "i" letters to go along with them, so I'm not sure how that's relevant. https://en.wikipedia.org/wiki/Turkish_alphabet – Jake Griffin Aug 01 '18 at 19:00
  • @JakeGriffin It's relevant because otherwise, [it breaks](https://github.com/scijava/native-lib-loader/issues/39). – tresf Jun 02 '21 at 17:09
3

But the issue in the latter, where you make an assumption that either upper or lower case is passed, you cannot blindly trust the caller. So you have to include an ASSERT statement at the start of the method to make sure that the input is always in the case your are expecting.

rkg
  • 5,559
  • 8
  • 37
  • 50
2

It depends on the use case.

If you're doing a one to one string comparison, equalsIgnoreCase is probably faster, since internally it just uppercases each character as it iterates through the strings (below code is from java.lang.String), which is slightly faster than uppercasing or lowercasing them all before performing the same comparison:

if (ignoreCase) 
{
    // If characters don't match but case may be ignored,
    // try converting both characters to uppercase.
    // If the results match, then the comparison scan should
    // continue.
    char u1 = Character.toUpperCase(c1);
    char u2 = Character.toUpperCase(c2);
    if (u1 == u2) {
        continue;
    }
    // Unfortunately, conversion to uppercase does not work properly
    // for the Georgian alphabet, which has strange rules about case
    // conversion.  So we need to make one last check before
    // exiting.
    if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
        continue;
    }
}

But when you have a situation where you want to do lookups against a data structure full of strings (especially strings that are all in the US Latin/ASCII space) in a case insensitive manner, it will be quicker to trim/lowercase the strings to be checked against and put them in something like a HashSet or HashMap.

This is better than calling equalsIgnoreCase on each element of a List because the slight performance gain of equalsIgnoreCase() is canceled out by the fact that you're basically doing a modified version of contains() against an array, which is O(n). With a pre-normalized string you can check against the entire list of strings with a single contains() call that runs in O(1).

Jim W
  • 492
  • 2
  • 11
2

Neither is better, they both have their uses in different scenarios.

Many times when you have to do string comparisons there is the opportunity to massage at least one of the strings to make it easier to compare, and in these cases you will see strings converted to a particular case, trimmed, etc before being compared.

If, on the other hand, you just want to do an on-the-fly case-insensitive comparison of two strings then feel free to use equalsIgnoreCase, that's what its there for after all. I would caution, however, that if you're seeing a lot of equalsIgnoreCase it could be a code smell.

CurtainDog
  • 3,175
  • 21
  • 17
2

equalsIgnoreCase documentation in jdk 8

  • Compares this String to another String, ignoring case considerations. Two strings are considered equal ignoring case if they are of the same length and corresponding characters in the two strings are equal ignoring case.

    Two characters c1 and c2 are considered the same ignoring case if at least one of the following is true:

    • The two characters are the same (as compared by the == operator)
    • Applying the method java.lang.CharactertoUpperCase(char)to each character produces the same result
    • Applying the method java.lang.CharactertoLowerCase(char) to each character produces the same result

My thoughts:

So using equalsIgnoreCase we iterate through the Strings (only if their size values are the same) comparing each char. In the worst case, we will performance will be O( 3cn ) where n = the size of your strings. We will use no extra space.

Using toUpper() then comparing if the strings are equal, you ALWAYS loop through each string one time, converting all strings to upper, then do an equivalence by reference check (equals()). This is theta(2n + c). But just remember, when you do toUpperCase(), you actually have to create two new Strings because Strings in Java are immutable.

So I would say that equalsIgnoreCase is both more efficient and easier to read.

Again I would consider the use case, because that would be what it comes down to for me. The toUpper approach could be valid in certain use cases, but 98% of the time I use equalsIgnoreCase().

1

Performance wise both are same according to this post:

http://www.params.me/2011/03/stringtolowercasestringtouppercase-vs.html

So I would decide based on code readabilty, in some case toLowerCase() would be better if I am passing a value always to a single method to create objects, otherwise equalsIgnoreCase() makes more sense.

Sileria
  • 15,223
  • 4
  • 49
  • 28
  • 3
    That post does not actually cite any real performance tests, and incorrectly states that "equalsIgnoreCase function uses toLowerCase function internally", which is not true at least for OpenJDK 6. – Lambart Feb 15 '13 at 02:30
0

When I'm working with English-only characters, I always run toUpperCase() or toLowerCase() before I start doing comparisons if I'm calling .equalsIgnoreCase() more than once or if I'm using a switch statement. This way it does the case-change operation only once, and so is more efficient.

For example, in a factory pattern:

public static SuperObject objectFactory(String objectName) {
    switch(objectName.toUpperCase()) {
        case "OBJECT1":
            return new SubObject1();
            break;
        case "OBJECT2":
            return new SubObject2();
            break;
        case "OBJECT3":
            return new SubObject3();
            break;
    }
    return null;
}

(Using a switch statement is slightly faster than if..else if..else blocks for String comparison)

4castle
  • 32,613
  • 11
  • 69
  • 106