This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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).
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.
Thank you Campbell for the link, i will read the chapter 3
Joined: Sep 06, 2005
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.
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').
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
Joined: Oct 13, 2005
Thank you. I am relieved it was me misunderstanding Praveen, rather than him saying something daft. I ought to read the posts more carefully.