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

Stuart Marks stuart.marks at oracle.com
Wed Jun 6 21:58:13 UTC 2018


Serguei, great! Thanks.

All, I've updated the webrev to with changes to threadPrimitiveDeprecation.html 
to remove the sections that mention the removed methods.

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
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180606/0ad061e8/attachment.html>


More information about the serviceability-dev mailing list