This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: patches for DeflaterOutputStream.java and ZipOutputStream.java


Per Bothner wrote:

> It is clear that there has been zero testing of ZipOutputStream.java,
> since it contains numerous errors in the zip file format emitted.

Yes. I spent quite a bit of time fixing the ZipInput stuff a while back so
that the interpreter worked on compressed jar files and localization resources
could be loaded, but I haven't looked at the Output parts at all.

> The patches fixes the problems I found.  It seems to work for at
> least the case I've tested: a single uncompressed ("STORED") member.
>
> When it comes to deflating with level 0 (no compression), I finally
> got it so that the entire input file was written out, but pre-pended
> with 5 extra bytes.  My guess this is some zlib header that is
> emitted even when doing no compression, but the logic of zlib is
> convoluted enough I'm not sure.

There is an undocumented zlib flag (called NO_HEADER in Java) which is used to
turn the zlib header off when reading and writing from zip files. You should
check that this is being set correctly? I remember this being a problem in the
ZipInputStream originally too.

> I finally concluded that when using
> the STORED method we should by-pass zlib entirely - that is more
> efficient anyway.

Yeah, except that it probably hides bugs that only occur when using compressed
mode!

> With the patch (plus the String patch I will check in soon), Kawa
> builds *and* the entire Kawa testsuite runs correctly!
>
> I'll give people a chance to comment before I check this in.

Anything that improves the ZipOutput situation for you is probably a good
thing.

regards

  [ bryce ]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]