RFR: 8289610: Degrade Thread.stop [v4]

[Alan Bateman]

On Tue, 20 Sep 2022 04:21:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 12 additional commits since the last revision:
>> 
>>  - Merge
>>  - Updates to Java Thread Primitive Deprecation page
>>  - Repalce "it" with "victim thread"
>>  - Merge
>>  - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop
>>  - become -> became in javadoc
>>  - Merge
>>  - Remove stopThread permission from RuntimePermission table, exclude jshell tests
>>  - Deprecate for removal
>>  - Next iteration, update dates in headers
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/26f404b2...93806f99
>
> src/java.base/share/classes/java/io/FilterOutputStream.java line 195:
> 
>> 193:                    // evaluate possible precedence of flushException over closeException
>> 194:                    if ((flushException instanceof ThreadDeath) &&
>> 195:                        !(closeException instanceof ThreadDeath)) {
> 
> If the ThreadDeath originates from the debugger then this is now a change in behaviour.

> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places.

I've gone through a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed.  As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd libraries.

> Should this have always mentioned the possibility of TD coming from a debugger as well?

The debugger can cause any error or exception to be thrown so I don't think we should put anything in the TD spec about this.

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

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