RFD: A plan to untangle ZipFile.Source.initCEN

[Eirik Bjørsnøs]

On Tue, Feb 10, 2026 at 7:24 PM Lance Andersen <lance.andersen at oracle.com>
wrote:


> While I think there may be some merit/benefit to what your suggesting, I
> think we should take a step back and also look at ZipFS to see what we
> might be able to share as part of a refactoring as there is a somewhat
> similar flow to ZipFS initCEN
>
> The benefit would be reducing the need to have to maintain somewhat
> duplicate code across both APIs.
>

I have less intimate experience with the ZipFS implementation. But
ZipFile's initCEN is so convoluted with various responsibilities, state
management and control flow that every time I take a step back from it I
immediately lose track of whatever understanding I just had about how this
method actually works :)

If anything, peeling apart the various layers of this very big onion should
make it easier to see which parts are reusable, and which parts are better
maintained in each implementation. Perhaps we could eventually extract the
CEN parsing and validation into a little utility library, reusable from
ZipFS?

ZipFs includes write support, needs to fit within the FileSystem API,
supports Posix attributes etc. But sure, there may be some synergies.

I don't see how the refactorings and enhancements in code organization
proposed here would make such synergies less achievable. On the contrary, I
think peeling the onion may be a necessary precondition.

Or did you have more specific ideas in mind when suggesting we "take a step
back"?

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