On Wed, 3 Sep 2025 05:51:03 GMT, Jaikiran Pai <[email protected]> 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
