4206909 - adding Z_SYNC_FLUSH support to deflaters

Xueming Shen Xueming.Shen at Sun.COM
Fri Sep 4 22:18:56 UTC 2009

I would like to take the conservative (read compatible) approach for 
this issue.

(1)expose zlib's flush mode Z_NO_FLUSH, Z_SYNC_FLUSH and Z_FULL_FLUSH
(2)add deflate(byte[] b, int off, int len, int flush)
(3)document the existing deflate() continues to use Z_NO_FLUSH
(4)add DeflaterOutputStream.flush(int flushmode)
    and leave DeflaterOutputStream.flush() un-touched.


So the sophisticated Deflater/DeflaterOutputStream user can now use all 
3 flush flavors
by using the newly added APIs explicitly. "naive" Deflater/DOS user 
(means no need for
the sync/full_flush) and existing application can continue live with/use 
the existing API
without any compatibility concern. The only disadvantage of this 
approach is the
"in-direct flush" use scenario (means the DOS is passed around and the 
inherited flush()
is invoked by other wrapping classes) will not be benefited from this 
change, they have
to override the flush() methold before passing the DOS object around, 
like what I do
in the test case Flush()

    static class MyDeflaterOutputStream extends DeflaterOutputStream {
        public MyDeflaterOutputStream(OutputStream out) {

        public void flush() throws IOException {

A little inconvenient, but seen like worth the  price of being 
compatible, for now. And we
still have the choice to do whatever we want to do with this method in 
the future should the
feedback show I'm wrong and the compatibility does not matter.

Opinion? If you guys agree (please also review the webrev) I can start 
the "process".


More information about the core-libs-dev mailing list