File close on JVM exit
See the following code:
import java.io.*;
publicclass Test{
publicstaticvoid main(String[] args)throws IOException{
PrintWriter pw =new PrintWriter(new FileWriter("test.txt"));
pw.write("hi");
}
}
This code does not close pw, hence no data is written to test.txt. To me,
this does not make sense, because I believe that JVM surely knows what
files are opened. Thus it wouldn't be difficult for JVM to close all files
that are opened but not closed until user application exit.
But, JVM does not close pw, and result in loss of data. This behavior
would make sense if I were writing apps w/ C or C++ because those
languages give much freedom to programmers such that people can do
whatever they want. Java, on the other hand, has the philosophy of
easy of use and safety, I believe.
Does anybody know why JVM does not try to close pw?
Sincerely,
Minkoo Seo
[1436 byte] By [
4bafa] at [2007-10-2 22:14:13]
Ido not think that JVM should keep track of open files and close them on exit.
JVM runs the finalizer of all the objects still in the memory when it terminates (proper way)
And In my point of view its the responsibility of the stream to close itself when it is being finalized if it is still open.
LRMKa at 2007-7-14 1:31:08 >
well... I think JVM works well - it must be close all files that are opened. it just did'nt flush stream.add 'pw.flush();' or set a autoflush variable true for Prinwriter.
> Ido not think that JVM should keep track of open
> files and close them on exit.
I believe JVM already has file descriptions for the files that
are opened, because JVM is actually an operating system
on which Java programs run. Thus, JVM must maintain
file descriptors as other OS does.
> JVM runs the finalizer of all the objects still in
> the memory when it terminates (proper way)
It's not true. Running finalization is not guranteed.
> And In my point of view its the responsibility of the
> stream to close itself when it is being finalized if
> it is still open.
4bafa at 2007-7-14 1:31:08 >
> well... I think JVM works well - it must be close all
> files that are opened. it just did'nt flush stream.
> add 'pw.flush();' or set a autoflush variable true
> for Prinwriter.
Try this:
pw.close();
Closing file will automatically flush buffers.
4bafa at 2007-7-14 1:31:08 >
> this does not make sense, because I believe that JVM
> surely knows what
> files are opened. Thus it wouldn't be difficult for
> JVM to close all files
It's not just the open file connections, though (this will be handled by the operating system, not the jVM) it's all the filters you place on top of them like PrintWriters, OutputStreamWriters etc. all of which, potentially, need to be flushed.
It wouldn't pay for the JVM to track all of those. These are general purpose classes which may be used with things other than files.
You should get into the habbit of closing all such resources, preferably in a finally clause so it happens even if your program crashes.
The JVM is not an operating system it is a program. When the JVM exits, all the files opened by the JVM (or any other program) are closed by the real operating system. That doesn't include calling flush() or close(), which only the JVM can do and only if it GCs the object, which it may not do.
ejpa at 2007-7-14 1:31:08 >
Thank you for the comment!
> The JVM is not an operating system it is a program.
> When the JVM exits, all the files opened by the JVM
> (or any other program) are closed by the real
> operating system. That doesn't include calling
> flush() or close(), which only the JVM can do and
> only if it GCs the object, which it may not do.
I think JVM is actually a layer which exists right above the
operating system and acts like a 'virtual machine.'
Thus, like I said, I believe that the virtual machine maintains
file descriptors like all other operating systems do.
And ejp suggest that JVM is nothing but a program which
makes sense also.
So I wonder whether JVM actually maintains file descriptor
table (or linked list) or not. If it does, JVM is irresponsible
because it does not take care of destruction of file descriptor
table. If not, that's okay. I'm just curious.
4bafa at 2007-7-14 1:31:08 >
I have read all the relevant source code at one time or another and I've seen no evidence that the JVM maintains tables or lists of FDs other than what's in the objects. Do you have any evidence about this or are you just guessing?
You can describe the JVM as a layer or a virtual machine for the Java bytecode, which it is, but to the operating system it is just another program. Not a driver, not a supervisor, not an executive, not a simulator, not privileged in any way, nada, nothing, zero. No privilege, no special behaviour, no file descriptor table, just a C program which exits like all the others. Not 'irresponsible' either, just behaving according to its specification.
ejpa at 2007-7-14 1:31:08 >
> I have read all the relevant source code at one time
> or another and I've seen no evidence that the JVM
> maintains tables or lists of FDs other than what's in
> the objects. Do you have any evidence about this or
> are you just guessing?
>
No reason why it should - since the JVM is also an operating system task (like any program), and the OS will necessarilly manage the FDs for all tasks.
> And In my point of view its the responsibility of the
> stream to close itself when it is being finalized if
> it is still open.
Not really. One cannot guarantee that the finalised() method will ever be called even when a progarm exits gracefully. I would normally use a shutdown hook to close files if it matters but this may not be invoked if an external event closes down the JVM
