Spring-Boot with Swing UI

I want to use dependency injection for my Swing UI components in a Spring-Boot application and having a hard time figuring out, how to properly execute the UI behavior on the Event Dispatch Thread.

What I came up with first was like this:

App

@SpringBootApplication
public class App {

    private static AppView view;

    @Bean
    public AppView appView() {
        return view;
    }

    public static void main(String[] args) throws Exception {
        SwingUtilities.invokeLater(() -> view = new AppView());

        SpringApplication app = new SpringApplication(App.class);
        app.run(args);
    }

}

AppView

public class AppView extends JFrame {

    ...

    @Inject
    private DependencyWithTimeConsumingOperations backendController;

    @Inject
    private JPanel someChildComponent;

    @PostConstruct
    public void init() {
        constructView(); // inits frame properties and child components
        showView();
    }

    private void showView() {
        SwingUtilities.invokeLater(() -> {
            pack();
            setVisible(true);
        });
    }

    ...
}

The backend dependency gets called when certain UI events occur. What I observe is, that the backend calls get excuted on the EDT instead of the main application thread, which is bad, I assume. As I understand, not having much experience with Swing, is, that only UI updates should be executed on the EDT.

Is there a better way to wire my dependencies so that everything is executed in its proper thread? What I could find out so far seems a bit outdated or I plainly did not understand the answers :-)

Not sure if it is still relevant to you after so long :), but since it may help others, I'll try to answer.

Spring is only injecting the objects, it is not managing the threads. The behaviour would be the same if you'd instantiated and set the backendController manually, meaning that the EDT (or any thread that is calling the operation) would be the one to execute the code on the controller.

If you explicitly want to run in a different thread, we'd need to know more about the methods in the controller. Are they methods that you want to call and not wait for a reply (fire and forget)? Or maybe you need the reply but can run more than one at the same time? In these scenarios you can take advantage of the Executors class and do something like:

    Executors.newSingleThreadExecutor().execute(() -> backendController.timeConsumingOperation1()); // Fire and forget. The operation timeConsumingOperation1 will be executed by a separate thread and the EDT will continue to the next line (won't freeze your GUI)

If you need a result, you may submit it to the pool and poll for the result (maybe with a "refresh" button on the screen). Keep in mind that as soon as you call "get()" the current thread will wait for the pooled thread to finish before proceeding to the next line.

    Future result = Executors.newSingleThreadExecutor().execute(() -> backendController.timeConsumingOperation2);
    result.isDone(); // You can add a "refresh" button or a scheduled task to check the state...
    doSomething(result.get()); // This will hold the current thread until there is a response from the thread running the timeConsumingOperation

Or maybe you do want to freeze the GUI until you have a response from all methods called in the controller, but they can be safely called in parallel:

    ExecutorService executorService = Executors.newFixedThreadPool(2);
    List<Future<Object>> results = executorService.invokeAll(
            Arrays.asList(() -> backendController.timeConsumingOp3(), () -> backendController.timeConsumingOp4));
    results.forEach(e -> doSomething(e.get())); // The tasks will be executed in parallel and "doSomething()"  will be called as soon as the result for the given index is available
    executorService.shutdown(); // Always shutdown

Of course this is just an example, but in large Swing applications it is good practice to create pools of threads (shared by the controllers) to which we submit our long running tasks. You can configure the pool size based on the number of cores (Runtime.getRuntime().availableProcessors()) to best use the resources available on the machine (the tasks submitted will be queued up with no restriction, but only X threads will execute the tasks in parallel, where X is the pool size).