CODEWITHSUNDEEP
javamultithreadingswing
nervousDev
nervousDev

Reputation: 72

Java multithreading and SWING

I'm developing a SWING based Java application with multithreading.

The idea is to create a set of background "tasks/services" to do some tasks repeatedly.

My problem is how to implement multithreading (in the lower level of the application) that can interact with the GUI by displaying SWING components at some conditions.

I know I can use SwingWorker but using that I will turn my application more "gui oriented" wich I don't want to but in the other hand I also don't want to make my multithreading classes depended on GUI classes.

What are the options where?

Thank you in advance.

EDIT

I forgot to mention that this background tasks need to be started in the beginning and cannot be launched by the GUI (like a bootstrap process).

Upvotes: 1

Views: 723

Answers (3)

Jool
Jool

Reputation: 1785

What you want to do is the standard way most designers would want to do it, that is, have a background worker class which is independent of the GUI.

Creating a class, MySwingWorker, which extends SwingWorker and which calls your background classes is the standard approach. You may want to create one or more dialog classes to wrap your usage of MySwingWorkers, depending on the complexity of your application.

Upvotes: 0

Derrops
Derrops

Reputation: 8117

You need to learn about concurrency design patterns, such as actors, futures, thread pools ect. Event driven means that you don't have blocking code, eg. rather than me waiting on you and constantly asking if you are finished with your task, you simply tell me once you are ready.

If you go the actor route you can wrap your gui class in a controller which is an actor which will process one message at a time. You need to be carefull with swing that you don't create event loops, as in event A triggers event B which triggers event A again and so on.

That's why an obserever pattern can be nice for displaying data.

But there is no silver bullet for concurrency unfortunately, the actor model is picking up, as well as futures, (take a look at akka), but it is essentially a difficult task so it will always be hard to get right.

Essentially I would say that the easiest approach is to make very strict rules on the sort of concurrency you are willing to accomodate, you need to think about the consequences of adding each bit of parallel functionality, and what effect it has. Then design your code based on that using a well established concurrency model.

Upvotes: 1

G. Demecki
G. Demecki

Reputation: 10586

but in the other hand I also don't want to make my multithreading classes depended on GUI classes.

What about using Observer/ Listener pattern? Your background tasks, launched by SwingWorker, can notify some other components when there is such need. @Xeon comment is pointing you in good direction.

Personal advice: start with some solution and then continuously refactor when code became not so readable.

btw. I hope you remember the old rule: Swing components should be accessed on the Event Dispatch Thread only ;)

Upvotes: 2

Related Questions