Repercussions of trying to kill a program before closing OutputStreamWriter

Question

This is part of larger graphing program (JavaPlot specifically). In a nut shell, I would try to graph something; the graph would appear at

out.write(comms);

but then close once it hit

out.close()

I know you need to close OutputStreamWriter, so instead of removing that line, I created a Scanner that waits until the user presses 'Q' and then the program continues as normal, closes the graph, the OutputStreamWriter, and the Scanner

        OutputStreamWriter out = new OutputStreamWriter(proc.getOutputStream());
        out.write(comms);
        out.flush();

//added from here
        //waiting until input is given
        Scanner timeKiller = new Scanner(System.in);
        String check = timeKiller.nextLine();
        if(check != "q"){
            check = timeKiller.nextLine();  //<---waiting here. 
        }
        timeKiller.close();
//to here

        out.close();

Is what I'm doing dangerous? If someone closes the graph by closing the window, this won't kill the program, correct? This won't cause a memory leak (right?) but if the process is still running and they run this program several times, it will eventually start to be an issue. How can I fix this? Just off the top of my head, maybe add a listener to the window that breaks the loop if the window is closed? Or am I mistaken and this is isn't an issue at all?

score 2 · Accepted Answer · answered Jul 13 '12 at 14:42

2

If you have flushed the stream / writer after the most recent write, then you won't lose any data if you exit the application without calling close on the stream first. And if you are exiting the application, the JVM terminates and storage leaks become irrelevant.

On the other hand, if you don't cause the application to exit when it arguably should exit, and the user spawns multiple instances as a result, you'll have a problem with lots of JVMs filling up the user's PC's memory. If that happens, the hypothetical leaked stream is insignificant compared with dealing with the orphanned JVMs.

But it is really unclear from your question what you are actually doing and/or proposing to do, so I can't really comment on your specific situation.

answered Jul 13 '12 at 14:42

Stephen C

698,415
94
811
1,216

This question is somewhat ironic :P but can you be more specific on what I'm not clear on so I can specify? Are you referring to my issue or what I'm trying to do in general. Do I need to post more code? – Daniel Jul 13 '12 at 14:48
For a start, you've got seeming contradiction between the code and the text in describing the way that the application gets terminated; i.e. closing a window *versus* this clunky "time killer" notion that you have. – Stephen C Jul 13 '12 at 14:55
oh ok. Ideally, the user would press 'Q', the scanner loop would end, the graph would close, and the JVM would close. My question was if the user closed the window by clicked X on the top of the window and didnt press Q, the loop would never end and thus the issue would form (failing to close the OSW and the JVM). Does that help clear it up? – Daniel Jul 13 '12 at 15:04
@Daniel - not really. You've still got two mechanism whose sole purpose seems to be to terminate the application. You only need one ... the close window button (and other actions like "File>Quit" ... if your UI supports it). – Stephen C Jul 13 '12 at 15:24
So you're suggesting I get rid of the scanner? – Daniel Jul 13 '12 at 15:29

score 1 · Answer 2 · answered Jul 13 '12 at 14:50

1

The window has a setDefaultCloseOperation, which you can set to EXIT_ON_CLOSE which will do System.exit(0).

answered Jul 13 '12 at 14:50

Viktor Mellgren

4,318
3
42
75

Repercussions of trying to kill a program before closing OutputStreamWriter

2 Answers2