Thanks, this helps a lot.  I understand it now.

Mike


On Jul 26, 9:55 am, Michèle Garoche <[email protected]> wrote:
> On 26 juil, 10:26, "Mike M. Lin" <[email protected]> wrote:> The examples 
> in the Networking lesson did not close any of the input
> > streams, the output streams, the readers, or the writers.
>
> They close the enclosing stream and this is sufficient to release all
> objects associated with them, that is also the in, out, etc.
>
> An example:
> in = new DataInputStream(new BufferedInputStream(new
> FileInputStream(dataFile)));
>
> You need to close in which will close all objects it contains.
>
> See the Javadoc for full explanation.
> You may also use debugging in NetBeans to trace the status of all
> those objects.
>
>   I have some> questions about that:
>
> > 1) Is it normal to NOT close those objects?
> > 2) When should we explicitly close a stream,
>
> Always when not using it anymore. (well maybe not at the end of a
> unique main program where it is closed anyway, but this is not a good
> practice).
>
> > a reader, or a writer --
>
> If they are called from a stream, buffered stream, anything enclosing
> them, never, providing that you close the enclosing stream. They will
> be automatically closed when closing the enclosing stream.
>
> > and when is OK not to?  [Does it depend on the specific class, or
> > maybe how long before the program exits and releases everything
> > anyways?]
> > 3) If I do close a reader that's wrapper around an input stream, does
> > the input stream automatically get closed as well?  [Is the same true
> > for a writer and an output stream?]
>
> Not sure if I understand here (but it may be a problem of not being a
> native English speaker), I would have said that an input stream is a
> wrapper around a reader not the other way around, anyway see answer
> above. The principle is to close the most left open stream whatever.
>
>
>
> > Also, I'd like to share an observation with the group.  I noticed that
> > if you do not flush the writer before closing the socket, then the
> > unflushed data will not be written to the socket.
>
> This is because the PrintWriter works by buffer, so normally the
> buffer is written when it is full. That's why you need to flush the
> buffer at the end to ensure that contrary to its normal behaviour, the
> buffer is written immediately.
> Notice that if you use auto-flush in the creation of the PrintWriter,
> that does not impede that some character (especially end of line) may
> not be written at the end, so conclusion: always flush at the end, no
> matter if you enable auto-flush or not. (well if you rely on finding
> end of line characters in the other parts of the program or any
> program which uses your snippet of code).
>
> Again see the Javadoc for PrintWriter, which explains that in full
> detail.  
>
> Michèle Garoche
>
>
>
> >Be careful with
> > that.  Here's a sample of broken code:
>
> > Socket client = server.accept();
> > PrintWriter out = new PrintWriter(client.getOutputStream()); // no
> > auto-flush
> > out.println("poop, but don't flush"); // put the message in the buffer
> > client.close(); // failure: the message is never delivered

-- 
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/javaprogrammingwithpassion?hl=en

Reply via email to