jQuery in Action, 2nd edition*
The moose likes Beginning Java and the fly likes Why strings  are not equal? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Why strings  are not equal?" Watch "Why strings  are not equal?" New topic
Author

Why strings are not equal?

vishal mishra
Ranch Hand

Joined: Jul 12, 2010
Posts: 103
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

Joined: Oct 13, 2005
Posts: 38519
    
  23
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

Joined: Oct 02, 2003
Posts: 11257
    
  16

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.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

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.


Junilu - [How to Ask Questions] [How to Answer Questions]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
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

Joined: Oct 13, 2005
Posts: 38519
    
  23
…and you can get that behaviour reversed if you use +0 and -0 instead of nan
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38519
    
  23
Earlier, I wrote: . . . bit patterns, which you get from the first line, . . .
Sorry. that should read first print statement.
vishal mishra
Ranch Hand

Joined: Jul 12, 2010
Posts: 103
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

Joined: Jul 12, 2010
Posts: 103
Thanks to you all....
vishal mishra
Ranch Hand

Joined: Jul 12, 2010
Posts: 103
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

Joined: Oct 13, 2005
Posts: 38519
    
  23
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why strings are not equal?