<div dir="ltr"><br><div>Hi,</div><div><br></div><div>I noticed that ZipOutputStream violates APPNOTE.txt when writing directory entries:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Zero-byte files, directories, and other file types that<br>contain no content MUST NOT include file data.</blockquote><div><br></div><div>Nobody seems to have complained about this violation (I searched JBS), so in itself it might not be worth pursuing a fix. However, in addition to breaking the specification, this also causes suboptimal performance both on the write and read paths.</div><div><br></div><div>Before I go ahead and suggest any particular solution, I wanted to share some analysis:</div><div><br></div><div>ZipOutputStream writes directories as any other entry, so by default it ends up writing a LOC header with the DEFLATED method and the data descriptor bit set. This is followed by a final, empty DEFLATE block (0x0300) and then a signed data descriptor with the CRC, csize (2) and size (0), each 4 bytes:</div><div><br></div><div>------  Local File Header  ------<br>000000  signature          0x04034b50     <br>000004  version            20             <br>000006  flags              0x0808         <br>000008  method             8              Deflated<br>000010  time               0x9812         19:00:36<br>000012  date               0x5666         2023-03-06<br>000014  crc                0x00000000     <br>000018  csize              0              <br>000022  size               0              <br>000026  nlen               9              <br>000028  elen               0              <br>000030  name               9 bytes        'META-INF/'<br></div><div><br>------  File Data  ------<br>000039  data               2 bytes        <br><br>------  Data Descriptor  ------<br>000041  signature          0x08074b50     <br>000045  crc                0x00000000     <br>000049  csize              2              <br>000053  size               0              <br></div><div><br></div><div>In total, this means that an extra 18 bytes is output, which is a waste of storage space and IO cycles while writing and reading/parsing the unnecessary headers and data. If the directory entry has the STORED method and the sizes and crc is set to 0, then the file data and data descriptors are skipped and we reclaim 18 bytes.</div><div><br></div><div>The use of DEFLATE has an adverse negative impact on performance, since native ZLIB code needs to be called to produce and read (in ZipInputStream) the empty DEFLATE block. Worse, Deflater.reset and Inflater.reset are called, which seems to incur a significant overhead.</div><div><br></div><div>In fact, when configuring the STORED method and explicitly setting csize, size and crc to 0, we see considerable benchmark improvements writing and reading directory entries:</div><div><br></div><div>DEFLATED:</div><div><br></div><div><font face="monospace">Benchmark                        (size)  Mode  Cnt  Score   Error  Units<br>ZipEmptyStreams.readDirStream       512  avgt   15  0.278 ± 0.005  ms/op<br>ZipEmptyStreams.readDirStream      1024  avgt   15  0.550 ± 0.006  ms/op<br>ZipEmptyStreams.writeDirStreams     512  avgt   15  2.379 ± 0.043  ms/op<br>ZipEmptyStreams.writeDirStreams    1024  avgt   15  4.845 ± 0.087  ms/op</font><br></div><div><br></div><div>STORED:</div><div><br></div><div><font face="monospace">Benchmark                       (size)  Mode  Cnt  Score   Error  Units<br>ZipEmptyStreams.readDirStream      512  avgt   15  0.082 ± 0.001  ms/op<br>ZipEmptyStreams.readDirStream     1024  avgt   15  0.176 ± 0.015  ms/op<br>ZipEmptyStreams.writeDirStream     512  avgt   15  0.233 ± 0.021  ms/op<br>ZipEmptyStreams.writeDirStream    1024  avgt   15  0.460 ± 0.028  ms/op</font><br></div><div><br></div><div><br></div><div>Possible actions:</div><div><br></div><div>- Do nothing: Nobody complained so far, so if is ain't broke, don't fix it.</div><div>- Update Javadocs of ZipInputStream.putNextEntry to recommend that users should use STORED  and configure sizes & crc for directory entries for correctness and performance </div><div>- Change the default compression method for directories to STORED and set sizes & crc to 0. This would add the risk of changing behavior of existing code.</div><div><br></div><div>For context, 7% of entries in the dependencies of Spring Petclinic are directories.  </div><div><br></div><div>Any thoughts or input?</div><div><br></div><div>Thanks,</div><div>Eirik.</div></div>