Change in GZIPOutputStream behavior in Java 17?

Question

Was there an undocumented change to GZIP behavior in Java 17? I've looked at the Java update notes and they make no mention of compression to gzip changes. I've created a simple program to demonstrate the change:

ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
GZIPOutputStream compressorStream = new GZIPOutputStream(byteStream);
IOUtils.write("test1 test2 test3".getBytes(StandardCharsets.UTF_8), compressorStream);
compressorStream.finish();
for (byte b : byteStream.toByteArray()) {
    System.out.print(String.format("%02x ", b));
}

When I run this on Java 8 vs Java 17, it produces different results:

 Java 8: 1f 8b 08 00 00 00 00 00 00 ff 2b 49 2d 2e 31 54 28 01 92 46 60 d2 18 00 e8 5e b8 b9 11 00 00 00
Java 17: 1f 8b 08 00 00 00 00 00 00 ff 2b 49 2d 2e 31 54 28 49 2d 2e 31 02 93 c6 00 e8 5e b8 b9 11 00 00 00 

As you can see, not only are the byte values different, the number of bytes in the resulting array is even different!

Does anyone know why this is happening? Was there any documentation from the Java developers explaining this change in behavior?

(Java 8 version: 1.8.0_333, Java 17 version: 17.0.8)

Answer 1

I also ran into this, and what I found was that in JDK17, the deflate library is bundled with the Java runtime environment; in JDK8, it uses the system's zlib. And the bundled version is very slightly less efficient than the system version for me: if you pass the compressed stream to infgen, you can see that it uses a literal token instead of a backreference sometimes. I tried iterating over all combinations of Deflater parameters I could, but I couldn't get the two implementations to produce the same output stream.

(For people who are curious why I care at all, I'm using deflate in a compression-based similarity measure, and this change slightly perturbs my "golden output" tests.)