[concurrency-interest] Reason behind making execute method of SwingWorker as final ?
mallikap at deshaw.com
Mon Mar 2 09:46:16 EST 2009
SwingWorker's doInBackground() method will be called from non-EDT
It guarantees that process() method will be called in EDT.
You can control which thread runs doInBackground() using custom
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
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:
> 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
> Currently, this can be done by explicitly putting the worker in a
> executor service. I would like put this logic in execute() method so
> Generators of SwingWorker need not worry how to execute them.
The SwingWorker class is intended to allow execution in only one
of thread, an AWT event dispatch thread. Usually there is exactly one
but sometimes, during dialog display, one may be halted and another
process events in that dialog. Thus, there is only, exactly one active
execute tasks, and the event queue is where requests go to be responded
that one active thread.
Are you trying to make work go into the queue of a halted event dispatch
More information about the Concurrency-interest