-
Bug
-
Resolution: Fixed
-
P4
-
8, 9, 10
-
b06
-
Not verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8179092 | 9 | Ivan Gerasimov | P4 | Closed | Won't Fix | |
| JDK-8188635 | 8u172 | Ivan Gerasimov | P4 | Resolved | Fixed | b01 |
| JDK-8190637 | 8u171 | Ivan Gerasimov | P4 | Resolved | Fixed | b01 |
| JDK-8179093 | 8u162 | Ivan Gerasimov | P4 | Resolved | Fixed | b01 |
| JDK-8198131 | emb-8u171 | Ivan Gerasimov | P4 | Resolved | Fixed | b01 |
The hash code is currently implemented as
{code}
public int hashCode() {
long hash = minSmallest + minLargest << 16 + minLargest >> 48 + maxSmallest << 32 +
maxSmallest >> 32 + maxLargest << 48 + maxLargest >> 16;
return (int) (hash ^ (hash >>> 32));
}
{code}
Since addition has higher precedence, the hash value is almost always is zero.
(E.g. >> (32 + maxLargest) swaps away at least half of all the bits).
The fix is to add some parentheses.
{code}
public int hashCode() {
long hash = minSmallest + minLargest << 16 + minLargest >> 48 + maxSmallest << 32 +
maxSmallest >> 32 + maxLargest << 48 + maxLargest >> 16;
return (int) (hash ^ (hash >>> 32));
}
{code}
Since addition has higher precedence, the hash value is almost always is zero.
(E.g. >> (32 + maxLargest) swaps away at least half of all the bits).
The fix is to add some parentheses.
- backported by
-
JDK-8179093 java.time.temporal.ValueRange has poor hashCode()
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
- links to
(2 links to)