On Wed, 12 Mar 2025 06:35:54 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1434:
>>
>>> 1432: @Override
>>> 1433: public int hashCode() {
>>> 1434: long t = entryNameCommentCharset.hashCode();
>>
>> This represents a behavioral change, right? Is a CSR warranted?
>>
>> EDIT: Scratch that, I guess the caching mechanism here is unspecified and
>> and more of implementation detail.
>
> This is an internal implementation detail, so doesn't require a CSR.
Hello Jaikiran,
Before this change, two ZipFile instances opened using different (non-UTF-8)
charsets would have equal keys, and thus be backed by the same Source and
ZipCoder instance, whichever ZipFile constructed first would "win".
This seems like a separate bug, independent of the concurrency concerns
described JDK-8347712.
For the benefit of future maintainers, I think this independent bug should be
described in a separate JBS issue.
The bug could be solved in a separate PR, however I feel it's also ok to fix it
in this PR, since moving the ZipCoder instance to ZipFile seems to incidentally
solve the issue as well.
WDYT?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2009047793
