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