Member Avatar for ronnieaka

the answer to this i found on the web was this:

The AWT event dispatcher thread is not a daemon thread. You must explicitly call System.exit to terminate the JVM.

and what i understand of it is that the thread which is terminated when we close a JFrame or Applet is that the thread associated with that is not the main thread which runs when jvm starts. that is, my understanding of the 'daemon' thread in the above answer is that its the main thread that jvm executes on - backbone thread of jvm. so any jframe app we run by executing the java command on the cmd runs on other thread.
if thats not right please correct me

Edited by ronnieaka because: n/a
  • 2 Contributors
  • 5 Replies
  • 584 Views
  • 10 Hours Discussion Span
  • Latest Post Latest Post by JamesCherrill

Dani AI

Generated

Short answer: the JVM only exits when there are no non‑daemon (user) threads left. , a thread being a "daemon" is a property of that thread, not a name for the JVM's main thread. The main thread is just a normal (non‑daemon) thread by default. is right that modern Java will try to stop AWT helper threads when no top‑level windows or events remain, but that only helps if every top‑level window is actually disposed — and it won't save you from other non‑daemon threads left running.

Practical checklist to find and fix the problem:

  • Make sure every top‑level window is disposed (not merely hidden). If you use listeners, ensure you call dispose() when closing.
  • Look for other non‑daemon threads: timers, ExecutorServices, library threads, JDBC/network threads, etc. These commonly keep the JVM alive.
  • Programmatically dump non‑daemon threads to see what remains (example below), or use a tool (jps/jstack or VisualVM/jconsole) to inspect the running process.

Example: list non‑daemon threads at shutdown (quick diagnostic)

Map<Thread,StackTraceElement[]> all = Thread.getAllStackTraces();
for (Thread t : all.keySet()) {
    if (!t.isDaemon()) {
        System.out.println("NON-DAEMON: " + t.getName() + " state=" + t.getState());
    }
}

Common fixes: use new Timer(true) for java.util.Timer, supply a daemon ThreadFactory to executor services, explicitly dispose windows, or — as a last resort — call System.exit(0) only after an orderly cleanup. Use jstack/jcmd or VisualVM when the program still refuses to exit; they show the exact threads keeping the JVM alive and point to the offending component.

Recommended Answers

All 5 Replies

Member Avatar for JamesCherrill

This is a deep question, and the answer changed with Java 1.4. Unfortunately there is a lot of info on the web that relates to old versions of Java.
Here's an authoritative doc from Oracle re Java 1.5
http://download.oracle.com/javase/1.5.0/docs/api/java/awt/doc-files/AWTThreadIssues.html
The most relevant part is

... Prior to 1.4, the helper threads were never terminated.

Starting with 1.4, the behavior has changed as a result of the fix for 4030718. With the current implementation, AWT terminates all its helper threads allowing the application to exit cleanly when the following three conditions are true:

There are no displayable AWT or Swing components.
There are no native events in the native event queue.
There are no AWT events in java EventQueues.

Therefore, a stand-alone AWT application that wishes to exit cleanly without calling System.exit must:

Make sure that all AWT or Swing components are made undisplayable when the application finishes. This can be done by calling Window.dispose on all top-level Windows. See Frame.getFrames. ...

In summary, although the EDT is not a daemon, versions 1.4 and later have explicit code to terminate the EDT (and thus allow the JVM to terminate) when there are no displayable components or outstanding Events left.

Member Avatar for ronnieaka

This is a deep question, and the answer changed with Java 1.4. Unfortunately there is a lot of info on the web that relates to old versions of Java.
Here's an authoritative doc from Oracle re Java 1.5
http://download.oracle.com/javase/1.5.0/docs/api/java/awt/doc-files/AWTThreadIssues.html
The most relevant part is


In summary, although the EDT is not a daemon, versions 1.4 and later have explicit code to terminate the EDT (and thus allow the JVM to terminate) when there are no displayable components or outstanding Events left.

well what i found practically from my app is that when close the app by clicking on the close button,jvm still doesn't return the control back to the cmd. so the cursor on cmd blinks at a line below the 'java myprogram' command.
but when i actually click on the cancel button oh my app which causes system.exit, the app cleanly closes and the control in the cmd is returned back to the prompt

Edited by ronnieaka because: n/a
Member Avatar for JamesCherrill

You need to ensure that you call dispose() on your window when the close button is clicked - just making it invisible isn't enough.

Member Avatar for JamesCherrill

Try this, it exits the JVM as soon s the window is disposed in response to the close button

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
import javax.swing.JFrame;

public class BasicWindow {

   public static void main(String[] args) {
      System.out.println("Starting...");
      final JFrame frame = new JFrame();
      final JButton cancelButton = new JButton("Cancel");
      frame.add(cancelButton);
      cancelButton.addActionListener(new ActionListener() {
         @Override
         public void actionPerformed(ActionEvent arg0) {
            System.out.println("Disposing...");
            frame.dispose();
         }
      });    
      frame.pack();
      frame.setLocationRelativeTo(null);
      frame.setVisible(true);
   }
}
Member Avatar for JamesCherrill

when close the app by clicking on the close button,jvm still doesn't return the control back to the cmd.

The default action for the window's close button is HIDE_ON_CLOSE. Hides the frame after invoking any registered WindowListener objects.
If you change the close action to DISPOSE_ON_CLOSE. Hides and disposes the frame after invoking any registered WindowListener objects.
That will have the desired effect.

ps System.exit(0); is very popular, but it can be undesirable in real apps - you may need to free external resources, commit transactions, write log files, log off servers etc, but System.exit(0)will just shut you down without doing any of those.

Edited by JamesCherrill because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.