RFD: A plan to untangle ZipFile.Source.initCEN

[Eirik Bjørsnøs]

On Fri, Feb 13, 2026 at 8:43 PM Lance Andersen <lance.andersen at oracle.com>
wrote:


> Yes one of the goals should  be to share as much code as possible,
> regardless of where the initial changes are to ZipFile.   initCEN is
> similar in both instances WRT flow and would best to keep changes in mind
> so that they can easily be retrofitted to ZipFS with the hopes of having
> shared code making it easier to address issues that often apply to both due
> to CEN processing
>

Good, it seems our goals here are reasonably aligned: To pick apart initCEN
and make parts reusable across implementations. Reduce maintenance costs
caused by duplicated and difficult-to-understand code paths.


> Another area which you had indicated looking at is ZipCoder which there
> are 2 similar implementations between ZipFS and ZipFile et al.  I believe
> part of that is due to ZipFS starting as a demo but would be good to
> streamline and ideally get to 1 implementation if possible.  I have asked
> Sherman, who is the original author of ZipFS and worked extensively on Zip
> to chime in on your  ZipCoder suggestion.
>

Yes, ZipCoder also have a lot in common but have diverged over the years.
There may be slight differences in client needs, but I think most of it can
be aligned across implementations.

I have done a quick review of differences between ZipFile/ZipFileSystem
implementations and so far I have filed:

https://bugs.openjdk.org/browse/JDK-8377983 to make ZipFileSystem not read
the END header when reading the CEN

https://bugs.openjdk.org/browse/JDK-8377992 to align ZipFileSystem END
header validation with ZipFile.

https://bugs.openjdk.org/browse/JDK-8377978 to add a test for a
ZipFile.Source.findEND edge-case.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260216/4d96ae96/attachment.htm>