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
