Added ZipArchiveEntryRequest class
ZipArchiveEntry is not thread safe, and the hand-off between the creating thread
and the executorService actually doing the compression has been somewhat of a
tightrope-walking effort, since we cannot reliably read fields off the ZipArchiveEntry
Furthermore, to achieve true maximum IO performance in the gather-phase it would
be required that Zip headers be created in the parallel part of the compression run,
which was not possible prior to this commit.
The ZipArchiveEntryRequest has clear and well-defined thread semantics and can cater
for any future algorithmic improvements that may want to try to take performance to the
very edge of what is achievable. To my understanding this will not be for this next
relasease :)
git-svn-id: https://svn.apache.org/repos/asf/commons/proper/compress/trunk@1651575 13f79535-47bb-0310-9956-ffa450edef68
4 files changed