4206909 - adding Z_SYNC_FLUSH support to deflaters
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.
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