Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Jeff Higgins Newsgroups: comp.lang.java.programmer Subject: Re: javax.swing.Timer blocking program termination Date: Mon, 13 Jul 2015 21:35:55 -0400 Organization: A noiseless patient Spider Lines: 126 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 14 Jul 2015 01:38:10 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="8e164d158183579609bf09837dee5210"; logging-data="22777"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gc/4kSYsEjUn/sMME6jjyecKmwvYCDKY=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 In-Reply-To: Cancel-Lock: sha1:TTmDNXQfuJYRYj6DRRGYFyETx1k= Xref: csiph.com comp.lang.java.programmer: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:~$