Closing sockets and streams?

java-programmer, Closing sockets and streams? If I have a socket and an InputStream and OutputStream that I have
opened from that socket, do I need to close the streams when I am
finished if I close the socket?

--

Knute Johnson
email s/nospam/knute/

java-programmer >> Closing sockets and streams? out.close();
in.close();
clientSocket.close();
serverSocket.close();

from
http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html

protected void finalize(){
//Clean up
try{
in.close();
out.close();
server.close();
} catch (IOException e) {
System.out.println("Could not close.");
System.exit(-1);
}
}

from
http://java.sun.com/developer/onlineTraining/Programming/BasicJava2/Code/SocketServer.java

It appears it is recommended.

Opalinski
email***@***.com
http://www.geocities.com/opalpaweb/

java-programmer >> Closing sockets and streams? email***@***.com opalinski from opalpaweb wrote:
> out.close();
> in.close();
> clientSocket.close();
> serverSocket.close();
>
> from
> http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html
>
> protected void finalize(){
> //Clean up
> try{
> in.close();
> out.close();
> server.close();
> } catch (IOException e) {
> System.out.println("Could not close.");
> System.exit(-1);
> }
> }
>
> from
> http://java.sun.com/developer/onlineTraining/Programming/BasicJava2/Code/SocketServer.java
>
>
> It appears it is recommended.
>
>
>
> Opalinski
> email***@***.com
> http://www.geocities.com/opalpaweb/
>

Excellent! Thank you.

--

Knute Johnson
email s/nospam/knute/

java-programmer >> Closing sockets and streams? On Fri, 20 Jan 2006 16:22:19 -0800, Knute Johnson
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

>If I have a socket and an InputStream and OutputStream that I have
>opened from that socket, do I need to close the streams when I am
>finished if I close the socket?

You close the last thing you opened, and it deals with closing all the
things you built up to it.

So, for example, closing a buffered output stream closes the embedded
output stream.

close calls super.close() all the way down like turtles.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Closing sockets and streams? Roedy Green wrote:
>
> You close the last thing you opened, and it deals with closing all the
> things you built up to it.
>
> So, for example, closing a buffered output stream closes the embedded
> output stream.
>
> close calls super.close() all the way down like turtles.

If the construction of the buffered output stream fails, then you have
to remember to close the underlying stream. However, you can wrap this
up in a convenience method.

A simpler idiom is: for output streams, flush the most wrapped output
stream in the happy case. close the underlying stream within a finally
block.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

java-programmer >> Closing sockets and streams? Thomas Hawtin wrote:
> Roedy Green wrote:
>
>>
>> You close the last thing you opened, and it deals with closing all the
>> things you built up to it.
>>
>> So, for example, closing a buffered output stream closes the embedded
>> output stream.
>>
>> close calls super.close() all the way down like turtles.
>
>
> If the construction of the buffered output stream fails, then you have
> to remember to close the underlying stream. However, you can wrap this
> up in a convenience method.
>
> A simpler idiom is: for output streams, flush the most wrapped output
> stream in the happy case. close the underlying stream within a finally
> block.
>
> Tom Hawtin

If you don't close them will they eventually get closed in the garbage
collector or are they left dangling forever?

--

Knute Johnson
email s/nospam/knute/

java-programmer >> Closing sockets and streams?
"Knute Johnson" <email***@***.com> wrote in message
news:JGBAf.12678$email***@***.com...

> If you don't close them will they eventually get closed in the garbage
> collector or are they left dangling forever?

Since the GC may never run, worst case is that they stay open. So it's wise
to close them youeself when you're done with them.

java-programmer >> Closing sockets and streams? On Sat, 21 Jan 2006 18:00:07 -0800, Knute Johnson
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

>
>If you don't close them will they eventually get closed in the garbage
>collector or are they left dangling forever?

I don't know. I have always presumed they could dangle unclosed
forever.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Closing sockets and streams? "email***@***.com opalinski from opalpaweb" <email***@***.com> wrote in
news:email***@***.com:

>
> protected void finalize(){
> //Clean up
> try{
> in.close();
> out.close();
> server.close();
> } catch (IOException e) {
> System.out.println("Could not close.");
> System.exit(-1);
> }
> }
>

