1 / 12

Keeping your Swing Applications Responsive using FoxTrot and Friends

Keeping your Swing Applications Responsive using FoxTrot and Friends. Rob Ratcliff. Swing’s Thread Model. Mostly not Thread Safe by design - very few thread safe operations All events added to AWT Queue and processed sequentially

hunter
Télécharger la présentation

Keeping your Swing Applications Responsive using FoxTrot and Friends

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Keeping your Swing Applications Responsive using FoxTrotand Friends Rob Ratcliff

  2. Swing’s Thread Model • Mostly not Thread Safe by design - very few thread safe operations • All events added to AWT Queue and processed sequentially • Events “popped” off queue by dispatcher running in AWT Thread and delivered to registered listeners • Long running listener code results in a non-responsive application

  3. Sequence Diagram of Event Processing

  4. Consequences of direct Swing calls in an alternate thread • Deadlock • Quirky Painting • Sluggish application

  5. Alternatives – Worker Thread and InvokeLater() // some swing code new Thread(new Runnable() { public void run() { // long running task runSwingCode(); } protected void runSwingCode() { SwingUtilities.invokeLater(new Runnable(){ public void run() { // run more swing code } } } ).start();

  6. Alternatives – SwingWorker // some swing code new SwingWorker() { public Object construct() { // long running code } public void finished() { // more swing code } }.start();

  7. JDialog’s Approach • Modal dialog blocks AWT Event Thread • Creates another thread to dispatch the events to keep the GUI painting • FoxTrot leverages this concept

  8. FoxTrot Approach • Similar to JDialog • Blocking call, but takes over event queue processing • Natural • Usage: // some swing code try { Object value = Worker.post(new Task() { public Object run() throws Exception { // long running task }}); } catch (Exception e) {// do something} // more swing code

  9. Dynamic Proxy Client • Wrap long running calls a Dynamic Proxy that wraps calls with Foxtrot • Avoid sprinkling Foxtrot calls everywhere • Assists developers in not having to worry about this stuff • Keep this stuff deep down in your framework

  10. Demo Example

  11. Comments on Dynamic Proxy for CallBacks • Example Problem – RMI Callback • Callback calls Swing methods on RMI dispatch thread to update GUI • Inevitable that invokeLater() will be forgotten by some developer on team resulting in an embarassing deadlock! • Embed InvokeLater into a proxy around the callback interface (See ChatListenerNotifierFactory.)

  12. References • Foxtrot - http://foxtrot.sourceforge.net/ • Simone Bordet - simone.bordet@hp.com • SwingWorker -http://java.sun.com/products/jfc/tsc/articles/threads/update.html • Threads and Swing - http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html • Dyanamic Proxy -

More Related