The contract for java.io.OutputStream.flush()

Question

The Javadoc for method java.io.OutputStream.flush() is
public void flush()
           throws IOException
    Flushes this output stream and forces any buffered output bytes to be written out. The
general contract of flush is that calling it is an indication that, if any bytes previously
written have been buffered by the implementation of the output stream, such bytes
should immediately be written to their intended destination.Thread http://forums.sun.com/thread.jspa?threadID=5318876&tstart=0 highlighted a problem with this contract in that there are some OutputStream such as CipherOutputStream (when using PKCS5Padding) where it does not make sense to implement to the flush() contract. In meeting this contract one would have to close the stream so that nothing else could be written after a flush. The reason for the problem is that only complete blocks of data can be written. Until one has a complete block, the bytes of an incomplete block have to be stored in the CipherOutputStream. Only when one closes a CipherOutputStream can the bytes of the incomplete block be padded to create a complete block, encrypted and then written.
I have a similar problem with my Base64OutputStream where I can only write a multiple of 3 input bytes until I close() when I can provide appropriate padding.
So, should one do as ghstark proposed in http://forums.sun.com/thread.jspa?threadID=5318876&tstart=0 and close() the stream when one flushes it or should one do as I currently do and only write out as much as possible without closing the stream. It would seem that one either has to break the flush() contract or break the encryption (or in my case Base64) contract.
I would appreciate comments.

Answer 1

DrClap wrote:
Well, if it were me I would probably redefine the flush() method to only write the bytes that I was ready to write. So in your Base64 case I might be holding back one or two bytes.That is exactly what my Base64OutputStream and Sun's CipherOutputStream do.
If challenged on that I would just say that my flush() method conformed to the contract because those bytes weren't "buffered" yet.I like the concept but any wording would have to be carefully written. I suppose that I could argue that I have not buffered any bytes that could be written so I have not buffered any bytes.