i feel hashcode method is not correctly implemented..but answer says opposite.. here ..i feel that "just if the hashcodes are equal then we cant say that both are equal using equals" "if both are equal using equals then and then the hashcodes are equal"
If I'm reading the code correctly, it is using java.lang.Object's hashCode method exclusively. The Object hashCode returns unique integers for every instance, thus no 2 object will have the same hashCode. Thus the code's equals() method will only return true if the same instance is being compared. IE. It is acting like the == operator, which is what the Object.equals() method does. So in effect, the Photos code behaves just like the Object code for hashCode() and equals(). Since Object has them implemented correctly, then Photos does as well.
If I'm reading the code correctly, it is using java.lang.Object's hashCode method exclusively.
No. The object in question is an instance of the Photos class, so the hashCode method of Photos will be called. It doesn't matter what type of variable is referring to the object.
As for the original post, it's hard to say whether the code depends on special features of the class's hashCode implementation when the hashCode method was not posted. It may be that the value of hashCode is indeed a unique key for the object in this case.
(Edited to basically retract the entire post
Now that I look more carefully, I do see the implementation of hashCode there. (Amazing what a lack of whitespace does for readability.) So yes, the Object version of hashCode is being used. But as Srikanth says, it is a bad practice to assume that two different objects will have different hash codes, despite what certain implementations happen to do. [ October 28, 2005: Message edited by: Paul Clapham ]
Lets investigate whether the contracts of equals and hashCode are followed.
Starting with hashCode:
Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.Well, we can safely assume that Object's hashCode follows this rule, so check.
If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
equals basically returns whether or not the hash codes are equal. So if the hash codes are equal, then the two objects must return the same hash code. No brainer.
It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.
It is reflexive: for any non-null reference value x, x.equals(x) should return true.hashCode() == hashCode(). Yep, that returns true alright.
It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.Symmetry of integer calculation, I'm not going to explain why this rule is followed.
It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.See previous point.
It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
Ah, interesting. However, recall hash codes first rule. This says that hash code always returns the same value for Object. As a result, x.equals(y) will always return the same value for any set of x and y. Check
For any non-null reference value x, x.equals(null) should return false.
!(null instanceof Photos), so equals returns false. Check
So it is correct.
[ October 28, 2005: Message edited by: Rob Spoor ] [ October 28, 2005: Message edited by: Rob Spoor ]