I started to use CheckThreadViolationRepaintManager to detect EDT violations.
It complains about:
partner = getParameter("partner",generatePartnerSelectionPanel(),Design.partnerSelectionDuration);
Because it does not like generatePartnerSelectionPanel() because it does not like JPanel panel = new JPanel(); in this method. But I cannot find out why there should be a problem around that.
In more details, generatePartnerSelectionPanel() generates a JPanel (I do it not in the EDT) but then, in the getParameter I add the JPanel to the main JFrame and I do it in the EDT (using invokeLater).
So, why there should be a problem?
An EDT violation doesn't mean something necessarily did go wrong, it means you tried to do a GUI related action on a thread other than the EDT (a situation where something might go wrong).
Creating a new Swing component is covered by "doing something GUI related", hence the warning about the violation.
This forum has quite a discussion on why it's not recommended to create Swing components on other threads.
Usually this will happen if you create any GUI components in the thread handed to you in main.
Now, in reality nothing bad will ever happen as long as you don't modify it after you've realized it (setVisible(true) or pack() will realize a frame), BUT Sun found some edge case that they claim make it so this can cause a problem.
So to be perfectly correct have your main construct your first window inside an invokeLater or invokeAndWait.
Actually, I wonder if exiting your main thread right after the invokeLater might allow your entire app to exit (since the window almost certainly hasn't had time to come up yet)... You might want to use invokeAndWait unless your main thread doesn't exit.
Swing is thread-hostile. Even if a component is not realised, it may still access shared resources or call EventQueue.invokeLater. There was a period when it was widely stated that Swing components could be created off the, but that was incorrect.
In addition to using the CheckThreadViolationRepaintManager I've been using an Aspect Oriented solution to detect when any Swing components are constructed off of the EDT. This is an elegant way to troubleshooting EDT violations if you use AspectJ.
See this blog post for details:
Debugging Swing, the final summary (from archive.org)
Related
This is mostly a theoretical question. The example below is what made me think of it, but it may not be the best example. Please assume that the reason's below are concrete, and can't for the moment be worked around.
The Program I have been running has an optional Debug frame that is created on the program startup, and it made visible by the user pressing buttons/keyboard shortcut.
My issue is that as I have lengthy processes on the EDT, if it is hanging for some reason or fails I'd like to see straight away, and not wait for that thread to end running, to update the Debug Log Frame.
My solution would be to have two separate EDT for two separate GUIs that are updated by a separate thread.
Is this possible, or am I not able to do so? I haven't found any online resourcethat would show me how to. I know that EDTs should be single threaded, but if I keep the threads disentangled, can I have two? Please?
The answer is simple: No you cannot have 2 EDTs, that is not possible.
But you are not stuck with a frozen GUI, you have some options available.
First and foremost, two important rules:
Never do lengthy calculations in the EDT. Ever.
Never manipulate Swing components from outside the EDT. Ever.
Breaking the first rule will result in your GUI being frozen and no events of any sort being processed during that time. This includes updates to the GUI you want to do during the calculations which will not appear until after the calculations are done.
The latter is often ignored which will go by unnoticed most of the time, but it can - and will - bite you in the ass and then most of the time it is a huge pita to go back and fix it. So do it the correct way from the start. What can happen? Components can suddenly display in a broken state, they may appear white, or the whole application can freeze because there is a deadlock between the EDT and your other threads (been there, done that). Adhere to the Oracle Swing Threading Policy!
So, how to avoid doing lengthy calculations on the EDT after for example the user pressed a button? Options:
use a SwingWorker. Advantage: Has a done() method you can use which is automatically executed in the EDT once the worker is done. Also implements the Future interface and can therefore be used to return a result.
you can just create your own Runnable and do the calculations in there.
use any other way Java provides for parallel execution.
Ok, and how to avoid ever manipulating GUI from outside the EDT?
call SwingUtilities.invokeLater() and execute Swing manipulations in there.
use the SwingWorkers done() method as described above.
If you follow these two rules, your Swing GUI will be in a much better shape and you can focus more on your application development rather than Swing issues.
I've searched this along the way on the net but i haven't found an answer yet.. maybe someone of you guy knows this.
I'm developing a swing desktop like application; since I know that swing is not thread-safe (and if I call a method on a JComponent outside the EDT there is always the chance to get a deadlock with the EDT itself), I would like to have an exception thrown by the thread that is trying to call that method.. let me explain better:
suppose I have 2 threads: the EDT and a background worker ("BW").
If I call, for instance, JButton.setText(), or JButton.setIcon() within the BW there is a chance to get a deadlock with the EDT. Now I would like that when the BW calls JButton.setText() and exception is thrown to indicate that I'm doing very wrong..
I see that C# on VS2008 does this by default (I don't know if there is a way to disable this behaviour, but I think it is very useful to detect bad code). Is there a way to achieve a similar effect in java?
Take a look at this article which describes a RepaintManager which checks Swing threading violations. It will not catch all violations, but most of them.
You can easily adjust that class to throw Exceptions iso just printing a stack trace
Take a look at SwingUtilities.isEventDispatchThread. Calling this will return true if the call is made from within EDT, false otherwise.
It will do exactly what you want, the problem is you will probably have to make such calls in multiple places of your code; it's more work.
Wrap each swing object you have in a Proxy, generated with reflection. Make that proxy compare the thread to the known good EDT thread. If doesn't match throw a RuntimeException.
The "Painting in AWT and Swing" docs state the following.
"If multiple calls to repaint() occur on a component before the initial repaint request is processed, the multiple requests may be collapsed into a single call to update()."
Is it possible to change this behavior in a component so that multiple calls to repaint never get collapsed into a single call?
EDIT: The docs further state this, "The algorithm for determining when multiple requests should be collapsed is implementation-dependent."
My problem is I'm on a mobile platform that does separate calls to repaint and I'm trying to replicate the behavior on the desktop.
I'm guessing you have some long running task that is looping an not updating the GUI as you expect it to. This would be because you are blocking the Event Dispatch Thread so Swing can't repaint itself.
Read the section from the Swing tutorial on Concurrency in Swing. Use the SwingWorker for the long running task to you don't block the EDT and then you can publish results and required and they will be painted as expected.
Or if you problem is with animation, then use a Swing Timer. The tutorial also has a section on timers.
I fear the paint algorithm is pretty hardcoded in swing/awt and they only offer different hooks for different purposes. You can use use this method in swing which would offer what you want, but sadly there doesn't seem to be an awt equivalent. You could try mixing awt/swing, but that's usually not recommended and may lead to strange behavior in some cases as I hear
PS: And for people asking WHY you'd want this: Some apps (mostly games) need synchronous redraws to ensure that their visual appearance keeps up with the internal state - afaik the JScrollbar also uses it internally for example (I haven't looked at the code in question, so take this with a grain of salt - I do understand though why it could be useful in that particular case)
Re: Requirement to create Swing Object on Event-Dispatch Thread.
I am working on an application, the purpose of which is to monitor and display the condition of various remote embedded servers. I'm pretty new to Java, and my understanding of the requirement with respect to the Swing Objects and the EDT is incomplete.
The main GUI is started on the EDT in the usual fashion as follows,
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
The user may then select one or more menu options corresponding to the one or other of the remote machines. The effect of this is to create a new thread each time as follows
new Thread(new VoterStatus(itemNumber)).start();
which invokes VoterStatus's class "run" method which in turn creates a new window with a JFrame. The new thread, an instance of VoterStatus class, then interrogates (TCP etc) the particular remote specified (itemNumber), collecting various bits of information and displaying them in the JFrame.
There may be any number of such threads corresponding to an instance of VoterStatus, all updating their own windows. There is no sharing of data between these various windows/JFrame/tasks.
This seems to work just fine, but is is safe?
Have I violated the rule about creating Swing components on the EDT?
Would use of the SwingWorker class be beneficial?
I would appreciate any comments from Java programmers more experienced in such matters.
Thanks
Steve
From the section in the Swing tutorial titled The Event Dispatch Thread
Some Swing component methods are labelled "thread safe" in the API specification; these can be safely invoked from any thread. All other Swing component methods must be invoked from the event dispatch thread. Programs that ignore this rule may function correctly most of the time, but are subject to unpredictable errors that are difficult to reproduce.
I always invoke my methods on the EDT so I don't waste time chasing gremlins.
Edit:
I just read another posting which states that the comment "thread safe" has been removed from many methods in the JDK7 API. http://forums.oracle.com/forums/thread.jspa?threadID=2167051. This looks like another reason to make sure all methods that affect the GUI are executed on the EDT.
#camickr has the right of it. Incorrectly synchronized programs may appear to work most of the time, but the result is not reliable. Several related approaches are discussed here. SwingWorker is an especially convenient implementation of the Future interface, as process() runs on the event dispatch thread.
You might be safe, but you can be sure by creating your other UI components in the EDT, just like you did for the main application.
However, I would suggest a different approach. Rather than firing off a new Thread which creates the windows and stuff for each new VoterStatus, create the UI components in the EDT in response to ActionEvents from menus or whatever, and do processing of the network stuff only in a different thread. Then get the results and use the EDT to display them. As you've suggested, a SwingWorker is ideal for this - this is exactly the sort of use it was designed for. This represents a cleaner separation for me, separating the UI stuff from the network stuff as much as possible.
I'm not really answering my own question, but I do want to thank those that responded and ask a follow up question or two.
Rogash commented that if I was only creating the GUI on the EDT, I would be ok, but this doesn't seem quite in accordance with a strict interpretation of the rule?
The additional threads are created in the EDT, but they are still separate threads.
Whilst slightly better separation of the GUI and comms may be desirable, I expect this will add considerable complexity to the main GUI code, since it will have to determine which window originated various events and then update the correct window, not to mention the communication between the various threads and the main GUI thread. Perhaps I am overstating this difficulty (I haven't designed or thought about how to code it yet) but it would seem more complicated. Each of the threads/JFrame already has a couple of JToggleButton arrays (30 elements) causing potential events and 10 or so JTextField arrays with the same number of elements requiring updating.
Of course, if my method is unsafe, I'll have to change it, and that's that!
Actually, I wonder if I might be better off leaving things the way they are, and using a mutex or semaphore to make sure only one thread is accessing Swing methods at a time. There is really no long user actions or any other activity takes a long time, just lots of TCP or UDP packets being received that require the screen display to be updated.
Thanks again
Steve
PS I tried to register on this forum, but I think this discussion will stay with my unregistered persona.
In a "serious" Java GUI app, you'll have models behind many of your GUI elements: A DocumentModel backing a JEditorPane, for example, or a ListModel behind a JList.
We're always told not to make GUI changes from outside the Swing worker thread and given SwingUtilities.invoke...() for working around that. Fine, I can live with that! It's certainly necessary (and works well) when changing attributes of GUI components directly.
Ideally, most of my GUI-visible changes will be to models, not to JComponents, anyway. But because they're GUI-visible, do they "count" as GUI changes? I.e. do change events and listeners provide the necessary decoupling, or do model changes need to be wrapped in invoke...() as well?
Probably old hat to Swing pros, but I wasn't able to find any reference that clearly states one way or another.
Generally, the model change must be wrapped into invokeLater(...). There is no decoupling in the model's code of most of the swing classes in which I looked.
It's up to you to create a model which could contain the calls checking that GUI modifications are made on the Event Dispatcher Thread.
If the events are fired off the EDT and update Swing components that is going to be a problem.
In Swing text, events may or may not(!) get transferred to the EDT. This makes testing tricky. Unsurprisingly, the API is not useful in a multithreaded environment.
So: Easiest keep the model on the EDT and other threads should pass messages (involving EventQueue.invokeLater). Alternatively you can put a big lock around everything, which is more difficult (and you'll probably still to need to pass stuff to the EDT). Attempting microsynchronisation is very difficult.
Yes it is most definitely OK.
While it is true you should not modify Swing components outside of the EDT. You can certainly make changes to their models outside the EDT.
If you have wired the models to your Swing components correctly, the view updating and hence EDT scheduling will happen almost automatically.
See: http://java.sun.com/products/jfc/tsc/articles/architecture/#roots
See the part about JavaBeans Event model.
This is how models communicate their changed state to the GUI in an EDT safe manner. When creating new GUI components you should follow this design pattern.
Also note the distinction between GUI-state models and application-data models.
Making changes to models from the EDT still requires care. In fact most Swing issues happen when the programmer is modifying a model in the EDT when they should be modifying it from a separate thread. (Infamous frozen GUI problem)
Also none of this precludes being fully aware of typical multi threading pitfalls.
But you can most definitely make changes to a JTableModel from outside the EDT.