Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31994 > unrolled thread

javax.swing.Timer blocking program termination

Back to article view | Back to comp.lang.java.programmer

Contents

  javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-13 16:03 -0700
    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 20:27 -0400
      Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-13 17:46 -0700
        Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 21:35 -0400
          Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 22:13 -0400
            Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-13 22:27 -0400
            Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 06:31 -0700
              Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 10:15 -0400
                Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 10:22 -0400
                Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 07:39 -0700
                  Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 10:53 -0400
                    Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 10:16 -0700
                      Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 13:25 -0400
                        Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-14 10:45 -0700
                          Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 14:16 -0400
                            Re: javax.swing.Timer blocking program termination Gene Wirchenko <genew@telus.net> - 2015-07-14 12:56 -0700
                              Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 16:14 -0400
                                Re: javax.swing.Timer blocking program termination e.d.programmer@gmail.com - 2015-07-15 05:11 -0700
                                Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 08:33 -0400
                                  Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-15 18:46 +0000
                                    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 21:18 -0400
                                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 22:13 -0400
                  Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 10:55 -0400
                    Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-14 08:17 -0700
                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 11:42 -0400
                    Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-14 18:35 +0000
                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 15:17 -0400
                        Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 15:36 -0400
                      Re: javax.swing.Timer blocking program termination Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-14 15:51 -0400
                        Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-14 21:51 +0000
                          Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-14 15:08 -0700
                            Re: javax.swing.Timer blocking program termination Martin Gregorie <martin@address-in-sig.invalid> - 2015-07-15 01:16 +0000
                      Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 16:09 -0400
                        Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 18:32 -0400
                          Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 18:34 -0400
                            Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 20:31 -0400
                  Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-14 08:16 -0700
    Re: javax.swing.Timer blocking program termination Joerg Meier <joergmmeier@arcor.de> - 2015-07-14 08:32 +0200
    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-14 22:18 -0400
    Re: javax.swing.Timer blocking program termination Jeff Higgins <jeff@invalid.invalid> - 2015-07-15 08:26 -0400
      Re: javax.swing.Timer blocking program termination Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2015-07-15 11:05 -0700

Page 1 of 3  [1] 2 3  Next page →

#31994 — javax.swing.Timer blocking program termination

So I have this program that uses a couple of javax.swing.Timers.  I 
forgot to put in code to stop one of the timers yet the program would 
still terminate.  I have set the default close operation for the frame 
to be DISPOSE_ON_CLOSE.

What I found was that a timer of less the 1000ms would prevent an 
application based on a JFrame from stopping but 1000ms or more and it 
would stop just fine.

I know that javax.swing.Timer uses a common thread for all timers but I 
don't see anywhere that describes the stopping behavior.

The program below will stop if the JFrame is closed and the timer is 
1000ms or greater but hang if it is less.  I would be really curious to 
know if somebody else can duplicate this.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class test extends JFrame {
     public test() {
         Timer timer = new Timer(1000,event -> {});
         setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
         setSize(400,300);
         setVisible(true);
         timer.start();
     }

     public static void main(String... args) {
         EventQueue.invokeLater(() -> new test());
     }
}

Thanks,

-- 

Knute Johnson

[toc] | [next] | [standalone]

#31995

On 07/13/2015 07:03 PM, Knute Johnson wrote:
> So I have this program that uses a couple of javax.swing.Timers.  I
> forgot to put in code to stop one of the timers yet the program would
> still terminate.  I have set the default close operation for the frame
> to be DISPOSE_ON_CLOSE.
>
> What I found was that a timer of less the 1000ms would prevent an
> application based on a JFrame from stopping but 1000ms or more and it
> would stop just fine.
>
> I know that javax.swing.Timer uses a common thread for all timers but I
> don't see anywhere that describes the stopping behavior.
>
> The program below will stop if the JFrame is closed and the timer is
> 1000ms or greater but hang if it is less.  I would be really curious to
> know if somebody else can duplicate this.
>
> import java.awt.*;
> import java.awt.event.*;
> import javax.swing.*;
>
> public class test extends JFrame {
>      public test() {
>          Timer timer = new Timer(1000,event -> {});
>          setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>          setSize(400,300);
>          setVisible(true);
>          timer.start();
>      }
>
>      public static void main(String... args) {
>          EventQueue.invokeLater(() -> new test());
>      }
> }
>


import java.awt.EventQueue;
import javax.swing.JFrame;
import javax.swing.Timer;

public class test extends JFrame {
   public test() {
     Timer timer = new Timer(900, event -> {
       System.out.println("-"); });
     addWindowListener(new java.awt.event.WindowAdapter() {
       @Override
       public void windowClosing(java.awt.event.WindowEvent windowEvent) {
         System.out.println("Close"); }});
     setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
     setSize(400, 300);
     setVisible(true);
     timer.start();
   }

   public static void main(String... args) {
     EventQueue.invokeLater(() -> new test());
   }
}


jeff@debian:~$ javac test.java
jeff@debian:~$ java -showversion test
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

-
-
Close
-
-
-
-
^Z
[1]+  Stopped                 java -showversion test
jeff@debian:~$ jobs
[1]+  Stopped                 java -showversion test
jeff@debian:~$ fg
java -showversion test
-
-
-
-
^Cjeff@debian:~$

[toc] | [prev] | [next] | [standalone]

#31996

On 7/13/2015 17:27, Jeff Higgins wrote:
> On 07/13/2015 07:03 PM, Knute Johnson wrote:
>> So I have this program that uses a couple of javax.swing.Timers.  I
>> forgot to put in code to stop one of the timers yet the program would
>> still terminate.  I have set the default close operation for the frame
>> to be DISPOSE_ON_CLOSE.
>>
>> What I found was that a timer of less the 1000ms would prevent an
>> application based on a JFrame from stopping but 1000ms or more and it
>> would stop just fine.
>>
>> I know that javax.swing.Timer uses a common thread for all timers but I
>> don't see anywhere that describes the stopping behavior.
>>
>> The program below will stop if the JFrame is closed and the timer is
>> 1000ms or greater but hang if it is less.  I would be really curious to
>> know if somebody else can duplicate this.
>>
>> import java.awt.*;
>> import java.awt.event.*;
>> import javax.swing.*;
>>
>> public class test extends JFrame {
>>      public test() {
>>          Timer timer = new Timer(1000,event -> {});
>>          setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>          setSize(400,300);
>>          setVisible(true);
>>          timer.start();
>>      }
>>
>>      public static void main(String... args) {
>>          EventQueue.invokeLater(() -> new test());
>>      }
>> }
>>
>
>
> import java.awt.EventQueue;
> import javax.swing.JFrame;
> import javax.swing.Timer;
>
> public class test extends JFrame {
>    public test() {
>      Timer timer = new Timer(900, event -> {
>        System.out.println("-"); });
>      addWindowListener(new java.awt.event.WindowAdapter() {
>        @Override
>        public void windowClosing(java.awt.event.WindowEvent windowEvent) {
>          System.out.println("Close"); }});
>      setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>      setSize(400, 300);
>      setVisible(true);
>      timer.start();
>    }
>
>    public static void main(String... args) {
>      EventQueue.invokeLater(() -> new test());
>    }
> }
>
>
> jeff@debian:~$ javac test.java
> jeff@debian:~$ java -showversion test
> java version "1.8.0_40"
> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>
> -
> -
> Close
> -
> -
> -
> -
> ^Z
> [1]+  Stopped                 java -showversion test
> jeff@debian:~$ jobs
> [1]+  Stopped                 java -showversion test
> jeff@debian:~$ fg
> java -showversion test
> -
> -
> -
> -
> ^Cjeff@debian:~$
>
>

and does it stop on your Linux (I assume) system if the delay is 1000ms 
or more?

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#31997

On 07/13/2015 08:46 PM, Knute Johnson wrote:
> On 7/13/2015 17:27, Jeff Higgins wrote:
>> On 07/13/2015 07:03 PM, Knute Johnson wrote:
>>> So I have this program that uses a couple of javax.swing.Timers.  I
>>> forgot to put in code to stop one of the timers yet the program would
>>> still terminate.  I have set the default close operation for the frame
>>> to be DISPOSE_ON_CLOSE.
>>>
>>> What I found was that a timer of less the 1000ms would prevent an
>>> application based on a JFrame from stopping but 1000ms or more and it
>>> would stop just fine.
>>>
>>> I know that javax.swing.Timer uses a common thread for all timers but I
>>> don't see anywhere that describes the stopping behavior.
>>>
>>> The program below will stop if the JFrame is closed and the timer is
>>> 1000ms or greater but hang if it is less.  I would be really curious to
>>> know if somebody else can duplicate this.
>>>
>>> import java.awt.*;
>>> import java.awt.event.*;
>>> import javax.swing.*;
>>>
>>> public class test extends JFrame {
>>>      public test() {
>>>          Timer timer = new Timer(1000,event -> {});
>>>          setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>>          setSize(400,300);
>>>          setVisible(true);
>>>          timer.start();
>>>      }
>>>
>>>      public static void main(String... args) {
>>>          EventQueue.invokeLater(() -> new test());
>>>      }
>>> }
>>>
>>
>>
>> import java.awt.EventQueue;
>> import javax.swing.JFrame;
>> import javax.swing.Timer;
>>
>> public class test extends JFrame {
>>    public test() {
>>      Timer timer = new Timer(900, event -> {
>>        System.out.println("-"); });
>>      addWindowListener(new java.awt.event.WindowAdapter() {
>>        @Override
>>        public void windowClosing(java.awt.event.WindowEvent
>> windowEvent) {
>>          System.out.println("Close"); }});
>>      setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>      setSize(400, 300);
>>      setVisible(true);
>>      timer.start();
>>    }
>>
>>    public static void main(String... args) {
>>      EventQueue.invokeLater(() -> new test());
>>    }
>> }
>>
>>
>> jeff@debian:~$ javac test.java
>> jeff@debian:~$ java -showversion test
>> java version "1.8.0_40"
>> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>>
>> -
>> -
>> Close
>> -
>> -
>> -
>> -
>> ^Z
>> [1]+  Stopped                 java -showversion test
>> jeff@debian:~$ jobs
>> [1]+  Stopped                 java -showversion test
>> jeff@debian:~$ fg
>> java -showversion test
>> -
>> -
>> -
>> -
>> ^Cjeff@debian:~$
>>
>>
>
> and does it stop on your Linux (I assume) system if the delay is 1000ms
> or more?
>
Very consistantly
With 1000 it continues as long as I can stand.
With 1001 I get
-
Close
-
-
-
-
jeff@debian:~$

With 1002 I get
-
Close
-
-
-
jeff@debian:~$

With 1003 I get
-
Close
-
jeff@debian:~$

With 1500 I get
-
Close
-
jeff@debian:~$

[toc] | [prev] | [next] | [standalone]

#31998

On 07/13/2015 09:35 PM, Jeff Higgins wrote:
> On 07/13/2015 08:46 PM, Knute Johnson wrote:
>> On 7/13/2015 17:27, Jeff Higgins wrote:
>>> On 07/13/2015 07:03 PM, Knute Johnson wrote:
>>>> So I have this program that uses a couple of javax.swing.Timers.  I
>>>> forgot to put in code to stop one of the timers yet the program would
>>>> still terminate.  I have set the default close operation for the frame
>>>> to be DISPOSE_ON_CLOSE.
>>>>
>>>> What I found was that a timer of less the 1000ms would prevent an
>>>> application based on a JFrame from stopping but 1000ms or more and it
>>>> would stop just fine.
>>>>
>>>> I know that javax.swing.Timer uses a common thread for all timers but I
>>>> don't see anywhere that describes the stopping behavior.
>>>>
>>>> The program below will stop if the JFrame is closed and the timer is
>>>> 1000ms or greater but hang if it is less.  I would be really curious to
>>>> know if somebody else can duplicate this.
>>>>
>>>> import java.awt.*;
>>>> import java.awt.event.*;
>>>> import javax.swing.*;
>>>>
>>>> public class test extends JFrame {
>>>>      public test() {
>>>>          Timer timer = new Timer(1000,event -> {});
>>>>          setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>>>          setSize(400,300);
>>>>          setVisible(true);
>>>>          timer.start();
>>>>      }
>>>>
>>>>      public static void main(String... args) {
>>>>          EventQueue.invokeLater(() -> new test());
>>>>      }
>>>> }
>>>>
>>>
>>>
>>> import java.awt.EventQueue;
>>> import javax.swing.JFrame;
>>> import javax.swing.Timer;
>>>
>>> public class test extends JFrame {
>>>    public test() {
>>>      Timer timer = new Timer(900, event -> {
>>>        System.out.println("-"); });
>>>      addWindowListener(new java.awt.event.WindowAdapter() {
>>>        @Override
>>>        public void windowClosing(java.awt.event.WindowEvent
>>> windowEvent) {
>>>          System.out.println("Close"); }});
>>>      setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>>      setSize(400, 300);
>>>      setVisible(true);
>>>      timer.start();
>>>    }
>>>
>>>    public static void main(String... args) {
>>>      EventQueue.invokeLater(() -> new test());
>>>    }
>>> }
>>>
>>>
>>> jeff@debian:~$ javac test.java
>>> jeff@debian:~$ java -showversion test
>>> java version "1.8.0_40"
>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>>>
>>> -
>>> -
>>> Close
>>> -
>>> -
>>> -
>>> -
>>> ^Z
>>> [1]+  Stopped                 java -showversion test
>>> jeff@debian:~$ jobs
>>> [1]+  Stopped                 java -showversion test
>>> jeff@debian:~$ fg
>>> java -showversion test
>>> -
>>> -
>>> -
>>> -
>>> ^Cjeff@debian:~$
>>>
>>>
>>
>> and does it stop on your Linux (I assume) system if the delay is 1000ms
>> or more?
>>
> Very consistantly
> With 1000 it continues as long as I can stand.
> With 1001 I get
> -
> Close
> -
> -
> -
> -
> jeff@debian:~$
>
> With 1002 I get
> -
> Close
> -
> -
> -
> jeff@debian:~$
>
> With 1003 I get
> -
> Close
> -
> jeff@debian:~$
>
> With 1500 I get
> -
> Close
> -
> jeff@debian:~$
>
>
If I put a timer.stop()

addWindowListener(new java.awt.event.WindowAdapter() {
   @Override
   public void windowClosing(java.awt.event.WindowEvent windowEvent)
   { System.out.println("Close"); timer.stop();}});

for values of 1000 or less continues to print -
for values greater than 1000 doesn't print any - after Close

[toc] | [prev] | [next] | [standalone]

#31999

If I use EXIT_ON_CLOSE Java terminates cleanly.

DISPOSE_ON_CLOSE

static final int DISPOSE_ON_CLOSE

The dispose-window default window close operation.

Note: When the last displayable window within the Java virtual machine 
(VM) is disposed of, the VM may terminate. See AWT Threading Issues for 
more information.

<http://docs.oracle.com/javase/8/docs/api/java/awt/doc-files/AWTThreadIssues.html>

[toc] | [prev] | [next] | [standalone]

#32005

On Monday, July 13, 2015 at 10:17:14 PM UTC-4, Jeff Higgins wrote:
> On 07/13/2015 09:35 PM, Jeff Higgins wrote:
> > On 07/13/2015 08:46 PM, Knute Johnson wrote:
> >> On 7/13/2015 17:27, Jeff Higgins wrote:
> >>> On 07/13/2015 07:03 PM, Knute Johnson wrote:
> >>>> So I have this program that uses a couple of javax.swing.Timers.  I
> >>>> forgot to put in code to stop one of the timers yet the program would
> >>>> still terminate.  I have set the default close operation for the frame
> >>>> to be DISPOSE_ON_CLOSE.
> >>>>
> >>>> What I found was that a timer of less the 1000ms would prevent an
> >>>> application based on a JFrame from stopping but 1000ms or more and it
> >>>> would stop just fine.
> >>>>
> >>>> I know that javax.swing.Timer uses a common thread for all timers but I
> >>>> don't see anywhere that describes the stopping behavior.
> >>>>
> >>>> The program below will stop if the JFrame is closed and the timer is
> >>>> 1000ms or greater but hang if it is less.  I would be really curious to
> >>>> know if somebody else can duplicate this.
> >>>>
> >>>> import java.awt.*;
> >>>> import java.awt.event.*;
> >>>> import javax.swing.*;
> >>>>
> >>>> public class test extends JFrame {
> >>>>      public test() {
> >>>>          Timer timer = new Timer(1000,event -> {});
> >>>>          setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
> >>>>          setSize(400,300);
> >>>>          setVisible(true);
> >>>>          timer.start();
> >>>>      }
> >>>>
> >>>>      public static void main(String... args) {
> >>>>          EventQueue.invokeLater(() -> new test());
> >>>>      }
> >>>> }
> >>>>
> >>>
> >>>
> >>> import java.awt.EventQueue;
> >>> import javax.swing.JFrame;
> >>> import javax.swing.Timer;
> >>>
> >>> public class test extends JFrame {
> >>>    public test() {
> >>>      Timer timer = new Timer(900, event -> {
> >>>        System.out.println("-"); });
> >>>      addWindowListener(new java.awt.event.WindowAdapter() {
> >>>        @Override
> >>>        public void windowClosing(java.awt.event.WindowEvent
> >>> windowEvent) {
> >>>          System.out.println("Close"); }});
> >>>      setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
> >>>      setSize(400, 300);
> >>>      setVisible(true);
> >>>      timer.start();
> >>>    }
> >>>
> >>>    public static void main(String... args) {
> >>>      EventQueue.invokeLater(() -> new test());
> >>>    }
> >>> }
> >>>
> >>>
> >>> jeff@debian:~$ javac test.java
> >>> jeff@debian:~$ java -showversion test
> >>> java version "1.8.0_40"
> >>> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
> >>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
> >>>
> >>> -
> >>> -
> >>> Close
> >>> -
> >>> -
> >>> -
> >>> -
> >>> ^Z
> >>> [1]+  Stopped                 java -showversion test
> >>> jeff@debian:~$ jobs
> >>> [1]+  Stopped                 java -showversion test
> >>> jeff@debian:~$ fg
> >>> java -showversion test
> >>> -
> >>> -
> >>> -
> >>> -
> >>> ^Cjeff@debian:~$
> >>>
> >>>
> >>
> >> and does it stop on your Linux (I assume) system if the delay is 1000ms
> >> or more?
> >>
> > Very consistantly
> > With 1000 it continues as long as I can stand.
> > With 1001 I get
> > -
> > Close
> > -
> > -
> > -
> > -
> > jeff@debian:~$
> >
> > With 1002 I get
> > -
> > Close
> > -
> > -
> > -
> > jeff@debian:~$
> >
> > With 1003 I get
> > -
> > Close
> > -
> > jeff@debian:~$
> >
> > With 1500 I get
> > -
> > Close
> > -
> > jeff@debian:~$
> >
> >
> If I put a timer.stop()
> 
> addWindowListener(new java.awt.event.WindowAdapter() {
>    @Override
>    public void windowClosing(java.awt.event.WindowEvent windowEvent)
>    { System.out.println("Close"); timer.stop();}});
> 
> for values of 1000 or less continues to print -
> for values greater than 1000 doesn't print any - after Close

Why wouldn't a timer stop?  I pasted that in and the last thing it always prints is the "Close".  I'm running this test in Eclipse Luna on JDK 8 update 45 on Windows 8.1.

import java.awt.EventQueue;

import javax.swing.JFrame;
import javax.swing.Timer;
import javax.swing.WindowConstants;

public class test extends JFrame { 
     public test() { 
         final Timer timer = new Timer(900,event -> { 
              System.out.println("-"); }); 
         addWindowListener(new java.awt.event.WindowAdapter() { 
              @Override 
              public void windowClosing(final java.awt.event.WindowEvent windowEvent) { 
                   timer.stop();
                System.out.println("Close"); }}); 
         setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); 
         setSize(400,300); 
         setVisible(true); 
         timer.start(); 
     } 

     public static void main(final String... args) { 
         EventQueue.invokeLater(() -> new test()); 
     } 
}

[toc] | [prev] | [next] | [standalone]

#32006

On 07/14/2015 09:31 AM, e.d.programmer@gmail.com wrote:
> On Monday, July 13, 2015 at 10:17:14 PM UTC-4, Jeff Higgins wrote:
>> On 07/13/2015 09:35 PM, Jeff Higgins wrote:
>>> On 07/13/2015 08:46 PM, Knute Johnson wrote:
>>>> On 7/13/2015 17:27, Jeff Higgins wrote:
>>>>> On 07/13/2015 07:03 PM, Knute Johnson wrote:
>>>>>> So I have this program that uses a couple of javax.swing.Timers.  I
>>>>>> forgot to put in code to stop one of the timers yet the program would
>>>>>> still terminate.  I have set the default close operation for the frame
>>>>>> to be DISPOSE_ON_CLOSE.
>>>>>>
>>>>>> What I found was that a timer of less the 1000ms would prevent an
>>>>>> application based on a JFrame from stopping but 1000ms or more and it
>>>>>> would stop just fine.
>>>>>>
>>>>>> I know that javax.swing.Timer uses a common thread for all timers but I
>>>>>> don't see anywhere that describes the stopping behavior.
>>>>>>
>>>>>> The program below will stop if the JFrame is closed and the timer is
>>>>>> 1000ms or greater but hang if it is less.  I would be really curious to
>>>>>> know if somebody else can duplicate this.
>>>>>>
>>>>>> import java.awt.*;
>>>>>> import java.awt.event.*;
>>>>>> import javax.swing.*;
>>>>>>
>>>>>> public class test extends JFrame {
>>>>>>       public test() {
>>>>>>           Timer timer = new Timer(1000,event -> {});
>>>>>>           setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>>>>>           setSize(400,300);
>>>>>>           setVisible(true);
>>>>>>           timer.start();
>>>>>>       }
>>>>>>
>>>>>>       public static void main(String... args) {
>>>>>>           EventQueue.invokeLater(() -> new test());
>>>>>>       }
>>>>>> }
>>>>>>
>>>>>
>>>>>
>>>>> import java.awt.EventQueue;
>>>>> import javax.swing.JFrame;
>>>>> import javax.swing.Timer;
>>>>>
>>>>> public class test extends JFrame {
>>>>>     public test() {
>>>>>       Timer timer = new Timer(900, event -> {
>>>>>         System.out.println("-"); });
>>>>>       addWindowListener(new java.awt.event.WindowAdapter() {
>>>>>         @Override
>>>>>         public void windowClosing(java.awt.event.WindowEvent
>>>>> windowEvent) {
>>>>>           System.out.println("Close"); }});
>>>>>       setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>>>>>       setSize(400, 300);
>>>>>       setVisible(true);
>>>>>       timer.start();
>>>>>     }
>>>>>
>>>>>     public static void main(String... args) {
>>>>>       EventQueue.invokeLater(() -> new test());
>>>>>     }
>>>>> }
>>>>>
>>>>>
>>>>> jeff@debian:~$ javac test.java
>>>>> jeff@debian:~$ java -showversion test
>>>>> java version "1.8.0_40"
>>>>> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>>>>>
>>>>> -
>>>>> -
>>>>> Close
>>>>> -
>>>>> -
>>>>> -
>>>>> -
>>>>> ^Z
>>>>> [1]+  Stopped                 java -showversion test
>>>>> jeff@debian:~$ jobs
>>>>> [1]+  Stopped                 java -showversion test
>>>>> jeff@debian:~$ fg
>>>>> java -showversion test
>>>>> -
>>>>> -
>>>>> -
>>>>> -
>>>>> ^Cjeff@debian:~$
>>>>>
>>>>>
>>>>
>>>> and does it stop on your Linux (I assume) system if the delay is 1000ms
>>>> or more?
>>>>
>>> Very consistantly
>>> With 1000 it continues as long as I can stand.
>>> With 1001 I get
>>> -
>>> Close
>>> -
>>> -
>>> -
>>> -
>>> jeff@debian:~$
>>>
>>> With 1002 I get
>>> -
>>> Close
>>> -
>>> -
>>> -
>>> jeff@debian:~$
>>>
>>> With 1003 I get
>>> -
>>> Close
>>> -
>>> jeff@debian:~$
>>>
>>> With 1500 I get
>>> -
>>> Close
>>> -
>>> jeff@debian:~$
>>>
>>>
>> If I put a timer.stop()
>>
>> addWindowListener(new java.awt.event.WindowAdapter() {
>>     @Override
>>     public void windowClosing(java.awt.event.WindowEvent windowEvent)
>>     { System.out.println("Close"); timer.stop();}});
>>
>> for values of 1000 or less continues to print -
>> for values greater than 1000 doesn't print any - after Close
>
> Why wouldn't a timer stop?  I pasted that in and the last thing it always prints is the "Close".  I'm running this test in Eclipse Luna on JDK 8 update 45 on Windows 8.1.
>
Re-running, it always closes with timer.stop().
I don't know what I was running with the above?

Now, I still don't know why the short timer1 (below) keeps
the EDT active unless I explicitly stop it in windowClosing?

import java.awt.EventQueue;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JFrame;
import javax.swing.Timer;

public class test extends JFrame {
   public test() {
     Timer timer1 = new Timer(1000, event -> {});
     Timer timer2 = new Timer(1100, event -> {});

     Timer.setLogTimers(true);

     addWindowListener(new WindowAdapter() {
       @Override
       public void windowClosing(WindowEvent windowEvent) {
         System.out.println("Close");
       }});

     setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
     setSize(400, 300);
     setVisible(true);
     timer1.start();
     timer2.start();
   }

   public static void main(String... args) {
     EventQueue.invokeLater(() -> new test());
   }
}

[toc] | [prev] | [next] | [standalone]

#32007

On 07/14/2015 10:15 AM, Jeff Higgins wrote:

> Now, I still don't know why the short timer1 (below) keeps
> the EDT active unless I explicitly stop it in windowClosing?
>
> import java.awt.EventQueue;
> import java.awt.event.WindowAdapter;
> import java.awt.event.WindowEvent;
> import javax.swing.JFrame;
> import javax.swing.Timer;
>
> public class test extends JFrame {
>    public test() {
>      Timer timer1 = new Timer(1000, event -> {});
>      Timer timer2 = new Timer(1100, event -> {});
>
>      Timer.setLogTimers(true);
>
>      addWindowListener(new WindowAdapter() {
>        @Override
>        public void windowClosing(WindowEvent windowEvent) {
>          System.out.println("Close");
>        }});
>
>      setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
>      setSize(400, 300);
>      setVisible(true);
>      timer1.start();
>      timer2.start();
>    }
>
>    public static void main(String... args) {
>      EventQueue.invokeLater(() -> new test());
>    }
> }
>

If I don't start timer1 (above) main terminates
after one timer log entry after Close is printed.
Even without explicitly stopping timer2.

Shrug?

[toc] | [prev] | [next] | [standalone]

#32008

I don't use swing timers personally.  I embed my Java in BBj (http://www.basis.com/bbj) which did nothing when I tried to use a swing timer, so I still just use java.util.Timer.

Closing a window should never terminate a JVM unless you flag it as EXIT_ON_CLOSE which is not recommended.  You may want a timer to be able to do some cleanup after the window closes, so if the timer is running a process which doesn't need to finish if the window closes you want to manually stop it in the window close event process.

A method to stop all timers could be useful.  It appears you currently have to store a reference to any timers you create if you need to be able to stop them.

[toc] | [prev] | [next] | [standalone]

#32009

On 7/14/2015 10:39 AM, e.d.programmer@gmail.com wrote:
> [...]
> Closing a window should never terminate a JVM unless you flag it as EXIT_ON_CLOSE which is not recommended.  You may want a timer to be able to do some cleanup after the window closes, so if the timer is running a process which doesn't need to finish if the window closes you want to manually stop it in the window close event process.

     Could you elaborate on "not recommended?"  For my own applications,
EXIT_ON_CLOSE is the option I use most frequently. The next is
DO_NOTHING_ON_CLOSE with a WindowAdapter for window-closing events;
both stratagems seem unobjectionable to me.

> A method to stop all timers could be useful.  It appears you currently have to store a reference to any timers you create if you need to be able to stop them.

     A method to stop all timers sounds about as useful as a method
to stop all threads -- that is to say, more perilous than useful.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32014

>      Could you elaborate on "not recommended?"  For my own applications,
> EXIT_ON_CLOSE is the option I use most frequently. The next is
> DO_NOTHING_ON_CLOSE with a WindowAdapter for window-closing events;
> both stratagems seem unobjectionable to me.
> 

