The test/jdk/java/util/zip/ZipFile/ZipSourceCache.java test has been observed to fail with the following exception on certain filesystems where the last modification time of a file doesn't have the millisecond granularity:

STARTED ZipSourceCache::testKeySourceMapping 'testKeySourceMapping()'
org.opentest4j.AssertionFailedError: expected: <6> but was: <5>
        at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
        at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
        at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
        at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:531)
        at ZipSourceCache.testKeySourceMapping(ZipSourceCache.java:102)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
FAILED ZipSourceCache::testKeySourceMapping 'testKeySourceMapping()' [21ms]

This test peeks into the implementation details of java.util.zip.ZipFile to check the size of an internal Map. That Map will have newer entries if new ZIP files are opened through ZipFile() constructor(s). One component of this internal cache's key is the last modification time of the cached ZIP file. If that value changes for a cached ZIP file, then the cache creates a new entry for the ZIP file.

One part of this test updates the file contents and then uses ZipFile(...) constructor to construct an instance for that file. It then expects that a new cache entry would have been added for this "updated" file. On certain filesystems, the granularity of file timestamps can be in seconds. If the test happens to create the ZIP file and update that ZIP file within a few milliseconds, then the last modified timestamp on that ZIP file will still be the same second. As a result, the internal cache of ZipFile will not create a new entry for this ZIP file since it doesn't detect the "update". This then causes assertion failures in the test, which expects the cache to have had a new entry.

The test should be improved to take into account that the last modified timestamp may not have changed after the ZIP file's content was updated.