JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.
alexander.zuev at oracle.com
Thu Jan 16 16:21:30 UTC 2014
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
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
On 1/15/14 21:34, Xueming Shen wrote:
> On 1/15/14 7:01 AM, Alexander Zuev wrote:
>> the new webrev with all the typos and comments fixed can be found
>> at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/
> (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:-)
More information about the core-libs-dev