wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes the equals() contract Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "the equals() contract" Watch "the equals() contract" New topic
Author

the equals() contract

Milton Ochoa
Ranch Hand

Joined: Oct 23, 2007
Posts: 336

Hi everybody,

the contract is self explanatory, but i dont undestand explain me the 4 topic: consistent

if somebody know ... please reply me

thank
praveen Shangunathan
Ranch Hand

Joined: Sep 06, 2005
Posts: 65
meaning if two objects are equal(however you define 'equals' to be) should return true every time. (as long as they are unchanged).
to go into detail, equals() employs hashcodes. these hashcodes could be generated using random numbers(which is a very bad idea). so 2 objects being equal should not be due to 'chance'. if 2 objects are equal now, they should be equal always, consistently.( again assuming their states have not been changed).

HTH
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
You were right at the beginning, but I am afraid you have got very confused about hashCodes.

The equals() method doesn't use hashCodes, nor does it use random numbers. There was discussion on this recent thread, which has two useful links on, and a bit here, in the Java Tutorials.

The hashCode method doesn't use random numbers. See the description in the API for the java.lang.Object class. It often uses the memory location, but is overridden by using prime numbers (usually) multiplied by the values (or hashCodes) of fields. This Chapter, which is one of the links I mentioned earlier, has probably got details of hashCode in as well.
Milton Ochoa
Ranch Hand

Joined: Oct 23, 2007
Posts: 336

Thank you Campbell for the link, i will read the chapter 3
praveen Shangunathan
Ranch Hand

Joined: Sep 06, 2005
Posts: 65
Campbell,
Please correct me...

1) equal objects must have same hashcode.
2) we have to override equals() and hashcode()
3) so in my equals() i can just check my overridden hashcode() method, and if the hascodes are same i can say the 2 objects are 'equal'.
4) now in my hashcode() i can have some random generator influence the hashcode that is returned.
5) owing to 4. my equals() will not be 'consistent'.
however bad the above design might be i was trying to explain what 'consistent' meant.

again please correct me...
Brian Cole
Author
Ranch Hand

Joined: Sep 20, 2005
Posts: 862
An example of an inconsistent equals() is URL.equals(), in which "hosts are considered equivalent if both host names can be resolved into the same IP addresses; else if either host name can't be resolved, the host names must be equal".

This was a mistake (alas, too late to change it now, or so they say) because, for exameple, equals() may return false when your laptop is disconnected from the internet and true when connected. This has been the cause of reals bugs. (one solution: Use the URI class instead.)

Originally posted by praveen Shangunathan:
Please correct me...

... if the hascodes are same i can say the 2 objects are 'equal'.


No, not in general. Two different objects may happen to have the same hash code. This is called a "hash collision" and is inevitable. Consider the java.lang.Long class. There are 2^64 instances of Long that we would want to consider different, yet its hashCode() method returns an int (of course) which has only 2^32 possible values. By the pigeonhole principle there must be at least one collision.

What you can say is that if the hashcodes are not the same, then the two objects are not 'equal' (presuming hashCode() and equals() have been written 'correctly').


bitguru blog
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Brian Cole has given most of the answer, but:
  • You don't use anything random in hashCode; it has to be reproducible returning the same result again.
  • Have you read the quotes from Joshua Bloch?
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    Praveen was never saying that anyone should use anything random in a hashcode. He was saying that if that did, it would violate the consistency requirement. He's using it as an example of what the consistency requirement is about - which is what the question was. Praveen gave an extreme example that (hopefully) no one would be foolish enough to actually do. Brian gave a more realistic example of something with random behavior that had unfortunately made it into the standard API. We all agree this is a bad idea, and forbidden by the API. They're just using examples to explain why it would be bad.


    "I'm not back." - Bill Harding, Twister
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 39478
        
      28
    Thank you. I am relieved it was me misunderstanding Praveen, rather than him saying something daft. I ought to read the posts more carefully.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: the equals() contract