zip64 compatibility problems

Xueming Shen xueming.shen at
Wed Jan 16 01:23:25 UTC 2013

Hi Martin,

I would assume you are not asking for a similar flag for jar to disable the
zip64 support (or even something at API level) to generate "old" style 
file for > 64k entries, but the backport of this changeset to 7u, right?


On 1/15/13 1:46 PM, Martin Buchholz wrote:
> Hi zip64 team!
> It's always a problem creating zip files using new zip spec features,
> since older zip implementations will fail to read those files.
> I see the jdk8 fix to allow the launcher to read zip64 files
> changeset:   5812:f1838d040cc7
> user:        ksrini
> date:        2012-09-05 11:38 -0700
> 7194005: (launcher) needs to be enhanced for 64-bit jar file handling
> Reviewed-by: darcy, sherman
> but that has not been backported to jdk7, which seems like a serious
> problem to me.
> More generally, most zip implementations, including in the jdk, worked
> just fine with >64k entries, since the entry count field was generally
> just treated as a hint.  The change to use zip64 when there are >64k
> entries makes zip files *less* portable in practice for the next few
> years.  It would have been better to default to writing non-zip64 zip
> files in such cases.
> Note that zip 3.0 does write zip64 files for >64k entries, but also
> provides a flag -fz- to change the default.
> I'd like to see a backport of 7194005 and am also aware of some other
> issues with our ugly friend parse_manifest.c.
> You changed calls to open to do this:
>      if ((fd = open(jarfile, O_RDONLY
> #ifdef O_LARGEFILE
>          | O_LARGEFILE /* large file mode on solaris */
> #endif
> #ifdef O_BINARY
>          | O_BINARY /* use binary mode on windows */
> #endif
>          )) == -1)
> But this is not done consistently - there are 2 other calls to open in
> the same file that didn't get the LARGEFILE treatment.  Why isn't
> there a JLI_Open?
> Comments?

More information about the core-libs-dev mailing list