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 Tue, 23 Dec 2014 19:01:07 GMT
On 2014-12-22, Kristian Rosenvold wrote:

> There are quite a few extension points in this class that make
> changing it really hard.


> I just committed  r1647329 which basically duplicates some code from
> this class into another class. As much as I hate duplication, I wasn't
> able to achieve what I wanted to without A) breaking some extension
> capability of the existing class or B) duplicating the code.

I'm not sure adding the features of ScatterZipOutputStream to
ZipArchiveOutputStream would be such a good idea.  Maybe it is not too
bad they are two separate clases.  Most likely you are not suggesting
that but rather rewriting ZipArchiveOutputStream in terms of
StreamCompressor to reduce duplication.

Your commit message calls out writeOut as a particilar problem.
Fortunately this is one is final, so we don't have to retain the effect
of subclasses overriding it.  Wouldn't it be possible to have writeOut
call the StreamCompressor's writeOut method so it still worked as

[As an aside I'd prefer the StreamCompressor being passed into the
stream so we don't need subclasses just to replace the compressor.  One
problem of the zip package is that it doesn't support all the other
compression methods possible for ZIPs, this might be a possible
extension point.]


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

View raw message