This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.

What is the result of attempting to compile and run the program?

a. Prints: false,false
b. Prints: false,true
c. Prints: true,false d. Prints: true,true
e. Compile-time error
f. Run-time error
g. None of the above

sb1 & sb2 are unequal but their hashcodes may be equal or may not be equal. so b2 will be true or false, you can't say.
my understanding is if the hashcodes of two objects are unequal then the objects can't be equal but if the hashcodes are equal it doesn't necessarily means objects are equal.

sb1 & sb2 are unequal but their hashcodes may be equal or may not be equal. so b2 will be true or false, you can't say.
my understanding is if the hashcodes of two objects are unequal then the objects can't be equal but if the hashcodes are equal it doesn't necessarily means objects are equal.

You have a very good point here....

However, implementation wise, I doubt you will find a case where b2 is true. The reason is, the Object class uses the identity hashcode as its hashcode, and the identity hashcode is somewhat related to the physical address of the object (at instantiation). Since these two stringbuffers were instantiated back to back, I doubt they can ever have the same identity hashcode.

This has something to do with how equals() and hashcode() method are implemented in java.

Let me first replicate the contract for these methods (which u've also mentioned):

Rule: If two objects are equal i.e. s1.equals(s2) is true then their hashcodes will always be equal.

If you look in this question, you can not determine what would be the respective hascodes of these String and StringBuffer references. Rather you can tell if these refrences are equals() or not. Now using the rule above you can determine if the hashcodes are equal or not.

Strings have an overriden equals method in java. which checks the literal equality of values. And hence s1.equals(s2) is true in your code snippet. //1
StringBuffer use the Object class implentation, which is, if s1==s2 is true then equlas() will return true. sb1.equals(sb2) is false as sb1!=sb2. //2

Therefore hashcode is equal for s1 s2 but not sb1 sb2. Hence true false.

StringBuffer use the Object class implentation, which is, if s1==s2 is true then equlas() will return true. sb1.equals(sb2) is false as sb1!=sb2. //2

Therefore hashcode is equal for s1 s2 but not sb1 sb2. Hence true false.

Shruti,

I think you missed the point that the OP is making.

The contract says that if two objects are equal based on the equals method, then their hashcodes must be equal. The contract doesn't make a relationship for when they are not equal. If two objects are not equal based on the equals method, you can't say anything about the hashcode -- they may be equal, but they may not.

Henry

ShrutiRavi Gupta
Greenhorn

Joined: Jan 08, 2009
Posts: 8

posted

0

Hi Henry,

your'e right. I missed on the point. That when objects are not equal then hashcodes necessarily don't have to be euqal or unequal.

to resolve this question however we can probably use the reasoning mentioned in java docs for Object class:

"As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.) "