1

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).

Improve this question
4
  • Make your core "multithreading codebase" independent of SwingWorker and just use this codebase in the SwingWorkers - I mean separate concerns and use tiny layer of abstraction/glue between your SwingWorkers & "multithreading codebase". Maybe you could even create event-driven / bus oriented design. Commented Aug 28, 2015 at 10:34
  • @Xeon Could elaborate more your answer please? What you mean by codebase and "event-driven / bus oriented design"? Could you give an example (a link or something) of what you proposed? Commented Aug 28, 2015 at 10:42
  • @nervousDev you can look for example how GWT EventBus is working. Concept is exactly the same. Commented Aug 28, 2015 at 10:47
  • I did a quick search and yes, this could be what I need. Is that the only option for a event bus desing? Commented Aug 28, 2015 at 10:52

3 Answers 3

Reset to default
2

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 ;)

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

I forgot to mention that this background tasks need to be launched at the start ( I will edit the question, see there please).
@nervousDev it's not a problem. Still your app can react to the events coming from your background tasks.
1

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.

Improve this answer

3 Comments

Thank you for your explanation. I do know design patterns but not so much applied to multithreading applications. I do use a design by layers (GUI, controller, model, and so on). That's why I don't want such important and relevant classes like the multithreading ones to be dependent on other classes.
No worries, I would mention too that not many people are making desktop apps in Swing anymore, and even less people are making multithreaded desktop applications, this will be a very difficult task so good luck. I made a desktop build server and client for a project which was multithreaded ussing akka. It let you control how many checkout and builds could happen at any given time, thought it would take 2 weeks, took 2 months lol. But it was pretty awesome.
I know that Swing is not really a modern approach and it's getting put the corner but for now it's the only gui framework I can use. Maybe one day it get changed. Multithreading I'm not going to say the same as you. It might getting not use as it used to but it still is a great "feature" because you can make some things that you otherwise couldn't. Thank you!
0

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.

Improve this answer

5 Comments

As I add to the question the background tasks need to be running all the time for the beginning so the GUI (SwingWorker) can´t do that. This is not the case for one operation in background. Thank you.
Actually SwingWorker can accomodate that via its publish() method - but then you would need an interface class between your background method and the class containing your SwingWorker - and then you need to work out a method of synchronising them (when to call publish() ). See more here: docs.oracle.com/javase/tutorial/uiswing/concurrency/…
For what I could see in a quick search I think I'm gonna go with the eventbus design option. Just because I really hate to code "from the GUI" even with a layer separation. Thank you anyways. I will check you link.
You wouldn't be "coding from the GUI" you would be coding from the application which contains various components including the GUI - but EventBus is a good way of doing it.
Thank you. I'll try both ways. I gonna make a test application and I'll see what the best approach to me and to the project itself.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.