Time to put a stop to Thread.stop?

[Dr Heinz M. Kabutz]

Alan Bateman wrote:
> On 25/05/2013 12:35, Alan Bateman wrote:
>> On 24/05/2013 19:14, Martin Buchholz wrote:
>>> :
>>>
>>> Alan, you're telling everyone there's no need for Thread.stop, but 
>>> you are replacing usages in tests with calls to Unsafe, which is not 
>>> available to normal code.  So you have a kind of moral obligation 
>>> here to replace usages with "ordinary" java code.  There are other 
>>> ways to do sneakyThrow, and perhaps a sneakyRethrow method should be 
>>> added to the jdk test library.
>> For these the tests then it shouldn't really matter but if you or 
>> Doug would prefer if they are changed to use sneakyThrow then we can 
>> do that.
> Martin has pushed updates to the 4 tests to the jsr166 CVS so I'll 
> going to push these to jdk8/tl forest along with the Thread.stop changes.
I noticed the other day when using Java 8 that Thread.stop(Throwable) 
was throwing an UOE.  Unfortunately I missed the discussion in May 
amongst the thousands of other important JDK emails.  Thus I presume 
that nothing I might have to say on the matter would change what is 
currently in the OpenJDK ;-)  But I'd like to state it "for the record" 
anyway.

Throwing checked exceptions in an unchecked context is, IMHO, something 
one should almost never do, except maybe in test cases.  Up to now, I've 
known of quite a few ways to do this though:

1. Thread.stop(Throwable) with some mangling - see ThrowerConcurrent in 
http://www.javaspecialists.eu/archive/Issue144.html
2. Abusing generics
3. Class.newInstance(), described in Java Puzzlers 
(http://www.javaspecialists.eu/archive/Issue144.html)
4. Unsafe.throwException() similar to ThrowerConcurrent in #1.

Since this is something that we should not do anyway, it is no harm to 
remove one of the ways, this being Thread.stop(Throwable).

However, there is another use case.  If you cause a deadlock with 
ReentrantLock, you might be able to bust out of that by sending a 
DeadlockVictimError to one of the threads in the deadlock.  This would 
not work for threads deadlocked with synchronized.  I agree this is a 
rare situation and we should rather avoid the deadlock.  But it is 
useful to be able to do it.

Here are two newsletters where I write about this:

http://www.javaspecialists.eu/archive/Issue130.html
http://www.javaspecialists.eu/archive/Issue160.html

Now it is enough of an edge case that I can accept using 
Unsafe.throwException() as being the "proper" solution.  Since it is 
"unsafe", we might as well use that mechanism.  However, it is yet 
another temptation to use Unsafe, which, of course, we should avoid, 
seeing that it is, ahem, "unsafe" ;-)

Regards

Heinz