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
