> On 30 Nov 2017, at 14:46, Xueming Shen <xueming.s...@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
