On 30 Nov 2017, at 14:46, Xueming Shen <xueming.shen@oracle.com> wrote:
Hi,
Please help review the change for JDK-8191918:
issue: https://bugs.openjdk.java.net/browse/JDK-8191918 webrev: http://cr.openjdk.java.net/~sherman/8191918/webrev
InflateIn_DeflateOut.java — 174 GZIPInputStream gzis = new GZIPInputStream(byteInStream); 175 ByteArrayOutputStream baos = new ByteArrayOutputStream(); 176 int numRead; 177 byte[] b = new byte[4 * 1024]; 178 try { 179 while ((numRead = gzis.read(buf)) >= 0) { 180 baos.write(b, 0, numRead); 181 } 182 } finally { 183 baos.close(); 184 } Can you use gzis.transferTo(baos)? Paul.
This is the backport/identical change we have already putback into earlier update releases for JDK-8189789. It includes two changes
(1) to replace the change we put into jdk9 for #8184306 with the "official" change currently in zlib github repo (https://github.com/madler/zlib/issues/275)
http://cr.openjdk.java.net/~sherman/8184306 https://bugs.openjdk.java.net/browse/JDK-8184306
(2) to change the way we handle the returned result Z_BUF_ERROR. Now the implementation expects that there might be bytes read from the input and bytes written to the output buffer when the deflateParams()/deflate() returns Z_BUF_ERROR. It is "interpreted as there is no enough buffer space for all output, but the deflater has decoded input bytes and write out output bytes as many as possible, come back with more available output space".
See related github/zlib discussions at #275 [1] and #305[2]
Thanks, Sherman
[1] https://github.com/madler/zlib/issues/275 [2] https://github.com/madler/zlib/issues/305