By Nathan H


2009-02-04 23:17:07 8 Comments

I've been using the == operator in my program to compare all my strings so far. However, I ran into a bug, changed one of them into .equals() instead, and it fixed the bug.

Is == bad? When should it and should it not be used? What's the difference?

23 comments

@Aaron Maenpaa 2009-02-04 23:19:49

== tests for reference equality (whether they are the same object).

.equals() tests for value equality (whether they are logically "equal").

Objects.equals() checks for null before calling .equals() so you don't have to (available as of JDK7, also available in Guava).

String.contentEquals() compares the content of the String with the content of any CharSequence (available since Java 1.5).

Consequently, if you want to test whether two strings have the same value you will probably want to use Objects.equals().

// These two have the same value
new String("test").equals("test") // --> true 

// ... but they are not the same object
new String("test") == "test" // --> false 

// ... neither are these
new String("test") == new String("test") // --> false 

// ... but these are because literals are interned by 
// the compiler and thus refer to the same object
"test" == "test" // --> true 

// ... string literals are concatenated by the compiler
// and the results are interned.
"test" == "te" + "st" // --> true

// ... but you should really just call Objects.equals()
Objects.equals("test", new String("test")) // --> true
Objects.equals(null, "test") // --> false
Objects.equals(null, null) // --> true

You almost always want to use Objects.equals(). In the rare situation where you know you're dealing with interned strings, you can use ==.

From JLS 3.10.5. String Literals:

Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern.

Similar examples can also be found in JLS 3.10.5-1.

@Henrik Paul 2009-02-05 11:03:52

I guess in Java you should say "references" instead of "pointers".

@xocasdashdash 2009-02-27 13:59:45

If you can do things this way, what is the method compareTo useful for?

@Michael Myers 2009-02-27 15:17:01

@Xokas11: compareTo is generally used for sorting.

@user166390 2009-10-25 21:44:26

equals, compareTo and hashCode are all directly related with contracts that must be fulfilled. Only equals and hashCode are polymorphic over all objects. compareTo is from Comparable.

@LiuYan 刘研 2012-06-11 08:37:31

I always think it's a lack of java, if using C++, override operator == method of String class should achieve this

@Vishal 2012-12-06 06:27:54

+1 for "test" == "!test".substring(1) ==> false line. I could have marked it as true only... But as you said, compiler can not determine the results at compile time so these 2 will reference two difference memory locations... I would not have detected it.. :-)

@ahmednabil88 2013-02-28 15:30:12

Just a note equals() exactly Compares this String to another String, BUT equalsIgnoreCase() Compares this String to another String, ignoring case considerations

@SnakeDoc 2013-05-29 14:53:58

Always use equalsIgnoreCase() unless you have a good reason. There is very little performance tradeoff (if any at all) and the safety if provides your program is much higher.

@SnakeDoc 2013-05-29 14:56:55

@LiuYan刘研 I don't think its a lacking feature in Java, using == for multiple things is confusing enough for newbies! A String is an object, and therefore you must call a function on that object to do things with it (compare value in this situation). It would be as if we expected ` 4 == 4 ` to compare the pointer in memory. Different data types must be treated differently. Strings are objects, use them as such!

@LiuYan 刘研 2013-05-31 02:25:17

@SnakeDoc the "confusing" problem is caused by another lack/feature of java: java does not support pointer. == is straighter than .equals(), i will prefer using == to compare objects if java support overriding operator == : "bool MyString::operator == (const char *sAnotherString) {return strcmp(this.m_String, sAnotherString);}". 2 other lack of java (compared to C++): (a) does not support structure data. (b) does not support unsigned integers.

@SnakeDoc 2013-05-31 03:01:59

Java does use pointers, but they are abstracted away to Object References, it was a design decision and provides a whole level of program safety that you cannot always guarantee with pointers, even with a high level of understanding of pointers and pointer arithmetic. Structured Data (Struct) I think is coming in Java8 or may have been pushed back to Java9. Anyways, java is java, with it's lumps and it's pearls. :/

@kajacx 2013-05-31 14:44:15

Also note that .equals() does generally the same as ==, String is one of few exceptions, if you will want to compare your own classes you will need to redefine (override) the .equals() method.

@SnakeDoc 2013-05-31 15:05:37

@kajacx good point +1, I don't think anyone mentioned that yet. If you have a custom object, .edquals() doesn't know what to compare the value of inside your object, so override it and implement your own .equals().

@Bbvarghe 2013-07-24 23:41:15

@SimonNickerson does == compare objects in all objected oriented languages?

@Aaron Maenpaa 2013-07-25 17:05:10

@Bbvarghe No. In C# for instance it's overloaded on strings to do value equality... likewise for Python (which has the is operator to do reference equality).

@Nicolas Barbulesco 2013-08-22 09:06:39

@SnakeDoc — We can say the opposite. Always use equals() unless you have a good reason. What you call safety is entirely context-dependent. For instance, when comparing passwords to determine whether the user has entered the right password, it is unsafe to ignore case differences.

@SnakeDoc 2013-08-23 15:32:21

@NicolasBarbulesco I hope you aren't checking passwords in plain text! Passwords should at the very least be stored as a char[] since String is mutable. (see stackoverflow.com/questions/8881291/…) -- Anyways, it is context dependent of course. My general rule remains: use .equalsIgnoreCase() unless you have a good reason (being case matters or such). Far too many times i've been burned by a user typing in something like SOMESTRING instead of and expected somestring and then report program is busted (caps lock on or something).

@SnakeDoc 2013-08-23 16:26:19

Just to clarify for everyone, .equals() is necessary in Java as it's comparing the Value of two objects, not the object references. == would compare the references (think pointers for simplicity). You can use == to compare two objects, but it won't give you the expected result if the references aren't the same. It may work in some cases, such as with Strings, but isn't reliable. The JVM does some magic when you create a new string with the same value as another in memory, it basically just creates a new reference to the same memory location in some cases. Just use .equals()...

@Nicolas Barbulesco 2013-08-24 11:49:29

@SnakeDoc — ?? String is not mutable.

@Nicolas Barbulesco 2013-08-24 11:56:11

@SnakeDoc — These are security considerations and, as such, they all depend on the context. Not all applications use perfect security — which does not exist, by the way. Passwords are just an example. And if, instead of passwords, you prefer testing equality on hashes of passwords, same situation : test considering case differences, for security.

@SnakeDoc 2013-08-28 19:02:49

@NicolasBarbulesco I don't see where I said they were mutable. Anyways, I find using .equalsIgnoreCase() happens far more often in my work as I'm often dealing with a file (config file) or direct input that is given by users. If you are expecting a hash, then that would be the "good reason" to use .equals(). Otherwise, it would be silly to expect a string of some_value and have your prog break because user had caps lock on (doh!). It's context sensitive, but again, I find I end up using .equalsIgnoreCase() far more often, usually to protect runtime from bad users...

@Marquez 2013-09-18 17:20:07

Another reason why the equality operator does not do what any average human would intuitively think it does is because java does not support operator overloading.

@parasietje 2013-09-19 09:49:07

Small extra note: every time you use "myString" in java code, you are actually creating a private static String with an automatically generated name. Using "myString" twice in the same class should yield the same reference, as the compiler uses the same static class field. It's just syntactic sugar, similar to how an anonymous iterator is created for the construction for(Object o: collection) {}

@David Doumèche 2013-10-17 12:45:39

== is usefull for primitives than you should use instead of Objects when you can.

@Ted Hopp 2013-10-23 23:48:24

@Marquez - On the other hand, operator overloading (as in C++) is why the equality operator sometimes does not do what any average human would intuitively think it does. Concerning the operators in Java, at least you can just look at code and WYSIWYG.

@Andrey Akhmetov 2013-11-09 11:57:42

Regarding concatenation of literals, will this happen at compile-time if String objects created from literals are unconditionally concatenated in a later line?

@Torque 2014-04-10 10:42:14

One minor edit, == is not "much cheaper" than .equals, because the first statement in String.equals reads: if (this == anObject) { return true; }.

@user877329 2014-04-30 12:23:57

@HenrikPaul Yes, thats the Java terminology. But references in Java is more like pointers in C++ terminology, since a reference in C++ behaves like the object it refers to semantically.

@Jeff 2014-06-25 01:05:18

This article has good explanation codenuggets.com/2014/06/24/java-equals-method

@JohnMerlino 2014-07-01 22:36:13

You have to be kidding that == tests only for reference and not value.

@Sudip7 2014-09-26 10:12:18

If you want to compare/check empty strings, then you can use isEmpty() [ from java 1.6].

@Flotolk 2014-10-03 17:20:36

== also only works for primitive data types, like an int. Strings work differently than primitive types

@i_am_zero 2015-01-05 05:09:40

