"invokeLater (Runnable obj)" - doubt

Question

"invokeLater (Runnable obj)" - doubt

Navigation

#1 by (1 votes)

0

Although I have already designed some applications in Java I am following a language manual to establish the base of this language. I have reached the SWING part.

In the manual they create an example class in which an object of type JFrame is created, they add a JLabel, they make it visible, etc, etc (the typical example).

What has caught my attention is that, in the main method of the class they use to visualize the example, they use the following code:

SwingUtilities.invokeLater(new Runnable() {
   public void run() {
      new SwingDemo(); //Donde SwinDemo es la clase con JFrame
   }
});

Also, they say: "..., you can not directly create an instance of a SwingDemo object, instead you must create a Runnable object that runs ..."

It strikes me because, in the examples that I have followed and modified, to design my SWING GUI what I was doing was to create the SwingDemo class as a class that inherits directly from JFrame and in the main of my programs create a instance of that class, for example:

SwingDemo guiEjemplo = new SwinDemo();

Could someone explain to me why one way or another should be used? Is either wrong? Is it not efficient?

Thanks

java java-swing

asked by José Manuel Ortiz Sánchez 26.04.2018 в 16:30

source

1 answer

Detect when an iframe ends loading PHP Catchable fatal error: Object of class mysqli could not be converted to string

score 1 · Accepted Answer

Swing's Threading Policy:

In general, Swing is not thread safe. All Swing components and related classes must be accessed, unless otherwise documented, in the event submission thread. Typical Swing applications process in response to an event generated from a user gesture. For example, clicking on a JButton will notify all the ActionListeners added to the JButton. As all events generated from a user gesture are sent in the sequence of sending the event, the restriction does not affect most of the developers.

However, where the impact lies is in building and displaying a Swing application. Calls to the main method of an application, or methods in Applet, are not invoked in the send thread of the event. As such, care must be taken to transfer control to the event's send thread when building and displaying an application or applet. The preferred way to transfer control and start working with Swing is to use invokeLater. The invokeLater method schedules a Runnable to be processed in the event's send thread. The following two examples work just as well to transfer the control and launch a Swing application:

import javax.swing.SwingUtilities;

public class MyApp implements Runnable {
    public void run() {
        // Invoked on the event dispatching thread.
        // Construct and show GUI.
    }

    public static void main(String[] args) {
        SwingUtilities.invokeLater(new MyApp());
    }
}

Or:

import javax.swing.SwingUtilities;

public class MyApp {
    MyApp(String[] args) {
        // Invoked on the event dispatching thread.
        // Do any initialization here.
    }

    public void show() {
        // Show the UI.
    }

    public static void main(final String[] args) {
        // Schedule a job for the event-dispatching thread:
        // creating and showing this application's GUI.
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                new MyApp(args).show();
            }
        });
    }
}

This restriction also applies to the models attached to the Swing components. For example, if a table model is connected to a JTable table, the table model should only be modified in the event distribution chain. If you modify the model in a separate thread, you run the risk of exceptions and possible damage to the display. As all events are delivered in the event's sending thread, care should be taken in the processing of events. In particular, a long-running task, such as the io network or intensive computational processing, executed in the event sending thread blocks the sending of the event delivery chain so that it does not send other events. While the send thread of the event is blocked, the application does not respond completely to the user's input. Consult SwingWorker for the preferred way to perform such processing when working with Swing.

Information extracted from the java api and literally translated into Spanish, to see the original: link