RFR JDK-8191918: tomcat gzip-compressed response bodies appear to be broken in update 151
Paul Sandoz
paul.sandoz at oracle.com
Sat Dec 2 01:11:35 UTC 2017
+1
This is a good example of where “var” can really reduce the verbosity, up to you.
Also ByteArrayOutputStream.close is a no-op, you don’t need the finally block.
Paul.
> On 1 Dec 2017, at 17:04, Xueming Shen <xueming.shen at oracle.com> wrote:
>
> On 12/1/17, 3:40 PM, Paul Sandoz wrote:
>>
>>> On 30 Nov 2017, at 14:46, Xueming Shen<xueming.shen at 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.
>>
>>
>
> Thanks Paul!
>
> webrev has been updated as suggested.
>
> http://cr.openjdk.java.net/~sherman/8191918/webrev
>
> -Sherman
More information about the core-libs-dev
mailing list