4206909 - adding Z_SYNC_FLUSH support to deflaters

[Xueming Shen]

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