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
