Sure it does - it's inherited from InputStream. Admittedly the 1.1.8 docs arent very good at showing this clearly, which is one of many reasons to use 1.2.2 or 1.3 instead. It is rather odd that you can still read a stream after it's been closed, at least in this case. Looking carefully at the API, there doesn't seem to be anything said about this behavior one way or another - "closing" an InputStream is never really defined. The base close() method inherited from InputStream is specifically said not to do anything; for the overriding method in ByteInputStream (overridden in Java 1.2 and 1.3 at least) it just says that the method closes the stream, nothing more. Although common sense would be that a closed stream could no longer be used, that doesn't seem to apply here. My guess is that the close() method is there so that, in case there is anything special that needs to be done to a stream when it's done which would not automatically be done as part of garbage collection or exiting the JVM, or which should not be made to wait until one of those events occurs, then calling the close() method provides a mechanism for that to occur. For example if a socket or file must be closed before another thread can access it, then calling the close() method takes care of it. And so it's good to be in the habit of calling close() for any stream so that you don't forget. However it turns out that it isn't actually necessary for all streams as they are currently implemented.
"I'm not back." - Bill Harding, Twister
Joined: Sep 06, 2000
Apu hates,....abhors methods that don't behave. If you open the stream, it will flow. Iffin you stream.close() and stream still flow.. Apu want better close().