aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Why is Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Why is " == " on different strings with same content  is returning "false"" Watch "Why is " == " on different strings with same content  is returning "false"" New topic
Author

Why is " == " on different strings with same content is returning "false"

Kareem Qureshi
Ranch Hand

Joined: Mar 14, 2002
Posts: 102
Byte b1 = new Byte("127");
System.out.println(b1.toString().hashCode());
System.out.println(b1.toString().hashCode());
if(b1.toString()==b1.toString())
System.out.println("True");
else
System.out.println("False");
For the above piece of code why is that == is printing "false" when the hashCode gives identical values.
Please advice
Thanks in advance
kareem
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
quick answer:
a == b compares the value of the references a and b
method a.equals(b) compares the content of the Strings a and b


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Kareem Qureshi
Ranch Hand

Joined: Mar 14, 2002
Posts: 102
But Valentin, is it not that with Strings "==" would give same result unless they are created as two new objects.
Because with the Strings a Literal Pool is created and if two different references have same contents then they point to the same.
Please correct me.
Thanks in advance
kareem
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
the invocation to b1.toString() invokes String.valueOf((int)value) where value is the byte value held by the Byte object referenced by b1. In turn, String.valueOf((int)value) invokes Integer.toString(value) which in turn creates a new String everytime it is invoked.
So basically, b1.toString() returns a new String reference, and thus, two references obtained that way will not compare equal with the == operator.
[ March 14, 2002: Message edited by: Valentin Crettaz ]
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Kareem,
I think where you're getting confused is that the method Byte.toString() creates a new String (not a String literal) and returns it. A new String is created every time you call the toString() method. Therefore, when you call this method the first time, you get one String object and when you call it a second time, you get a different String object. Therefore, even though the equals() method would show that they have the same contents, the == operator shows that they are two distinct objects.
Hope that helps,
Corey


SCJP Tipline, etc.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Perhaps I've been hitting the pipe too much again...
I'm pretty darn sure I read that two different objects can have the same hash code generated for them, which gets to the algorithm used to generate the hash codes - I don't know what that is off hand.
Good Luck.


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
the hashcode of an object is based on the object state and not the reference to it.
All String ahaving the same character sequence will have the same hashcode, which makes sense, otherwise how could we use String objects as keys in hashtables?
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4419
    
    5

the hashcode of an object is based on the object state and not the reference to it.
Caveat: This is true for Strings and perhaps other immutable objects. However, basing hashcode on an object's state is not advisable if the object is mutable. If you add an object to a hashtable and its state (hence, also its hashcode) changes sometime thereafter, the object will be lost in the hashtable.
Junilu


Junilu - [How to Ask Questions] [How to Answer Questions]
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
right Junilu, I should have been more precise.
The bottom line was that the reference itself has nothing to do with the hashcode.
I rephrase:
the hashcode of an immutable object is usually based on the object state and not the reference to it.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Originally posted by Valentin Crettaz:
All Strings having the same character sequence will have the same hashcode, which makes sense, otherwise how could we use String objects as keys in hashtables?

Makes sense. Is there a good reason, though, for objects that are not Strings, and are in the same state to generate the same hashcode? Doesn't this only cause extra work for the programmer when dealing with different objects of the same class and state referenced in any given hash table?
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Dirk,
the == operator does not care about the hashcode as far as I know.
As Junilu stated, mutable objects should not base their hashcode on their internal state for the reason invoked above.
Although there are some mutable objects in the JDK (like Dimension,...) that base their hashcode on their state. It depends on what the hashcode for such an object should mean...
Kareem Qureshi
Ranch Hand

Joined: Mar 14, 2002
Posts: 102
Thanks everybody for the enlightening me
kareem
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why is " == " on different strings with same content is returning "false"
 
Similar Threads
toString()
Interesting Question
* Byte == comparision
byteRef.toString() == byteRef.toString() ?
related to "=="