String is an object, == is true when two objects refer to same memory location,equals() is true when two objects have same content stored inside. e.g.Employee object then we can override equals to specify equality for employees (emp-id or name or both), but if we use == then again it means reference equality. If we want our objects (or strings) to be comparable then implement Comparable interface which has method compareTo(). We can then define how the employee objects must be compared (e.g. using emp-id or name or both). This is useful when you want to sort employees (or strings).

@ToolmakerSteve 2015-06-30 18:13:32

@Torque: your conclusion might be incorrect, because most comparisons (in most programs) will be unequal, hence will fail that if test, and have to continue to additional logic. I haven't looked at the implementation, but I presume the next test is a length test. Which usually will be sufficient to distinguish two strings, so the extra cost is usually not huge, but still definitely more than a single comparison.

@Rogue 2015-07-01 17:55:42

@ToolmakerSteve but that's irrelevant, if it fails the reference comparison then using it in the first place wouldn't even be valid (for comparing string value), let alone a more efficient operation.

@Rose 2015-07-09 02:33:59

When you are comparing a known constant with a variable that "potentially" has string, start with the constant as the variable could hold null. That way you don't have to check for nulls. Some thing like this : "SOME_CONSTANT".equals(someVariable)

@ToolmakerSteve 2015-09-09 12:16:03

@Rogue - You misunderstand the point raised by Torque, and my response to it. Obviously, if the functionality one wants is equals, then one must use equals. Torque made an incorrect assertion about performance, and I was pointing that out. [I only bothered to point this out, because so many people up-voted Torque's comment, meaning they failed to recognize the incorrectness of his logic.]

@Glenn Teitelbaum 2015-11-23 22:19:14

"In the rare situation where you know you're dealing with interned strings, you can use ==." Generally you intern so you can use ==. Once you intern you should (as opposed to can) use ==

@ΦXocę 웃 Пepeúpa ツ 2016-07-20 10:29:51

Since java has no pointer it is recommended to use he word references instead, and will strongly discourage to use the word pointer....!!

@okarakose 2016-12-12 13:44:39

what an easy question to take thousands of upvotes :)

@Ole V.V. 2016-12-12 13:47:54

s1.equals(s2) has the potential advantage over Objects.equals(s1, s2) that it tells the reader that I know s1 is not null. And that I will discover if I was wrong about it. Whether it is really an advantage depends on the situation.

@Aaron Maenpaa 2016-12-12 17:10:39

I see where you're coming from, but that's starting to sound like an implicit not null assertion at which point I'd encourage requireNonNull rather than overloading the equals check.

@Maksim 2017-02-02 12:11:39

One more thing to add to make this answer even more awesome: String string1 = "qwe"; String string2 = "qwe"; System.out.println(string1 == string2); // true This is comparison by reference but still it prints true because Java optimises it so 'a' and 'b' refer to the same object. But do not be confused, for all other data types (except String) this will be false. This is a very often asked question during interviews.

@Aaron Maenpaa 2017-02-02 19:21:03

@Maksim That's covered by the "test" == "test" => true example and the comment about interning.

@Maksim 2017-02-03 10:33:44

@AaronMaenpaa, totally agree, just syntactically a bit different. Somebody can be tricked.

@A.Shaheri 2017-07-30 07:25:46

apache provides a StringUtils class which has a more useful method for handling the equation and it checks whether it's null or not.

@Panos 2017-08-14 11:53:27

This was so frustrating to me with java. Thanks posting an answer!

@Dinesh Pathak DK 2017-09-23 07:26:34

why new String("test") == new String("test") this gives false as result ?

@Karan 2017-10-18 17:22:01

new String("test") == new String("test") This gives false as result because two objects are created that have two different references ans == is used to compare references.

@Jarkid 2017-12-09 02:24:21

Another good example: String s1 = "123" + "456"; String s3 = new String("123456"); s3 == s1 // false String s4 = "123456"; s4 == s1 // true

@ASK Arjun 2018-01-27 16:18:50

Just try "str1.equals(str2)" or "str1.equalsIgnoreCase(str2)". This is normally used inside an if else condition statement. You can even try using "comapre" but in that case the retutn type will be Boolean.

@pgras 2009-02-05 08:14:48

I agree with the answer from zacherates.

But what you can do is to call intern() on your non-literal strings.

From zacherates example:

// ... but they are not the same object
new String("test") == "test" ==> false 

If you intern the non-literal String equality is true

new String("test").intern() == "test" ==> true 

@Stephen C 2015-09-25 23:16:13

This is generally not a good idea. Interning is relatively expensive and can (paradoxically) >>increase<< your JVMs memory footprint and increase GC costs. In most cases, these outweigh the performance benefits from using == for string comparison.

@Whatsit 2009-02-04 23:50:40

== tests object references, .equals() tests the string values.

Sometimes it looks as if == compares values, because Java does some behind-the-scenes stuff to make sure identical in-line strings are actually the same object.

For example:

String fooString1 = new String("foo");
String fooString2 = new String("foo");

// Evaluates to false
fooString1 == fooString2;

// Evaluates to true
fooString1.equals(fooString2);

// Evaluates to true, because Java uses the same object
"bar" == "bar";

But beware of nulls!

== handles null strings fine, but calling .equals() from a null string will cause an exception:

String nullString1 = null;
String nullString2 = null;

// Evaluates to true
System.out.print(nullString1 == nullString2);

// Throws a NullPointerException
System.out.print(nullString1.equals(nullString2));

So if you know that fooString1 may be null, tell the reader that by writing

System.out.print(fooString1 != null && fooString1.equals("bar"));

The following is shorter, but it’s less obvious that it checks for null (from Java 7):

System.out.print(Objects.equals(fooString1, "bar"));

@aioobe 2012-07-24 12:44:24

