2 threads

omom used Ask the Experts™
Thinking about the design of a application with 2 threads on the client side, where one thread is the UI and one thread is a worker thread that talks with the server.

I can think of 3 ways to set it up:
1. main() starts the UI thread and the worker thread
2. main() starts the UI thread which in turn starts the worker thread
3. main() starts the worker thread which in turn starts the UI thread

Originally, I started out with 3, but now I am thinking it should be 2.

In recent reading, I think I saw 2 being used with the Java class SwingWorker.  Is SwingWorker truly viable, or is it more of a textbook example?

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Mick BarryJava Developer
Top Expert 2010

(i'm assuming your taliking about a Swing app)
A UI thread already exists and you don't have to worry about starting it.
So I'd go with:
4. main() starts the worker thread

SwingWorker is usable, though it may depend on your exact requirements whether it'll meet your needs.



Yes, I'm talking Swing application.
(I started out with SWT but I'm thinking of abandoning it)

The requirements, at a high level, are simple. The client sends a command to the server, the server does some number crunching and/or database access, then sends some data back to the client, then the client displays an image based on that data.
Mick BarryJava Developer
Top Expert 2010

in that case i'd have a thread handling sending commands to the server, and notify listeners when events of interest occur. The listener could then handle updating gui as required. This way the comms thread does not have to know anything about the gui.

PS. How did you find SWT?
Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

for omom: if you're talking Swing, you can't control which thread is the event dispatching thread(UI thread)
It's different from SWT, where your evt disp. thread can be controlled, and you have to loop for your own messages.
For objects:I've done a little benchmarking on SWT vs. Swing. I happened to be a SWT enthusiast for a few days, but it was better than Swing just at opening new frames.
I paste the results over here:
30 frames shown,then dispose
SWT 0.2s <-> Swing 0.49s
300 Frames show,then dispose
SWT 4.1s <-> Swing 7.8s
10000 oval drawing
SWT-7.8s <-> Swing 7.2s(without double buffering)
Button adding(100 buttons at a time)
Entire process:0.171 Entire process:0.13 Entire process:0.14 Entire process:0.12 Entire process:0.12 Entire process:0.13 Entire process:0.15 Entire process:0.311 Entire process:0.161
Entire process:0.11 Entire process:0.07 Entire process:0.09 Entire process:0.11 Entire process:0.13 Entire process:0.15 Entire process:0.16 Entire process:0.201 Entire process:0.21 5000 buttons on a form:
SWT - 6.4MB memory,terrible refresh
Swing - 12.4 MB memory,very good refresh(due to double buffering)
Note: the tests were taken with double buffering disabled,if I'd leave it on, Swing would have kicked ass.

This kind of benchmarking makes Swing look better.There are some tests I couldn't perform which would involve responsiveness(time between click and response, delay induced by GUI code,since Swing is kinda "heavyweight").
I'd personally go with Swing...at least until SWT gets some more background and community support.
P.S. Sorry about the layout of this reply, it's taken from a mail to one of my colleagues(which was in turn pasted from my benchmark app).


>>How did you find SWT?
I don't really have enough experience to compare the SWT to Swing. However, cavey79 expressed my first thought..."personally go with Swing...at least until SWT gets some more background and community support."  Being of limited intelligence, I need lots of examples and such.  This is not the fault of anyone developing SWT, its just very young.  I do applaud the developers of the SWT with the effort to improve the UI aspect of Java.

Thanks to cavey79 for the stats.

Actually I was kinda impressed by SWT and the whole idea behind it(there are some pretty articles available describing the architecture).Unfortunately seems that Swing's double buffering has been improved a lot lately...Another thing that I thought would be difficult is the manual disposal of resources, which, though necessary, has slowly got away from my style...the beauty of java,right?
SWT isn't a cure for slow interfaces, the truth is you have to know Swing well to design responsive interfaces. These are the two sides you will find in any argue over SWT and Swing. Swing fans say you have to know Swing to do right, SWT fans say Swing crawls and SWT kicks *ss.
I'm curious if anybody has done some benchmarking of their own...I'd like to see some linux results(I tested on a Win2K), cause I got no time for this anymore :(
Java Developer
Top Expert 2010
How heavy is SWT (for applet use)?


Sorry for getting sidetracked on your question.
Just yell if there is anything you want to discuss.
One thing I was thinking was that actually since creating displaying the gui will implicitly start the swing ui thread then option 1. looks like the approach I'd use:

1. main() starts the UI thread and the worker thread

Where the main creates your GUI (resulting in UI thread starting), and also starts up your comms thread.

I must apologize too for going the swt vs. swing direction :)
objects, SWT does not apply for applet use, since it uses native libraries...of course you could put those libs inside jre\lib and you could run the applet...of course with sufficient rights(modify the policy file also).
It's just not worth it...
I forgot...it's a very nice approach the SWT guys have taken(ibm of course) in separating the native code...both the java part and the native part are different...you should get the jar appliable to your platform and your platf. specific libraries.As far as I know, AWT has the same java implementation, only the native part differs.
If you have the time, read this


no apologies necesary, good info

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial