GeeCON Prague 2014*
The moose likes Beginning Java and the fly likes a.equals(b) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "a.equals(b)" Watch "a.equals(b)" New topic
Author

a.equals(b)

Jessica Benady
Greenhorn

Joined: Oct 14, 2012
Posts: 8
why is it better to use .equals() and not == to compare 2 strings?
if you use .equals() to compare 2 arrays, are you comparing the addresses in which the data is stored?

Thanks!
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18874
    
  40

Jessica Benady wrote:why is it better to use .equals() and not == to compare 2 strings?
if you use .equals() to compare 2 arrays, are you comparing the addresses in which the data is stored?


"better" may not be the correct word here, as the two operations you mention are different. The "==" is used to compare if the two instances are the exact same instance. The equals() method is used to compare if the value of the object is the same.

As an example, if you created two strings, and have them both with the value of "HELLO", then the "==" operator will report them as two different objects, while the equals() method will report them as having the same value.

So, why does everyone recommend using the equals() method? Because most of the time, for beginners, they mean if the value is equal. And it is probably better to get them using that as the default -- until they understand the difference.

Henry

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Red Smith
Ranch Hand

Joined: Aug 05, 2007
Posts: 136
    
    1
String a = "hello";
String b = "world";


These two statements create four different spots in memory. a and b actually do not refer to locations that contain the string values. a and b refer to spots in memory that hold a number which is the memory address or location of the strings. a and b are technically references that refer to Strings, not actually String objects. For example, (making up the memory addresses):

variable a contains the address of String class data ----------------- memory address 2222 contains String class data
[ 2222 ] ----------------------------------------------------------------------> "hello"

variable b contains the address of String class data ------------------- memory address 3333 contains String class data
[ 3333 ] ----------------------------------------------------------------------> "world"


if you say
a == b

you are asking if the memory address referred to by b refers to is equal to the memory address a refers to. Or is (2222 == 3333)?

If you say a.equals(b) you are asking if the character-strings are equal. ("hello" = "world") ?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Red Smith wrote:String a = "hello";
String b = "world";


These two statements create four different spots in memory. a and b actually do not refer to locations that contain the string values. a and b refer to spots in memory that hold a number which is the memory address or location of the strings. a and b are technically references that refer to Strings, not actually String objects. For example, (making up the memory addresses):


This is not accurate.

1. The variables hold values that are references to String objects. They point to String objects.

2. There is no difference between "Strings" and "actual String objects."

3. We cannot say anything about any memory addresses, because the JLS does not.

if you say
a == b

you are asking if the memory address referred to by b refers to is equal to the memory address a refers to. Or is (2222 == 3333)?


No. You're asking if a and b both point to the same object, or are both null.

Red Smith
Ranch Hand

Joined: Aug 05, 2007
Posts: 136
    
    1
Jeff Verdegan wrote:
Red Smith wrote:String a = "hello";
String b = "world";


These two statements create four different spots in memory. a and b actually do not refer to locations that contain the string values. a and b refer to spots in memory that hold a number which is the memory address or location of the strings. a and b are technically references that refer to Strings, not actually String objects. For example, (making up the memory addresses):


This is not accurate.

1. The variables hold values that are references to String objects. They point to String objects.


Don't see how that is different from my statement : " a and b are technically references that refer to Strings, not actually String objects".


2. There is no difference between "Strings" and "actual String objects."


The statement "refer to Strings, not actually String objects" wasn't making a distinction between Strings and String objects. To be clearer it should have been "refer to String objects, not actually are String objects".

3. We cannot say anything about any memory addresses, because the JLS does not.


Memory address works better for me. Absent that it becomes "some value of unstated type and form that allows us to find the object in memory". Are there situations in which thinking it was a memory address would cause incorrect code to be written?

if you say
a == b

you are asking if the memory address referred to by b refers to is equal to the memory address a refers to. Or is (2222 == 3333)?



No. You're asking if a and b both point to the same object, or are both null.



I forgot about null.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7892
    
  21

Jessica Benady wrote:why is it better to use .equals() and not == to compare 2 strings?

Because equals() actually compares them; '==' does NOT.

For more information, see AvoidTheEqualityOperator.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Red Smith wrote:
1. The variables hold values that are references to String objects. They point to String objects.


Don't see how that is different from my statement : " a and b are technically references that refer to Strings, not actually String objects".


2. There is no difference between "Strings" and "actual String objects."


The statement "refer to Strings, not actually String objects" wasn't making a distinction between Strings and String objects. To be clearer it should have been "refer to String objects, not actually are String objects".


Ah, I see. I mis-parsed your comment.

3. We cannot say anything about any memory addresses, because the JLS does not.


Memory address works better for me. Absent that it becomes "some value of unstated type and form that allows us to find the object in memory".


Then one could simply add something along the lines of, "We can think of references as holding the memory address," showing that it's a reasonable model to aid understanding while not stating it as a fact. I think it's important to keep the distinction between the specification and the implementation clear.

Are there situations in which thinking it was a memory address would cause incorrect code to be written?


Probably not, but nor are there any situations where it's necessary to think of it as a memory address in order to write correct code.

It will probably make no difference either way to a Java programmer, and in the end, in any mainstream JVM implementation, the value of the reference variable probably is in fact the address of the object, or something that could validly be considered to be so. I just tend to harp on this point because I think it provides a good opportunity to help get beginners into the habit of separating specification from implementation in their minds.
 
GeeCON Prague 2014
 
subject: a.equals(b)