• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Correct implementation?? :confused:

 
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ..
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
     
    reply
      Bookmark Topic Watch Topic
    • New Topic