[concurrency-interest] Reason behind making execute method of SwingWorker as final ?

Gregg Wonderly gregg at cytetech.com
Mon Mar 2 13:04:41 EST 2009


I have long used my own private subclass of an old version of swing-worker.  The 
main reason, is that I need to put a Subject and a context ClassLoader in view 
of doInBackground().  We've evolved our patterns over the years based on 
different experiences.

There is a version of this under http://swingutil.dev.java.net called 
org.wonderly.swing.SyncThread.  With this class, you could do what you are 
talking about, I believe.  An illustration of this would be the following code, 
which would perform a local search on some remotely gathered String values and 
then select the first one which matches, if any.

// Somewhere there is an executor visible.
ThreadPoolExecutor exec = ...

public void searchFor( String search ) {

     // Create an instance which uses exec to run the
     // background threads.  Disable comp while it runs.
     final SyncThread th = new SyncThread( comp ) {

         public void schedule( Runnable r ) {
             exec.execute( r );
         }
     };

     // Create a step which will get the values from
     // the remote instance
     th.add( new SyncThread<String[],String[]>() {

         public String[] run() {
             return remote.getValues();
         }

         public void done() {
             comp.setModel( new MyModel( getValue() ) );
         }
     });

     // Add another step to use the data and select the
     // searched for value if found.
     th.add( new SyncThread<String,String>() {

         public String run() {
             String[] dt = th.getLastThreadValue();
             for( String s : dt ) {
                 if( findPattern( search, s ) ) {
                     return s;
                 }
             }
             return null;
         }

         public void done() {
             if( getValue() == null ) {
                 comp.clearSelection();
             } else {
                 comp.setSelectedValue( getValue() );
             }
         }
     });

     // Run all the steps to completion and return
     th.block();
}

Mallikarjunaiah, Praveena wrote:
> SwingWorker's doInBackground() method will be called from non-EDT
> (event-dispatch-thread).
> It guarantees that process() method will be called in EDT.
> 
> You can control which thread runs doInBackground() using custom
> execution service.
> 
> My question was how best we can hide this information from the user of
> subclass of SwingWorker.
> (One way that I thought was overriding execute() method but that is a
> final method)
> 
> -Praveena
> 
> -----Original Message-----
> From: Gregg Wonderly [mailto:gregg at wonderly.org] 
> Sent: Monday, March 02, 2009 8:10 PM
> To: Mallikarjunaiah, Praveena
> Subject: Re: [concurrency-interest] Reason behind making execute method
> of SwingWorker as final ?
> 
> Mallikarjunaiah, Praveena wrote:
>> Hi,
>>
>> I was wondering why execute() method of SwingWorker is made final. In
>> some cases,  I want certain type of SwingWorker's to use a specific
>> thread.
>> Currently, this can be done by explicitly putting the worker in a
> custom
>> executor service.  I would like put this logic in execute() method so
>> that
>> Generators of SwingWorker need not worry how to execute them.
> 
> The SwingWorker class is intended to allow execution in only one
> specific type 
> of thread, an AWT event dispatch thread.  Usually there is exactly one
> of those, 
> but sometimes, during dialog display, one may be halted and another
> created to 
> process events in that dialog.  Thus, there is only, exactly one active
> to 
> execute tasks, and the event queue is where requests go to be responded
> to by 
> that one active thread.
> 
> Are you trying to make work go into the queue of a halted event dispatch
> thread?
> 
> Gregg Wonderly
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> 



More information about the Concurrency-interest mailing list