Always confused about this stuff. Anyone can help?
6 Answers
string1.equals(string2)
is the way.
It returns true
if string1
is equals to string2
in value. Else, it will return false
.

- 5,759
- 6
- 35
- 43

- 34,573
- 20
- 89
- 115
-
5Make sure that string1 is not null before you set out to use this method. – Sunny R Gupta Feb 23 '15 at 21:08
string1.equals(string2)
is right way to do it.
String s = "something", t = "maybe something else";
if (s == t) // Legal, but usually results WRONG.
if (s.equals(t)) // RIGHT way to check the two strings
/* == will fail in following case:*/
String s1 = new String("abc");
String s2 = new String("abc");
if(s1==s2) //it will return false

- 12,825
- 9
- 67
- 90

- 788
- 6
- 13
You can either use the == operator or the Object.equals(Object) method.
The == operator checks whether the two subjects are the same object, whereas the equals method checks for equal contents (length and characters).
if(objectA == objectB) {
// objects are the same instance. i.e. compare two memory addresses against each other.
}
if(objectA.equals(objectB)) {
// objects have the same contents. i.e. compare all characters to each other
}
Which you choose depends on your logic - use == if you can and equals if you do not care about performance, it is quite fast anyhow.
String.intern() If you have two strings, you can internate them, i.e. make the JVM create a String pool and returning to you the instance equal to the pool instance (by calling String.intern()). This means that if you have two Strings, you can call String.intern() on both and then use the == operator. String.intern() is however expensive, and should only be used as an optimalization - it only pays off for multiple comparisons.
All in-code Strings are however already internated, so if you are not creating new Strings, you are free to use the == operator. In general, you are pretty safe (and fast) with
if(objectA == objectB || objectA.equals(objectB)) {
}
if you have a mix of the two scenarios. The inline
if(objectA == null ? objectB == null : objectA.equals(objectB)) {
}
can also be quite useful, it also handles null values since String.equals(..) checks for null.

- 8,215
- 5
- 33
- 48
-
+1, this saved me actually. I always thought you could compare Strings with == on a data level, because you can compare Strings with compiler time constant Strings (e.g. `"Hello World!"`) without a problem. I did not knew the JVM backed these within a String pool. Question: is `objectA == objectB || objectA.equals(objectB)` generally faster than just `objectA.equals(objectB)`? – Jori Jun 02 '13 at 13:11
-
No it is not generally faster. For N comparisons, if cost of N == calls is cheaper than one .equals() then it is cheaper. So if N is low and the string length high, then it can be faster. – ThomasRS Jun 02 '13 at 17:46
-
-
Ah, they are internalized within the JVM through a HashTable in order to keep the cost constant? – Jori Jun 04 '13 at 07:12
-
No, but if you would like to internate like 25 strings of for example 7 previously known types, for use in some specific costly operations, you can use a hash table to map the 25 to the 7 string instances and then go on to use the == in subsequent operations. My experience is that it is faster than JVM internating (although, come to think of it, I tried that a long time ago and things might have changed). – ThomasRS Jun 06 '13 at 13:31
You should use some form of the String#equals(Object)
method. However, there is some subtlety in how you should do it:
If you have a string literal then you should use it like this:
"Hello".equals(someString);
This is because the string literal "Hello"
can never be null, so you will never run into a NullPointerException
.
If you have a string and another object then you should use:
myString.equals(myObject);
You can make sure you are actually getting string equality by doing this. For all you know, myObject
could be of a class that always returns true
in its equals
method!
Start with the object less likely to be null because this:
String foo = null;
String bar = "hello";
foo.equals(bar);
will throw a NullPointerException
, but this:
String foo = null;
String bar = "hello";
bar.equals(foo);
will not. String#equals(Object)
will correctly handle the case when its parameter is null, so you only need to worry about the object you are dereferencing--the first object.

- 44,826
- 10
- 98
- 87
==
checks to see if they are actually the same object in memory (which confusingly sometimes is true, since they may both be from the pool), where as equals()
is overridden by java.lang.String
to check each character to ensure true equality. So therefore, equals()
is what you want.

- 2,201
- 16
- 14
-
-
Well == is used for object equality, which is very useful, particularly when you consider types other than String. Consider a case where you are comparing elements within a List for duplicates. You'd write this with a nested for loop, and would not want to compare the same memory object, so you'd use `!=` to ensure they're not the same, but then `equals()` to see if they are "logically" the same. – Melv Mar 15 '11 at 03:10
-
@user - it is there because it is there for every Java reference type ... and every Java primitive type ... and Java does not allow custom operator overloading. – Stephen C Mar 15 '11 at 03:13
-
-
@user You may want to review the difference in Java between identity and state. This SO question might help: http://stackoverflow.com/questions/1692863/what-is-the-difference-between-identity-and-equality-in-oop – nybbler Mar 15 '11 at 03:16
Not forgetting
.equalsIgnoreCase(String)
if you're not worried about that sort of thing...

- 2,247
- 3
- 23
- 30