how to execute a java function in parallel with a joptionpane

Question

I want to execute a function in java, but meanwhile I want to show a JOptionPane to the user when the operation starts and when it ends, the problem is that if I don't push the "Accept" buyton of the first JOptionPane, my function doesn't starts, I'd like it to be automatically, how can I do that? here's my code, I'm using JRI interface for my function.

JOptionPane.showMessageDialog(null, "Leyendo archivos, espere un momento...","Importar archivos cel", JOptionPane.INFORMATION_MESSAGE);

REXP data = re.eval("rawdata <- read.celfiles(celFiles)");

JOptionPane.showMessageDialog(null, "Se han importado las muestras exitosamente.", "Importar archivos cel",JOptionPane.INFORMATION_MESSAGE);

Need to start a thread (which does calculations) before displaying the JOptionPane, it will continue running when the JOption pane is displayed. — maraca, Jun 22 '15 at 00:07
Hava a look at [Concurrency in Swing](http://docs.oracle.com/javase/tutorial/uiswing/concurrency/) and [Worker Threads and SwingWorker](http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html). Maybe something like [this for example](http://stackoverflow.com/questions/25418694/opening-jdialog-with-swingworker/25419069#25419069) or [this for example](http://stackoverflow.com/questions/14113644/java-global-reusable-loading-dialog/14114663#14114663) — MadProgrammer, Jun 22 '15 at 00:08
or even [this for example](http://stackoverflow.com/questions/12644778/multithreading-issues-with-swing-around-dialog-create-destroy/12647582#12647582) — MadProgrammer, Jun 22 '15 at 00:10
Alternatively use normal frames to display, those are not modal and execution continues after setVisible(true), then your code would more or less work as you expect it. — maraca, Jun 22 '15 at 00:13
@maraca Except if the "function" is blocking or long running, it will still block the EDT — MadProgrammer, Jun 22 '15 at 00:19
And where should the frames be created? If you're suggesting that the OP should create them outside of the context of the EDT, then you're violating the single thread rules of Swing, which could lead to other issues, such as paint artifacts and untraceable dead locks — MadProgrammer, Jun 22 '15 at 00:23
@maraca Except you are violating the single thread rules of Swing, which could lead to unexpected issues on different platforms, this is why Sun recommended that ALL UI creation/modifications should be done within the context of the EDT as outlined [here](https://bitguru.wordpress.com/2007/03/21/will-the-real-swing-single-threading-rule-please-stand-up/) — MadProgrammer, Jun 22 '15 at 00:27
@MadProgrammer there will be no UI modification, the user can just click it away, the frames are independent... still see no violation. By create I meant calling their creator, you can put setVisible in there, would you be satisfied then? — maraca, Jun 22 '15 at 00:30
As started [here](https://bitguru.wordpress.com/2007/03/21/will-the-real-swing-single-threading-rule-please-stand-up/) - *"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. (emphasis added)"*. Creation of the UI is also considered a modification of the UI context. There is no way to know when the EDT might kick in — MadProgrammer, Jun 22 '15 at 00:33
@MadProgrammer I see, if this is really that severe then a lot of books are wrong or have bad examples, I didn't knew about creation. — maraca, Jun 22 '15 at 00:37
@maraca Yep, as you can see, the rules changed (I'd been coding Swing for 6 years prior to this), it's also not widely known, there was no song and dance made about the change, it was just quietly documented...yeah of us — MadProgrammer, Jun 22 '15 at 00:39

Victor Anuebunwa · Answer 1 · 2015-06-22T01:21:52.803

Use ExecutorService, i believe it should be easier to implement if understood. example,

REXP data;
    try {
        ExecutorService newCachedThreadPool = Executors.newCachedThreadPool();
        Future<REXP> submit = newCachedThreadPool.submit(new Callable<REXP>() {
            @Override
            public Object call() throws Exception {
                return re.eval("rawdata <- read.celfiles(celFiles)");
            }
        });
        data = submit.get();
    } catch (InterruptedException | ExecutionException ex) {
        System.err.println(ex.getMessage);
    }
    JOptionPane.showMessageDialog(null, "Leyendo archivos, espere un momento...", "Importar archivos cel", JOptionPane.INFORMATION_MESSAGE);
    JOptionPane.showMessageDialog(null, "Se han importado las muestras exitosamente.", "Importar archivos cel", JOptionPane.INFORMATION_MESSAGE);

You can use other of its overloaded methods to your convenience. see documentation

how to execute a java function in parallel with a joptionpane

1 Answers1