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

[Jan Kratochvil]

On Wed, 12 Nov 2025 21:32:38 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> Multithreaded handling of ZIP files can throw an exception.
>> 
>> This backport is far from clean. The last commit resolves the conflicts.
>> 
>> The backport would be a little cleaner if there was backported as a pre-requisite JDK-8321156. But given there is [a backward compatibility concern](https://bugs.openjdk.org/browse/JDK-8321156?focusedId=14630523&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14630523) I have not backported it.
>> 
>> (jdk25 already contains it), this jdk21, [jdk17](https://github.com/openjdk/jdk17u-dev/pull/3720).
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'devmaster' into 8347712
>  - resolve conflicts
>  - 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset
>    8355975: ZipFile uses incorrect Charset if another instance for the same ZIP file was constructed with a different Charset
>    
>    Co-authored-by: Eirik Bjørsnøs <eirbjo at openjdk.org>
>    Reviewed-by: eirbjo, lancea, redestad, alanb

The problem does not happen for UTF8 ZIPs as ZipCoder contains its specialization UTF8ZipCoder which is stateless so it can be shared across threads. For non-UTF8 ZIPs:

The problem occured as res.zsrc.zc was using single ZipCoder for one on-disk ZIP file despite each thread had its own instance of ZipFile for that on-disk ZIP file. res.zsrc is ZipFile.Source which contains a cache using single ZipCoder for multiple threads of the same on-disk ZIP file. Now for non-UTF8 ZIPs each ZipFile instance has its new ZipCoder.

For regression risk the change is localized in ZipFile.java, the shared UTF8 ZipCoder is stateless and non-UTF8 ZipCoders are now created for each ZipFile instance. Multithreaded access to ZipFile must be synchronized by its user, not by ZipFile itself. That is documented by:

+ * The {@code ZipCoder} for UTF-8 charset is thread safe, {@code ZipCoder}
+ * for other charsets require external synchronization.


In JDK21 ZipCoder (and its UTF8ZipCoder) is mostly the same as in JDK25. 

A customer has reported IllegalStateException on multithreaded ZipFile access with non-UTF8 charset after they migrated their codebase to JDK17. JDK17 backport sure needs JDK21 backport to be done first.

JDK21 vs. JDK25 for src/java.base/share/classes/java/util/zip/ZipCoder.java:
- [Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc](https://bugs.openjdk.org/browse/JDK-8326687) noreg-doc
- [Make hashCode methods in ArraysSupport friendlier](https://bugs.openjdk.org/browse/JDK-8332826) it could be noreg-cleanup
- [Avoid duplicate checking of trailing slash in ZipFile.getZipEntry](https://bugs.openjdk.org/browse/JDK-8339874) noreg-cleanup
- [Desugar ZipCoder.Comparison](https://bugs.openjdk.org/browse/JDK-8340885) noreg-perf
- [Document preconditions for JavaLangAccess methods](https://bugs.openjdk.org/browse/JDK-8353197) noreg-doc

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/1949#issuecomment-3524503139