I’m working on integrating ConcJUnit into DrJava (for after the upcoming stable release of DrJava and for my presentations at Rice and PPPJ), and I ran into an interesting issue.
I had a thread that I knew was outliving the test, so it should be flagged with a “no join” warning. However, inside DrJava it wasn’t. The reason was that the thread was a daemon thread, even though I hadn’t set it to be a daemon. I looked at the Java API source code and the Javadoc and found the following statement (emphasis mine):
When code running in some thread creates a new Thread object, the new
thread has its priority initially set equal to the priority of the
creating thread, and is a daemon thread if and only if the creating
thread is a daemon.
It seems like the thread in which the Interactions Pane runs is a daemon thread, and therefore by default all threads created in it are daemons. I am now wondering if we should change this and whether there are any reasons why we couldn’t. The notion of ignoring daemon threads otherwise seems sound for ConcJUnit, so I’d rather not lose it.
Update
I dealt with this internally in ConcJUnit for now, by setting the test thread to always be a non-daemon. It seems like RMI threads are always daemons. If we want to change the behavior and let threads created in the Interactions Pane be non-daemon threads by default (which is the behavior in stand-alone applications), then we probably have to create a helper thread, force it to be a non-daemon, run the interaction in it, and wait for it to complete.
