[
https://issues.apache.org/jira/browse/COMPRESS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842087#action_12842087
]
Trejkaz commented on COMPRESS-93:
---------------------------------
> Then send a patch and wait
This part of the suggested workflow is unlikely to happen when the code is
written under employ of a company.
> IMO adding a plugging API for just the ZIP compressor methods is a little too
> much over-engineering.
I don't think so. For one thing, if Sun had added such an API to ZipFile from
the start, we wouldn't need all these alternative ZIP implementations like
Commons Compress'.
> and why would they?
Because not all historical ZIP files use DEFLATE. We had to make our own
implode algorithm from scratch for other purposes so we already have the code
to decompress EXPLODE. But even though we have this, we can't plug it into
Commons Compress or Java's ZipFile without forking the code of either of them.
> Support for alternative ZIP compression methods
> -----------------------------------------------
>
> Key: COMPRESS-93
> URL: https://issues.apache.org/jira/browse/COMPRESS-93
> Project: Commons Compress
> Issue Type: New Feature
> Reporter: Jukka Zitting
>
> As reported in TIKA-346, a ZIP file that uses a compression method other than
> STORED (0) or DEFLATED (8) will cause an IllegalArgumentException ("invalid
> compression method") to be thrown.
> It would be great if commons-compress supported alternative compression
> methods or at least degraded more gracefully when encountering them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
