All code in my posts, unless a source is explicitly mentioned, is my own.
be a well encapsulated person, don't expose your privates, unless you public void getWife()!
Ruben, you are almost correct, though your statement is incorrect. If you do not override Object method, hashCode() you are NOT violating the hashCode contract, as the contract can only be honored if you override the method. It certainly will produce erroneous results, if you don't override or if you use the default implementation, and then attempt to use the equals() method in a collection as such.
The general contract of hashCode is:
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. 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. 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.
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)
I am not sure why you need to override both methods before you consider the contract is violated.
equals() and hashCode are bound together by a joint contract that specifies if two objects are considered equal using the equals() method, then they must have identical hashcode values. So to be truly safe, your rule of thumb [emphasis added]should be, if you override equals(), override hashcode as well
be a well encapsulated person, don't expose your privates, unless you public void getWife()!
So, in my reading of this, it is good practice to override both, but it is not a contract that you must override hashCode() if you choose to override equals(). However inversely it makes no sense and it IS a contractual error not to override equals() if you override hashCode(), as the hasCode() contract specifies operability with the equals method.
so by commenting out the hashCode() implementation, there is indeed no contract broken is there not?
be a well encapsulated person, don't expose your privates, unless you public void getWife()!
Stephen Davies wrote:The brokeness, I certainly agree on, but as for commenting out hasCode() resulting in a broken contract with a compareTo() I will kindly agree that perhaps it is simply a matter of semantics and nothing else, and thus move on.
Though such as discussion as we have had is one of the great things about the Ranch, sharing ideas opinions and perspectives, is certainly invaluable input, keep it up!
Implementations are free to implement optimizations whereby the equals invocation is avoided, for example, by first comparing the hash codes of the two keys. (The Object.hashCode() specification guarantees that two objects with unequal hash codes cannot be equal.)
All code in my posts, unless a source is explicitly mentioned, is my own.
The problem in your code is that hashCode() shouldn't be commented, because if it is, you are violating the equals/hashCode() contract.
be a well encapsulated person, don't expose your privates, unless you public void getWife()!
Stephen Davies wrote:Ruben,
You stated
The problem in your code is that hashCode() shouldn't be commented, because if it is, you are violating the equals/hashCode() contract.
It is here, from which my understanding arose, I apologize if I have caused unnecessary confusion, though I am grateful we could go through it on this post to help. However, as I said before I would agree to put down the discussion now and admit it is probably a moot point now as its simply a misunderstanding on my part based on semantics and nothing, else. I gratefully request we move on.
Thanks
All code in my posts, unless a source is explicitly mentioned, is my own.
Consider Paul's rocket mass heater. |