Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why strings are not equal?

 
vishal mishra
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please Explain why this program is giving output "Not Equal"

Program-:



What i know is that the "String".replace('g','G') will return this "StrinG" . Both method will return same string then why these strings are not equal..?

The "==" operater looks in to the bit pattern, so according to this concept string should be equal that is what i am thinking but output is just opposite.

I have executed the above program by replacing capital 'G' with small 'g' and this time program gave output "Equal"
Changed Program-:


I am not getting why program is giving different output on nearly same condition ,so ,please explain me that...

Thank You.
 
Campbell Ritchie
Sheriff
Pie
Posts: 50225
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
vishal mishra wrote: . . . The "==" operater looks in to the bit pattern, . . .
Who on earth told you that? It is quite mistaken.
 
fred rosenberger
lowercase baba
Bartender
Posts: 12196
35
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
vishal mishra wrote: . . . The "==" operater looks in to the bit pattern, . . .
Who on earth told you that? It is quite mistaken.

I don't know...doesn't it look at the bit pattern of what is stored in the reference?

but seriously...

the == operator compares to see if the references are pointing to the same object. Usually, the String.replace() method creates a brand new string. So calling it twice, even if you end up with the same set of characters in your string, will give you two distinct objects. Therefore, the references are not the same.

My guess is that the replace() method is optimized so that if you replace 'g' with 'g', it knows there is no point in doing so. It saves the overhead of building a new object.

And since you are using a string literal, and the same string literal, in both places, they are both in the String pool, and thus are still equal.
 
Junilu Lacar
Bartender
Pie
Posts: 7766
62
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
use equals() to test for equality of Strings and in general, objects. The == operator is used to test for reference equality when it comes to objects.
 
Campbell Ritchie
Sheriff
Pie
Posts: 50225
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
fred rosenberger wrote:. . .doesn't it look at the bit pattern of what is stored in the reference? . . .
Of course it does! Silly me!

Actually, it doesn’t necessarily even look whether the bit patterns are the same for primitives. I shall do something I rarely do: use floats.Try that, and you can see that using the bit patterns, which you get from the first line, gives all sorts of strange results.


Note the difference between == and equals for nans ( )
 
Campbell Ritchie
Sheriff
Pie
Posts: 50225
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
…and you can get that behaviour reversed if you use +0 and -0 instead of nan
 
Campbell Ritchie
Sheriff
Pie
Posts: 50225
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Earlier, I wrote: . . . bit patterns, which you get from the first line, . . .
Sorry. that should read first print statement.
 
vishal mishra
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
fred rosenberger wrote:
Campbell Ritchie wrote:
vishal mishra wrote: . . . The "==" operater looks in to the bit pattern, . . .
Who on earth told you that? It is quite mistaken.

I don't know...doesn't it look at the bit pattern of what is stored in the reference?

but seriously...

the == operator compares to see if the references are pointing to the same object. Usually, the String.replace() method creates a brand new string. So calling it twice, even if you end up with the same set of characters in your string, will give you two distinct objects. Therefore, the references are not the same.

My guess is that the replace() method is optimized so that if you replace 'g' with 'g', it knows there is no point in doing so. It saves the overhead of building a new object.

And since you are using a string literal, and the same string literal, in both places, they are both in the String pool, and thus are still equal.


Thank You for clearing my concepts
 
vishal mishra
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to you all....
 
vishal mishra
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
vishal mishra wrote: . . . The "==" operater looks in to the bit pattern, . . .
Who on earth told you that? It is quite mistaken.


I have read this in Kathy Sierra and Bert Bates.It is written there "==" looks at the bits in the variable, I wrongly write bit pattern,sorry for that...
 
Campbell Ritchie
Sheriff
Pie
Posts: 50225
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I have shown it looks at bits, but not quite all the time.
For reference types it tests whether the addresses of the objects are the same. If two objects occupy the same memory location at the same time, they must both be the same object.

And no, I do not have Irish ancestry
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic