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/

-Sherman

On 08/24/2011 12:06 AM, Alan Bateman wrote:
Xueming Shen wrote:
:

Fix has been verified/test manually with existing test cases. Given the nature
of the > 4G zip data file. I'm not including an auto regression test.

Webrev is at

http://cr.openjdk.java.net/~sherman/7077769/webrev
The zip64 fix looks okay to me. The fix to sync() is okay too although I would change this to use try-with-resources.

On the test, I agree an automated test might be too slow to run. However, as zip64 is tricky to get right then having a sanity test in the test tree (without a @test tag) would be useful.

-Alan

Reply via email to