Crumble Crumble - 1 month ago 10
Java Question

When you close a JFrame, does everything in the program terminate?

I have a GUI that extends JFrame which is created by this constructor of another object:

public Engine(int width, int height) {
//ui is the GUI object declared as a field of this object
ui = new UI(width, height);
ui.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
ui.setVisible(true);
}


The GUI's eventListener also creates new threads when certain buttons are clicked:

public void actionPerformed(ActionEvent actionEvent) {
if(actionEvent.getSource().equals(ui.play)) {
if(clickerThread == null) {
autoClicker= new AutoClicker();
clickerThread = new Thread(autoClicker);
clickerThread.start();
}
}
}


Does this mean when I hit the X button on the window, everything related to this program (such as the autoclicker thread, everything in the memory allocated to this program) get cleared and does not slow down the computer in the future?

Or, would System.exit(0) be needed somwhere somehow in order to make it as if this application was never opened after the computer had started and closed the application?

Thanks in advance!

Answer Source

Per the JFrame API:

public void setDefaultCloseOperation(int operation)
Sets the operation that will happen by default when the user initiates a "close" on this frame. You must specify one of the following choices:

  • DO_NOTHING_ON_CLOSE (defined in WindowConstants): Don't do anything; require the program to handle the operation in the windowClosing method of a registered WindowListener object.
  • HIDE_ON_CLOSE (defined in WindowConstants): Automatically hide the frame after invoking any registered WindowListener objects.
  • DISPOSE_ON_CLOSE (defined in WindowConstants): Automatically hide and dispose the frame after invoking any registered WindowListener objects.
  • EXIT_ON_CLOSE (defined in JFrame): Exit the application using the System exit method. Use this only in applications.

So yes, this will exit the application by calling System exit for you.


Just a little side warning: if your threading is wired incorrectly, and you have long-running code that happens to tie up the Swing event thread, the EDT, then the JFrame's termination button won't respond until the EDT is unblocked.


Side recommendation 2, regarding:

I have a GUI that extends JFrame...

I recommend against creating classes that extend top-level windows such as JFrames since this creates inflexible classes that can only be used as a JFrame. Much better to gear your GUI classes to create (or if need be, extend) JPanel since this way your GUI can be displayed in many different contexts -- in a JFrame, a JDialog, in another JPanel, in a JTabbedPanel... it frees your code up a bit.


Side recommendation 3: regarding creating new threads in a Swing application, if the auto clicker will interact with the Swing application itself, then you may wish to consider using a SwingWorker to help create your background thread since this construct has mechanisms within it that help safe communication between background thread and the GUI without breaking Swing threading rules. Google "Concurrency in Swing" for more on this.