4206909 - adding Z_SYNC_FLUSH support to deflaters

[Xueming Shen]

The ZOutputStream of the "competing" jzlib has its "flush" control in 
its write() method,
it invokes "defalter.deflate()" with a "flush" parameter, the 
"flush"parameter is a protected
instance variable of the ZOutputStream class with a default value of 
z_no_flush.  So its
subclass can set whatever value is desirable. Its default "flush()" does 
the same thing we do,
out.flush():-)  So obviously all the "happy" jzlib users do not feel too 
bad to write their own
subclass to achieve whatever they can not get from our DOS/deflater.

While I still feel my original proposal is very close what the jzlib 
offers. I'm happy with
Alan's approach, and I suggest we simply do the z_no_flush/z_sync_flush. 
It should
not be too difficult for sophisticated developer to write their own DOS 
with the new
deflater class.

sherman

Alan Bateman wrote:
> Martin Buchholz wrote:
>> :
>> The use case for full flush is partial recoverability from future 
>> corruption
>> of the data.  If the competing java zib libraries are supporting this
>> flush variant,
>> we probably should too, for completeness.
>>   
> It's worth considering although we get into detail as to how the flush 
> mode is expressed in the constructor (an int is awkward because of the 
> existing size parameter, and java.util.zip was well into adolescence 
> when enums were introduced). The other option is to just ignore it as 
> the proposed Deflater.deflate method supports full flush and it's not 
> too difficult to create your own OutputStream that uses Deflater.
>
> -Alan.