• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Which bits to call on Event Dispatch Thread?

 
Ranch Hand
Posts: 441
Scala IntelliJ IDE Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a convenience method to test out JPanels:
I'm not sure exactly which of these statements I should be putting within the inner class, and does it matter? Is it just the setVisible bit that will determine if user interactions will occur on the EDT?
 
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All event dispatch in Swing occurs on the EDT. As a general rule, you should run all code that constructs and alters the state of Swing components only on the EDT. Also note that various Swing methods (particularly text component methods) that are, as of Java 1.6, documented as being thread safe are not actually so, and the mention of thread safety is removed from the documentation for Java 1.7.

Further reading, even if the articles are a little dated:
Threads and Swing
The Last Word in Swing Threads
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Darryl Burke wrote:All event dispatch in Swing occurs on the EDT. As a general rule, you should run all code that constructs and alters the state of Swing components only on the EDT.


I would also add all code that queries the state of Swing components, like calling getText() on a text field.

Luigi, you can get away with creating your user interface before the EDT is started. In your example the call to SwingUtilities.invokeLater could have been omitted; the setVisible(true) method would cause the EDT to be started. However, as Darryl said, could does not mean should. Although I still go the lazy way and skip EventQueue.invokeLater* when constructing my GUIs a lot of the time.

*SwingUtilities.invokeLater delegates to EventQueue.invokeLater, as is also mentioned in the Javadocs.
 
Luigi Plinge
Ranch Hand
Posts: 441
Scala IntelliJ IDE Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks. So really I should only ever call such a method from the EDT, or I should put everything in this method into the inner class, plus instantiating the JPanel I want to display. The latter could be a bit tricky if I'm subclassing JPanel, because I'd need to pass in a Class argument, rather than an instance of a panel.

Rob - thanks for the tip. I had a poke around in the JComponent.setVisible source code and it seems that the reValidate method that it calls checks whether it's being run in the EDT, and if not, adds itself.
 
Darryl Burke
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:setVisible(true) method would cause the EDT to be started.


How and when the EDT is started may be platform dependent. Here's a SSCCE that demonstrates that the mere construction of a JPanel kicks off the EDT, on Windows at least.If you comment out new JPanel() the main thread terminates and the program exits before the Timer has a chance to trigger its actionPerformed.

Incidentally, I found that constructing a JComponent doesn't kick off the EDT
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Didn't work on a Linux box.
 
Luigi Plinge
Ranch Hand
Posts: 441
Scala IntelliJ IDE Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tried it in Win XP. A JPanel keeps the application going for 3 "Timer event"s but a JComboBox only for 2!

Out of interest, why does the JVM shut down when we still have this Timer thread running? Aren't all threads supposed to terminate before it exits?
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Daemon threads will never keep a JVM alive.
 
Darryl Burke
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Interesting. On my Win7 machine, constructing either a JPanel or a JComboBox keeps the Timer running ad infinitum.

Shall try it on WinXP at the office, later today.
 
Luigi Plinge
Ranch Hand
Posts: 441
Scala IntelliJ IDE Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I also tried it on Win 7 64-bit and it carries on indefinitely on that - different to to Win XP. Weird!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic