I've got some problems while learning threads in Java. The goal is to make a simulation that shows us how rabbits are running from wolves on some kind of board. Every wolf and every rabbit should be a thread. So I created a GUI in main method of Test class and created a new class that implements the Runnable interface. That's easy and logical I think. But now, how can I call the AddRabbit method from these threads? Because very thread should do mething like:
Change its properties like place on the map
Check other threads place on the map
Paint itself on the panel
But how?
Updating Swing components directly using multiple threads is not allowed--Swing is not threadsafe. There is a single Swing event queue that it processes, so if you have to update a JComponent in an existing thread, you will use the following code:
//You are currently in a separate thread that's calculating your rabbit positions
SwingUtilities.invokeLater(new Runnable() {
public void run() {
//Put in code to modify your Swing elements
}
});
So every time you feel the need to update your GUI, then you can pass an instance of Runnable onto the Swing event queue using the SwingUtilities.invokeLater method, which it will process in its own thread.
A continuation, suggested here, is a good choice for updating the GUI from multiple threads, but it may be difficult to correctly synchronize access to shared data.
Alternatively, use a javax.swing.Timer to periodically update a model that manages the properties of wolves and rabbits. A related example of objects moving on a grid is examined here. For greater flexibility, use the Model–View–Controller pattern, illustrated here.
Related
I know about the Swing components and that they should be called from the event dispatch thread but as of now i developed test applications which are event thread centric, that means the UI does the program flow definition by calling listeners on event invocation. But i have read that other threads should not communicate with the UI because it is not synchronized.
Most books just teach how to use individual components and not how to
to use them in a real world application context.
How does one update status of a completed or in process thread status to a swing component.
UPDATE: If we configure the listener to invoke the job in an ExecutorService how does the working thread update the UI component in a safe manner.
the safest way is to use
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
}
});
inside run method you can manipulate Swing components
The basic answer is calling repaint.
The idea behind AWT/Swing is that at any moment, a component could be shown, resized, moved etc (either by the code or thru user interaction) prompting the need for repainting. So when you do your updating, you should update the model that the rendering is going to be based on... sometimes necessitating doing this on the EDT for consistency's sake, and then use repaint to show the changes to the model
You could...
Use SwingUtilities.invokeLater to schedule an a callback to be executed on the EDT at some time in the future.
The problem with this is synchronising data between the threads, as the data that the update might need might no longer be the same it was when the call was made
You could...
Use a SwingWorker. This provides a means to synchronise data changes between the background thread and the EDT as the data is passed through to the process method, so it can act on "relevant"/"related" data at the time it is called, this decreases (some) of the need for synchronising access to the data that the UI might need
UPDATE: If we configure the listener to invoke the job in an ExecutorService how does the working thread update the UI component in a safe manner.
SwingWorker itself is compatiable with ExecutorService, you can add instances of SwingWorker to it, neat trick ;)
For example
The EDT's only job is to call your handlers. The only way in which you can "communicate" with it is by registering handlers for it to call. (NOTE: The invokeLater(...) method is just a way to register a handler that the EDT will call immediately.)
i have read that other threads should not communicate with the UI because...
Don't think about it in terms of "communicating." Think about it in terms of threads operating on shared objects. What you ought to be saying is, "Other threads should never operate on Swing objects."
Other threads can operate on your objects, and then your objects can show their updated state on screen when the EDT calls their paint(g) methods.
I'm attempting to add a fancy InfiniteProgressPanel as a GlassPane for my big Swing program. However, it does not appear. It looks similar to this:
...
InfiniteProgressPanel glassPane = new InfiniteProgressPanel();
setGlassPane(glassPane);
...
glassPane.start();
doSomeStuff();
glassPane.stop();
...
I believe it is running in the same thread as the long process it is meant to cover up. I'll admit, I don't know nearly enough about threads, and I should probably figure out how to run that InfiniteProgressPanel GlassPane in a separate thread, and the long process in its own thread, too.
Be sure to:
Run all long running code in a background thread. This is a must.
Sounds great! How do I do so? Encapsulate all of the long-running code inside of an .invokeLater method? And should that be SwingUtilities.invokeLater or EventQueue.invokeLater? And what's the difference, anyway?
No, by using SwingUtilities.invokeLater(new MyRunnable) you're doing exactly the opposite -- you're guaranteeing that the long-running code will be called on the Swing event thread -- the exact opposite of what you want. Instead use a SwingWorker's doInBackground() method to run the long-running code. Regarding your second point, there's no difference whatsoever between SwingUtilities.invokeLater and EventQueue.invokeLater.
Make most all Swing calls on the Swing event thread, also a must.
Fantastic! Again, how do I do so? Same thing as above?
By using SwingUtilities.invokeLater(new MyRunnable) as noted above, or if you're using a SwingWorker then use its publish/process method pair as the SwingWorker tutorial will show you.
Call setVisible(true) on your glass pane since per the JRootPane API, all glasspanes are by default invisible.
Romain Guy's InfiniteProgressPanel doesn't seem to need a setVisible(true). It appears when the InfiniteProgressPanel.start() method is called.
I am not familiar with this, do you have a link?
Threads are different processes in the same program, per se.
In java, there are many different thread types, and the one you need for this job is SwingWorker.
The definition/use of this, from Oracle's docs, is:
When a Swing program needs to execute a long-running task, it usually uses one of the worker threads, also known as the background threads. Each task running on a worker thread is represented by an instance of javax.swing.SwingWorker. SwingWorker itself is an abstract class; you must define a subclass in order to create a SwingWorker object; anonymous inner classes are often useful for creating very simple SwingWorker objects.
As you can see, this is what you need; a background thread.
final InfiniteProgressPanel glassPane;
...
class GlassPaneHandler extends SwingWorker<String, Object> {
#Override
public String doInBackground() {
glassPane.start();
return setUpPaneAndStuff();
}
#Override
protected void done() {
try {
glassPane.stop();
} catch (Exception e) { } //ignore
}
private void setUpPaneAndStuff() {
//code
}
}
...
(new GlassPaneHandler()).execute(); //place this in your code where you want to initiate the pane
for more see:http://docs.oracle.com/javase/8/docs/api/javax/swing/SwingWorker.html
When you are updating a swing UI you need to do it in Swing's Event Thread. This includes creation of components or any sort of progress updates. You can do this via the SwingUtilities.invokeLater(Runnable) method.
Therefore, you should create the glasspane and show it via the invokeLater if in a background thread. Any progress updates to the glasspane from your long running process thread should be done via the invokeLater.
I am trying to understand the real purpose of this thread.
I have read books , articles ,but didn't undrstand clearly what EventQueue thread is responsible for. I have seen a lot of examples, sometimes this is used, sometimes not. As I understood this thread is responsible for ALL GUI OPERATIONS, such creating windows, components, calling native functions from OS API and other stuff. So every time I change some part of GUI I should pass this action to queue.
So using queue application has two threads by default main and event dispatching thread. So I all bussines logic should be performed in main thread (or create new thread from main) and all gui operations in EventQueue(for example adding new item to the table, changing text in label updating list). Futhermore I should create instance of main windows (class extends jframe) in EventQueue ?
Am I right ? If not please explain. Thanks everyone in advance.
EventQueue manages a single GUI thread because it must rely on the host platform's GUI resources, which are also single-threaded. You can run non-GUI code on the initial thread, but you must synchronize access to any shared data yourself. SwingWorker, examined here, is a convenient alternative.
It sounds like you've got the gist of it, yes. If your application is essentially "pure GUI" you can just do everything on the EDT (Event Dispatch Thread, which is the thread that runs whatever you pass to EventQueue.invokeLater), but you must create windows on the EDT which means your main() method must use EventQueue.invokeLater at least once.
Because all listeners on GUI objects will be notified on the EDT, you do not need use EventQueue.invokeLater from your handlers, generally.
I'm trying to flash a Java graphic object by changing the color and calling the repaint() method. The color is only updating with the final change color call. Here is my code:
public void start() {
try {
Color origColor = node.getColor();
for (int i=0; i<noOfFlashes; i++) {
Manager.gui.getDrawGraph().changeNodeColor(node, Color.WHITE);
Thread.sleep(500);
Manager.gui.getDrawGraph().changeNodeColor(node, origColor);
Thread.sleep(500);
}
Manager.gui.getDrawGraph().changeNodeColor(node, Graph.VISITED_NODE);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
and the change node color method is:
public void changeNodeColor(Node node, Color c) {
node.setColor(c);
repaint();
}
The change node color is in the same class as the paint component.
Any help would be much appreciated.
You need to use separate thread to manage your GUI event.
You can do this, using a SwingWorker, as suggested by Amine, or implement the Runnable interface, or extend the Thread class, developing the run() method, that is the task of your thread.
You can read this old question of SO : How do I use SwingWorker in Java?
A tutorial for SwingWorker : http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html
A tutorial to make a Thread : http://docs.oracle.com/javase/tutorial/essential/concurrency/
The color is only updating with the final change color call.
If you don't use a separate thread, your gui will freezing until the method is completely executed, and you won't see the color change separated by Thread.sleep(500);.
UPDATE
In this link, in the paragraph Why does a Swing GUI freeze or lock up?, you can understand why a Java Swing GUI freezes, with the use of a single thread.
Check also this official link, in the paragraph Creating Threads, and this page, that returns:
Swing's single-thread rule says that Swing components can only be
accessed by a single thread. This rule applies to both gets and sets,
and the single thread is known as the event-dispatch thread.
The single-thread rule is a good match for UI components because they
tend to be used in a single-threaded way anyway, with most actions
being initiated by the user. Furthermore, building thread safe
components is difficult and tedious: it's a good thing not to be doing
if it can be avoided. But for all its benefits, the single-thread rule
has far-reaching implications.
Swing components will generally not comply with the single-thread rule
unless all their events are sent and received on the event-dispatch
thread. For example, property-change events should be sent on the
event-dispatch thread, and model-change events should be received on
the event-dispatch thread.
For model-based components such as JTable and JTree, the single-thread
rule implies that the model itself can only be accessed by the
event-dispatch thread. For this reason, the model's methods must
execute quickly and should never block, or the entire user interface
will be unresponsive.
I think that the sentences above are very useful to understand better the Swing package.
I report the suggestion of trashgod.
You can use the Timer class, from the javax.swing.Timer package. That is also a good alternative.
In this question, trashgod reports some examples of Timer.
Check here for a tutorial about Timer.
Based on what i understand from your code, I will probably recommend the use of SwingWorker.
I know you do not have any cost expensive code but you using SwingWorker, you will be able to update your GUI more easily.
I am not sure which framework you're using here... but you may need a repaint() just before the Thread.sleep(). Is there a Manager.gui.repaint() perhaps? (Sorry, complete guesswork here...)
For what I can read, it is used to dispatch a new thread in a swing app to perform some "background" work, but what's the benefit from using this rather than a "normal" thread?
Is not the same using a new Thread and when it finish invoke some GUI method using SwingUtilities.invokeLater?...
What am I missing here?
http://en.wikipedia.org/wiki/SwingWorker
http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html
Yes, you can accomplish what a SwingWorker does with vanilla threads + invokeLater. SwingWorker provides a predictable, integrated way to accomplish tasks on a background thread and report result on the EDT. SwingWorker additionally adds support for intermediate results. Again, you can do all of this yourself but sometimes it's easy to use the integrated and predictable solution especially when it comes to concurrency.
A code example:
import org.jdesktop.swingx.util.SwingWorker; // This one is from swingx
// another one is built in
// since JDK 1.6 AFAIK?
public class SwingWorkerTest {
public static void main( String[] args ) {
/**
* First method
*/
new Thread() {
public void run() {
/** Do work that would freeze GUI here */
final Object result = new Object();
java.awt.EventQueue.invokeLater( new Runnable() {
public void run() {
/** Update GUI here */
}
} );
}
}.start();
/**
* Second method
*/
new SwingWorker< Object , Object >() {
protected Object doInBackground() throws Exception {
/** Do work that would freeze GUI here */
return null;
}
protected void done() {
try {
Object result = get();
/** Update GUI here */
}
catch ( Exception ex ) {
ex.printStackTrace();
if ( ex instanceof java.lang.InterruptedException )
return;
}
}
}.execute();
}
}
The choice always depends on personal preference and use case.
The second method has an advantage when refactoring. You can more easily convert the anonymous class to an inner class when the method it's used in is too large.
My personal preference goes to the second, for we have built a framework where SwingWorkers can be added and are executed one after the other...
SwingWorker is an implementation of a common pattern (in .Net i read there is GuiWorker BackgroundWorker for this), where you have to do some work in a GUI program, but keep the GUI responsive. The problem is that often GUI libraries are not multi thread safe, so the common way to implement such workers is to use the message loop of the library to transfer messages into the event loop of the application.
These classes allow you to easily update your GUI. Usually, they have a update(int status) method that is called by the thread, dispatched by the class, and handled by the GUI, while the thread continues its work.
Using normal threads, you would need to code your own events or some other messaging mechanism for this task, which can be a pain if you need this functionality often. Using invokeLater in Java for example, you would intermix the code for updating the gui into the code for doing the work. The SwingWorker allows you to keep things separate.
to answer your question, you are not missing anything. this class is just a convenient utility for wrapping up the functionality you discribed (start another thread to do the background work and then invoking some final action on the EDT with the results).
When working with Swing, it is important to know that the main swing processing (ie. rendering) happens on a single thread (which is not your main thread). This is often called the Swing or awt event thread. Those familiar with the JDK pre 1.6 will remember the "grey rectangle" bug if you spent too much time in an event dispatcher for a swing component. What does this mean. In any swing application you will have 2 threads running that you will now have to deal with. Normally if all your operations within an event dispatcher (the code that gets fired say when a button is clicked) is short (ie. changing the state of a siwng button) you can just run this inside of the event dispatcher. If your application is going to call a web service or a database, or you application state is driven by external events (ie. jms) or you want to just make your UI more interactive (ie. build a list of items and be able to do something else) you should use a thread other than the awt event thread (the main swing one). So in these cases you spawn a new thread and do what you have to, and when the results finally come back, you then somehow have to create an event that can be executed by the awt/swing dispatcher. SwingWorker is a great little design pattern that allows you do to do this (the other way is SwingUtilities). It is particularly useful for doing fetch data from external sources or say long calculations (rendering a graphics scene). It helps automate the dispatch and subsequent re-integration of the results from an external thread (other than the awt thread). For async events (ie. an event from JMS needs to update a result, use SwingUtilities).
SwingWorker makes trivial example code much more concise. However it creates a ball of mud. Communications to and from the GUI and executed logic are all welded together. So, I'd not like to see it used in real production code.
SwingWorker is far easier than mucking with your own threads because it gives you two things that are painful to manually, thread coordination between the UI and the background process and doing loops effective, background work that keeps working and sending updates back to the UI incrementally, like process a large amount of data, or loading a large list. The disadvantage (or advantage) depends on how you look at it, is that it hides the underlying implementation, so future version may have different behavior, performance, etc, which may be undesirable. I've found it quite useful as the glue between a UI event and my own command code, the SwingWorker maintains the link to the UI and my code pumps data.