You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2010/03/04 15:17:55 UTC
[COMPRESS] Jar*Stream COMPRESS-18
Hi,
while investigating an Ant issue I recently had a look at how Harmony
implements JarInputStream and friends.
If we wanted to enable the usual JarEntry fields on top of
ZipArchiveInputStream we'd be forced to re-implement the whole
verification process for signed jars that the class library can already
do for us (in some hidden code we cannot re-use from the outside).
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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Jar*Stream COMPRESS-18
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-05, sebb <se...@gmail.com> wrote:
> On 05/03/2010, Stefan Bodewig <bo...@apache.org> wrote:
>> On 2010-03-04, sebb <se...@gmail.com> wrote:
>>> On 04/03/2010, Stefan Bodewig <bo...@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
Re: [COMPRESS] Jar*Stream COMPRESS-18
Posted by sebb <se...@gmail.com>.
On 05/03/2010, Stefan Bodewig <bo...@apache.org> wrote:
> On 2010-03-04, sebb <se...@gmail.com> wrote:
>
> > On 04/03/2010, Stefan Bodewig <bo...@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 - rather than extending them. This would perhaps reduce
breakage somewhat.
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Jar*Stream COMPRESS-18
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-03-04, sebb <se...@gmail.com> wrote:
> On 04/03/2010, Stefan Bodewig <bo...@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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [COMPRESS] Jar*Stream COMPRESS-18
Posted by sebb <se...@gmail.com>.
On 04/03/2010, Stefan Bodewig <bo...@apache.org> wrote:
> Hi,
>
> while investigating an Ant issue I recently had a look at how Harmony
> implements JarInputStream and friends.
>
> If we wanted to enable the usual JarEntry fields on top of
> ZipArchiveInputStream we'd be forced to re-implement the whole
> verification process for signed jars that the class library can already
> do for us (in some hidden code we cannot re-use from the outside).
>
> 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?
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org