http://javaweb.sfbay.sun.com/~sherman/6332094/

[Martin Buchholz]

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.

If the JDK has ZIP64 support,
what goes wrong?

Martin

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.
>
> -Sherman
>