On Tue, 14 Apr 2026 09:55:15 GMT, Eirik Bjørsnøs <[email protected]> wrote:
>> This PR reorganizes `java.util.zip.ZipCoder` class hierarchies to handle >> UTF-8 in the base class and move support for general charsets down to a >> subclass. This better reflects reality where most ZIP files are encoded >> using UTF-8. >> >> The motivation can be summarized as: >> >> * Supporting the common case in the base class and the exceptional case in a >> subclass seems more natural and intuitive for maintainers >> * We avoid loading both classes for most JVM instances >> * A small performance improvement is observed, probably caused by unlocking >> effecively-monomorphic JVM optimizations >> >> See core-libs-dev discussion for details: >> https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/158281.html >> >> I have tried to not move methods around too much, making the side-by-side >> diff when ignoring whitespace easier to review. We can discuss further >> cleanups and reorganizaton if so desired. >> >> It may be useful to review commits individually. The first commit fe4a627 >> moves some methods out the way for the second commit 2926398. >> >> This PR also includes the similar change to the `ZipFileSystem` >> implementation of ZipCoder to keep these aligned. Could be pulled out to a >> separate PR if reviewers want to focus on a single area per PR. >> >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Eirik Bjørsnøs has updated the pull request incrementally with four > additional commits since the last revision: > > - Spell fix "as IF they" > - Spell fix "the the" > - Rename ZipCoder.utf8 to ZipCoder.UTF8 for consistency with java.util.zip > - Update copyright year Okay, so I prototyped the sibling hierarchy which was by itself unsurprisingly straightforward. However, I’m struggling a bit with getting convincing benchmark results with my setup. Current theory is that the abstract base class performs similarly to mainline, so a minor loss over the current PR. In some not so convenient real-life news, I’ll be away from keyboard a few weeks. So this PR could be put in draft until I’m back. An alternative would be to integrate what we have now and further investigate the abstract base class performance when I’m back. So unless suggested otherwise, I will put this PR into draft mode in a couple of days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30640#issuecomment-4278328724
