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

Mallikarjunaiah, Praveena mallikap at deshaw.com
Mon Mar 2 22:58:19 EST 2009

After reading that thread, I tend to agree that I should have used
containment rather inheritence. (as my XXXDataLoader is not a
Thanks for the pointers.


From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Joe
Sent: Monday, March 02, 2009 9:30 PM
To: Concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] Reason behind making execute method
ofSwingWorker as final ?


I see your point.  For your purposes, it would be nice if you could
supply your own executor service, or even thread factory.  If only the
getWorkerExecutorService method was not private static...

Manually submitting the SwingWorker to a custom executor was the
solution envisioned by the designers.

See related discussion:


I suggest you contact Igor Kushnirskiy and/or whoever is currently
maintaining SwingWorker.


On Sun, Mar 1, 2009 at 9:52 PM, 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
	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
	Generators of SwingWorker need not worry how to execute them.
	Am I missing something here ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090303/ecb7c547/attachment.html>

More information about the Concurrency-interest mailing list