I have an exec-maven-plugin java execution that works well when run via the mvn CLI. But when run by vscode (where the plugin is called from the java language server via m2e), it doesn't run properly. A ClosedByInterruptException is triggered upon the first I/O operation. After some investigation I found that the execution thread is already interrupted before it enters my code.
AbstractExecJavaBase.java creates a bootstrapThread to run the exec class in. It then calls joinNonDaemonThreads to wait for that thread to finish. This assumes that the exec thread is not a daemon thread. But, threads inherit their daemon status from their parents, so if the plugin is run in a daemon thread, then the bootstrap thread will be a daemon thread. In that case it does not wait for the thread to finish and (when cleanupDaemonThreads is true) it immediately calls terminateThreads, interrupting the exec thread.
If the intention is for bootstrapThread (and its children) to be joined in joinNonDaemonThreads, then I think the code should explicitly call bootstrapThread.setDaemon(false).
Why is the plugin being run in a daemon thread? Well it seems that JDTLanguageServer in eclipse.jdt.ls uses CompletableFuture without an explicit executor for lots of build operations. These use ForkJoinPool.commonPool(), in which all threads are initialized as daemon threads.
cleanupDaemonThreads can be set to false to avoid the interrupt, or I can clear the interrupt flag in my code. But that's not a complete workaround, the plugin still won't wait for the thread to complete, and later build steps might run too soon.
I have an exec-maven-plugin java execution that works well when run via the
mvnCLI. But when run by vscode (where the plugin is called from the java language server via m2e), it doesn't run properly. AClosedByInterruptExceptionis triggered upon the first I/O operation. After some investigation I found that the execution thread is already interrupted before it enters my code.AbstractExecJavaBase.javacreates abootstrapThreadto run the exec class in. It then callsjoinNonDaemonThreadsto wait for that thread to finish. This assumes that the exec thread is not a daemon thread. But, threads inherit their daemon status from their parents, so if the plugin is run in a daemon thread, then the bootstrap thread will be a daemon thread. In that case it does not wait for the thread to finish and (whencleanupDaemonThreadsis true) it immediately callsterminateThreads, interrupting the exec thread.If the intention is for
bootstrapThread(and its children) to be joined injoinNonDaemonThreads, then I think the code should explicitly callbootstrapThread.setDaemon(false).Why is the plugin being run in a daemon thread? Well it seems that
JDTLanguageServerineclipse.jdt.lsusesCompletableFuturewithout an explicit executor for lots of build operations. These useForkJoinPool.commonPool(), in which all threads are initialized as daemon threads.cleanupDaemonThreadscan be set to false to avoid the interrupt, or I can clear the interrupt flag in my code. But that's not a complete workaround, the plugin still won't wait for the thread to complete, and later build steps might run too soon.