JDK-8289610 : Degrade Thread.stop
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-07-02
  • Updated: 2022-09-29
  • Resolved: 2022-09-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 20
20 b17Fixed
Related Reports
Blocks :  
CSR :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8289612 :  
JDK-8289613 :  
JDK-8289616 :  
JDK-8289617 :  
JDK-8293591 :  
JDK-8293592 :  
JDK-8293684 :  
JDK-8293810 :  
JDK-8293852 :  
JDK-8294271 :  
Description
Degrade Thread.stop to throw UOE unconditionally and deprecate, for removal, ThreadDeath.

Thread.stop is inherently unsafe and has been deprecated, along with Thread.stop(Throwable) and ThreadGroup.stop() since JDK 1.2. The "progress" on removing this feature to date is as follows:

- Thread.stop(Throwable) was degraded to throw UOE in Java 8
- Thread.stop(Throwable) was deprecated for removal in Java 9 (Enhanced deprecation did not exist in Java 8)
- Thread.stop(Throwable) was removed in Java 11

- ThreadGroup.stop() was deprecated for removal in Java 16
- ThreadGroup.stop() was degraded to throw UOE in Java 19

- The no-arg Thread.stop() was deprecated for removal in Java 18

The next step is to to degrade Thread.stop to throw UOE. This will require updates to JLS 11.1.3 and JVMS 2.10 where asynchronous exceptions are defined.

This change will have no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). The APIs can be used to cause an asynchronous exception as before.

Comments
Changeset: acd5bcfc Author: Alan Bateman <alanb@openjdk.org> Date: 2022-09-23 07:55:29 +0000 URL: https://git.openjdk.org/jdk/commit/acd5bcfc8897908d82e9008ee2def9476f046a4d
23-09-2022

Just to add to Stuart's comment about the references to ThreadDeath in com.google.common.base.Throwables. That appears to be code that hacks into a JDK internal class that existed in JDK 8 and older. The class does not exist in JDK 9 or newer.
15-09-2022

> A static analysis of 24753517 classes in 106889 artifacts in Maven Central found 624 usages of Thread.stop in 617 classes and 817 references to ThreadDeath in 801 classes. Of the 817 references to ThreadDeath in the corpus, about 690 of them are from the Google Guava library that has been copied or shaded into many different jar files. The uses occur in one class: com/google/common/base/Throwables (but note that this fully qualified class name is often renamed as part of the shading process). There are a couple uses of ThreadDeath in this file; one example is here: https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Throwables.java#L495 Essentially this code does some reflective operations and needs to handle exceptions; as part of this handling, it simply catches and rethrows ThreadDeath. The remaining uses of ThreadDeath are quite diffuse, but they are likely also to be catch/rethrow of ThreadDeath, as that was for some time a recommended exception handling idiom for code that otherwise catches Throwable.
14-09-2022

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10230 Date: 2022-09-09 12:44:31 +0000
13-09-2022

A static analysis of 24753517 classes in 106889 artifacts in Maven Central found 624 usages of Thread.stop in 617 classes and 817 references to ThreadDeath in 801 classes.
09-09-2022