I sometime too feels the same frustration when get kicked by the compatibility, especially if you have to back out hundreds of lines of code just because it is "incompatible". I guess someone said it right a while
ago,  the compatibility sucks, but yes, MOST end user/developer like it.

I disagree with the statement that "we are not fixing it". As I said in my last email, the proposed change does address the issue and provide a reasonable solution to the problem that can't not be solved with the existing APIs. My understanding of the key issue here is that the existing DeflaterOutputStream and Deflater do not provide the method(s) to sync_flush the underlying deflater, which is a must for some use scenario. I believe most developers should be happy as long as such methods are provided, it is NOT necessary to be the flush().

Yes, the justification for me to go with the conservative approach here is exactly the "behavior has been in this
way for 10 years". Let me share my consideration here again.

For existing running application, the DOS.flush() has not been working the way someone might expect for decade, so I don't think there is any application is sitting tightly and patiently over there for years to just wait for us to "fix" the DOS.flush() behavior and their app will then magically work as "expected". They
either go with the ugly workaround or go use jzlib.

For developer that are waiting this to be fix so that they can simply use the default zlib included in java in their application, the proposed solution just works fine, use the flush(int) when needed, they have to explicitly invoke A flush method anyway, why it can not be the flush(int) (or say, why it must be the flush()).

The only benefit of having a sync_flush flush() in DOS is that you don't have to override the default flush() when you have to pass the DOS around and "flush()" will be invoked "indirectly" by other part/layer of the code. The price to pay for this "convenience" is the incompatibility. The applications that works for years might suddenly experience the "regression" when migrated to JDK7. We DONT know if there are really such applications there and how important they are until we hit it real world. At this point, the merit of doing this seems not worth it.

I can see other benefit of doing this. If we change the behavior of DOS.flush() in JDK7 and do not see lots of "regression" complain over there, it will be then easy to backport part of the change (means the DOS.flush()
only) into 6 releases.

I agree it might be a better to have some thing in the DOS api to explain the situation, how about to have
a note like below to add into the flush(int) API doc.

<p>Note: The inherited flush() method only flushes the output stream without flushing the compressor(), it should be overridden to do flush(Deflater.SYNC_FLUSH) or flush(Deflate.FULL_FLUSH) if desirable.


sherman






Brandon Long 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


Reply via email to