RFD: A plan to untangle ZipFile.Source.initCEN

Lance Andersen lance.andersen at oracle.com
Fri Feb 13 19:43:35 UTC 2026


Hi Eirik,

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

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.

This has been on the todo list to look at but has not risen to the top of the list so appreciate your time in giving some thought to it.

Hope that answers your question.

Best,
Lance

On Feb 13, 2026, at 9:58 AM, Eirik Bjørsnøs <eirbjo at gmail.com> wrote:

On Tue, Feb 10, 2026 at 7:24 PM Lance Andersen <lance.andersen at oracle.com<mailto: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.

Lance,

I think discussing a reusable CEN parsing library at this point may be a bit premature. But we certainly don't want refactorings discussed here to make such a future harder to get to.

If your concern is that the refactorings suggested here may make ZipFile/ZipFS initCENs diverge further, then perhaps we can add as a goal that these two should be refactored together?

We could certainly do that. Either in lockstep with each refactoring being applied across APIs in the same PRs (where applicable), or we could clean up the ZipFile first, then have a follow up where we realign ZipFS at the end. Whatever we think makes most sense.

Wdyt?

Eirik.

[oracle_sig_logo.gif]

Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260213/5a7f2302/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260213/5a7f2302/oracle_sig_logo-0001.gif>


More information about the core-libs-dev mailing list