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

[Sean Coffey]

On Wed, 3 Sep 2025 05:51:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The `java.util.zip.ZipFile` maintains an internal cache for an underlying ZIP file to read its CEN just once to try and avoid reading it every time a `ZipFile` instance is created. One internal implementation detail of that cache is that it has the ability to detect an update to the underlying ZIP file so that when a subsequent instance of `ZipFile` is created then it won't re-use an already cached CEN but instead will re-read the CEN (and cache it) afresh. To detect the updates to the ZIP file, it uses the last modified time of the file; and last modified timestamps have a granularity.

I'm still thinking the inner ZIpFile logic might have an issue if it can't detect an update to a ZipFile. The inner Source class will return an incorrect mapping and CEN calculation if a new Source isn't created. The test fails since the internal cache doesn't increment by 1, i.e. a new entry wasn't added to HashMap after ZIpFile was updated.

An obsolete key is returned since the Key class `hashcode` method doesn't detect a difference due to the coarse nature of the FS timestamps


            public int hashCode() {
                long t = charset.hashCode();
                t += attrs.lastModifiedTime().toMillis();
                Object fk = attrs.fileKey();
                return Long.hashCode(t) +
                        (fk != null ? fk.hashCode() : file.hashCode());
            }

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

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