Is updating from EDT in swing an absolute rule or are there exceptions?

Question

In Swing, the GUI should only be updated with EDT, as the GUI components are not thread safe.

My question is that if I have one thread other than EDT that is designed to update a specific component, and this component does not have access to any other thread in my program, only this dedicated thread, is this normal? In my case, I have a JTable , and the stream receives information from the network and updates the table (without using EventQueue.invokeLater ). All other components are updated with EDT. I have not seen the problem yet, and I was wondering if the error would eventually appear.

UPDATE My goal was to update the table in real time. The data is constantly coming from the network, and for this I selected 1 stream only for the table, in order to update it as they appear. If I use SwingUtilities.invokeLater, this means that the table will be updated when EDT is available. Isn't swing supposed for real-time update requirements?

Answer 1

There are several methods that are described as thread safe. I believe that it is somewhat smaller in JDK7, because it turns out that some of them are not implemented as thread-safe. For the most part, Swing is thread-hostile - it should be used from the AWT EDT stream. This is largely because it uses EventQueue.invokeLater internally with "random." There is also a hidden shared state (you can change PL & F without specifying, for example, each component). Some classes that you can treat as agnostic but not documented as such.

So the answer is: always use EDT for Swing. As with most alternating problems, you might think that this gets away with it and then suddenly fails. Errors are likely to be difficult to diagnose and reproduce (especially if this only happens in production on certain systems). Fixing a code base that is badly broken may not be very funny. Keep it clean from the start.

Answer 2

Instead of trying to speculate on whether it will work or not, I simply adhere to the well-known "rule" that you should only interact with GUI components using the event dispatch thread. When you get data from the network, just refresh the table using SwingUtilities.invokeLater (or invokeAndWait ).

You may not see the problems right away, but it is quite possible what you could do in the future.

Answer 3

You must update the GUI components on the EDT. Period. (There are a couple of outdated exceptions to this rule - but they all silently put things into the EDT anyway). EDT works like a message pump (like most window systems do) - you have to live in this limitation if you want to update GUI components.

If you want to quickly update the table, keep the EDT clean - do not put a huge load on it.

If you work with updating live tables, I highly recommend that you take a look at GlazedLists - they have a very, very good implementation of SwingThreadProxyList, which takes care of the efficient placement of updates in EDT. You must agree to drink GlazedLists koolaid to go this route, but it is a mighty tasty koolaid (I love GL).

Answer 4

Is Swing intended for real-time update requirements?

Not. You may be able to update your data model with sufficient speed, but the graphical interface is usually subordinate. You can use any network latency in your environment. In addition, you may need to consider something like the Oracle Sun Java Real-Time System .

You can improve the "viability" of EDT by updating updates and using minimal correct synchronization. Several alternatives are discussed here .

Answer 5

This is an absolute rule if you do not need race conditions. Sending a stream of events is fast enough so that our video surveillance application does not need hacks.