[
https://issues.apache.org/jira/browse/COMPRESS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-439.
-------------------------------------
Resolution: Not A Bug
This is due to the pack220 algorithm, please see the first paragraph in
http://commons.apache.org/proper/commons-compress/pack200.html - your
expectation that a pack200 cycle creates the exact same result is unfortunately
not true. The result of the cycle is a functionally identical jar file, but it
can and will be different at the byte level.
> Compressing and decompressing using Pack200 does not produce the original
> input
> -------------------------------------------------------------------------------
>
> Key: COMPRESS-439
> URL: https://issues.apache.org/jira/browse/COMPRESS-439
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
> Affects Versions: 1.14, 1.15
> Environment: Windows 7;
> # java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> Reporter: Valentin Brandl
> Priority: Minor
> Attachments: Test.java
>
>
> I just tested different compressors using
> [JUnitQuickcheck|https://github.com/pholser/junit-quickcheck].
> The tests should compress and then decompress some input and the result
> should be equal to the input.
> For gzip, bzip2, deflate and xz, this works as intended but pack200 seems to
> have some problems.
> I will attach the testcase I wrote.
> It seems that for empty input, the result won't be empty.
> Test output:
> ```
> input.length = 0
> input = []
> compressed.length = 19
> compressed = [-54, -2, -48, 13, 7, -106, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 3, 45,
> 0]
> decompressed.length = 29
> decompressed = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 7, 0, 80, 65, 67, 75, 50, 48, 48]
> ```
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
