Xueming Shen wrote:
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
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.




Reply via email to