Hi! I came across an exception when running pack200 test PackTestZip64.java when I use a non-bundled zlib library with JDK8. This causes the test to fail. Upon examining the code, I believe the test fails incorrectly. The error is an side-effect of how new JarEntry's are created.
Below is the detailed report : --------------------------------------------------------------------------------------------------------------------------------------------------- ERROR TITLE: PackTestZip64 fails incorrectly with ZipException with JDK using system zlib PRODUCT VERSION: openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-root_2017_02_21_13_06-b00) OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode) OS VERSION: Linux kkharbas-desk2.amr.corp.intel.com 4.9.12-200.fc25.x86_64 #1 SMP Thu Feb 23 19:31:49 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux A DESCRIPTION OF THE PROBLEM: When using an alternative zlib implementation (in this case the implementation at https://github.com/jtkukunas/zlib) PackTestZip64 test fails incorrectly. The test fails with following exception: java.util.zip.ZipException: invalid entry compressed size (expected 88 but got 89 bytes) at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:267) at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:192) at java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:109) at PackTestZip64.generateLargeJar(PackTestZip64.java:137) at PackTestZip64.testPacking(PackTestZip64.java:55) at PackTestZip64.main(PackTestZip64.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(Thread.java:745) Here is what happens : The test generates a new jar file ( in generateLargeJar()) from existing files in golden.jar and also adds a large number of small dummy files. Because the JarEntry is created from existing jar file, the compressed size for it is set. Later ZipOutputStream.closeEntry() validates the compressed size of a file by comparing it to number of bytes written, if (e.csize != def.getBytesWritten()) { throw new ZipException( "invalid entry compressed size (expected " + e.csize + " but got " + def.getBytesWritten() + " bytes)"); } The above check fails, throwing an exception. However, the Zlib specification gives implementations a flexibility of choosing a string search algorithm, thus generating different bit streams. A workaround is to reset the compressed size of 'JarEntry' before its added to the new jar. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : 1. Build JDK specifying configure option : --with-zlib=system 2. Download and build the zlib from https://github.com/jtkukunas/zlib 3. Override the Linux zlib at /usr/lib64/ 4. Run PackTestZip64 test with jtreg --------------------------------------------------------------------------------------------------------------------------------------------------- If the community thinks this a valid diagnosis, an error should be filed. Thanks Kishor