Martin Buchholz martinrb at
Sat May 15 05:59:26 UTC 2010

On Fri, May 14, 2010 at 19:24, Xueming Shen <xueming.shen at> wrote:
> Martin Buchholz wrote:
>> Well, the obvious thing to do is to use ZipFile,
>> and if something goes wrong,
>> back off and try the old implementation with
>> ZipInputStream in addition.
> I will add a check like
> if (fname != null && new File(fname).length() < 0x100000000L)
>   go ZipFile;
> else
>   go ZipInputStream

Sounds good.

If the input zip file is actually a ZIP64 file for some other reason
(for example to get >64k entries), then ZipInputStream
will still succeed, while ZipFile will probably fail,
in which case the fallback algorithm might be more robust.

But I am happy with any action on your part,
including doing nothing.

>> If the JDK has ZIP64 support,
>> what goes wrong?
> Nothing goes wrong with ZIP64, but we don't have that in 6u (yet)

Oh, right.  And a backport of ZIP64 support probably isn't
worth the risk and effort.


> -Sherman
>> Martin
>> On Fri, May 14, 2010 at 16:18, Xueming Shen <xueming.shen at>
>> wrote:
>>> It appears the backport to 6u of the optimization we did in #6332094
>>> breaks
>>> someone's code.
>>> Obviously the ZipInputStream works fine with >4G zipfile even without the
>>> ZIP64 format support
>>> as long as the individual zip entries inside is smaller than the 4G
>>> limit,
>>> so the sequential reading in jar's
>>> old implementation just works "fine" with the >4G zip. But the
>>> optimization
>>> we put in to use ZipFile
>>> instead causes the regression because it needs the access to the 64bit
>>> central directory table if the
>>> zip is > 4G. While it is arguable if a > 4G zipfile without the ZIP64
>>> extension table is a "correctly"
>>> formatted zip file or in fact that jar can never create a > 4G zip file
>>> before we added the ZIP64
>>> support, regression is a regression:-(
>>> I believe you also backport the same thing into 6open.
>>> -Sherman

More information about the core-libs-dev mailing list