Description
In some JDK classes there's still the following hashCode() implementation:
long objNum;
public int hashCode() {
return (int) objNum;
}
This outdated expression should be replaced with Long.hashCode(long) as it
- uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
- does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
See also https://stackoverflow.com/a/4045083
long objNum;
public int hashCode() {
return (int) objNum;
}
This outdated expression should be replaced with Long.hashCode(long) as it
- uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
- does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
See also https://stackoverflow.com/a/4045083
Attachments
Issue Links
- relates to
-
JDK-8275293 A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec
- Closed
-
JDK-8268113 Re-use Long.hashCode() where possible
- Resolved