On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman <al...@openjdk.org> wrote:

> The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since 
> JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to 
> throw UnsupportedOperationException unconditionally in Java 19/20.  Early in 
> Java 23 seems a fine time to finally remove these methods.
> 
> Corpus analysis of 176 million classes in 485k artifacts found no remaining 
> usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy 
> of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend 
> and 86 remaining usages of Thread.resume, some of these are tests.
> 
> Thread.suspend/resume have always linked to the "Java Thread Primitive 
> Deprecation" page. This originally explained the reasons why suspend/resume 
> were deprecated. When these methods were degraded to throw UOE we changed the 
> text to explain why the ability to suspend or resume a thread was removed. 
> Now we must change it again. One choice is to re-word to explain why the Java 
> APIs were removed or why the Java APIs don't define a way to suspend/resume 
> threads, the other choice (which I prefer) is to remove the text.
> 
> The method description of java.lang.management.ThreadInfo.isSuspended is 
> tweaked to link to JVMTI SuspendThread instead of Thread.suspend

Marked as reviewed by smarks (Reviewer).

Yeah, removing the text from the deprecation is reasonable. I expect that 
eventually the deprecation page will simply vanish when this is all over (I 
guess, after Thread.stop is finally removed).

Eventually somebody should write the definitive history of the Thread API.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16789#pullrequestreview-1753630611
PR Comment: https://git.openjdk.org/jdk/pull/16789#issuecomment-1830456956

Reply via email to