RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)

[Alan Bateman]

On 02/06/2018 06:45, David Holmes wrote:
> On 2/06/2018 11:07 AM, Stuart Marks wrote:
>> On 6/1/18 5:15 PM, David Holmes wrote:
>>> I would expect the CSR that marked them as deprecated for removal, 
>>> also serves for the actual removal. Certainly for VM flags we don't 
>>> do a separate CSR for each phase (deprecation, obsoletion, expiration).
>>
>> Hm. Well, this hasn't been tested for Java SE APIs yet, as most of 
>> the deprecations-for-removal occurred in Java SE 9, before the CSR 
>> was active. Instead, those deprecations went through the (Oracle 
>> internal) CCC process.
>>
>> Now that we're fully on the CSR system, I'd expect that deprecations 
>> (whether or not for removal) and removals of Java SE APIs would have 
>> separate CSR requests. The reason is that adding or changing a 
>> deprecation annotation is a spec change, and removing the API is a 
>> distinct spec change. They also occur in different releases.
>
> Good points. Though given the annotation is on the method being 
> removed it's really only one spec change.
Adding @Deprecated(forRemoval=true) in one release and then removing the 
element in a later release has to be tracked as two spec changes, and 
thus two CSRs. There may be more steps of course. In the case of 
Thread.stop(Throwable) under discussion here, and several 
SecurityManager methods, the methods were "degraded" (to always throw an 
exception or only check AllPermission in the case of the SM methods) 
before removal. So that's another intermediate spec change that has to 
be tracked via the CSR.

-Alan