RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary

Uwe Schindler github.com+1005388+uschindler at openjdk.java.net
Sun Sep 20 18:32:17 UTC 2020


On Sun, 20 Sep 2020 18:03:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review the fix  for JDK-8252739 which addresses an issue introduced by
> https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by
> Deflater.setDictionary.  Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and
> java/util/jar JCK tests.

The tests with byte buffers (direct and heap) are not using offsets (arrayOffset=0). The direct buffer test uses just a
series of 0-bytes, so incorrect offsets won't change result. There should be real data copied into the direct buffer.

test/jdk/java/util/zip/DeflaterDictionaryTests.java line 105:

> 103:         byte[] output = new byte[RESULT_SIZE];
> 104:         // Compress the bytes
> 105:         ByteBuffer dictDef = ByteBuffer.wrap(DICTIONARY.getBytes(UTF_8));

This should use a slice of the byte buffer, so array offset is not 0. This can be done with offset and size on the
wrap() call.

test/jdk/java/util/zip/DeflaterDictionaryTests.java line 150:

> 148:         byte[] output = new byte[RESULT_SIZE];
> 149:         // Compress the bytes
> 150:         ByteBuffer dictDef = ByteBuffer.allocateDirect(DICTIONARY.length());

This creates an empty dictionary with only 0 bytes. Maybe copy some real data into the buffer. Also a slice should be
used.

-------------

Changes requested by uschindler at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/269


More information about the core-libs-dev mailing list