This week's book giveaway is in the Cloud/Virtualization forum. We're giving away four copies of Mastering Corda: Blockchain for Java Developers and have Jamiel Sheikh on-line! See this thread for details.
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
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
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 ]
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
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.
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?
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
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
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.
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?
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...