[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16315853#comment-16315853
]
Dawid Weiss commented on COMPRESS-380:
--------------------------------------
I'll check again once I get back home, thanks Stefan. I did look at the changes
and they look good. I can't decide whether those extensive sanity checks should
be in there at all times (and shouldn't be just in assertion-enabled mode); I
think it'll slow down decompression by a large factor. Whether this is of
practical importance, I've no idea.
I also looked at the bit reader yesterday and wondered if it'd be a better idea
to make a bit reader factory depending on byte order, then the returned
implementation could be optimized for a particular byte order and not do so
many conditionals. While this would mean virtual method calls, in practice
these would be predominantly homogeneous and would inline fairly quickly.
Maybe worth taking a look at - if you agree and file an issue, I may take a
look in a spare moment. I am fond of bit-fiddling.
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> ------------------------------------------------------
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
> Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
