On Fri, Feb 13, 2026 at 8:43 PM Lance Andersen <[email protected]> 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.
