Code review request 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field
Alan Bateman
Alan.Bateman at oracle.com
Fri Aug 26 21:39:55 UTC 2011
Xueming Shen wrote:
> On 08/26/2011 01:17 PM, Alan Bateman wrote:
>> Xueming Shen wrote:
>>> Alan
>>>
>>> Webrev has been updated to
>>>
>>> (1) use the new try(resource){}
>>> (2) update the existing test case LargetZip to
>>> a) be able to add one more entry at the end of the > 4g zip via
>>> ZipFileSystem
>>> b) read through all entries inside the large zipfile, given
>>> zipfile's self-crc-check
>>> it guarantees the correctness of the zipfile. So it now
>>> goes through 18G+
>>> file read/write for one round:-)
>>> (you have to use -XX:-UseLoopPredicate on server vm for now to
>>> workaround
>>> the C2 loop redicate bug)
>>>
>>> http://cr.openjdk.java.net/~sherman/7077769/webrev/
>> Looks good. On the test I guess I would have used Files.walkFileTree
>> in the update method. Also in the mkdirs implementation can be
>> replaced with Files.createDirectories.
>
> Webrev has been updated to use Files.walkFileTree and
> Files.createDirectories.
Mostly okay to me. If you want you could remove lines 233-236 as
walkFileTree will just invoke the visitFile method if you call it with a
path to a file that isn't a directory. Also just noticed line 218 checks
if the scheme is "jar" and that comparison should technically be without
regard to case.
-Alan.
More information about the core-libs-dev
mailing list