This discussion is archived
1 2 Previous Next 21 Replies Latest reply: Oct 4, 2010 10:40 PM by 796440 RSS

"flush on outputstream will do nothing"

799873 Newbie
Currently Being Moderated
Hello,



as stated in the api: http://download.oracle.com/javase/1.4.2/docs/api/java/io/OutputStream.html#flush()
the method flush does nothing on outputstream, but what does this exactly means?

if i do socket.getOutputStream().flush(), does that means it will do nothing, so i can delete it?


thanks in advance
  • 1. Re: "flush on outputstream will do nothing"
    Kayaman Guru
    Currently Being Moderated
    No, it only says that in the abstract class OutputStream flush() does nothing. It doesn't say anything about its concrete subclasses.
  • 2. Re: "flush on outputstream will do nothing"
    801079 Newbie
    Currently Being Moderated
    Whenever flush is encountered, then any pending bytes present in the output stream are flushed out.

    Usually a buffered writer is used to write contents to disk. BufferedWriter buffers contents and writes in chunks. If flush is not called in the last, then if there are any leftover bytes in the output stream they are lost and are not written to disk.

    See the following method which writes out 100 random numbers to file.
         public static void writeJunk() throws IOException {
              int r;
              FileOutputStream fos = null;
              BufferedOutputStream bos = null;
              BufferedWriter br = null;
    
              fos = new FileOutputStream("TRs.txt");
              OutputStreamWriter osw = new OutputStreamWriter(fos);
              br = new BufferedWriter(osw);
    
              for (r = 0; r < 100; r += 10) {
                   br.write(String.valueOf(Math.random()));
                   System.out.println(r);
              }
              // This is where flush is called.
              br.flush();
              br.close();
              bos.close();
              fos.close();
         }
    Suppose all 100 random numbers accounted to be 804kb and 800 write operations have written 800 bytes of the 804 bytes to disk by the time the for loop has ended. 4 are still left in the buffer of the BufferedWriter.

    Now if the 'flush' method is not called, these left over bytes are not written to disk and are simply lost. This might lead to anything, a corrupt zip file written to disk, or corrupt text file etc.
  • 3. Re: "flush on outputstream will do nothing"
    796440 Guru
    Currently Being Moderated
    DynamicBasics wrote:
    If flush is not called in the last, then if there are any leftover bytes in the output stream they are lost and are not written to disk.
    That might happen. There's no guarantee that it will. First calling close() also calls flush(). Second, there's nothing to prevent the buffered Stream or Writer from flushing of its own accord.

    Of course, the fact that it could happen is reason enough to insist that flush(), or at least close(), must be called.
    Now if the 'flush' method is not called, these left over bytes are not written to disk and are simply lost. This might lead to anything, a corrupt zip file written to disk, or corrupt text file etc.
    If you're using a Writer at all with a zip file, you're pretty much guaranteed it will be corrupt regardless. Writers are for text only.
  • 4. Re: "flush on outputstream will do nothing"
    801079 Newbie
    Currently Being Moderated
    jverd wrote:
    DynamicBasics wrote:
    If flush is not called in the last, then if there are any leftover bytes in the output stream they are lost and are not written to disk.
    That might happen. There's no guarantee that it will. First calling close() also calls flush(). Second, there's nothing to prevent the buffered Stream or Writer from flushing of its own accord.

    Of course, the fact that it could happen is reason enough to insist that flush(), or at least close(), must be called.
    Okay, but I always had this doubt- Why to have flush in the API at all? Why not the API take care that things are flused out on close or something?

    I always felt the following -

    The very existance of flush method in API makes me feel that something the API should ensure is not ensuring, so we cannot take a chance and should call flush before closing.
    or
    programmers would indeed need to flush in between, and I'm am not understanding when such an action is required.

    Any thoughts?
  • 5. Re: "flush on outputstream will do nothing"
    Kayaman Guru
    Currently Being Moderated
    DynamicBasics wrote:
    Okay, but I always had this doubt- Why to have flush in the API at all? Why not the API take care that things are flused out on close or something?
    It is flushed on close. The API does take care of it.

    Sometimes you just might need to flush() without closing, for example when you have written enough data and want to send it off without waiting for the buffer to flush itself.
    Still, the programmer rarely needs to call flush() by himself.
  • 6. Re: "flush on outputstream will do nothing"
    801079 Newbie
    Currently Being Moderated
    Kayaman wrote:
    Still, the programmer rarely needs to call flush() by himself.
    Yes, that is what I'm curious about, anyone ever found it necessary to use flush in some of their code? Or is it that flush is exposed by the API but is useless!
  • 7. Re: "flush on outputstream will do nothing"
    Kayaman Guru
    Currently Being Moderated
    DynamicBasics wrote:
    Kayaman wrote:
    Still, the programmer rarely needs to call flush() by himself.
    Yes, that is what I'm curious about, anyone ever found it necessary to use flush in some of their code? Or is it that flush is exposed by the API but is useless!
    It's not useless, it's just not often needed by the programmer. Depending of course on the type of things the program is doing.
    If you have a simple "read all data from point A and write the data to point B" it's not needed.
    If you're sending messages back and forth between point A and point B, then you can flush the buffer after every message.
  • 8. Re: "flush on outputstream will do nothing"
    801079 Newbie
    Currently Being Moderated
    Kayaman wrote:
    If you're sending messages back and forth between point A and point B, then you can flush the buffer after every message.
    Whow! It never occured to me!
    Thanks for the education!!
  • 9. Re: "flush on outputstream will do nothing"
    452196 Journeyer
    Currently Being Moderated
    DynamicBasics wrote:
    Kayaman wrote:
    Still, the programmer rarely needs to call flush() by himself.
    Yes, that is what I'm curious about, anyone ever found it necessary to use flush in some of their code? Or is it that flush is exposed by the API but is useless!
    It's about decoupling. When you write code which writes to an OutputStream it's better that that code makes no assumptions about what kind of OutputStream it is, like if if's buffered or not.

    So you make sure you call flush if relevant and close every time anyway, rather than assuming you don't need it in this particular case.
  • 10. Re: "flush on outputstream will do nothing"
    796440 Guru
    Currently Being Moderated
    DynamicBasics wrote:
    jverd wrote:
    DynamicBasics wrote:
    If flush is not called in the last, then if there are any leftover bytes in the output stream they are lost and are not written to disk.
    That might happen. There's no guarantee that it will. First calling close() also calls flush(). Second, there's nothing to prevent the buffered Stream or Writer from flushing of its own accord.

    Of course, the fact that it could happen is reason enough to insist that flush(), or at least close(), must be called.
    Okay, but I always had this doubt- Why to have flush in the API at all? Why not the API take care that things are flused out on close or something?
    As I already said, close() does call flush(). However, sometimes that's not good enough. For instance, if you have a long-lived network connection. You send some data, and you're not ready to close the connection yet, but you want the data to be sent ASAP, so you call flush().

    >
    I always felt the following -

    The very existance of flush method in API makes me feel that something the API should ensure is not ensuring, so we cannot take a chance and should call flush before closing.
    Nope. close() calls flush()
    or
    programmers would indeed need to flush in between, and I'm am not understanding when such an action is required.
    Yup. When you want to send the data now, but are not ready to close() yet.
  • 11. Re: "flush on outputstream will do nothing"
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jverd wrote:
    As I already said, close() does call flush(). However, sometimes that's not good enough. For instance, if you have a long-lived network connection. You send some data, and you're not ready to close the connection yet, but you want the data to be sent ASAP, so you call flush().
    To be sure however that is only relevant if it is explicitly buffered.
  • 12. Re: "flush on outputstream will do nothing"
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    DynamicBasics wrote:
    Kayaman wrote:
    Still, the programmer rarely needs to call flush() by himself.
    Yes, that is what I'm curious about, anyone ever found it necessary to use flush in some of their code?
    stdout with character output. It buffers to the line and perhaps to a count. So single character output doesn't go. Although that might have been associated with C++ rather than java.
  • 13. Re: "flush on outputstream will do nothing"
    796440 Guru
    Currently Being Moderated
    jschell wrote:
    jverd wrote:
    As I already said, close() does call flush(). However, sometimes that's not good enough. For instance, if you have a long-lived network connection. You send some data, and you're not ready to close the connection yet, but you want the data to be sent ASAP, so you call flush().
    To be sure however that is only relevant if it is explicitly buffered.
    Possibly. Is it a guarantee that any OutputStream or Writer that is not explicitly buffered (i.e., its docs don't state that it is or is not) is not buffered? Rather than assume, I'd call flush() in those cases. Additionally, many APIs deal with the abstract types, so you don't know what the underlying implementation is. So while the actual practical effect may only be present for Streams/Writers that document their buffered-ness, that may be a black box, so the rule "If you want it to go now, call flush()" applies.
  • 14. Re: "flush on outputstream will do nothing"
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jverd wrote:
    jschell wrote:
    jverd wrote:
    As I already said, close() does call flush(). However, sometimes that's not good enough. For instance, if you have a long-lived network connection. You send some data, and you're not ready to close the connection yet, but you want the data to be sent ASAP, so you call flush().
    To be sure however that is only relevant if it is explicitly buffered.
    Possibly. Is it a guarantee that any OutputStream or Writer that is not explicitly buffered (i.e., its docs don't state that it is or is not) is not buffered? Rather than assume, I'd call flush() in those cases. Additionally, many APIs deal with the abstract types, so you don't know what the underlying implementation is. So while the actual practical effect may only be present for Streams/Writers that document their buffered-ness, that may be a black box, so the rule "If you want it to go now, call flush()" applies.
    Per the above discussion it was referring to network connections. And that was given as an example for this discussion.

    The stream that you strip from the socket has the flush method. That flush does nothing. It can't do anything because there is no such thing as 'flush' in TCP.

    Conversely if that stream is wrapped in a buffered one, explicitly in the users code, then the user must explicitly consider whether it is appropriate to call flush on that or not (depending on the needs of the app.) Since that is often suggested (code examples, etc) when using sockets it is consistent to suggest that flush should be called. But not forgetting why flush is being called.
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points