aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Correct implementation?? :confused: Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Correct implementation?? :confused: " Watch "Correct implementation?? :confused: " New topic
Author

Correct implementation?? :confused:

srikanth reddy
Ranch Hand

Joined: Jul 28, 2005
Posts: 252
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 ..


Thanks & Regards<br /> <br />-Srikanth
patrick J. d'cousta
Greenhorn

Joined: Oct 25, 2005
Posts: 24
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

Joined: Oct 20, 2005
Posts: 39
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
Bartender

Joined: Oct 14, 2005
Posts: 18908
    
    8

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

Joined: Oct 27, 2005
Posts: 19762
    
  20

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 ]

    SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
    How To Ask Questions How To Answer Questions
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Correct implementation?? :confused: