4206909 - adding Z_SYNC_FLUSH support to deflaters
Xueming.Shen at Sun.COM
Mon Sep 14 04:12:22 UTC 2009
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.
not be too difficult for sophisticated developer to write their own DOS
with the new
Alan Bateman wrote:
> Martin Buchholz wrote:
>> The use case for full flush is partial recoverability from future
>> 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.
More information about the core-libs-dev