Hello everyone, To contribute to the discussion concerning Thread.stop(*) and its usefulness. I've implemented a JUnit test runner for Lucene/ Solr and we needed test suite isolation badly but at the same time wanted to reuse the same JVM (for performance reasons).
The initial implementation worked by detecting "leaked" threads (those started within a test suite and crossing its lifecycle boundary) and then tried to gracefully interrupt them; if this didn't help, an attempt to "kill" those threads was issued with a call to Thread.stop(). This works very well on small examples only. In practice what happens is: 1) you get loops with a catch (Throwable) inside; pretty much prevents the thread from being stopped (these we called ChuckNorris-type...), 2) threads going into native sections and hung there (not necessarily via JNI, even via system IO calls), Eventually we just dropped thread.stop altogether -- if a thread cannot be interrupted, it is considered a "zombie" and the test framework either proceeds or aborts entirely (depending on the configuration). So, based on this experience my point of view on the matter is that Thread.stop() is useless. For rethrowing checked exceptions you can use the generics-based sneaky throw. If you have control over the code of the threads you want to stop then you shouldn't use Thread.stop() anyway. For any code you don't have the control over it's not 100% reliable so I doubt its use is really fully justified. A much more needed addition to the standard library in place of Thread.stop() would be methods to acquire: 1) your own PID (this one is in planning for 1.8 or even has been added already), 2) forked process PID (?), 3) a way to kill the forked process (and possibly its sub-tree). These are platform-specific operations and the "workarounds" for these missing API calls are truly horrible, even if implemented nicely (see sources of Jenkins for example [1]). Dawid [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/util/ProcessTree.java#L501