No! Don't ever use finalizers to close critical resources. In fact, don't
use finalizers at all - there are very few legitimate reasons to ever use
one. Finalizers are not guaranteed to be called at any time, in any order,
or at all!

java-programmer >> Closing sockets and streams? Knute Johnson wrote:
> Thomas Hawtin wrote:
>> Roedy Green wrote:
>>> So, for example, closing a buffered output stream closes the embedded
>>> output stream.

>> A simpler idiom is: for output streams, flush the most wrapped output
>> stream in the happy case. close the underlying stream within a finally
>> block.

> If you don't close them will they eventually get closed in the garbage
> collector or are they left dangling forever?

If a tree falls in a wood with nobody about to here it, does it make any
noise?

It's not a question of when they get closed by the garbage collector.
They will have no chance at all of being closed by the garbage
collector. (Or more strictly, in a finalizer thread.) They have no
finaliser (nor other forms of reference handlers). They are not
resource, so it does not matter. Insisting on closing them is just voodoo.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

java-programmer >> Closing sockets and streams? On Mon, 23 Jan 2006 18:32:04 +0000, Thomas Hawtin
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

>Insisting on closing them is just voodoo.

If you don't close a file, the last bytes you wrote to it won't get
written.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Closing sockets and streams? Roedy Green wrote:
> On Mon, 23 Jan 2006 18:32:04 +0000, Thomas Hawtin
> <email***@***.com> wrote, quoted or indirectly quoted someone
> who said :
>
>> Insisting on closing them is just voodoo.
>
> If you don't close a file, the last bytes you wrote to it won't get
> written.

You should certainly flush OutputStream decorators in the happy case,
but there's no reason that you must close them (so long as you do close
the actual resources somehow).

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

java-programmer >> Closing sockets and streams? On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin
<email***@***.com> wrote, quoted or indirectly quoted someone
who said :

>You should certainly flush OutputStream decorators in the happy case,
>but there's no reason that you must close them (so long as you do close
>the actual resources somehow).

If you can remember to flush, surely you can remember to close.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Closing sockets and streams? Roedy Green wrote:
> On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin
> <email***@***.com> wrote, quoted or indirectly quoted someone
> who said :
>
>
>>You should certainly flush OutputStream decorators in the happy case,
>>but there's no reason that you must close them (so long as you do close
>>the actual resources somehow).
>
>
> If you can remember to flush, surely you can remember to close.

Sometimes it isn't an issue of memory or care. For example, I have
several methods which output formatted text to a Writer. The Writer is
provided as a method argument, and the method implementations wrap it in
a Formatter, which is then used to produce the output. (Not exactly
stream wrapping, but Formatters have exactly the same flushing/closing
semantics as stream decorators.) These methods must *not* close their
Formatters because doing so would close the underlying stream, which is
not their responsibility and not the desired behavior. They must flush
their Formatters, however, lest data be lost.

I agree with Tom. Streams that own system resources must assuredly be
closed to prevent resource leaks. This can be accomplished by closing
some decorating stream, but the only advantage in that is ensuring that
all data written directly via that decorator are committed to the stream
destination. If that is done by some other means (or if it isn't
important) then it doesn't matter which stream up or down the decorator
chain is closed -- closing any one of them will free up the system
resources.

--
John Bollinger
email***@***.com

java-programmer >> Closing sockets and streams? John C. Bollinger wrote:
> Roedy Green wrote:
>> On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin
>> <email***@***.com> wrote, quoted or indirectly quoted someone
>> who said :
>>
>>
>>> You should certainly flush OutputStream decorators in the happy case,
>>> but there's no reason that you must close them (so long as you do
>>> close the actual resources somehow).
>>
>>
>> If you can remember to flush, surely you can remember to close.

Roedy, it is only necessary to flush in the happy case. No need to
introduce any more finally ugliness, nor to ask for more than is required.

> I agree with Tom. Streams that own system resources must assuredly be
> closed to prevent resource leaks. This can be accomplished by closing
> some decorating stream, but the only advantage in that is ensuring that
> all data written directly via that decorator are committed to the stream
> destination. If that is done by some other means (or if it isn't
> important) then it doesn't matter which stream up or down the decorator
> chain is closed -- closing any one of them will free up the system
> resources.

It doesn't matter much whether you close the resource or its decorator.
However you MUST close the resource *even if the construction of the
decorator fails*.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/