4206909 - adding Z_SYNC_FLUSH support to deflaters
blong at google.com
Thu Sep 10 19:52:09 UTC 2009
The only use case that can't be worked around is if someone is relying
on code which either sub-classes DeflaterOutputStream or uses a
non-injected DeflaterOutputStream, where they can't replace it with a
fixed version. Both of these use cases probably aren't that common,
since if they ever needed a working flush, they would have had to work
around this bug a while back.
On 09/10/09 Xueming Shen uttered the following other thing:
> I think we have enough discussion on this topic, it's time to make a
> final decision. Seems like we are all happy on the
> changes in Deflater and new DOS.flush(mode), the only difference is
> whether or not we should change the existing
> behavior of DOS.flush() should use Z_SYNC_FLUSH by default.
> Brandon is very firm on the "yes" side, strongly believe this is a MUST.
> Martin is on the fence, leaning towards "yes"
> Sherman is on the "no" side
> So if there is no other vote coming with strong opinion, your vote will
> be important:-) Are you also leaning to "yes"
> or "strongly" suggesting a yes? I need strong "yes" to change my mind.
> The current proposal has the advantage of still keeping the door open to
> change the behavior if the new APIs
> really can not make the developer to achieve what they want to do or
> someone can present a strong case that
> the compatibility is really not a concern (we are all assuming there are
> some applications over there might be broken by this).
> The latest webrev is at
> I added a note to describe the behavior of DOS.flush(), as Brandon
> suggested as his "at the very least".
> Alan Bateman wrote:
>> 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?).
"I'd like to take this opportunity to thank all my code reviewers.
Without you ignoring my requests, I couldn't have made the list."
-- Wei-Hwa Huang
More information about the core-libs-dev