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

[Sean Coffey]

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.

thanks for looking at this @jaikiran  - Do we have a product regression here with this env ? I'm thinking that a cached ZipFile$Source instance was returned from the `files` HashMap when a new one should have been created. The Source.hashCode() wasn't able to differentiate on the updated file due to to crude timestamps being returned from the buggy filesystem ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27005#issuecomment-3246489204