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
Zi
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
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.
On 04/03/2010, Stefan Bodewig 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
> verif
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 ca
