Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8293843

Degrade Thread.stop

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P4 P4
    • 20
    • core-libs
    • None
    • source, behavioral
    • medium
    • Hide
      Existing code that relies on Thread.stop will fail with UOE. A static analysis of 24M classes found 617 remaining usages of this method.

      A pattern seen in very old code is to catch Throwable and re-throw ThreadDeath. There will be a warning at compile-time if this code is re-compiled. It will run as before. The static analysis of 24M classes found 800 usages of ThreadDeath of which 690 were re-packaging of Google Guava code that re-throws ThreadDeath. The Google Guava usage is in code for JDK 8 or older.

      ThreadDeath has a public constructor so it has always been possible to construct/throw this Error outside of Thread.stop. This code will compile (with warnings), and run, as before. The compilation warning will serve to warn developers to use a different error or exception.
      Show
      Existing code that relies on Thread.stop will fail with UOE. A static analysis of 24M classes found 617 remaining usages of this method. A pattern seen in very old code is to catch Throwable and re-throw ThreadDeath. There will be a warning at compile-time if this code is re-compiled. It will run as before. The static analysis of 24M classes found 800 usages of ThreadDeath of which 690 were re-packaging of Google Guava code that re-throws ThreadDeath. The Google Guava usage is in code for JDK 8 or older. ThreadDeath has a public constructor so it has always been possible to construct/throw this Error outside of Thread.stop. This code will compile (with warnings), and run, as before. The compilation warning will serve to warn developers to use a different error or exception.
    • Java API
    • SE

      Summary

      Degrade Thread.stop() to throw UnsupportedOperationException (UOE) unconditionally. Deprecate the error ThreadDeath, for removal.

      Problem

      Thread.stop dates from JDK 1.0 as an API to "stop" a victim thread by causing the victim thread to throw the error ThreadDeath. It is inherently unsafe with all "stop" methods deprecated since JDK 1.2 with a link to the "Java Thread Primitive Deprecation" page that explains the reasoning for the deprecation.

      The recent steps on degrading and removing the feature are:

      • Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11.

      • ThreadGroup.stop() was degraded to throw UOE in Java 19.

      The remaining method is the no-arg Thread.stop(). This method is terminally deprecated since Java 18. In Java 19 it was specified to throw UOE when invoked on a virtual Thread.

      Solution

      • Degrade the no-arg Thread.stop to throw UOE.

      • Deprecate ThreadDeath, for removal.

      • Update the specification of ThreadGroup.uncaughtException to remove its special handling for ThreadDeath.

      • Remove the target permission name "stopThread" from the table of names in java.lang.RuntimePermission.

      The solution has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). The debugger APIs can still be used to send an asynchronous exception as before.

      Specification

      A zip file with the specdiffs is attached to this CSR.

      Asynchronous exceptions are described in JLS 11.1.3 and JVMS 2.10. A separate issue tracks the updates to the JLS and JVMS.

        1. specdiff-20220916.zip
          1.48 MB

            alanb Alan Bateman
            alanb Alan Bateman
            Mandy Chung (Inactive), Stuart Marks
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: