On Fri, Feb 13, 2026 at 8:43 PM Lance Andersen <lance.andersen@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.