I would like to use the Inflater/Deflater from a java-program to 
communicate with a c-program using the zlib impl. In my case I can't
do this due to the fact that I can't do Z_PARTIAL_FLUSH, it would IMHO
be VERY nice if the "native" zlib inflate/deflate were exposed in
the Inflater/Deflater classes, this would make the use more generic.
(Review ID: 88111) 
======================================================================

N/A

Not sure if this is a reasonable and general request. Will investigate further
into this.

 xxxxx@xxxxx  2000-03-09

What would the reason for NOT exposing the "true"
functionality from ZLIB be?

The program in question does a very nice job of ssh, but it 
does not perform the gzip compression that makes ssh 
conserve bandwidth so well.  If the appropriate 
Z_PARTIAS_FLUSH were allowed, then this pure java 
implementation of ssh would be doable.

As far as I can tell, there is very little downside, save 
that if you decide to implement this in java rather than 
native code, you would need to supply the same 
functionality.

This is the same as 4206909,  by having it twice it dilutes
the votes for it.   It is a very reasonable and general
request and should be very easy since the functionality is 
already in zlib, you just need to add the wrapper for it.
This avoids the duplications of zlib that is needed now to 
support streaming interactive compressions applications 
like ssh.  And avoids needed to run a java reimplimentation 
of zlib also.

I agree, I dont think this is an unreasonable request.

As noted it is the same as bug 4206909. Sun has been
lamenting on this from 1999 on. One cannot deny the
importance of having pure java solution supported by
standard libs that allows to use compressed sockets. This
also affects RMI/EJB...

In the meantime we can use http://www.jcraft.com/jzlib/ to
have compete compatibility with zlib.
But nonetheless having it "native" would be better...

Extending DeflaterOutputStream and overriding flush() as 
outlined below
yields a deflating OutputStream, that can be used for data 
transmission
(e.g. SocketOutputStream). 

Plase note, that InflaterInputStream should be subclassed 
as well in
order to prevent false blocking on reads. 

Furthermore (De/In)-flaters with nowrap == true should be 
used
to ommit headers/trailers.

rws@saddey.com 23-jun-02

The output part:

public class CompressingOutputStream extends 
DeflaterOutputStream {

    public CompressingOutputStream (final OutputStream out) 
{
      // Using Deflater with nowrap == true will ommit 
headers and trailers
      super(out, new Deflater
(Deflater.DEFAULT_COMPRESSION,true));
    }

    private static final byte [] EMPTYBYTEARRAY = new byte 
[0];
    /**
     * Insure all remaining data will be output.
     */
    public void flush() throws IOException {
        /**
         * Now this is tricky: We force the Deflater to 
flush
         * its data by switching compression level.
         * As yet, a perplexingly simple workaround for 
         * 
http://developer.java.sun.com/developer/bugParade/bugs/42557
43.html 
         */
        def.setInput(EMPTYBYTEARRAY, 0, 0);

        def.setLevel(Deflater.NO_COMPRESSION);
        deflate();

        def.setLevel(Deflater.DEFAULT_COMPRESSION);
        deflate();

        out.flush();
    }
} // class

The input part:

public class DecompressingInputStream extends 
InfalterInputStream {

    public DecompressingInputStream (final InputStream in) {
      // Using Inflater with nowrap == true will ommit 
headers and trailers
      super(in, new Inflater(true));
    }

    /**
     * available() should return the number of bytes that 
can be read without
     * running into blocking wait. Accomplishing this feast 
would eventually require
     * to pre-inflate a huge chunk of data, so we rather 
opt for a more relaxed
     * contract (java.util.zip.InflaterInputStream does not 
fit the bill). 
     * This code has been tested to work with 
BufferedReader.readLine();
     */
    public int available() throws IOException {
      if (!inf.finished() && !inf.needsInput()) {
        return 1;
      } else {
        return in.available();
      }
    }

} //class

The workaround suggested by rsaddey works great except for
one small problem.  The code in the 'flush' method needs to
run only if 'def.finished()' returns false.  (e.g. if
(!def.finished()) { ... }

I see no reason not to select this bug as a duplicate of bug
 4206909... maybe Sun people just don't read bug reports 0_O
Let's move all our votes there (right now there are 20 here
and 38 there) so that the bug can get a little more
"importance".

The following changes has to be made:
1) Z_PARTIAL_FLUSH must be exposed.
2) DeflaterOutputStream must correctly implement flush() method. 

It looks like authors of java.util.zip have only file compression in mind and had no clue whatsoever that one might want to compress messages that are being sent back and forth over network.

It is because of the absence of this flushing functionality that a complete reimplementation of zlib in Java has been produced at <http://www.jcraft.com/jzlib/> under a BSD-style license.  Hey, Sun, please consider replacing the native version with this!  [And I'll see you on Tuesday]

man its a shame that this design _flaw_ still has not been fixed!

what's about 1.7 ?
around 10 years, it's too long time.

JCraft implementation is good, but up to 8 times slowly than zlib :(

I'm seeing cases where using flush as defined here gives an extra 0 byte on the end of the decompressed content.

I haven't managed to track down why...