From the InputStream class javadocs for the close() method:
Closes this input stream and releases any system resources associated with the stream.
Closing either of the streams should close the socket as well however I'd advocate the explicit release of all resources.
But if I were to create a program that first open an input stream, read some data, close the input stream, open an output stream, send som data, and finally close the outputstream...then this scheme would be a bit weird? So I am forced to keep the streams open untill the socket are to be closed?
> So I am forced to keep the streams open
> untill the socket are to be closed?
It would appear so. However there are two methods of the Socket class which may alternatively be used instead of closing the streams. Have a look at the shutdownInput() and shutdownOutput() methods. The javadocs for shutdownInput() follows:
Places the input stream for this socket at "end of stream". Any data sent to the input stream side of the socket is acknowledged and then silently discarded.
> But if I were to create a program that first open an
> input stream, read some data, close the input stream,
Why? Why do you need to close the input stream?
> open an output stream, send som data, and finally
> close the outputstream...
Now this makes sense.
Contrary to what's suggested above, the best way to close a socket is to close its output stream. That ensures that any final flush() occurs and it closes the input stream and the socket too. You don't need to close the input stream or the socket explicity if you do this and therefore you don't need to code the two extra try-catch blocks that would be needed if you were to code those extra closes properly.