I know I checked how to write a window close method before and found multiple references saying never use EXIT_ON_CLOSE.  Here is one such example.
-----
http://stackoverflow.com/questions/258099/how-to-close-a-java-swing-application-from-the-code
Your JFrame default close action can be set to "DISPOSE_ON_CLOSE" instead of EXIT_ON_CLOSE (why people keep using EXIT_ON_CLOSE is beyond me).

If you have any undisposed windows or non-daemon threads, your application will not terminate. This should be considered a error (and solving it with System.exit is a very bad idea).

The most common culprits are java.util.Timer and a custom Thread you've created. Both should be set to daemon or must be explicitly killed.

If you want to check for all active frames, you can use Frame.getFrames(). If all Windows/Frames are disposed of, then use a debugger to check for any non-daemon threads that are still running.
-----

I just set my windows to DO_NOTHING_ON_CLOSE.  I map the F7 key to open a confirm exit dialog, and F7 again to call dispose() on the window if the dialog is already visible. (F5 mapped to cancel dialog)

[toc] | [prev] | [next] | [standalone]

#32015

On 7/14/2015 1:16 PM, e.d.programmer@gmail.com wrote:
>>       Could you elaborate on "not recommended?"  For my own applications,
>> EXIT_ON_CLOSE is the option I use most frequently. The next is
>> DO_NOTHING_ON_CLOSE with a WindowAdapter for window-closing events;
>> both stratagems seem unobjectionable to me.
>>
>
> I know I checked how to write a window close method before and found multiple references saying never use EXIT_ON_CLOSE.  Here is one such example.
> -----
> http://stackoverflow.com/questions/258099/how-to-close-a-java-swing-application-from-the-code
> [...]

     Thanks.  Looks like there's one guy on that thread who's pretty
vehement about EXIT_ON_CLOSE, but he just keeps saying it's evil and
doesn't explain why he thinks so.  Some of the other participants
specifically recommend EXIT_ON_CLOSE, so I guess the jury's still out.

     Differing opinions are a prerequisite for horse races.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32016

> > I know I checked how to write a window close method before and found multiple references saying never use EXIT_ON_CLOSE.  Here is one such example.
> > -----
> > http://stackoverflow.com/questions/258099/how-to-close-a-java-swing-application-from-the-code
> > [...]
> 
>      Thanks.  Looks like there's one guy on that thread who's pretty
> vehement about EXIT_ON_CLOSE, but he just keeps saying it's evil and
> doesn't explain why he thinks so.  Some of the other participants
> specifically recommend EXIT_ON_CLOSE, so I guess the jury's still out.
> 
>      Differing opinions are a prerequisite for horse races.
> 
> -- 
> esosman@comcast-dot-net.invalid
> "Don't be afraid of work. Make work afraid of you." -- TLM

EXIT_ON_CLOSE as he says is generally frowned upon because it executes System.exit(0) and forces the application JVM to instantly terminate.
If you dispose instead, manually calling dispose() like I do or setting DISPOSE_ON_CLOSE, it allows the JVM to run cleanup.  It also allows you to run multiple windows or applications in a single JVM.
Normally the only time an application should call System.exit() is with a nonzero value for a critical error (crash).  It's like if dispose is telling Windows to shut down, exit() is pressing the power button.

[toc] | [prev] | [next] | [standalone]

#32017

On 7/14/2015 1:45 PM, e.d.programmer@gmail.com wrote:
>>> I know I checked how to write a window close method before and found multiple references saying never use EXIT_ON_CLOSE.  Here is one such example.
>>> -----
>>> http://stackoverflow.com/questions/258099/how-to-close-a-java-swing-application-from-the-code
>>> [...]
>>
>>       Thanks.  Looks like there's one guy on that thread who's pretty
>> vehement about EXIT_ON_CLOSE, but he just keeps saying it's evil and
>> doesn't explain why he thinks so.  Some of the other participants
>> specifically recommend EXIT_ON_CLOSE, so I guess the jury's still out.
>>
>>       Differing opinions are a prerequisite for horse races.
>>
>> --
>> esosman@comcast-dot-net.invalid
>> "Don't be afraid of work. Make work afraid of you." -- TLM
>
> EXIT_ON_CLOSE as he says is generally frowned upon [...]

     I've heard this called "Proof by Repeated Assertion."

     ... and *I'll* repeat my remark about horse races.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32022

On Tue, 14 Jul 2015 14:16:28 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>On 7/14/2015 1:45 PM, e.d.programmer@gmail.com wrote:

[snip]

>> EXIT_ON_CLOSE as he says is generally frowned upon [...]
>
>     I've heard this called "Proof by Repeated Assertion."
>
>     ... and *I'll* repeat my remark about horse races.

     You snipped the following material which started with "because"
and then gave a reason.  Since it gave a reason, it is not a case of
Proof by Repeated Assertion.  Are you unable to argue effectively
against the reason?

