4206909 - adding Z_SYNC_FLUSH support to deflaters

[Brandon Long]

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.

Brandon

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
>
> http://cr.openjdk.java.net/~sherman/zipflush/webrev
>
> I added a note to describe the behavior of DOS.flush(), as Brandon  
> suggested as his "at the very least".
>
> Sherman
>
> 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?).
>>
>> -Alan.
>>
>>
>>
>>

-- 
  "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