Sherman, Kumar,

i have fixed the glitches you have found and changed the test so it creates a new jar based on the golden.jar content (to have a reasonable set of various data to start with), then adding to it 65536 empty files to test how we cope with such a huge jars.

The testing time is less than a 30 seconds on my machine (not the top-of-the-line) so i decided not to bother with conditional testing, lets test our behavior every time in full.

The updated webrev can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.02

/Alex

On 1/15/14 21:34, Xueming Shen wrote:
On 1/15/14 7:01 AM, Alexander Zuev wrote:
Hello,

the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/

/Alex

(1) jarmagic can be just a static constant somewhere or a stack variable. not big deal though. (2) the test only "tests" EOF for s. there is possibility that the newly created has more extra bytes at the end...though in theory this should not happen, it might be better just add an
      extra line to check the sizes of two first first?
(3) the rest of the change looks good, but I agreed with Kumar that you may need to add a regression test for a jar file with > 64k entries. otherwise the code for zip64 end is not being tested. the code looks fine, but I would trust a regression test more than my eyes:-)

Thanks!
-Sherman

Reply via email to