JavaShellToolBuilder lingering daemon threads

[Robert Field]

Thank you, Seth, for your detailed bug report.

I have created:

      JShell: JavaShellToolBuilder lingering daemon threads
      https://bugs.openjdk.java.net/browse/JDK-8210767

To track it.

Thanks again,
Robert


On 09/13/18 22:49, seth lytle wrote:
> when running:
>      mvn exec:java -Dexec.mainClass=Kshell
>
> with java 9, 10 or 11
>
> with a pom:
> <project>
>      <modelVersion>4.0.0</modelVersion>
>      <groupId>test</groupId>
>      <artifactId>test</artifactId>
>      <version>1</version>
>      <build>
>          <sourceDirectory>src</sourceDirectory>
>      </build>
>      <properties>
>          <maven.compiler.source>9</maven.compiler.source>
>          <maven.compiler.target>9</maven.compiler.target>
>      </properties>
> </project>
>
> and source:
> public class Kshell {
>      public static void main(String[] args) throws Exception {
>          jdk.jshell.tool.JavaShellToolBuilder.builder().run(args);
>      }
> }
>
> maven complains:
> jshell> /exit
> |  Goodbye
> [WARNING] thread Thread[Timer-0,5,Kshell] was interrupted but is still
> alive after waiting at least 15000msecs
> [WARNING] thread Thread[Timer-0,5,Kshell] will linger despite being asked
> to die via interruption
> [WARNING] thread Thread[Thread-2,5,Kshell] will linger despite being asked
> to die via interruption
> [WARNING] NOTE: 2 thread(s) did not finish despite being asked to  via
> interruption. This is not a problem with exec:java, it is a problem with
> the running code. Although not serious, it should be remedied.
>
>
>
> going through the debugger somewhat it looks like the first is created by
> Preferences and calling:
>          builder.persistence(new TreeMap());
> eliminates this warning (though not if called after the run finishes). the
> timer is stored in a static field, and due to the module system i don't
> think i can work around this with classloader magic
>
> the second thread appears to be the static field
> SourceCodeAnalysisImpl.INDEXER, and again, i don't see any cleanup logic
>
>
> workaround:
> for now i'm calling System.exit(0)