RFR: 8920687: Deflater.setLevel does not work as expected

Alan Bateman Alan.Bateman at oracle.com
Sat Sep 14 12:24:09 UTC 2013

On 13/09/2013 20:44, Xueming Shen wrote:
> Hi,
> This is change to clarify the java doc to match the existing behavior.
> If there is a "pending" level/strategy change (via 
> setLevel/Stragety()) when
> deflate(...) is invoked, the implementation goes down to zlib's 
> deflateParams()
> for deflating operation, which clearly specifies its behavior in 
> zlib.h as
> ----------------------------------------------------------------
>    Dynamically update the compression level and compression strategy.  
> The
>    interpretation of level and strategy is as in deflateInit2.  This 
> can be
>    used to switch between compression and straight copy of the input 
> data, or
>    to switch to a different kind of input data requiring a different 
> strategy.
>    If the compression level is changed, the input available so far is
>    compressed with the old level (and may be flushed); the new level 
> will take
>    effect only at the next call of deflate().
> -----------------------------------------------------------------
> and its corresponding implementation does exactly that.
It seems reasonable to have new strategy or level take effect after the 
available input has been compressed.

Your proposed wording is okay but I wonder if the word "current" should 
be dropped from the existing statement in setLevel. You might also be 
able to get away with a single statement too, something like "If 
changed, the new compression strategy takes effect after the input 
available has been compressed (or flushed)". Your wording is okay too if 
you really need to be explicit about deflate being called.


More information about the core-libs-dev mailing list