On Fri, 29 Aug 2025 14:33:03 GMT, Jaikiran Pai <[email protected]> wrote:
> Can I please get a review of this test-only change which addresses a failure > in `test/jdk/java/util/zip/ZipFile/ZipSourceCache.java` test? > > As noted in the description of https://bugs.openjdk.org/browse/JDK-8366439, > this test fails if the underlying file system's timestamp granularity doesn't > allow for the last modified timestamp to increase when the test's ZIP file is > updated with newer content. > > The change in this PR updates the test to first check that the last modified > timestamp has increased on the ZIP file that was updated, before running the > rest of the test assertions. The test continues to pass in our CI with this > change. A related observation: It seems dubious that `Key::hashCode` calls `toMillis` on the `FileTime` object, while `Key::equals` simply delegates to `FileTime:equals`: // hashCode: t += attrs.lastModifiedTime().toMillis(); vs. // equals: !attrs.lastModifiedTime().equals(key.attrs.lastModifiedTime()) While this conversion to millisecond precision does not break the hashCode/equals contract, I'm wondering if it would be simpler and more clear to instead delegate to `FileTime::hashCode`: t += attrs.lastModifiedTime().hashCode(); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3249022632
