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

[Jaikiran Pai]

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.

Hello Eirik,

> Adding file size into the mix should be cheap while still improving the heuristics on file systems with course time granularity. This will also help cases where the last modified date is explicitly set by the system and cannot be trusted and on file systems which don't support last modification date at all and always return something like the epoch.

Adding file size as another component to the cache's key sounds reasonable and can reduce the chances of not detecting an update to the ZIP file contents. I'll wait a day or two to hear from others before deciding if we should go ahead with that idea.

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

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