4813885: RFE: GZIPOutputStream should implement flush using Z_SYNC_FLUSH
Martin Buchholz
martinrb at google.com
Thu May 13 06:58:37 UTC 2010
On Wed, May 12, 2010 at 23:46, Xueming Shen <xueming.shen at oracle.com> wrote:
> Thanks for the review.
>
> The Z_SYNC_FLUSH is supposed to fully replace the Z_PARTIAL_FLUSH.
>
> We concluded last round that Z_SYNC_FLUSH is enough for the "high-level"
> DOS, as well as the GZIPOS, use Deflater directly if more needed. I hope
> you
> are not suggesting we go back to redo the flush to int.
Maybe we should.
http://www.jcraft.com/jzlib/
"""
To implement this functionality, the Z_PARTIAL_FLUSH mode of zlib must
be used, however JDK does not permit us to do so. It seems that this
problem has been well known and some people have already reported to
JavaSoft's BugParade(for example, BugId:4255743), but any positive
response has not been returned from JavaSoft, so this problem will not
be solved forever. This is our motivation to hack JZlib.
"""
> Took a quick look at 1.2.5, don't see anything make it attractive for us to
> "upgrade" again.
I rather liked their marketing:
# Fixed bugs in adler32_combine(), compressBound(), and deflateBound()
# Wholesale replacement of gz* functions with faster versions
# As part of that, added gzbuffer(), gzoffset(), gzclose_r(), and
gzclose_w() functions
# Faster Z_HUFFMAN_ONLY and Z_RLE compression for images and other
specialized compression
# Added flush options Z_BLOCK to deflate() and Z_TREES to inflate()
for finer control
# Added inflateReset2() and inflateMark() functions, the latter to aid
in random access applications
# Added LFS (Large File Summit) support for 64-bit file offsets and
many other portability improvements
Martin
> Sherman
>
> Martin Buchholz wrote:
>>
>> zlib 1.2.5 is out!
>>
>> Quite notably, there are now more flush modes
>> and the comment claiming that Z_PARTIAL_FLUSH
>> will be removed has been removed!
>>
>> As I recall saying in a previous email,
>> we should support Z_PARTIAL_FLUSH at least
>> because the ssh protocol requires it.
>> I think the flush parameter should be an int.
>>
>> ----
>>
>> invocatin => invocation
>>
>> + * if {@code true} invocatin of the inherited
>>
>> Martin
>>
>> On Wed, May 12, 2010 at 15:51, Xueming Shen <xueming.shen at oracle.com>
>> wrote:
>>
>>>
>>> Martin,
>>>
>>> Would you please help review the change for
>>>
>>> 4813885: RFE: GZIPOutputStream should implement flush using Z_SYNC_FLUSH
>>>
>>> http://cr.openjdk.java.net/~sherman/4813885/webrev
>>>
>>> It appears people want to have the same flush option in GZIPOutputStream
>>> as
>>> the
>>> one we provided in DeflaterOutputStream for #4206909 a while ago, the
>>> webrev
>>> for
>>> 4206909 is at
>>>
>>> http://cr.openjdk.java.net/~sherman/4206909/webrev
>>>
>>> Thanks,
>>> -Sherman
>>>
>>>
>
>
More information about the core-libs-dev
mailing list