Saturday, June 9, 2018

Thread Methods destroy() and stop(Throwable) Removed in JDK 11

The message "RFR(s): 8204243: remove Thread.destroy() and Thread.stop(Throwable)" by @DrDeprecator (Stuart Marks) on the core-libs-dev OpenJDK mailing list is a request for review (RFR) of a change set associated with JDK-8204243 ["remove Thread.destroy() and Thread.stop(Throwable)"]. Both the bug report and the mailing list message describe the history of these two referenced Thread methods and explain that neither method really does anything useful.

The JDK 10 Javadoc API documentation for java.lang.Thread shows six methods on the Thread class that are deprecated, three of which are explicitly marked for removal. The table below summarizes these deprecated Thread methods.

Methods Deprecated in java.lang.Thread as of JDK 10
MethodDeprecated
Since
For
Removal?
JDK 10
Status
countStackFrames() 1.2 Yes Depends on deprecated suspend()
destroy() 1.5 Yes Throws NoSuchMethodError since inception
(never implemented)
resume() 1.2 No "Exists solely for use with suspend()"
stop() 1.2 No "This method is inherently unsafe."
stop(Throwable) 1.2 Yes Throws UnsupportedOperationException since JDK 8
suspend() 1.2 No "This method ... is inherently deadlock-prone."

It now appears that two of the three Thread methods that are deprecated and marked for removal will be removed with JDK 11. Both methods Thread.destroy() and Thread.stop(Throwable) should be completely removed as of JDK 11. The destroy() method has never done anything except throw the NoSuchMethodError and the stop(Throwable) method hasn't done anything except throw UnsupportedOperationException since JDK 8. Good riddance to these methods!

Additional References

3 comments:

@DustinMarx said...

It turns out that there are some "negative ramifications" of these methods being removed as documented on the Java subreddit. :)

Vipin kaushik Mangloria said...

Why not removing the methods that are deprecated even since java 1.2 like suspend()

@DustinMarx said...

Hello Vipin,

A deprecated method is less likely to be removed if it is determined that it is used by a lot of code. Deprecated methods that are determined to not be used or to be rarely used are more likely to be removed altogether. This approach reduces the chance of breaking backwards compatibility for too many developers. The most likely deprecated methods to actually get removed at some point are those which have been explicitly marked as "for removal" (enhanced deprecation) via the @Deprecation annotation. For example, the Java SE 10 API documentation for Thread indicates that the destroy() and stop(Throwable) methods were previously deprecated with explicit indication that they are deprecated "for removal" while other deprecated methods on that same class such as suspend(), resume(), and stop() are not explicitly marked for removal.