RFR(m): 8145468 deprecations for java.lang
stuart.marks at oracle.com
Mon Apr 18 21:53:03 UTC 2016
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.
More information about the core-libs-dev