javac doesn't work with jar files with >64k entries
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Nov 7 09:58:33 PST 2012
Martin,
As a workaround, you can disable the use of the internal impl, and use
the default impl from JDK
-- Jon
On 11/07/2012 09:49 AM, Martin Buchholz wrote:
> Hi compiler folk,
>
> You don't like someone else's zip implementation, cuz it's too SLOOOW,
> so you write your own. Now you have two problems.
>
> ./share/classes/com/sun/tools/javac/file/ZipFileIndex.java:571:
> int entryCount = get2ByteLittleEndian(zipDir, 0);
>
> The ZIP specification includes ENDTOT, a field that contains the
> number of entries in a zip file.
> Unfortunately, all high quality zip implementations ignore this field
> (or more accurately, treat it as a hint).
> Read zip_util.c and be enlightened:
>
> /* Initialize zip file data structures based on the total number
> * of central directory entries as stored in ENDTOT. Since this
> * is a 2-byte field, but we (and other zip implementations)
> * support approx. 2**31 entries, we do not trust ENDTOT, but
> * treat it only as a strong hint. When we call ourselves
>
> This needs fixing. Since you are iterating through the CEN already,
> just stop when you hit the end header, whose location you know.
>
> 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.
>
> jdk6 javac has the same problem, but disabling the "optimized" zip
> implementation requires different mechanisms.
>
> The sources could be more readable. Probably your source code is
> haunted by Phil Katz' ghost because you are using hex constants
> instead of 'P' and 'K' as Phil Katz intended.
>
> !(endbuf[i] == 0x50 &&
> endbuf[i + 1] == 0x4b &&
>
> You get points for noticing that the input zip file is in ZIP64 format
>
> if (sz < 0 || get2ByteLittleEndian(zipDir, 0) ==
> 0xffff) {
> throw new ZipFormatException("detected a zip64
> archive");
> }
>
> but the only proper reaction is to either add full ZIP64 support or
> fallback to the "unoptimized but actually working" implementation.
>
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20121107/cbd5cae0/attachment.html
More information about the compiler-dev
mailing list