RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v2]

[Eirik Bjørsnøs]

On Wed, 12 Mar 2025 06:35:54 GMT, Jaikiran Pai <jpai at 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