On Fri, May 14, 2010 at 19:24, Xueming Shen <xueming.s...@oracle.com> 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. hmmm.... 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. Martin > -Sherman > > >> Martin >> >> On Fri, May 14, 2010 at 16:18, Xueming Shen <xueming.s...@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 >>> >>> > >
