domingo, 5 de abril de 2015

EventQueue.invokeLater

------------------------------------------------------------------------------------------------------------------
 Creating and modifying the components outside the EDT(Event Dispatching Thread) breaks the threading rules, but the breakage is not necessarily visible. The larger the program grows, the more likely it starts behaving badly sometimes, on some systems, and on some java versions

-------------------------------------------------------------------------------------------------------------------

- The complete Swing processing is done in a thread called EDT (Event Dispatching Thread). Therefore you would block the GUI if you would compute some long lasting calculations within this thread.

The way to go here is to process your calculation within a different thread, so your GUI stays responsive. At the end you want to update your GUI, which have to be done within the EDT. Now EventQueue.invokeLater comes into play. It posts an event (your Runnable) at the end of Swings event list and is processed after all other GUI events are processed.

Also the usage of EventQueue.invokeAndWait is possible here. The difference is, that your calculation thread blocks until your GUI is updated. This must not be used from the EDT.

Be careful not to update your Swing GUI from a different thread. In most cases this produces some strange updating/refreshing issues.

Still there is Java code out there that starts a JFrame simple from the main thread. This could cause issues, but is not prevented from Swing. Most modern IDEs now create something like this to start the GUI

---------------------------------------------------------------------------------------------------------------------

- You only need to use invokeLater when you want to update your UI from another thread that is not the UI thread (event dispatch thread).

Suppose you have a handler for a button-click and you want to change the text of a label when someone clicks the button. Then it's perfectly save to set the label text directly. This is possible because the handler for the button-click event runs in the UI thread.

Suppose, however, that on another button-click you start another thread that does some work and after this work is finished, you want to update the UI. Then you use invokeLater. This method ensures that your UI update is executed on the UI thread.

So in a lot of cases, you do not need invokeLater, you can simply do UI updates directly. If you're not sure, you can use isDispatchThread to check whether your current code is running inside the event dispatch thread.

--------------------------------------------------------------------------------------------------------------------
You need to do this only if you're not already on the event dispatch thread. Unless you've started new threads or executed code from the main thread all your code probably already runs from the event dispatch thread making this unnecessary. For example, all the UI event handlers are called on the event dispatch thread so you would not need to do that for code called from there.

--------------------------------------------------------------------------------------------------------------------

- Java's GUI is strictly single-threaded.
All GUI related things in java should always go through a single thread. The thread is our legendary "AWT-EventQueue-0"   . Hence all GUI related actions should necessarily go through the AWT Event thread. If not so you may end up in a deadlock. For small programs, this might never happen. But for a huge java application if you try frame.setVisible(true) kind of thing in main thread, you will soon find yourself searching a new job. What invokeLater() does is to post your Runnable in the AWT thread's event queue. So the code in your run method will be executed in the AWT-Eventqueue thread.

------------------------------------------------------------------------------------------------------------------

To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread
-------------------------------------------------------------------------------------------------------------------
Most code that invokes Swing methods also runs on this thread. This is necessary because most Swing object methods are not "thread safe": invoking them from multiple threads risks thread interference or memory consistency errors. 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

-----------------------------------------------------------------------------------------------------------------

Tasks on the event dispatch thread must finish quickly; if they don't, unhandled events back up and the user interface becomes unresponsive.

----------------------------------------------------------------------------------------------------------------

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

--------------------------------------------------------------------------------------------------------------

SwingUtilities.invokeLater() vs EventQueue.invokeLater() 

-  SwingUtilities class was built to combine all general utility methods used in swing to be in one single class. Internally SwingUtilities.invokeLater() calls EventQueue.invokeLater()