<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">Hi compiler folk,<div><br></div><div>You don&#39;t like someone else&#39;s zip implementation, cuz it&#39;s too SLOOOW, so you write your own.  Now you have two problems.</div>
<div><br></div><div>./share/classes/com/sun/tools/javac/file/ZipFileIndex.java:571:            int entryCount = get2ByteLittleEndian(zipDir, 0);</div><div><br></div><div>The ZIP specification includes ENDTOT, a field that contains the number of entries in a zip file.</div>
<div>Unfortunately, all high quality zip implementations ignore this field (or more accurately, treat it as a hint).</div><div>Read zip_util.c and be enlightened:</div><div><div><br></div><div>    /* Initialize zip file data structures based on the total number</div>
<div>     * of central directory entries as stored in ENDTOT.  Since this</div><div>     * is a 2-byte field, but we (and other zip implementations)</div><div>     * support approx. 2**31 entries, we do not trust ENDTOT, but</div>
<div>     * treat it only as a strong hint.  When we call ourselves</div></div><div><br></div><div>This needs fixing.  Since you are iterating through the CEN already, just stop when you hit the end header, whose location you know.</div>
<div><br></div><div>You can imagine the painful frustrating failure mode of javac starting to very mysteriously fail as the size of an input jar creeps over 64k entries.</div><div><br></div><div>jdk6 javac has the same problem, but disabling the &quot;optimized&quot; zip implementation requires different mechanisms.</div>
<div><br></div><div>The sources could be more readable.  Probably your source code is haunted by Phil Katz&#39; ghost because you are using hex constants instead of &#39;P&#39; and &#39;K&#39; as Phil Katz intended.</div>
<div><br></div><div><div>                        !(endbuf[i] == 0x50 &amp;&amp;</div><div>                        endbuf[i + 1] == 0x4b &amp;&amp;</div></div><div><br></div><div>You get points for noticing that the input zip file is in ZIP64 format</div>
<div><br></div><div><div>                    if (sz &lt; 0 || get2ByteLittleEndian(zipDir, 0) == 0xffff) {</div><div>                        throw new ZipFormatException(&quot;detected a zip64 archive&quot;);</div><div>                    }</div>
</div><div><br></div><div>but the only proper reaction is to either add full ZIP64 support or fallback to the &quot;unoptimized but actually working&quot; implementation.</div><div><br></div><div>Martin</div></div>