On Fri, May 14, 2010 at 23:53, Xueming Shen <xueming.s...@oracle.com> wrote: > OK, Thanks! > > btw, did you ask this before? > > http://cr.openjdk.java.net/~sherman/6581715/webrev/
I think I did. All JDK classes returning an Enumeration should be retrofitted to implement Iterable. Looks good. --- There are a few more places where you can remove ZipFile.this. 507 ",\n jzfile = " + ZipFile.this.jzfile + 508 ",\n total = " + ZipFile.this.total + 509 ",\n name = " + ZipFile.this.name + Martin > -Sherman > > Martin Buchholz wrote: >> >> 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 >>>>> >>>>> >>>>> >>> >>> > >
