[MGPG-80] implement GpgVersion equality in adherence to comparibility by Syquel · Pull Request #12 · apache/maven-gpg-plugin (original) (raw)
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you also test that hashcodes are not equal here?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While objects which are equal must produce the same hash code it is neither required nor expected that unequal objects always produce different hash codes.Arrays.hashCode should already provide a reasonable implementation to minimize hash collisions.
Returns a hash code value for the object. This method is supported for the benefit of hash tables such as those provided by java.util.HashMap.
The general contract of hashCode is:
[ ... ]
- 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(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 hash tables.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is indeed expected to a very high degree of probability, specifically one in 4.2 billion. It is also expected that hashcodes are deterministic and not random so if this case is not equal now it should not be equal on the next run. Finally it's expected that a good hash algorithm move nearby values far apart so this one should definitely be different.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added test statements to assert that the hash codes are different.