Hi Alex,
Kumar,
thanks for your findings. See my comments inline.
On 1/15/14 2:10, Kumar Srinivasan wrote:
Hi Alex,
zip.cpp: (nit) I would keep the hex values to be in upper case just
like the others for
consistency, not a big deal.
Fixed.
typo: + // Zip64 END sugnature
Also fixed.
PackTestZip64.java: shouldn't we test a jar with 64K+ entries ?
Do we really have to do so? Creating, repacking, packing, unpacking
and comparing of such jar
file would take a lot of testing time. Right now i'm just testing that
we are producing binary
identical jar after we normalized it. If you think creating of large
jar file is necessary i can easily do so.
We must have a test!, it is not necessary that we should execute this
all the time, but having this
in place, will enable SQ to run this test periodically, and we can run
it as well during development.
You can copy most of the logic from here, and use the system
property/strategy to enable the
time consuming one.
http://hg.openjdk.java.net/jdk9/dev/jdk/file/3b4ac8d1b76f/test/tools/launcher/BigJar.java
I think it would be good to test jars created by the JDK (tools.jar or
some suitable one), using the
golden jar may not be appropriate, since it is a pre-canned binary.
Also I am not sure if we should test jars created by JarOutputStream as
well as JarFile,
there are some nuances with these APIs and how they write out the jar file.
Kumar
/Alex
Kumar
On 1/14/2014 10:04 AM, Alexander Zuev wrote:
Please review my fix for
JDK-8029646: [pack200] should support the new zip64 format.
The fix can be found at
http://cr.openjdk.java.net/~kizune/8029646/webrev.00/
Bug description is: https://bugs.openjdk.java.net/browse/JDK-8029646
/Alex
