On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman <al...@openjdk.org> wrote:
> Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the > user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 > (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume > were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume > continues to work for platform threads but throws UOE for virtual threads. > The next step is to degrade both methods to throw UOE for all threads. A > corpus search of 19M classes in 113k JAR files found only 22 classes using > these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP > specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on > [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the > last few usages of Thread.suspend/resume from the hotspot tests (most of > these can use JVMTI SuspendThread/ResumeThread). One minor nit but otherwise looks good! Thanks. src/java.base/share/classes/java/lang/SecurityManager.java line 497: > 495: * <p> > 496: * This method is invoked for the current security manager by the > 497: * {@code stop}, {@code suspend}, {@code resume}, Why is stop being removed in this PR? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324
