4206909 - adding Z_SYNC_FLUSH support to deflaters

Brandon Long blong at google.com
Wed Sep 9 19:34:39 UTC 2009

I really don't understand this.  I think just about everyone would
expect that flush on an output stream means send all the data I've
written.  There are a large number of people who have stumbled on this
bug and several others, and the fact that it wasn't fixed when it was
discovered 10 years ago is justification for not fixing it now?

I imagine a lot of people will stumble on this in the future, instead of
it just working as expected.

This is up against some unknown fraction of people who are for some
reason happy with the current broken behavior, and would dislike paying
a 10-50% penalty in compression because their code calls flush when they
don't actually need to?

At the very least, this misfeature needs to be called out in the
documentation for the DeflaterOutputStream class.


On 09/09/09 Xueming Shen uttered the following other thing:
> Martin, Brandon, Alan
> I still believe the best choice at this moment is to be a little more  
> conservative, given the DOS.flush() has been
> working in this behavior for decade. The proposed methods are good  
> enough to serve the functionality required,
> I don't think it is worth breaking the compatibility in this case simply  
> because "it would be better...". We definitely
> can consider to change the position should the feedback show this is not  
> the case.
> I will start the CCC if you guys are OK with the latest wording. The doc  
> has been changed "slightly" compared to
> last version, thanks for the comment from all of you.
> http://cr.openjdk.java.net/~sherman/zipflush/webrev
> Sherman

 "I need to either get a new hard drive or clean my home dir." 
        -- Mark Notarus

More information about the core-libs-dev mailing list