• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

the equals() contract

 
Milton Ochoa
Ranch Hand
Posts: 336
Firefox Browser Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 336
Firefox Browser Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Campbell for the link, i will read the chapter 3
 
praveen Shangunathan
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 903
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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').
 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 18671
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Campbell Ritchie
    Sheriff
    Posts: 48652
    56
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you. I am relieved it was me misunderstanding Praveen, rather than him saying something daft. I ought to read the posts more carefully.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic