This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Correct implementation?? :confused:

 
srikanth reddy
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
frnds,


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"

please expain me ..
 
patrick J. d'cousta
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If objects are equal the hashcode should be same.

Here we are going backwards....our implementation of hascode is such that when hashcode is equal the objects are equal.

So funda 1 "If objects are equal the hashcode should be same" holds true hence the hashcode is correct implementation.

Dont think equals implementation is correct but.
 
Ray Horn
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Paul Clapham
Sheriff
Pie
Posts: 20768
30
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Rob Spoor
Sheriff
Pie
Posts: 20495
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

  • Not interesting.

    equals:
  • 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 ]
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic