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.
