BufferedInputStream -- does not recommend "close()"?

[Stefan Ram]

The operation »close()« is mentioned in the class documentation

http://java.sun.com/javase/6/docs/api/java/io/BufferedInputStream.html

But nowhere does it recommend to use »close()«.

I had expected the constructor documentation to
say something like

»Whenever an object of this class has been constructed
successfully it needs to be closed at some instant in the
future to avoid resource leaks, because only by closing
all resource allocated by the construction will be
released again.«

But this is not so.

The tutorial also does not recommend close:

http://java.sun.com/docs/books/tutorial/essential/io/buffers.html

I used to believe that closing was important.
Why is it not recommended in the documentation nor the tutorial?

(When insisting on the use of »close()«, I'd
like to have some evidence for its necessity.)

 

[Adam Maass]

The operation »close()« is mentioned in the class documentation

http://java.sun.com/javase/6/docs/api/java/io/BufferedInputStream.html

But nowhere does it recommend to use »close()«.

I had expected the constructor documentation to
say something like

»Whenever an object of this class has been constructed
successfully it needs to be closed at some instant in the
future to avoid resource leaks, because only by closing
all resource allocated by the construction will be
released again.«

But this is not so.

The tutorial also does not recommend close:

http://java.sun.com/docs/books/tutorial/essential/io/buffers.html

I used to believe that closing was important.
Why is it not recommended in the documentation nor the tutorial?

(When insisting on the use of »close()«, I'd
like to have some evidence for its necessity.)

Huh. I am slightly mystified as well.

But I believe a plausible explanation might be that BufferedInputStream
itself doesn't hold any system resources; it simply forwards the "close"
call onto the InputStream it wraps. It is those wrapped objects whose
"close" methods must be called. So since for the BufferedInputStream itself,
the "close" call isn't so critical, maybe (just maybe) Sun decided not to
insert a stern warning into the documentation of that class.


It is best practice to close all streams (and readers/writers) when you are
done with them. Nasty unpredictible things can happen otherwise.


-- Adam Maass

 

[Lew]

The operation »close()« is mentioned in the class documentation

http://java.sun.com/javase/6/docs/api/java/io/BufferedInputStream.html

But nowhere does it recommend to use »close()«.

I had expected the constructor documentation to
say something like

»Whenever an object of this class has been constructed
successfully it needs to be closed at some instant in the
future to avoid resource leaks, because only by closing
all resource allocated by the construction will be
released again.«

But this is not so.

The tutorial also does not recommend close:

http://java.sun.com/docs/books/tutorial/essential/io/buffers.html

I used to believe that closing was important.
Why is it not recommended in the documentation nor the tutorial?

(When insisting on the use of »close()«, I'd
like to have some evidence for its necessity.)

Well, you could read what close() does and infer its necessity from that.

Closes this input stream and releases any system resources associated with the stream.

Ask yourself in what universe it's a good idea to leave system resources
unreleased after they're not needed.

 

[Adam Maass]

You could read what close() does and infer its necessity from that.


Ask yourself in what universe it's a good idea to leave system resources
unreleased after they're not needed.

Um... one in which system resources are unlimited? ;-> (Sorry, I just
couldn't resist.)


-- Adam Maass

 

[Lew]

Um... one in which system resources are unlimited? ;-> (Sorry, I just
couldn't resist.)

How would that make it a good idea not to release resources? All that does it
make it not a terrible idea.

Now, getting away from science fiction ...

 

[Andreas Leitgeb]

How would that make it a good idea not to release resources? All that does it
make it not a terrible idea.
Now, getting away from science fiction ...

As programmers, aren't we all a bit responsible to not let the vendors
of memory-modules starve ... ?-)

 

[Roedy Green]

Why is it not recommended in the documentation nor the tutorial?

Too obvious? Java requires explicit close of all files. Various
horrible things will happen if you don't, e.g. holds onto RAM, does
not write out last bytes written, does not update directory with
times, does not update directory with length, does not unlock file if
there were some locking.

Is a similar way, Frames require an explicit dispose.

Oddly old languages like FORTRAN and Abundance closed files
automatically that were left open on exit. I guess the idea is the
designers of Java wanted to encourage you to close early.

 

[Stefan Ram]

Oddly old languages like FORTRAN and Abundance closed files
automatically that were left open on exit.

Early closing also in important in servers that are not
expected to exit anytime soon, so that they will not exhaust
resources.

 

[Christian]

Too obvious? Java requires explicit close of all files. Various
horrible things will happen if you don't, e.g. holds onto RAM, does
not write out last bytes written, does not update directory with
times, does not update directory with length, does not unlock file if
there were some locking.

Is a similar way, Frames require an explicit dispose.

Oddly old languages like FORTRAN and Abundance closed files
automatically that were left open on exit. I guess the idea is the
designers of Java wanted to encourage you to close early.

Java also closes all open streams on exit..
Well it might rather be the OS that cleans up any ressource of programs.

 

[Mike Schilling]

Roedy Green schrieb:

Java also closes all open streams on exit..
Well it might rather be the OS that cleans up any ressource of
programs.

That's easy to check; the OS can close files, but it doesn't know
enough to flush data Java still has buffered.

import java.io.*;

class NoFlush
{
public static void main(String[] args) throws Exception
{
Writer w = new FileWriter("a.log");
w.write("abcd");
w.flush();
w.write("defg");
}
}

% ls -l a.log
-rwx------+ 1 mschilling None 4 Jan 7 17:07 a.log

Yes, the file is getting closed; no, Java is not flushing the stream.

 

[John W. Kennedy]

Roedy Green schrieb:

Java also closes all open streams on exit..
Well it might rather be the OS that cleans up any ressource of
programs.

That's easy to check; the OS can close files, but it doesn't know
enough to flush data Java still has buffered.

import java.io.*;

class NoFlush
{
public static void main(String[] args) throws Exception
{
Writer w = new FileWriter("a.log");
w.write("abcd");
w.flush();
w.write("defg");
}
}

% ls -l a.log
-rwx------+ 1 mschilling None 4 Jan 7 17:07 a.log

Yes, the file is getting closed; no, Java is not flushing the stream.

Which is exactly the same behavior as C with setbuf/setvbuf.

 

[Roedy Green]

Java also closes all open streams on exit..
Well it might rather be the OS that cleans up any ressource of programs.

When did that start happening? IIRC some time ago, I forgot to close
is some program and the file did not get written. Adding the close
fixed it.

 

[Lew]

When did that start happening? IIRC some time ago, I forgot to close
is some program and the file did not get written. Adding the close
fixed it.

See upthread:

The "file" in question may well be something only the Java program knows about
- from the OS's point of view it might still be a non-existent or zero-length
file at the time the JVM exits.

It might also be that the JVM is better about telling the OS of its crashes
than it used to be?

Even if so, there are still no guarantees about the completeness or
consistency or usability of an OS file after a Java program leaves without
properly close()ing its connection to it. That much hasn't changed.