RFR(m): 8145468 deprecations for java.lang

[Stuart Marks]

On 4/17/16 4:05 PM, David Holmes wrote:
> On 14/04/2016 11:50 AM, Stuart Marks wrote:
>> The methods being deprecated with forRemoval=true are listed below. All
>> of these methods have already been deprecated. They are all ill-defined,
>> or they don't work, or they don't do anything useful.
>
> Surprised Thread.suspend/resume are not marked for removal given they are
> effectively unusable.

There's some rationale here. These methods (along with the no-arg Thread.stop()) 
have been deprecated for many years, since JDK 1.2 according to my research. 
Isn't it time to remove them?

Well, the fact is that they do perform their intended functions: suspend() and 
resume() really do suspend and resume the target thread, and stop() really 
causes the target thread to throw ThreadDeath. No doubt using these is unsafe. 
Using them involves either some risk of deadlock or data corruption, or using 
them in such a restricted fashion that the risk is mitigated.

In fact they do get a fair amount of use. It's not difficult to find a bunch of 
usages of them on grepcode.com. For example, Hadoop among other projects uses 
suspend/resume to test timeout handling code. I'm aware of frameworks that use 
stop() on runaway plugins in an attempt to initiate error recovery and an 
orderly shutdown. Clearly such usage isn't guaranteed to work, but it *might* 
work, and if so, it seems preferable to forcible termination of the entire JVM. 
That risk tradeoff is for the applications and frameworks to make.

With this in mind it's not obvious to me that suspend/resume/stop ought to be 
deprecated for removal.

This is certainly a worthwhile discussion to have. If someone has a pressing 
case to get rid of these, or perhaps just suspend/resume, by all means make it. 
I do think this should be considered separately from JDK-8145468, though.

s'marks