commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?
Date Sun, 28 Dec 2014 10:35:02 GMT
On 2014-12-26, Kristian Rosenvold wrote:

> Yup; I'm taking care of the duplication in trunk on my github fork.
> The other interesting branch to look at is the somewhat stale
> "concurrentSupport" branch and in particular the class
> ConcurrentZipCreator. This is my primary goal, I just went off on a
> round of yak-shaving first. I seem to have finished with the yaks now,
> so
> I aim to rebase this branch to trunk soon.


> Right now the problem of multiple algorithms is not "my" itch; I have
> enough other itches right now.


> My todo list right now look like this:
> A) Think about manifest handling in genreal

This applies to plexus since CC isn't doing any manifest handling at all
right now.

> B) Investigate manifest merging in ConcurrentZipCreator. ATM I'm just
> thinking of exposing all the added manifests as a collection and
> leaving this to the client to merge stuff when multiple manfests are
> present.

Since you see ConcurrentZipCreator coming to CC we should try to void
special casing the manifest.  ZipFile already has an API that exposes
all entries of a given name, the same may be possible for

> D) Look at performance in the "gather" phase. It's too slow right now,
> even with my last commit on trunk. Consider moving the creation of the
> LFH to the multithreaded parts and actually copy parts to the central
> directory upon merging. Ideally, the "gather" phase should be just IO.
> Maybe make the creation of the central directory a Deferred stream
> too, preferably of the offloading type.

As long as you only write to the central directory stream after you've
completely written the entry (otherwise you may not know the sizes
depending on the method and whether the backing store is seekable) this
should be doable.

May I ask sneaking in "prefer using delegation over inheritance where
possible"? ;-)



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

View raw message