commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <>
Subject Re: [compress] Need Feedback for COMPRESS-479
Date Tue, 13 Aug 2019 19:37:21 GMT
The enum makes sense. Are there any feasible ways to, say, configure
some sort of handler class that can implement logic around unknown
fields? Sort of an extensibility model there, but hopefully without
having to extend ZipInputStream or anything like that.

On Tue, 13 Aug 2019 at 14:01, Stefan Bodewig <> wrote:
> Hi
> highlights a problem
> where our zip reading code may reject an archive because it uses extra
> fields that we only partially understand. In this case the archive is
> not a real one, but it is easy to envision extra fields in the wild that
> use more advanced versions than we currently support.
> For most of our users the ZIP extra fields will be noise and they really
> are only interested in the actual content of the archives.
> Therefore I have decided to treat any such "not quite as we expect"
> extra field the same way as any "we have no idea how this extra field
> looks internally" field - i.e. just store it but don't try to parse
> it.
> In addition I have provided an API inside of ZipArchiveEntry that allows
> users to specify in detail how strict they want the extra field parsing
> to be.
> Does this make sense to you? Would you recommend taking a different
> approach? And it if makes sense, are the enum names I've chosen in
> understandable?
> Thanks
>         Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Matt Sicker <>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message