-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MGPG-80] implement GpgVersion equality in adherence to comparibility #12
Conversation
assertEquals( GpgVersion.parse( "gpg (GnuPG/MacGPG2) 2.2.10" ).hashCode(), GpgVersion.parse( "2.2.10" ).hashCode() ); | ||
assertEquals( GpgVersion.parse( "gpg (GnuPG) 2.0.26 (Gpg4win 2.2.3)" ).hashCode(), GpgVersion.parse( "2.0.26" ).hashCode() ); | ||
|
||
assertNotEquals( GpgVersion.parse( "gpg (GnuPG) 2.2.1" ), GpgVersion.parse( "2.2.0" ) ); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
running through jenkins: https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-gpg-plugin/job/MGPG-80/ |
and it passed, will merge |
Provides an implementation of GpgVersion#equals andGpgVersion#hashCode to address MGPG-80.
"GpgVersion#equals" is implemented by utilizing "GpgVersion#compareTo".