RFR: 8289610: Degrade Thread.stop [v2]

[Jaikiran Pai]

On Wed, 14 Sep 2022 14:09:52 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.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge
>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>  - Deprecate for removal
>  - Next iteration, update dates in headers
>  - Merge
>  - Initial commit

src/java.logging/share/classes/java/util/logging/LogManager.java line 2670:

> 2668:                 c.run();
> 2669:             } catch (ThreadDeath death) {
> 2670:                 throw death;

In theory, before this change, some (odd/weird) application code which was registered as a `listener` could throw a `ThreadDeath` and we would then abort any other `listeners` from being run. With this change that would no longer be that case. However, I think that is fine, since the API doc of `LogManager.addConfigurationListener()` already states:


* It is recommended that listeners do not throw errors or exceptions.
*
* If a listener terminates with an uncaught error or exception then
* the first exception will be propagated to the caller of
* {@link #readConfiguration()} (or {@link #readConfiguration(java.io.InputStream)})
* after all listeners have been invoked.

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

PR: https://git.openjdk.org/jdk/pull/10230