Deprecated Thread Methods

Question

My organization has recently come from the Microsoft world into the J2EE world. In .Net, Microsoft has an abort method on threads that is similar to the Java's stop method. Unfortunately, the stop method has been deprecated.
While I have read the information on why this method is dangerous, I don't understand why the method has been removed. If I have a situation that warrants killing a thread (such as in the case of an application server that hosts other threads of execution), why remove it from the platform? While I agree with Sun's article on seeking out alternative methods, there are still exceptions where a thread just needs to be interrupted so that it can get out of a deadlock, endless loop or blocking I/O.
Since the stop method is deprecated, is there an equivalent VM call that I can interface from native code?
I must say that I feel a bit like I'm being mothered by Sun.

Answer 1

From your comments, you make a strong argument that suggests there's no need for a VM-level stop function.
This puzzles me because operating systems implement kill methods to terminate rogue processes, yet they remain efficient and manage to keep things clean. Granted, multiple processes don't generally share memory structures but certainly the OS, on their behalf, shares memory structures. I'm puzzled as to why similar desires/features aren't present in the JRE.
Regardless, short of running multiple JRE instances, each managing just one piece of work, the current deprecated status of the stop method renders Java without the ability to stop something that's gone wild unless the application is specifically pre-programmed to anticipate this behavior. (Of course that's a bit of a catch 22 in and of itself but...)
There is also a subscription to the notion that my company or company x can write perfect software that never hangs a Java-based application server. I feel that this is impractical -- especially when what businesses ask of IT continues to get more complex.
At this point perhaps it's fair to reveal the underlying reasons for my up-to-now, hypothetical questions. In my situation, company x is actually Sun. They failed to expose a socket timeout on their implementation of HTTPUrlConnection. I suppose that pretty much removes the luster from the argument that I, or anyone else, can write perfect software when the inventors of Java are themselves, imperfect. Of course, like you said and the JDK documents, the stop method will not abort a blocking socket read anyway (...although there's no reason why it couldn't except for more flawed design decisions...)
I've certainly investigated alternative packages but I'm just chasing a moving target. HTTPUrlConnection today, class x tomorrow. That's why I was wanting something at the framework level to provide a trap door so that recovery without terminating the JRE is possible.