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

[David Holmes]

On 7/06/2018 7:58 AM, Stuart Marks wrote:
> Serguei, great! Thanks.
> 
> All, I've updated the webrev to with changes to 
> threadPrimitiveDeprecation.html to remove the sections that mention the 
> removed methods.

That reads much better!

Thanks,
David

> http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.2/
> 
> s'marks
> 
> 
> On 6/6/18 2:37 PM, serguei.spitsyn at oracle.com wrote:
>> Stuart,
>>
>> Thank you for explanation!
>> I'm Okay with the fix it is now.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 6/6/18 14:02, Stuart Marks wrote:
>>> On 6/6/18 10:58 AM, serguei.spitsyn at oracle.com wrote:
>>>> But the fix below is not clear to me:
>>>>
>>>> http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/src/hotspot/share/prims/jvmti.xml.udiff.html
>>>>       <function id="StopThread" num="7">
>>>>         <synopsis>Stop Thread</synopsis>
>>>>         <description>
>>>> - Send the specified asynchronous exception to the specified thread
>>>> - (similar to <code>java.lang.Thread.stop</code>).
>>>> + Send the specified asynchronous exception to the specified thread.
>>>>           Normally, this function is used to kill the specified thread with an
>>>> - instance of the exception <code>ThreadDeath</code>.
>>>> + instance of the exception <code>ThreadDeath</code>, similar to
>>>> + <code>java.lang.Thread.stop</code>.
>>>>         </description>
>>>> A reference to the java.lang.Thread.stop has been removed in one 
>>>> place and added in another.
>>>> I thought, we wanted to get rid of these references in the spec.
>>>> Do I miss anything? Could you, explain this a little bit?
>>> Sure. The current state (through JDK 10) is that there two APIs:
>>>
>>>     1. Thread.stop(Throwable)
>>>     2. Thread.stop() // no-arg
>>>
>>> They are both deprecated, but only (1) is deprecated for removal, and 
>>> it's the one being removed by this changeset. Method (2) will remain 
>>> in the platform for the forseeable future.
>>>
>>> Method (1) causes the target thread asynchronously to throw the 
>>> argument, which can be an instance of any subtype of Throwable. 
>>> Method (2) causes the target thread to throw ThreadDeath (a subtype 
>>> of Error) asynchronously.
>>>
>>> The wording in the JVMTI doc isn't terribly explicit. The original 
>>> wording actually means "similar to Thread.stop(Throwable)" that is 
>>> method (1). My rewording places the mention of Thread.stop into the 
>>> context of throwing ThreadDeath, implying method (2). Since that will 
>>> be the only Thread.stop method remaining, there's no ambiguity. So 
>>> yes, the wording change looks odd, but there is a subtle shift in the 
>>> meaning, and I think the meaning is clear after (1) has been removed.
>>>
>>> But I can remove the "similar to Thread.stop" bit if you prefer.
>>>
>>> s'marks
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 6/5/18 17:05, Stuart Marks wrote:
>>>>> [adding serviceability-dev]
>>>>>
>>>>> Hi serviceability folks,
>>>>>
>>>>> I'm in the process of removing Thread.destroy() and 
>>>>> Thread.stop(Throwable) from the Java SE API. Alan and David have 
>>>>> pointed out that there are some cross-references to 
>>>>> Thread.stop(Throwable) in the JDWP and JVMTI specs, as well as in 
>>>>> the JDI ThreadReference API. I've adjusted the relevant files.
>>>>>
>>>>> See please review this updated webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/
>>>>>
>>>>> For context, please see the full review thread on core-libs-dev:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053536.html
>>>>>
>>>>>
>>>>>
>>>>> On 6/4/18 11:11 PM, Alan Bateman wrote:
>>>>>> The source file that is used to generate the JDWP protocol code 
>>>>>> and the spec is in make/data/jdwp/jdwp.spec. The JVM TI spec is at 
>>>>>> src/hotspot/share/prims/jvmti.xml. It should be okay to skip those 
>>>>>> for this change-set, assuming it is followed up quickly with 
>>>>>> another change-set to update those specs.
>>>>>
>>>>> OK. I took a look at those other files and they seem simple enough 
>>>>> to update as part of this changeset. If there aren't any objections 
>>>>> from anyone, might as well get this all done at once.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> s'marks
>>>>
>>>
>>
>