commons-dev mailing list archives

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

> On 05/03/2010, Stefan Bodewig <bodewig@apache.org> wrote:
>> On 2010-03-04, sebb <sebbaz@gmail.com> wrote:

>>> On 04/03/2010, Stefan Bodewig <bodewig@apache.org> 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.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message