4206909 - adding Z_SYNC_FLUSH support to deflaters
Xueming.Shen at Sun.COM
Thu Sep 10 18:47:54 UTC 2009
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?).
More information about the core-libs-dev