4206909 - adding Z_SYNC_FLUSH support to deflaters

Alan Bateman Alan.Bateman at Sun.COM
Wed Sep 9 20:57:17 UTC 2009

Xueming Shen wrote:
> 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
The Deflater proposal feels right and fits well with the existing API. 
The DeflaterOutputStream.flush(int) proposal is workable but it will 
clearly be a hard sell to get developers to extend DeflaterOutputStream 
and override the no-arg flush method (which they will need to do to get 
this to work with existing code/libraries). How you considered 
overriding the flush() method to use Z_SYNC_FLUSH but have some way to 
restore existing behavior in the event that it causes severe performance 
or other issues for someone migrating an existing application to jdk7? I 
hate suggesting yet another system property to get us out of jail. Aside 
from an application calling flush a lot, are there any other behavioral 
implications (say for GZIPOutputStream?).


More information about the core-libs-dev mailing list