Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: javax.swing.Timer blocking program termination Date: Tue, 14 Jul 2015 18:35:38 +0000 (UTC) Organization: A noiseless patient Spider Lines: 26 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 14 Jul 2015 18:35:38 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="25546"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19H8KDrf5YJHpyWjwfcyhb2Wf93sFtt0tk=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:ZSOxrbPvRZxq8CvJUFD8jdQi7CI= Xref: csiph.com comp.lang.java.programmer:32018 On Tue, 14 Jul 2015 10:55:20 -0400, Jeff Higgins wrote: > Makes perfect sense to me. > But I'm still not sure how a <1 sec timer keeps the EDT alive while a >1 > sec timer doesn't - barring explicit stops in windowClosing. > It occurs to me that, the way Knute's original example works, that he might have inadvertently set up a race condition because all the heavy lifting involved in setting up the JFrame, i.e. loading a shedload of classes and constructing instances from them all happens on the EDT and that this might well take a second or so to complete and still be running when the timer gets started. IOW, could the timer have fired its event before the default close operation had been defined and would the timer event have been ignored if it fired its event before the JFrame had been completed and displayed? Of course, this may be a stupid idea, but it does fit the test results which show a short timeout being ignored while a longer one does what you'd expect. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |