• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

a.equals(b)

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
author
Posts: 23956
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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") ?
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 136
1
Netscape Opera Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Hug your destiny! And hug this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic