Integrated: 8289610: Degrade Thread.stop
Alan Bateman
alanb at openjdk.org
Fri Sep 23 07:59:16 UTC 2022
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads.
>
> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them.
>
> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code.
This pull request has now been integrated.
Changeset: acd5bcfc
Author: Alan Bateman <alanb at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/acd5bcfc8897908d82e9008ee2def9476f046a4d
Stats: 341 lines in 26 files changed: 115 ins; 162 del; 64 mod
8289610: Degrade Thread.stop
Reviewed-by: rriggs, cjplummer, jpai, mchung, prr, mullan
-------------
PR: https://git.openjdk.org/jdk/pull/10230
More information about the serviceability-dev
mailing list