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

Mallikarjunaiah, Praveena mallikap at deshaw.com
Mon Mar 2 09:46:16 EST 2009


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



More information about the Concurrency-interest mailing list