RFR: 8366439: test/jdk/java/util/zip/ZipFile/ZipSourceCache.java fails with AssertionFailedError: expected: <6> but was: <5>

[Eirik Bjørsnøs]

On Fri, 29 Aug 2025 14:33:03 GMT, Jaikiran Pai <jpai at openjdk.org> 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