• 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

GUI Thread Safety - Exam questions

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I haven't done any Swing programming for 3 years but I am looking at it again now for the exam. When I last looked, swing components were not thread safe and could only be updated within the event-dispatch thread. If you didn't update them in the event-dispatch thread then you ran the risk of them not working correctly. Normally (for quick tasks) this is not a problem since you would just process events in the same thread.
However, in this case we have an application that is performing IO (either locally and remotely) and this has the potential to take a longer time. When a long task is running, the event-dispatch thread would queue up other events and would prevent events such as repainting the display occuring until the long task is finished (which may be bad for the user if the call takes some time).
My usual approach to overcome this is to perform these potentially long tasks actions in a separate thread on the client. During this time I lock the user interface (by activating the glass pane, showing an hour glass etc.). When the task finishes, I would then call back to the user-interface with the results (using SwingUtilities.invokeLater) and then "re-activate" the user interface (i.e. hide the glass pane, show the normal cursor etc.). I would try and design a framework that did things consistently (i.e. a task framework).
My questions are
- Are Swing components still not thread safe?
- Is this overkill for the exam? I would have thought that for just local IO it might be but you might potentially have lengthy delays using a networked database.
- I'm not sure if this would have an impact on the MVC design (not my strongest area). I think I would have the task frame work running in the controller.
Thanks,
Paul Kelcey
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well Paul, Thread Safety in Swing is not my strong point, I mean I don't think it is from a certain standpoint, but from thsi assignment, I took it as being safe for me not to use anything to make it thread safe.
There have been many people who used SwingUtilities.invokeLater. I didn't, and got 20/20 on GUI. I just had the screen wait and it was locked then. So if it was going to the server, the screen would just stay the way it was.
Mark
 
Paul Kelcey
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, thanks for that. I think I'll only do it if I can keep it simple.
Thanks.
PK
 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As far I as I know, Swing is still only designed to run in 1 thread
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic