Some method still running when my program should be finished... how do I find out?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • blazedaces
    Contributor
    • May 2007
    • 284

    #16
    Originally posted by JosAH
    Yep, if you System.exit(<nu mber>) everything dies. About that AWT thread:
    the thread doesn't do anything at all (read: doesn't take up cpu time) when there
    are no user instigated events and nothing needs to be repainted, so you can let
    it run forever. It won't stop running when your main thread dies though, hence the
    System.exit(<nu mber>).

    You won't lose performance because of that (waiting) thread. It was a design
    issue for the designers of AWT/Swing: either have a multi threaded GUI thing,
    which is a total mess (google for that) or have a single threaded, non daemon
    thread take care of it all. You don't even want to terminate that thread when your
    main thread terminates, i.e. it would be nearly impossible to build GUI applications
    if that were the case.

    Simply let that thread wait and invoke System.exit(<nu mber>) when your main
    thread dies. If you're really paranoia about it: check the ThreadGroup an use the
    (deprecated) stop() method on the AWT thread.

    kind regards,

    Jos
    Thanks a lot. I guess I'll just use the system.exit(<nu mber>) whenever I'm completely finished...

    -blazed

    Comment

    • JosAH
      Recognized Expert MVP
      • Mar 2007
      • 11453

      #17
      Originally posted by blazedaces
      Thanks a lot. I guess I'll just use the system.exit(<nu mber>) whenever I'm completely finished...

      -blazed
      Yup, that's the way to go or otherwise don't start up that AWT thread at all,
      i.e. don't instantiate any AWT/Swing component at all. That 'setVisible()' method
      is the culprit: it enqueues a repaint operation which is the job of that AWT thread.

      kind regards,

      Jos

      Comment

      • blazedaces
        Contributor
        • May 2007
        • 284

        #18
        Originally posted by JosAH
        Yup, that's the way to go or otherwise don't start up that AWT thread at all,
        i.e. don't instantiate any AWT/Swing component at all. That 'setVisible()' method
        is the culprit: it enqueues a repaint operation which is the job of that AWT thread.

        kind regards,

        Jos
        What better way is there to ask the user what file to read or save to? Is there a way to make the file dialog appear without using setVisible? How can the AWT thread do it on it's own?

        -blazed

        Comment

        • JosAH
          Recognized Expert MVP
          • Mar 2007
          • 11453

          #19
          Originally posted by blazedaces
          What better way is there to ask the user what file to read or save to? Is there a way to make the file dialog appear without using setVisible? How can the AWT thread do it on it's own?

          -blazed
          Nothing 'appears' out of itself without making it visible first. Either bail out if the
          user didn't supply the correct command line argument(s) or use a shell or command
          line interface for the correct arguments or go for the whole nine yards and
          supply a gui (in which case you have to System.exit()).

          kind regards,

          Jos

          Comment

          Working...