Sincerelky,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#32024

On 7/14/2015 3:56 PM, Gene Wirchenko wrote:
> On Tue, 14 Jul 2015 14:16:28 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote:
>
>> On 7/14/2015 1:45 PM, e.d.programmer@gmail.com wrote:
>
> [snip]
>
>>> EXIT_ON_CLOSE as he says is generally frowned upon [...]
>>
>>      I've heard this called "Proof by Repeated Assertion."
>>
>>      ... and *I'll* repeat my remark about horse races.
>
>       You snipped the following material which started with "because"
> and then gave a reason.  Since it gave a reason, it is not a case of
> Proof by Repeated Assertion.  Are you unable to argue effectively
> against the reason?

     The snipped piece said that EXIT_ON_CLOSE is bad because it calls
System.exit().

     And it said System.exit() was bad because it stops the JVM.

     And it said stopping the JVM was bad because, um, well, actually
it didn't say *why* stopping the JVM was bad, it just said it was.

     In other words, the snipped portion was the same as the quoted
part, just in, well, other words.

     Personally, I like applications that stop.  When they keep on
running with no windows open, no user interaction, nothing but the
occasional background burbling as the CPU stalls for another cache
miss ...  Well, that's eerie, that's what that is.  When I close my
application's main window, I want my application to Go Away.  If
it's got no state that needs preserving, EXIT_ON_CLOSE is a perfectly
good way to accomplish this.  If there *is* state, I'll use a
WindowAdapter, do whatever's necessary, and then call System.exit()
myself.

     Evil or not, here I come.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32033

On Tuesday, July 14, 2015 at 4:14:59 PM UTC-4, Eric Sosman wrote:
>      The snipped piece said that EXIT_ON_CLOSE is bad because it calls
> System.exit().
> 
>      And it said System.exit() was bad because it stops the JVM.
> 
>      And it said stopping the JVM was bad because, um, well, actually
> it didn't say *why* stopping the JVM was bad, it just said it was.
> 
>      In other words, the snipped portion was the same as the quoted
> part, just in, well, other words.
> 
>      Personally, I like applications that stop.  When they keep on
> running with no windows open, no user interaction, nothing but the
> occasional background burbling as the CPU stalls for another cache
> miss ...  Well, that's eerie, that's what that is.  When I close my
> application's main window, I want my application to Go Away.  If
> it's got no state that needs preserving, EXIT_ON_CLOSE is a perfectly
> good way to accomplish this.  If there *is* state, I'll use a
> WindowAdapter, do whatever's necessary, and then call System.exit()
> myself.
> 
>      Evil or not, here I come.
> 
> -- 
> esosman@comcast-dot-net.invalid
> "Don't be afraid of work. Make work afraid of you." -- TLM

I did say, it's like turning off your computer by holding the power button.  That may work just fine.  If you're running your OS screen with no applications doing anything it may never appear to be a problem.  It's not the proper way to do it.  There's a shutdown option in Windows that runs cleanup to avoid corruption.  As I said a stopAllTimers method could be useful and you say that's a bad idea, that may not be a problem if you know there are no timers running that couldn't just be terminated.  System.exit() kills the system, the JVM.  It ends all timers and bypasses all other cleanup.  It destroys any and all frames no matter what they may be doing or what their close method is assigned.  Just use the proper procedure and there won't be a problem.  Tell the frame to DISPOSE_ON_CLOSE and have the window close listener stop all timers that need to be stopped.  I tested this and didn't see the timer do anything after the window close no matter what the timer interval.  You just keep pressing your power button to end your computer session and hope there's no side effects.  I just hope I never have to use a program you wrote.

[toc] | [prev] | [next] | [standalone]

#32035

On 07/14/2015 04:14 PM, Eric Sosman wrote:
>
>      Evil or not, here I come.

Your discussion prompted some web searching - thanks.
A couple of articles I found interesting.

Exiting the JVM
http://blog.joda.org/2014/02/exiting-jvm.html

Know the JVM Series – 2 – Shutdown Hooks
http://blog.yohanliyanage.com/2010/10/know-the-jvm-2-shutdown-hooks/

[toc] | [prev] | [next] | [standalone]

#32037

On Wed, 15 Jul 2015 08:33:37 -0400, Jeff Higgins wrote:

> On 07/14/2015 04:14 PM, Eric Sosman wrote:
>>
>>      Evil or not, here I come.
> 
> Your discussion prompted some web searching - thanks.
> A couple of articles I found interesting.
> 
> Exiting the JVM http://blog.joda.org/2014/02/exiting-jvm.html
> 
> Know the JVM Series – 2 – Shutdown Hooks
> http://blog.yohanliyanage.com/2010/10/know-the-jvm-2-shutdown-hooks/

Thanks for posting that. The shutdown hooks look a lot like C's atexit() 
function: almost identical in fact, since they have the same limitations 
(not triggered by SIGKILL).


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web