4206909 - adding Z_SYNC_FLUSH support to deflaters

[Martin Buchholz]

JDK has often chosen compatibility over doing something Right.

I think the risk of performance degradation due to frequent calls to
flush() is higher than one might think at first.  Calls to flush may be
made on one's behalf by some middleware between the user
and the DOS.  E.g. someone might wrap an auto-flushing PrintStream
around a DOS, which causes surprisingly many calls to flush
(Although see java puzzler "Char'ed beyond recognition")
Venerable System.out is an example of an auto-flushing PrintStream.

As I said previously, I am a bit on the fence with this issue myself,
but given Xueming's reluctance, let's agree to do things his way.

Users (like Google) who want this functionality *now* will need
to develop a private version of this change in any case for use with
java 6.

Martin

On Wed, Sep 9, 2009 at 12:34, Brandon Long<blong at google.com> wrote:
> I really don't understand this.  I think just about everyone would
> expect that flush on an output stream means send all the data I've
> written.  There are a large number of people who have stumbled on this
> bug and several others, and the fact that it wasn't fixed when it was
> discovered 10 years ago is justification for not fixing it now?
>
> I imagine a lot of people will stumble on this in the future, instead of
> it just working as expected.
>
> This is up against some unknown fraction of people who are for some
> reason happy with the current broken behavior, and would dislike paying
> a 10-50% penalty in compression because their code calls flush when they
> don't actually need to?
>
> At the very least, this misfeature needs to be called out in the
> documentation for the DeflaterOutputStream class.
>
> Brandon
>
> On 09/09/09 Xueming Shen uttered the following other thing:
>> Martin, Brandon, Alan
>>
>> I still believe the best choice at this moment is to be a little more
>> conservative, given the DOS.flush() has been
>> working in this behavior for decade. The proposed methods are good
>> enough to serve the functionality required,
>> I don't think it is worth breaking the compatibility in this case simply
>> because "it would be better...". We definitely
>> can consider to change the position should the feedback show this is not
>> the case.
>>
>> I will start the CCC if you guys are OK with the latest wording. The doc
>> has been changed "slightly" compared to
>> last version, thanks for the comment from all of you.
>>
>> http://cr.openjdk.java.net/~sherman/zipflush/webrev
>>
>> Sherman
>
> --
>  "I need to either get a new hard drive or clean my home dir."
>        -- Mark Notarus
>                                           http://www.fiction.net/blong/
>