JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.

Alexander Zuev alexander.zuev at oracle.com
Thu Jan 16 16:21:30 UTC 2014


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




More information about the core-libs-dev mailing list