On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman <[email protected]> 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