Sometimes it looks as if "==" compares values, -- == do always compare values! (It's just that certain values are references!)

@Jon Coombs 2014-06-20 01:00:46

Alas, there is no static method for isNullOrEmpty(), and no custom overloading of operators, which makes this part of Java clunkier than in C# or Python. And since Java doesn't have extension methods, you can't write your own utility to extend java.lang.String. Right? Any thoughts on subclassing String, adding that static utility method, and then always using MyString instead? A static method with two parameters for doing null-safe comparisons would be nice to have in that subclass too.

@Charles Wood 2014-06-25 16:28:46

Groovy makes this a little easier with the safe navigation operator (groovy.codehaus.org/…), ?.. That would convert nullString1?.equals(nullString2); into an entirely null statement. However, it doesn't help if you have validString?.equals(nullString); -- that still throws an exception.

@Vadzim 2015-03-12 17:19:13

Short methods to compare nullable strings in java: stackoverflow.com/questions/11271554/…

@Panther 2015-04-12 05:05:47

@JonCoombs Java supports the subclassing and creating own method. However few classes are marked final due to certain reasons, String is one of them so we cannot extend. We can create other class and make utility class there which take two string as arguments and implement our logic there. Also for null check some other libraries like spring and apache he good collections of methods, one can use that.

@Paŭlo Ebermann 2016-02-10 20:19:12

@CharlesWood validString.equals(null) should return false, not throw an exception. (It is specified this way for object.equals, and String.equals does follow this.)

@smith 2017-04-11 12:16:00

== compares the reference of the object,and .equals() method compares the string content i.e., String.If you wish to compare the string use .equals() method.It is quite useful

@DoArNa 2018-01-09 20:35:37

You Saved my day. I was calling .equals from a possible null value and sometime was erroring out. +1

@Eddie B 2018-03-10 22:20:13

Be careful as mentioned... String literals are used from the string pool. As such, String s1 = "Java"; String s2 = "Java" ; s1 == s2 : true

@Darrel Lee 2018-07-11 17:11:38

I like to use "literalString".equals(str) syntax. It's compact and avoids null reference.

@user25 2019-01-26 22:08:09

ok, let's keep these 666 votes here

@Rakesh KR 2013-12-18 19:26:34

If the equals() method is present in the java.lang.Object class, and it is expected to check for the equivalence of the state of objects! That means, the contents of the objects. Whereas the == operator is expected to check the actual object instances are same or not.

Example

Consider two different reference variables, str1 and str2:

str1 = new String("abc");
str2 = new String("abc");

If you use the equals()

System.out.println((str1.equals(str2))?"TRUE":"FALSE");

You will get the output as TRUE if you use ==.

System.out.println((str1==str2) ? "TRUE" : "FALSE");

Now you will get the FALSE as output, because both str1 and str2 are pointing to two different objects even though both of them share the same string content. It is because of new String() a new object is created every time.

@Aniket Thakur 2013-07-25 05:08:18

The == operator check if the two references point to the same object or not. .equals() check for the actual string content (value).

Note that the .equals() method belongs to class Object (super class of all classes). You need to override it as per you class requirement, but for String it is already implemented, and it checks whether two strings have the same value or not.

  • Case 1

    String s1 = "Stack Overflow";
    String s2 = "Stack Overflow";
    s1 == s2;      //true
    s1.equals(s2); //true
    

    Reason: String literals created without null are stored in the String pool in the permgen area of heap. So both s1 and s2 point to same object in the pool.

  • Case 2

    String s1 = new String("Stack Overflow");
    String s2 = new String("Stack Overflow");
    s1 == s2;      //false
    s1.equals(s2); //true
    

    Reason: If you create a String object using the new keyword a separate space is allocated to it on the heap.

@Balasubramanian Jayaraman 2013-05-29 02:51:02

You can also use the compareTo() method to compare two Strings. If the compareTo result is 0, then the two strings are equal, otherwise the strings being compared are not equal.

The == compares the references and does not compare the actual strings. If you did create every string using new String(somestring).intern() then you can use the == operator to compare two strings, otherwise equals() or compareTo methods can only be used.

@sham.y 2013-04-30 06:14:22

Operator == is always meant for object reference comparison, whereas the String class .equals() method is overridden for content comparison:

String s1 = new String("abc");
String s2 = new String("abc");
System.out.println(s1 == s2); // It prints false (reference comparison)
System.out.println(s1.equals(s2)); // It prints true (content comparison)

@Saurabh Agarwal 2013-04-02 09:15:33

Java have a String pool under which Java manages the memory allocation for the String objects. See String Pools in Java

When you check (compare) two objects using the == operator it compares the address equality into the string-pool. If the two String objects have the same address references then it returns true, otherwise false. But if you want to compare the contents of two String objects then you must override the equals method.

equals is actually the method of the Object class, but it is Overridden into the String class and a new definition is given which compares the contents of object.

Example:
    stringObjectOne.equals(stringObjectTwo);

But mind it respects the case of String. If you want case insensitive compare then you must go for the equalsIgnoreCase method of the String class.

Let's See:

String one   = "HELLO"; 
String two   = "HELLO"; 
String three = new String("HELLO"); 
String four  = "hello"; 

one == two;   // TRUE
one == three; // FALSE
one == four;  // FALSE

one.equals(two);            // TRUE
one.equals(three);          // TRUE
one.equals(four);           // FALSE
one.equalsIgnoreCase(four); // TRUE

@Mysticial 2013-04-02 09:19:49

I see that this is a late answer to big question. May I ask what it provides that isn't already mentioned in the existing answers?

@AmitG 2013-04-04 08:48:41

@Mysticial he has added equalsIgnoreCase which might be informative for the fresher.

@Ganesh 2013-01-02 14:05:35

== compares Object references.

.equals() compares String values.

Sometimes == gives illusions of comparing String values, as in following cases:

String a="Test";
String b="Test";
if(a==b) ===> true

This is because when you create any String literal, the JVM first searches for that literal in the String pool, and if it finds a match, that same reference will be given to the new String. Because of this, we get:

(a==b) ===> true

                       String Pool
     b -----------------> "test" <-----------------a

However, == fails in the following case:

String a="test";
String b=new String("test");
if (a==b) ===> false

In this case for new String("test") the statement new String will be created on the heap, and that reference will be given to b, so b will be given a reference on the heap, not in String pool.

Now a is pointing to a String in the String pool while b is pointing to a String on the heap. Because of that we get:

if(a==b) ===> false.

                String Pool
     "test" <-------------------- a

                   Heap
     "test" <-------------------- b

While .equals() always compares a value of String so it gives true in both cases:

String a="Test";
String b="Test";
if(a.equals(b)) ===> true

String a="test";
String b=new String("test");
if(a.equals(b)) ===> true

So using .equals() is always better.

@Jacob 2016-03-18 02:14:52

.equals() compares the two instances however equals is implemented to compare them. That might or might not be comparing the output of toString.

@Satyadev 2016-05-07 10:54:24

@Jacob Object class .equals() method compares the instances(references/Address) where as String class .equals() methods is overridden to compare content(chars)

@Roland 2017-11-10 13:34:45

Good pointing out String pool versus Java heap differences as they are certainly not the same. In the string pool Java tries to "cache" String objects to save memory footprint as String is known for being immutable (I hope, I say it correctly here). Also check stackoverflow.com/questions/3052442/…

@James 2012-09-03 04:55:32

All objects are guaranteed to have a .equals() method since Object contains a method, .equals(), that returns a boolean. It is the subclass' job to override this method if a further defining definition is required. Without it (i.e. using ==) only memory addresses are checked between two objects for equality. String overrides this .equals() method and instead of using the memory address it returns the comparison of strings at the character level for equality.

A key note is that strings are stored in one lump pool so once a string is created it is forever stored in a program at the same address. Strings do not change, they are immutable. This is why it is a bad idea to use regular string concatenation if you have a serious of amount of string processing to do. Instead you would use the StringBuilder classes provided. Remember the pointers to this string can change and if you were interested to see if two pointers were the same == would be a fine way to go. Strings themselves do not.

@Ted Hopp 2014-04-10 18:13:50

"once a string is created it is forever stored in a program at the same address" - This is flat-out wrong. Only compile-time constant string expressions (possibly involving final String variables) and strings that your program explicitly interns are stored in what you call a "lump pool". All other String objects are subject to garbage collection once there are no more live references to them, just like any other type of object. Also, while immutability is required for the whole interning mechanism to work, it's otherwise irrelevant to this.

@Shailendra Singh 2016-07-08 15:31:16

String comparison is done either through equals or equalsIgnoreCase method which actually compares the contents of the string. But == sign just check the reference values. For string literals from string pool will work fine for this case. String s1 = new String("a"); String s2 = new String("a"); in this case s1==s2 is false, but s1.equals(s2) is true.

@Faisal Feroz 2009-02-05 10:54:17

Strings in Java are immutable. That means whenever you try to change/modify the string you get a new instance. You cannot change the original string. This has been done so that these string instances can be cached. A typical program contains a lot of string references and caching these instances can decrease the memory footprint and increase the performance of the program.

When using == operator for string comparison you are not comparing the contents of the string, but are actually comparing the memory address. If they are both equal it will return true and false otherwise. Whereas equals in string compares the string contents.

So the question is if all the strings are cached in the system, how come == returns false whereas equals return true? Well, this is possible. If you make a new string like String str = new String("Testing") you end up creating a new string in the cache even if the cache already contains a string having the same content. In short "MyString" == new String("MyString") will always return false.

Java also talks about the function intern() that can be used on a string to make it part of the cache so "MyString" == new String("MyString").intern() will return true.

Note: == operator is much faster than equals just because you are comparing two memory addresses, but you need to be sure that the code isn't creating new String instances in the code. Otherwise you will encounter bugs.

@Uri 2009-02-04 23:20:18

Yea, it's bad...

== means that your two string references are exactly the same object. You may have heard that this is the case because Java keeps sort of a literal table (which it does), but that is not always the case. Some strings are loaded in different ways, constructed from other strings, etc., so you must never assume that two identical strings are stored in the same location.

Equals does the real comparison for you.

@Khaled.K 2013-03-24 14:01:20

Function:

public float simpleSimilarity(String u, String v) {
    String[] a = u.split(" ");
    String[] b = v.split(" ");

    long correct = 0;
    int minLen = Math.min(a.length, b.length);

    for (int i = 0; i < minLen; i++) {
        String aa = a[i];
        String bb = b[i];
        int minWordLength = Math.min(aa.length(), bb.length());

        for (int j = 0; j < minWordLength; j++) {
            if (aa.charAt(j) == bb.charAt(j)) {
                correct++;
            }
        }
    }

    return (float) (((double) correct) / Math.max(u.length(), v.length()));
}

Test:

String a = "This is the first string.";

String b = "this is not 1st string!";

// for exact string comparison, use .equals

boolean exact = a.equals(b);

// For similarity check, there are libraries for this
// Here I'll try a simple example I wrote

float similarity = simple_similarity(a,b);

@Mark 2015-09-10 12:27:50

How does this differ from other answers? and why do it the way you suggest

@Khaled.K 2015-09-10 20:45:42

@Mark The question on difference between == and equals was already answered by other solutions, I just offered a different way to compare strings in a loose way

@Mohamed E. ManSour 2013-06-11 09:17:11

If you're like me, when I first started using Java, I wanted to use the "==" operator to test whether two String instances were equal, but for better or worse, that's not the correct way to do it in Java.

In this tutorial I'll demonstrate several different ways to correctly compare Java strings, starting with the approach I use most of the time. At the end of this Java String comparison tutorial I'll also discuss why the "==" operator doesn't work when comparing Java strings.

Option 1: Java String comparison with the equals method Most of the time (maybe 95% of the time) I compare strings with the equals method of the Java String class, like this:

if (string1.equals(string2))

This String equals method looks at the two Java strings, and if they contain the exact same string of characters, they are considered equal.

Taking a look at a quick String comparison example with the equals method, if the following test were run, the two strings would not be considered equal because the characters are not the exactly the same (the case of the characters is different):

String string1 = "foo";
String string2 = "FOO";

if (string1.equals(string2))
{
    // this line will not print because the
    // java string equals method returns false:
    System.out.println("The two strings are the same.")
}

But, when the two strings contain the exact same string of characters, the equals method will return true, as in this example:

String string1 = "foo";
String string2 = "foo";

// test for equality with the java string equals method
if (string1.equals(string2))
{
    // this line WILL print
    System.out.println("The two strings are the same.")
}

Option 2: String comparison with the equalsIgnoreCase method

In some string comparison tests you'll want to ignore whether the strings are uppercase or lowercase. When you want to test your strings for equality in this case-insensitive manner, use the equalsIgnoreCase method of the String class, like this:

String string1 = "foo";
String string2 = "FOO";

 // java string compare while ignoring case
 if (string1.equalsIgnoreCase(string2))
 {
     // this line WILL print
     System.out.println("Ignoring case, the two strings are the same.")
 }

Option 3: Java String comparison with the compareTo method

There is also a third, less common way to compare Java strings, and that's with the String class compareTo method. If the two strings are exactly the same, the compareTo method will return a value of 0 (zero). Here's a quick example of what this String comparison approach looks like:

String string1 = "foo bar";
String string2 = "foo bar";

// java string compare example
if (string1.compareTo(string2) == 0)
{
    // this line WILL print
    System.out.println("The two strings are the same.")
}

While I'm writing about this concept of equality in Java, it's important to note that the Java language includes an equals method in the base Java Object class. Whenever you're creating your own objects and you want to provide a means to see if two instances of your object are "equal", you should override (and implement) this equals method in your class (in the same way the Java language provides this equality/comparison behavior in the String equals method).

You may want to have a look at this ==, .equals(), compareTo(), and compare()

@JAVA 2013-09-07 18:11:10

for string literals Like String string1 = "foo bar"; String string2 = "foo bar"; you can directly use == operator to test content equality

@user3887038 2018-04-24 12:40:31

In google apps script "compareTo" is not possibe. I tried instaed "equals" This was the only solution that works....

@icza 2013-03-28 12:22:37

== performs a reference equality check, whether the 2 objects (strings in this case) refer to the same object in the memory.

The equals() method will check whether the contents or the states of 2 objects are the same.

Obviously == is faster, but will (might) give false results in many cases if you just want to tell if 2 Strings hold the same text.

Definitely the use of equals() method is recommended.

Don't worry about the performance. Some things to encourage using String.equals():

  1. Implementation of String.equals() first checks for reference equality (using ==), and if the 2 strings are the same by reference, no further calculation is performed!
  2. If the 2 string references are not the same, String.equals() will next check the lengths of the strings. This is also a fast operation because the String class stores the length of the string, no need to count the characters or code points. If the lengths differ, no further check is performed, we know they cannot be equal.
  3. Only if we got this far will the contents of the 2 strings be actually compared, and this will be a short-hand comparison: not all the characters will be compared, if we find a mismatching character (at the same position in the 2 strings), no further characters will be checked.

When all is said and done, even if we have guarantee that the strings are interns, using the equals() method is still not that overhead that one might think, definitely the recommended way. If you want efficient reference check, then use enums where it is guaranteed by the language specification and implementation that the same enum value will be the same object (by reference).

@Razzle Shazl 2018-06-22 06:38:58

Obviously == is faster -- actually the implementation of .equals(String) first checks == before anything else so I would say the speed is about identical.

@Razzle Shazl 2018-06-22 06:51:12

public boolean equals(Object anObject) { if (this == anObject) { return true; } ...

@fabricioflores 2013-01-08 04:37:14

I think that when you define a String you define an object. So you need to use .equals(). When you use primitive data types you use == but with String (and any object) you must use .equals().

@Khaled.K 2013-03-24 14:03:58

Also note that == doesn't work for char[]

@Christian 2015-03-18 21:02:44

"char[]" isn't a primitive data type! It's an array of "char". And arrays aren't primitive data types theirselves.

@Matt Razza 2009-02-04 23:20:47

.equals() compares the data in a class (assuming the function is implemented). == compares pointer locations (location of the object in memory).

== returns true if both objects (NOT TALKING ABOUT PRIMITIVES) point to the SAME object instance. .equals() returns true if the two objects contain the same data equals() Versus == in Java

That may help you.

@cletus 2009-02-04 23:19:49

Yes, == is bad for comparing Strings (any objects really, unless you know they're canonical). == just compares object references. .equals() tests for equality. For Strings, often they'll be the same but as you've discovered, that's not guaranteed always.

@Lijo 2014-01-14 11:07:15

In Java, when the “==” operator is used to compare 2 objects, it checks to see if the objects refer to the same place in memory. In other words, it checks to see if the 2 object names are basically references to the same memory location.

The Java String class actually overrides the default equals() implementation in the Object class – and it overrides the method so that it checks only the values of the strings, not their locations in memory. This means that if you call the equals() method to compare 2 String objects, then as long as the actual sequence of characters is equal, both objects are considered equal.

The == operator checks if the two strings are exactly the same object.

The .equals() method check if the two strings have the same value.

@Jon Coombs 2014-06-20 01:05:22

unless one of them is null, since s.equals(s2) will crash if s is null, causing the comparison to fail. Of course, this doesn't really contradict the answer; it's just a caveat.

@Bludzee 2016-03-04 09:51:20

No, it won't crash, it will throw a NullPointerException, causing the comparison to not take place.

@samkit shah 2012-04-12 05:25:59

== compares the reference value of objects whereas the equals() method present in the java.lang.String class compares the contents of the String object (to another object).

@Jacob Schoen 2012-11-20 17:04:11

not to be nit picky, but the equals() method for String is actually in the String class, not in Object. The default equals() in Object would not compare that the contents are the same, and in fact just returns true when the reference is the same.

@Amandeep Singh 2019-01-27 06:16:12

@JacobSchoen : The above link does not work anymore as GrepCode is down. Here is the alternative for equals Implementation : [Inline Link] (zgrepcode.com/java/openjdk/10.0.2/java.base/java/lang/…)

@Clayton 2009-02-04 23:21:25

The == operator checks to see if the two strings are exactly the same object.

The .equals() method will check if the two strings have the same value.

@Marcin Erbel 2014-10-16 10:32:23

Generally I strongly recommend apache commons library: commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/‌​…, java.lang.String)

@MarekM 2017-06-27 14:48:46

You can also use .compareTo() method if you want to evaluate order of strings.

@duffymo 2009-02-04 23:25:04

String a = new String("foo");
String b = new String("foo");
System.out.println(a == b); // prints false
System.out.println(a.equals(b)); // prints true

Make sure you understand why. It's because the == comparison only compares references; the equals() method does a character-by-character comparison of the contents.

When you call new for a and b, each one gets a new reference that points to the "foo" in the string table. The references are different, but the content is the same.

@coobird 2009-02-04 23:20:08

== compares object references in Java, and that is no exception for String objects.

For comparing the actual contents of objects (including String), one must use the equals method.

If a comparison of two String objects using == turns out to be true, that is because the String objects were interned, and the Java Virtual Machine is having multiple references point to the same instance of String. One should not expect that comparing one String object containing the same contents as another String object using == to evaluate as true.

Related Questions

Sponsored Content

59 Answered Questions

[SOLVED] How do I read / convert an InputStream into a String in Java?

43 Answered Questions

[SOLVED] How do I convert a String to an int in Java?

81 Answered Questions

[SOLVED] How do I make the first letter of a string uppercase in JavaScript?

78 Answered Questions

[SOLVED] Is Java "pass-by-reference" or "pass-by-value"?

47 Answered Questions

9 Answered Questions

[SOLVED] Why is subtracting these two times (in 1927) giving a strange result?

  • 2011-07-27 08:15:58
  • Freewind
  • 589325 View
  • 6333 Score
  • 9 Answer
  • Tags:   java date timezone

19 Answered Questions

[SOLVED] Why is char[] preferred over String for passwords?

57 Answered Questions

[SOLVED] What is the difference between String and string in C#?

33 Answered Questions

[SOLVED] How to split a string in Java

  • 2010-08-14 03:01:53
  • riyana
  • 3443547 View
  • 1430 Score
  • 33 Answer
  • Tags:   java string

16 Answered Questions

[SOLVED] Comparing Java enum members: == or equals()?

  • 2009-11-17 17:26:27
  • Matt Ball
  • 565604 View
  • 1534 Score
  • 16 Answer
  • Tags:   java enums

Sponsored Content