8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values#27660
8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values#27660naotoj wants to merge 5 commits intoopenjdk:masterfrom
Conversation
|
👋 Welcome back naoto! A progress list of the required criteria for merging this PR into |
|
@naotoj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 58 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
There was a problem hiding this comment.
Include equals in the test name as well? Perhaps HashCodeEqualsTest or something along those lines.
There was a problem hiding this comment.
Renamed. I left SimpleTimeZone as the test is specific for this class.
| { | ||
| return startMonth ^ startDay ^ startDayOfWeek ^ startTime ^ | ||
| endMonth ^ endDay ^ endDayOfWeek ^ endTime ^ rawOffset; | ||
| int hash = 31 * getID().hashCode() + rawOffset; |
There was a problem hiding this comment.
int hash = Objects.hash(getID(), rawOffset, useDaylight);
return !useDaylight ? hash : 31 * hash + Objects.hash(
startMonth, startDay, startDayOfWeek, startTime, endMonth, endDay, endDayOfWeek, endTime);
Seems reasonable to use Objects.hash here. Could save some lines if wanted?
There was a problem hiding this comment.
Initially, I thought so, but decided to avoid extra array allocation/copy. But on second thought, the instances of this class would seldom be used as hash keys so not that performance critical. Either way is fine with me
| @@ -112,15 +112,15 @@ | |||
| * <pre><code> | |||
There was a problem hiding this comment.
We can consider replacing <pre><code> with @snippet so that the code example can be copied by readers. Although I understand if leaving it for another time as to not invalidate the existing approvals.
There was a problem hiding this comment.
I think, that's out of scope for this PR.
test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java
Outdated
Show resolved
Hide resolved
| stz.setEndRule(NOVEMBER, 8, -SUNDAY, 7_200_000); | ||
| assertNotEquals(STZ_WITH_DST, stz); | ||
| // from the contract point, hash codes may be the same | ||
| assertNotEquals(STZ_WITH_DST.hashCode(), stz.hashCode()); |
There was a problem hiding this comment.
Like you said, from !a.equals(b) it does not follow that a.hashCode() != b.hashCode(). Unless you want hash code to specifically have this additional property, I'd remove this assertion.
There was a problem hiding this comment.
I wanted to test the implementation which takes DST related fields into consideration for hash code calculation. Added some comments for clarity
| stz.setEndRule(NOVEMBER, 8, -SUNDAY, 7_200_000); | ||
| assertTrue(stz.useDaylightTime()); | ||
| assertNotEquals(STZ_WITHOUT_DST, stz); | ||
| assertNotEquals(STZ_WITHOUT_DST.hashCode(), stz.hashCode()); |
There was a problem hiding this comment.
Ditto on equals-hashCode contract.
Co-authored-by: Pavel Rappo <32523691+pavelrappo@users.noreply.github.com>
|
Thanks for the reviews! |
|
Going to push as commit 37b725d.
Your commit was automatically rebased without conflicts. |
Fixing the equals/hashCode contract in the SimpleTimeZone class. The current implementation includes DST rule fields in hash code computation even for zones that do not observe DST, while equals() always considers them. Also correcting the example code in the class description, where it used 20-year-old obsolete "America/Los_Angeles" rule.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27660/head:pull/27660$ git checkout pull/27660Update a local copy of the PR:
$ git checkout pull/27660$ git pull https://git.openjdk.org/jdk.git pull/27660/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 27660View PR using the GUI difftool:
$ git pr show -t 27660Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27660.diff
Using Webrev
Link to Webrev Comment