commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [COMPRESS] Jar*Stream COMPRESS-18
Date Fri, 05 Mar 2010 13:57:41 GMT
On 2010-03-05, sebb <> wrote:

> On 05/03/2010, Stefan Bodewig <> wrote:
>> On 2010-03-04, sebb <> wrote:

>>> On 04/03/2010, Stefan Bodewig <> wrote:

>>>>  The more I think about this, the more I believe we should make
>>>>  JarArchiveInputStream use the java.util.jar package rather than extend
>>>>  ZipArchiveInputStream - this would also mean we'd break the API of 1.0,
>>>>  though.

>>> Seems good to me.
>>> Presumably JarArchiveOutputStream should also be changed?

>> Yes, as well as JarArchiveEntry.  Neither of the three classes would
>>  subclass their Zip* counterparts anymore.  That's the API breakage I was
>>  talking about.

> Though I suppose the streams could still extend
> archivers.Archive(In|Out)PutStream by composition with the java.util
> classes

Sure, that would be the idea.  Implementing count and friends will
involve a bit more coding but it doesn't look too hard.

> - rather than extending them. This would perhaps reduce breakage
> somewhat.

IMHO there won't be many people out there who expect the streams to be
subclasses of the Zip-streams.  Things may be different fro the entry
classes, but again I wouldn't expect too clients that would be broken.


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

View raw message