xueming.shen at oracle.com
Sat May 15 02:24:05 UTC 2010
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)
> If the JDK has ZIP64 support,
> what goes wrong?
Nothing goes wrong with ZIP64, but we don't have that in 6u (yet)
> On Fri, May 14, 2010 at 16:18, Xueming Shen <xueming.shen at oracle.com> 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.
More information about the core-libs-dev