RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Jaikiran Pai jai.forums2013 at gmail.com
Wed Oct 23 11:24:28 UTC 2019


Can I please get a review and a sponsor for a potential fix for
JDK-8232879[1]? The patch is available as a webrev at [2].

What's happening in there is that the
jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the
one arg write(byte b) method and calling the super.write(b) and then
doing a crc.update. The super.write(b)
(java.util.zip.DeflaterOutputStream in this case) actually internally
calls the 3 arg write(b, offset, length) which is overriding by this
jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream. In its
implementation of write(b, offset, length), in addition to (rightly)
calling super.write(b, offset, length), this method also updates the CRC
(again). So this ends up updating the CRC multiple times when the single
arg write is invoked.

The patch now removes this overridden implementation of write(b) in the
DeflatingEntryOutputStream so that the call is handled by the
java.util.zip.DeflaterOutputStream. Although there's no @implNote on
java.util.zip.DeflaterOutputStream#write(byte b) static that it's
(always) going to call the 3 arg write(b, offset, length) method, the
implementation as of now does indeed do that. So I guess, its probably
OK to rely on that knowledge and get rid of this overridden write(b)
method instead of coming up with a bit more complicated fix.

The patch also includes a jtreg testcase which reproduces this issues
and verifies the fix.

[1] https://bugs.openjdk.java.net/browse/JDK-8232879

[2] https://cr.openjdk.java.net/~jpai/webrev/8232879/1/webrev/

-Jaikiran




More information about the core-libs-dev mailing list