From darcy at openjdk.org  Thu Sep  1 05:23:25 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 05:23:25 GMT
Subject: RFR: JDK-8173605: Remove support for source and target 1.7 option
 in javac [v2]
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <PhjxTbUT9SG0f9E9xTuaJtcO2dXs2BXBUiykCQN0VR8=.e1d79c6c-208e-4aa9-bd60-266e6d387842@github.com>

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

Joe Darcy 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 27 additional commits since the last revision:

 - Update copyrights.
 - Delete unneeded test.
 - Merge branch 'master' into JDK-8173605
 - Merge branch 'master' into JDK-8173605
 - Small refactoring to remove more stale code.
 - Remove effectively dead code.
 - Adjust data for CheckExamples test.
 - Partial restore of DEFAULT_METHODS Source.Feature for test java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java.
 - Merge branch 'master' into JDK-8173605
 - Fix MultiReleaseJars.java.
 - ... and 17 more: https://git.openjdk.org/jdk/compare/a81a20ee...b2039d68

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10074/files
  - new: https://git.openjdk.org/jdk/pull/10074/files/f3095350..b2039d68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10074&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10074&range=00-01

  Stats: 14641 lines in 536 files changed: 4475 ins; 7382 del; 2784 mod
  Patch: https://git.openjdk.org/jdk/pull/10074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10074/head:pull/10074

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

From vromero at openjdk.org  Thu Sep  1 13:34:11 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 Sep 2022 13:34:11 GMT
Subject: RFR: JDK-8282434: Leading combining diacritic character in string
 renders incorrectly
In-Reply-To: <jB_MTXKRslgSgCkO-6-sLsoY42Xuc_-2nbnnC7CFGdA=.a1c8a419-b61e-4d90-9bab-f4d315f92b24@github.com>
References: <jB_MTXKRslgSgCkO-6-sLsoY42Xuc_-2nbnnC7CFGdA=.a1c8a419-b61e-4d90-9bab-f4d315f92b24@github.com>
Message-ID: <_3dedhTxh8GlJXryhMv5DLtI2A7zoF-uE9byhc3-094=.b09667f1-a3e7-4694-840c-d466b49b1838@github.com>

On Mon, 18 Jul 2022 14:34:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There's a group of characters, that add diacritics to the preceding character. JShell wraps String values into double quotes, and so when such a combining character is the first character of a string, there is a double quote followed by the diacritics. On some terminals, it may print the diacritics merged with the double quote.
> 
> Sadly, the behavior seems to differ much between terminals, so the proposal here is to use Unicode escape sequences for these characters when they would immediately follow the opening double quote. Sample output:
> $1 ==> "\u032Ea"

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.org  Thu Sep  1 16:46:21 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Sep 2022 16:46:21 GMT
Subject: Integrated: JDK-8173605: Remove support for source and target 1.7
 option in javac
In-Reply-To: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
References: <uDC2tcltL-cJGF3GsLILu3bF_V28ricJ9o-VHQxgBxA=.5279188b-36fc-4a63-b2b1-cb772826948f@github.com>
Message-ID: <gbPQrgcQ4ahoMdC7kieutONxygrBOxirKmi5HmDu-10=.d68cd13f-d992-443b-9353-2a19ef40cd8d@github.com>

On Tue, 30 Aug 2022 00:04:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update to remove support for -source/-target/--release 7 from javac.
> 
> As seen in the PR, many test fails are affected. Further refactorings of javac's implementation that can be made from dropping 7 support are left as future work.

This pull request has now been integrated.

Changeset: 2d18dda3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d18dda3f2074a4f8b9a0c62ece9ac6d5284e93b
Stats:     4595 lines in 156 files changed: 25 ins; 4413 del; 157 mod

8173605: Remove support for source and target 1.7 option in javac

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Fri Sep  2 21:19:11 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 21:19:11 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7
Message-ID: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>

This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?

TIA

[1] https://github.com/openjdk/jdk/pull/10074

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

Commit messages:
 - 8293051: Further refactor javac after removal of -source/-target/--release 7

Changes: https://git.openjdk.org/jdk/pull/10150/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293051
  Stats: 255 lines in 21 files changed: 10 ins; 198 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/10150.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10150/head:pull/10150

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

From vromero at openjdk.org  Fri Sep  2 21:35:46 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 21:35:46 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
Message-ID: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>

> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
> 
> TIA
> 
> [1] https://github.com/openjdk/jdk/pull/10074

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fixing additional test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10150/files
  - new: https://git.openjdk.org/jdk/pull/10150/files/331e4392..29f0b8a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10150&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10150&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10150.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10150/head:pull/10150

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

From darcy at openjdk.org  Fri Sep  2 21:46:00 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Sep 2022 21:46:00 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216:

> 214:         POLY(JDK8),
> 215:         LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL),
> 216:         DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL),

As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail.

I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too.

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

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

From vromero at openjdk.org  Fri Sep  2 21:54:43 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 Sep 2022 21:54:43 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
Message-ID: <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>

On Fri, 2 Sep 2022 21:42:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing additional test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216:
> 
>> 214:         POLY(JDK8),
>> 215:         LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL),
>> 216:         DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL),
> 
> As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail.
> 
> I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too.

that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`?

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

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

From darcy at openjdk.org  Fri Sep  2 23:24:53 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Sep 2022 23:24:53 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
Message-ID: <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>

On Fri, 2 Sep 2022 21:47:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 216:
>> 
>>> 214:         POLY(JDK8),
>>> 215:         LAMBDA(JDK8, Fragments.FeatureLambda, DiagKind.PLURAL),
>>> 216:         DEFAULT_METHODS(JDK8, Fragments.FeatureDefaultMethods, DiagKind.PLURAL),
>> 
>> As noted in https://github.com/openjdk/jdk/pull/10074#issuecomment-1230998246, if DEFAULT_METHODS is removed, there is a core libs test that will fail.
>> 
>> I believe the functionality request is a standard idiom for forcing a source file to be compiled as Preview. Merely setting -XDpreview (however that hidden option is spelled) is not sufficient. A feature that triggers a checkSourceLevel call is needed too.
>
> that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`?

Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area.

If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work.

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

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

From vromero at openjdk.org  Sat Sep  3 02:51:34 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 3 Sep 2022 02:51:34 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
 <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
Message-ID: <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>

On Fri, 2 Sep 2022 23:20:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> that can be worked out I think as I did with other tests, it should show up in the mach5 run, are you referring to: `PreviewHiddenClass.java`?
>
> Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area.
> 
> If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work.

all tier1-3 tests are passing in mach5

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

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

From darcy at openjdk.org  Sat Sep  3 16:34:31 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Sep 2022 16:34:31 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <sxlIH_5wLX99vToeTiz70ThFlwANYLc3y6Oh_X-y674=.8769ef12-3577-4f90-8d6f-c6839348274a@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

Marked as reviewed by darcy (Reviewer).

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

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

From darcy at openjdk.org  Sat Sep  3 16:34:32 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Sep 2022 16:34:32 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
 <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
 <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>
Message-ID: <IFkoBgh6IU7kuBYciLIi84lf0xlsfPfqGqlC7jUGOS8=.8b6fa695-f1f2-4ab7-a607-b022ba31a3e1@github.com>

On Sat, 3 Sep 2022 02:47:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Pretty sure the test in question was under java.lang.invoke in the libraries (i.e. test/jdk vs test/langtools) area.
>> 
>> If we come up for a supported idiom for this, there is at least one other test I'd want to update to use it; that can be done as future work.
>
> all tier1-3 tests are passing in mach5, I guess you were referring to: `test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java` which I have modified to play with records.

Sounds good.

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

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

From vromero at openjdk.org  Sat Sep  3 18:02:50 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 3 Sep 2022 18:02:50 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <IFkoBgh6IU7kuBYciLIi84lf0xlsfPfqGqlC7jUGOS8=.8b6fa695-f1f2-4ab7-a607-b022ba31a3e1@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <AshVsHQnBAxYTvg5r-QJYPZjhHqk3aumlHnXa1SH3jA=.35905544-5e9c-479e-a110-ce473934e7e9@github.com>
 <OyfwpNbj4lLbW5K14j2p75G1yk7-WER1dlqS5W3Y_uc=.a7a3537c-30ec-407d-84f0-95726733a5c5@github.com>
 <Zyvmc7YNwvrKu92KxdxTRpjjh9QKJ-6slVJxv25c8yw=.9d957eb0-6f20-4243-8129-2239b0ec74da@github.com>
 <bJkwLj2qAFEV908aXLrIG-k1NOzfwJXB5i4G3dzjDX8=.eaee3b50-46f4-421b-ac43-5db294ebe9af@github.com>
 <IFkoBgh6IU7kuBYciLIi84lf0xlsfPfqGqlC7jUGOS8=.8b6fa695-f1f2-4ab7-a607-b022ba31a3e1@github.com>
Message-ID: <HaP8pLGcbtPIdthPgH1P_9uUGDGS8Fucsdt4AuTzPzs=.7bf7f205-44ea-4ac1-9961-1b4a0b566b9b@github.com>

On Sat, 3 Sep 2022 16:30:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> all tier1-3 tests are passing in mach5, I guess you were referring to: `test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java` which I have modified to play with records.
>
> Sounds good.

thanks for the review

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

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

From asotona at openjdk.org  Mon Sep  5 12:49:20 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 12:49:20 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
Message-ID: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>

LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.

Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.

Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 

Please review.

Thanks,
Adam

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

Commit messages:
 - removed obsolete SuppressWarnings
 - 8289613: Drop use of Thread.stop in jshell

Changes: https://git.openjdk.org/jdk/pull/10166/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289613
  Stats: 54 lines in 2 files changed: 41 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10166.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10166/head:pull/10166

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

From alanb at openjdk.org  Mon Sep  5 13:21:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Sep 2022 13:21:34 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

This is the last usage of Thread.stop in the JDK so this change is welcome.

The instrumentation to check a flag at jump instrumentation looks reasonable, and works here because the method is public on a public class in an exported package. I hadn't noticed that jdk.jshell.execution is exported and the addition to LocalExecutionControl means it's a new API so I assume forces you to write javadoc.

If a user presses control-C in jshell does it also interrupt the thread or will it just set the stop flag? If it also interrupts then you have another choice to check the interrupt status (assumes all code is well behaved of course).

Is there one or many LocalExecutionControl objects when I execute a snippet, control-C, execute another? I'm wondering because the allStop flag is static but STOP_LOCK is per instance.

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

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

From forax at openjdk.org  Mon Sep  5 13:35:41 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 5 Sep 2022 13:35:41 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <tuc-oZZY8mb111gU6_rbv5xEFcNEEXbwpQtC5ZGyALY=.a7513ea3-a6ef-44f6-9a51-8f4928b8bb13@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

I've checked the code, same question as Alan, i believe you can have multiple instances of LocalExecutionControl, but `allStop` is a global flag.

Usually, the way to get an instance at runtime is either to use a ClassValue on the generated class or to store the instance in a ClassLoader and several one class loaders.
The last option is to pass an instance when defining a class, it only works with hidden classes, not normal classes but that code can be changed in the JDK.

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

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

From jlahoda at openjdk.org  Mon Sep  5 14:38:19 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Sep 2022 14:38:19 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <M-3gpFNgAjDQU4Z2yYzd3WFnrsJq3g1zzLgT8DD6Lzo=.29847941-eadf-491b-a0eb-c0cb5ac4d269@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

I believe that one instance of JShell will use only once instance of `ExecutionControl` at one time (although if it fails, it may spawn a new one). But there may be multiple instances of JShell at one time, so I suspect the static field on `LocalExecutionControl` won't work. I apologize for not realizing this sooner.

I think one way to resolve this is, for every `LocalExecutionControl` instance, synthesize a class, possibly named `REPL.$Cancel$`, which would hold the `allStop` field and the `stopCheck` method. This would then be load using the `LocalExecutionControl`'s `LoaderDelegate`, and used by the snippet.

A positive side-effect of this would be that we wouldn't need a new method in the public API, which I think would be preferred.

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

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

From forax at openjdk.org  Mon Sep  5 14:44:56 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 5 Sep 2022 14:44:56 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <LJOOVuo5TpZftXl_2b5YtHghXPv54_NkooDGJLWGU88=.68456000-3d98-4f98-8e56-448fd58dea33@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

yes, this is a good plan.

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

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

From asotona at openjdk.org  Mon Sep  5 14:44:56 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 14:44:56 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>
Message-ID: <x6K5mbGfTpCj17uacmEi4KzXdi716aLRGM2KZJohIlw=.fa7d68bb-db18-4493-948e-cbff8a6f0aee@github.com>

On Mon, 5 Sep 2022 13:18:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> This is the last usage of Thread.stop in the JDK so this change is welcome.
> 
> The instrumentation to check a flag at jump instrumentation looks reasonable, and works here because the method is public on a public class in an exported package. I hadn't noticed that jdk.jshell.execution is exported and the addition to LocalExecutionControl means it's a new API so I assume forces you to write javadoc.
> 
> If a user presses control-C in jshell does it also interrupt the thread or will it just set the stop flag? If it also interrupts then you have another choice to check the interrupt status (assumes all code is well behaved of course).
> 
> Is there one or many LocalExecutionControl objects when I execute a snippet, control-C, execute another? I'm wondering because the allStop flag is static but STOP_LOCK is per instance.

I think @AlanBateman proposal to monitor interrupted status is easy to implement and also does not require a new public method nor synthetic class.

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

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

From forax at openjdk.org  Mon Sep  5 15:00:32 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 5 Sep 2022 15:00:32 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <x6K5mbGfTpCj17uacmEi4KzXdi716aLRGM2KZJohIlw=.fa7d68bb-db18-4493-948e-cbff8a6f0aee@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <eukIvPsEpzdhKUSIVWmju1MrWq1XQ6GBU1uQHp-Z6oQ=.a625f68a-253f-4d9d-af45-b2caa0cbb309@github.com>
 <x6K5mbGfTpCj17uacmEi4KzXdi716aLRGM2KZJohIlw=.fa7d68bb-db18-4493-948e-cbff8a6f0aee@github.com>
Message-ID: <bQ2OxhjZUUZ3ll_eVy21MTuu7UjI5M3Gu1sD8WYKf8Q=.d961a06c-9e86-4260-9cd1-ef64c65ae91a@github.com>

On Mon, 5 Sep 2022 14:42:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is the last usage of Thread.stop in the JDK so this change is welcome.
>> 
>> The instrumentation to check a flag at jump instrumentation looks reasonable, and works here because the method is public on a public class in an exported package. I hadn't noticed that jdk.jshell.execution is exported and the addition to LocalExecutionControl means it's a new API so I assume forces you to write javadoc.
>> 
>> If a user presses control-C in jshell does it also interrupt the thread or will it just set the stop flag? If it also interrupts then you have another choice to check the interrupt status (assumes all code is well behaved of course).
>> 
>> Is there one or many LocalExecutionControl objects when I execute a snippet, control-C, execute another? I'm wondering because the allStop flag is static but STOP_LOCK is per instance.
>
> I think @AlanBateman proposal to monitor interrupted status is easy to implement and also does not require a new public method nor synthetic class.

@asotona, the problem is that user code may also react to the interrupted status,
the cancelling has be a mechanism a user can not trigger directly.

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

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

From mcimadamore at openjdk.org  Mon Sep  5 15:10:45 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 5 Sep 2022 15:10:45 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

Great cleanup - few test changes were not 100% clear to me, probably I'm missing some context.

test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31:

> 29: public interface HiddenInterface {
> 30:     default void test() {
> 31:         record R() {}

surprised to see this change

test/langtools/jdk/jshell/ToolEnablePreviewTest.java line 76:

> 74:     public void testCompilerTestFlagEnv() {
> 75:         test(new String[] {"-C", "-XDforcePreview"},
> 76:                 (a) -> assertCommandOutputContains(a, "Function<Integer,Integer> f = (var i) -> i + i",

surprised to see these changes

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

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

From asotona at openjdk.org  Mon Sep  5 15:53:32 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 15:53:32 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v2]
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  alternative implementation where instrumented code is directly checking Thread::interrupted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10166/files
  - new: https://git.openjdk.org/jdk/pull/10166/files/355ba7f7..0f0e0dd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=00-01

  Stats: 27 lines in 1 file changed: 17 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10166.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10166/head:pull/10166

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

From asotona at openjdk.org  Mon Sep  5 15:58:16 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 15:58:16 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v2]
In-Reply-To: <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
Message-ID: <zfChbHs9EqngR0b3GKMkuAPEpwKTfzDIoyyzCqiJU3I=.24036395-74b4-4250-af18-01e6a5e380c7@github.com>

On Mon, 5 Sep 2022 15:53:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   alternative implementation where instrumented code is directly checking Thread::interrupted

Right, let's try the synthetic class.

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

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

From alanb at openjdk.org  Mon Sep  5 18:05:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Sep 2022 18:05:46 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v2]
In-Reply-To: <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <R6D3ECyQWC7o_018IUo4wm4NpniQTdSWvLHRYPo2JlY=.40bdea3e-d024-4316-b777-b29ddf453575@github.com>
Message-ID: <49K0meTAqOz2xAWBvfP8sYwxjm8pZ-wT71N-KjpuRGA=.c8c743ce-be75-4e90-95c1-663ca334b943@github.com>

On Mon, 5 Sep 2022 15:53:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   alternative implementation where instrumented code is directly checking Thread::interrupted

LocalExecutionControl.stop invoking Thread::interrupt is good as that will cause any interruptible methods to wakeup.

I'm less sure about instrumenting every "if" and "goto" to invoke Thread::interrupted but more recent comment suggests are going back to a stop field that polled by code in a generated class so I'll wait until you are done.

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

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

From vromero at openjdk.org  Mon Sep  5 18:22:36 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 5 Sep 2022 18:22:36 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
Message-ID: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>

On Mon, 5 Sep 2022 15:04:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing additional test
>
> test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31:
> 
>> 29: public interface HiddenInterface {
>> 30:     default void test() {
>> 31:         record R() {}
> 
> surprised to see this change

this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature`

> test/langtools/jdk/jshell/ToolEnablePreviewTest.java line 76:
> 
>> 74:     public void testCompilerTestFlagEnv() {
>> 75:         test(new String[] {"-C", "-XDforcePreview"},
>> 76:                 (a) -> assertCommandOutputContains(a, "Function<Integer,Integer> f = (var i) -> i + i",
> 
> surprised to see these changes

similar as comment before `LAMBDA` is being removed but `VAR_SYNTAX_IMPLICIT_LAMBDAS` is still there

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

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

From asotona at openjdk.org  Mon Sep  5 19:23:30 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Sep 2022 19:23:30 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
 - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
   
   This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10166/files
  - new: https://git.openjdk.org/jdk/pull/10166/files/0f0e0dd1..30c34b6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=01-02

  Stats: 43 lines in 1 file changed: 33 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10166.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10166/head:pull/10166

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

From asotona at openjdk.org  Tue Sep  6 06:27:39 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 06:27:39 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
Message-ID: <9mnAHYpCi5pQB-I5e5UVcUga2hHb8Av5LtZsHv2SbdE=.6771eb0a-a309-4966-b4a7-702edecf2936@github.com>

On Mon, 5 Sep 2022 19:23:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>    
>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.

The latest version combines all comments. It instruments user code, delegates "allStop" to generated REPL.$Cancel$ class (loaded by specific LoaderDelegate), triggers REPL.$Cancel$.allStop and also interrupts all related threads to wake them up.

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

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

From forax at openjdk.org  Tue Sep  6 08:10:48 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 6 Sep 2022 08:10:48 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
Message-ID: <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>

On Mon, 5 Sep 2022 19:23:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>    
>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.

Otherwise, it looks good to me

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 98:

> 96:         var cancelWriter = new ClassWriter(ClassWriter.COMPUTE_FRAMES|ClassWriter.COMPUTE_MAXS);
> 97:         cancelWriter.visit(Opcodes.V19, Opcodes.ACC_PUBLIC, "REPL/$Cancel$", null, "java/lang/Object", null);
> 98:         cancelWriter.visitField(Opcodes.ACC_PUBLIC|Opcodes.ACC_STATIC|Opcodes.ACC_VOLATILE, "allStop", "Z", null, null);

fomatting: operators like '|' usually have a space before and a space after

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 119:

> 117:     protected String invoke(Method doitMethod) throws Exception {
> 118:         if (allStop == null) {
> 119:             super.load(new ClassBytecodes[]{genCancelClass()});

fomatting: usually, people use spaces like this

  new ClassBytecodes[] {  genCancelClass()  }

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 200:

> 198:                 allStop.set(null, true);
> 199:             } catch (IllegalArgumentException| IllegalAccessException ex) {
> 200:                 throw new InternalException(ex.getMessage());

to avoid to drop the stack trace of the original exception, it's better to chain the exceptions,

  throw (InternalException) new InternalException().initCause(ex);

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

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

From jlahoda at openjdk.org  Tue Sep  6 08:46:48 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Sep 2022 08:46:48 GMT
Subject: Integrated: JDK-8282434: Leading combining diacritic character in
 string renders incorrectly
In-Reply-To: <jB_MTXKRslgSgCkO-6-sLsoY42Xuc_-2nbnnC7CFGdA=.a1c8a419-b61e-4d90-9bab-f4d315f92b24@github.com>
References: <jB_MTXKRslgSgCkO-6-sLsoY42Xuc_-2nbnnC7CFGdA=.a1c8a419-b61e-4d90-9bab-f4d315f92b24@github.com>
Message-ID: <Z_ry5xiyk777GllMt0T9h9dRECYogpH2LceAUWT8hr0=.ac5a90ad-9721-40fc-8640-ffa888bc0c72@github.com>

On Mon, 18 Jul 2022 14:34:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There's a group of characters, that add diacritics to the preceding character. JShell wraps String values into double quotes, and so when such a combining character is the first character of a string, there is a double quote followed by the diacritics. On some terminals, it may print the diacritics merged with the double quote.
> 
> Sadly, the behavior seems to differ much between terminals, so the proposal here is to use Unicode escape sequences for these characters when they would immediately follow the opening double quote. Sample output:
> $1 ==> "\u032Ea"

This pull request has now been integrated.

Changeset: 49558352
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/495583524976fb63575b9a45f329e535e490dc80
Stats:     55 lines in 2 files changed: 36 ins; 0 del; 19 mod

8282434: Leading combining diacritic character in string renders incorrectly

Reviewed-by: vromero

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

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

From asotona at openjdk.org  Tue Sep  6 09:09:48 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 09:09:48 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
 <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
Message-ID: <eqNFeas5FsuQxyjzY2s30KyP33G_0qrhHoy57sxgpX4=.4fb677ec-34c0-49c8-821a-1412bf816f8c@github.com>

On Tue, 6 Sep 2022 08:04:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>>    
>>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 200:
> 
>> 198:                 allStop.set(null, true);
>> 199:             } catch (IllegalArgumentException| IllegalAccessException ex) {
>> 200:                 throw new InternalException(ex.getMessage());
> 
> to avoid to drop the stack trace of the original exception, it's better to chain the exceptions,
> 
>   throw (InternalException) new InternalException().initCause(ex);

I just followed similar pattern as in other 9 cases of throwing new InternalException in idk.jshell.

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

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

From asotona at openjdk.org  Tue Sep  6 09:14:47 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 09:14:47 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Minor formating fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10166/files
  - new: https://git.openjdk.org/jdk/pull/10166/files/30c34b6a..c6821bcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10166&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10166.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10166/head:pull/10166

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

From asotona at openjdk.org  Tue Sep  6 12:19:48 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Sep 2022 12:19:48 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
 <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
Message-ID: <w8DmLqW4p8GTY1WTT7YQ8kEsTKjW24ZLA6xMNhUr8Jw=.794f348f-0f27-4949-a0ac-3079c26f542c@github.com>

On Tue, 6 Sep 2022 08:06:13 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>>  - Revert "alternative implementation where instrumented code is directly checking Thread::interrupted"
>>    
>>    This reverts commit 0f0e0dd17c121955e7806073bb8cc78da1f133ea.
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 119:
> 
>> 117:     protected String invoke(Method doitMethod) throws Exception {
>> 118:         if (allStop == null) {
>> 119:             super.load(new ClassBytecodes[]{genCancelClass()});
> 
> fomatting: usually, people use spaces like this
> 
>   new ClassBytecodes[] {  genCancelClass()  }

Fixed, thanks

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

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

From alanb at openjdk.org  Wed Sep  7 18:25:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Sep 2022 18:25:43 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

Would it be possible to summarize how the loader delegate work in jshell? Instrumenting the code to invoke REPL/$Cancel$.stopCheck looks reasonable but I can't immediately see how the generated REPL/$Cancel$ has access to LocalExecutionControl.allStop.

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

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

From jlahoda at openjdk.org  Wed Sep  7 18:33:44 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Sep 2022 18:33:44 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <q8DOPk6Ycf_9z5nKNGVEVo8LnDvz2w8ltAPDMQBN75c=.7782cb28-e2ee-468f-b183-3d6270492908@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

Seems reasonable to me.

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

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

From jlahoda at openjdk.org  Wed Sep  7 18:37:43 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 Sep 2022 18:37:43 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>
Message-ID: <AM8OtPmjdxL4Py28hAqWUX-ZCRwFxJdl-Sd-dUSdxS8=.a229f2df-6b95-4ce6-b7e3-9f3014b89097@github.com>

On Wed, 7 Sep 2022 18:22:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to summarize how the loader delegate work in jshell? Instrumenting the code to invoke REPL/$Cancel$.stopCheck looks reasonable but I can't immediately see how the generated REPL/$Cancel$ has access to LocalExecutionControl.allStop.

Not sure what you mean - as far as I can tell, neither the generated class, nor the snippets access `LocalExecutionControl.allStop`. The snippets only access the generated class, and `LocalExecutionControl` sets the cancelled value into the generated class. And there is no problem accessing the generated class, as it is in the unnamed module and public.

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

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

From alanb at openjdk.org  Wed Sep  7 18:48:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Sep 2022 18:48:43 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <AM8OtPmjdxL4Py28hAqWUX-ZCRwFxJdl-Sd-dUSdxS8=.a229f2df-6b95-4ce6-b7e3-9f3014b89097@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <iefMarU77AZurBI9lsZ_41R22mUMZCx57rRfZ5xWXJw=.0f2c6377-3a6f-410c-bc94-a97a46b38317@github.com>
 <AM8OtPmjdxL4Py28hAqWUX-ZCRwFxJdl-Sd-dUSdxS8=.a229f2df-6b95-4ce6-b7e3-9f3014b89097@github.com>
Message-ID: <SW37eotjKyFHMChF5bYOn6OKeLbf39-epiZFTgEsej0=.c7eec432-0835-44f3-9f43-8a84162c67f3@github.com>

On Wed, 7 Sep 2022 18:35:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Not sure what you mean - as far as I can tell, neither the generated class, nor the snippets access `LocalExecutionControl.allStop`. 

Okay, I see it now. REPL.$Cancel$.allStop is public so there is no issue accessing it from LEC.invoke.

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

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

From duke at openjdk.org  Wed Sep  7 19:54:45 2022
From: duke at openjdk.org (ExE Boss)
Date: Wed, 7 Sep 2022 19:54:45 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 51:

> 49:     private boolean userCodeRunning = false;
> 50:     private ThreadGroup execThreadGroup;
> 51:     private Field allStop = null;

It?might be?better to?use a?`VarHandle` for?this (as?it doesn?t?need?boxing or?access?checks on?every?access).

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

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

From asotona at openjdk.org  Thu Sep  8 08:40:00 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Sep 2022 08:40:00 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>
Message-ID: <VO8VdoA35Yy2fWDDMRhf9aJVCrj0yRn8ByMchEX_jHc=.31517850-2a93-4aa2-9d75-bf2de3a76cc0@github.com>

On Wed, 7 Sep 2022 19:48:56 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor formating fixes
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 51:
> 
>> 49:     private boolean userCodeRunning = false;
>> 50:     private ThreadGroup execThreadGroup;
>> 51:     private Field allStop = null;
> 
> It?might be?better to?use a?`VarHandle` for?this (as?it doesn?t?need?boxing or?access?checks on?every?access).

According to javadoc VarHandle of static field "effectively ignore the volatile declaration".
Volatility of REPL.$Cancel.allStop field is critical for this use case.

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

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

From asotona at openjdk.org  Thu Sep  8 08:40:00 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Sep 2022 08:40:00 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v3]
In-Reply-To: <eqNFeas5FsuQxyjzY2s30KyP33G_0qrhHoy57sxgpX4=.4fb677ec-34c0-49c8-821a-1412bf816f8c@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <nVWcamwX-PTcahYaIcHpHGoo2a5ItBrVNW9ImSd5RvM=.214ebaf8-ad2d-4348-8acc-b74d4e03f175@github.com>
 <MHUPVdtqnKJo50BP3ByLUKLPHa49SbTt8lkZjrmtvHM=.35ee2523-330a-4747-925a-c79117d5adef@github.com>
 <eqNFeas5FsuQxyjzY2s30KyP33G_0qrhHoy57sxgpX4=.4fb677ec-34c0-49c8-821a-1412bf816f8c@github.com>
Message-ID: <c-KjQfLp_Vn_r2kK-D7RKWpbWuN8CnHQkast3TXChsA=.a0f28368-0568-4be4-89b8-e33ad38bebfa@github.com>

On Tue, 6 Sep 2022 09:05:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 200:
>> 
>>> 198:                 allStop.set(null, true);
>>> 199:             } catch (IllegalArgumentException| IllegalAccessException ex) {
>>> 200:                 throw new InternalException(ex.getMessage());
>> 
>> to avoid to drop the stack trace of the original exception, it's better to chain the exceptions,
>> 
>>   throw (InternalException) new InternalException().initCause(ex);
>
> I just followed similar pattern as in other 9 cases of throwing new InternalException in idk.jshell.

Adjusted exception message construction to exactly match other cases.

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

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

From alanb at openjdk.org  Thu Sep  8 08:51:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Sep 2022 08:51:53 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <VO8VdoA35Yy2fWDDMRhf9aJVCrj0yRn8ByMchEX_jHc=.31517850-2a93-4aa2-9d75-bf2de3a76cc0@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
 <6WDxkch-eI0hI2WF0ZbWcCrC3E96fZoFKLuye2dGjLk=.bc1c79c3-e7d2-4a1c-9ec1-27285141f806@github.com>
 <VO8VdoA35Yy2fWDDMRhf9aJVCrj0yRn8ByMchEX_jHc=.31517850-2a93-4aa2-9d75-bf2de3a76cc0@github.com>
Message-ID: <O3BQ14WJo_eD5koxEhIis-MY4ri9P6BpV9HfdfSOpBI=.20b41057-0373-4a58-a2ec-2aa17b80100c@github.com>

On Thu, 8 Sep 2022 08:34:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> According to javadoc VarHandle of static field "effectively ignore the volatile declaration".
> Volatility of REPL.$Cancel.allStop field is critical for this use case.

VarHandles defines xxxVolatile so it would be feasible but I don't see a strong need to change it as the reflective op is only done at the start to reset "stop" and when control-C/stop is done.

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

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

From jlahoda at openjdk.org  Thu Sep  8 09:53:34 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Sep 2022 09:53:34 GMT
Subject: RFR: 8289613: Drop use of Thread.stop in jshell [v4]
In-Reply-To: <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
 <xrJWvyFSxCoKKFHL5TunUs-Gdr7cZJqp6zG-6UgyGOA=.61545fcd-8e13-4f31-9d6f-19a783eb4ed5@github.com>
Message-ID: <Ybp8lCA2bBRkAy786RW9bJNXhuzu7w4YHnGre2x_3RA=.1cd00c92-458d-4ca2-b2a9-1e476de391b3@github.com>

On Tue, 6 Sep 2022 09:14:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
>> 
>> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
>> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
>> 
>> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor formating fixes

Marked as reviewed by jlahoda (Reviewer).

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

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

From asotona at openjdk.org  Thu Sep  8 10:06:47 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Sep 2022 10:06:47 GMT
Subject: Integrated: 8289613: Drop use of Thread.stop in jshell
In-Reply-To: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
References: <4lpVQSiW8vgB8YgsopNLFBshvgfn2tHxCOrCdm2v2T4=.fffeead5-a927-4587-8144-6d89c717ee47@github.com>
Message-ID: <9SQ5u6EHSaEdUMrd0_i598-6OcfrKuhT-DbJgfbASek=.88fa004f-d99e-4f1b-947a-3e9635a0e6e3@github.com>

On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel execution of (long-running or infinite loops) user code in JShell, however Thread::stop is deprecated and planned for removal.
> 
> Proposed patch instruments all user code to call LocalExecutionControl::stopCheck method before every branch instruction.
> Thread::stop call is replaced by setting global field LocalExecutionControl.allStop to true and stopCheck method then throws ThreadDead when called from the instrumented code.
> 
> Proposed patch requires jdk.jshell access to java.base jdk.internal.org.objectweb.asm package. 
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ffc249ae
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffc249ae2120752a9c0e9de18167b0c16f2de410
Stats:     71 lines in 2 files changed: 67 ins; 1 del; 3 mod

8289613: Drop use of Thread.stop in jshell

Reviewed-by: jlahoda

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

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

From mcimadamore at openjdk.org  Thu Sep  8 13:04:48 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Sep 2022 13:04:48 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
Message-ID: <oCSb7On3WWM1Nk-yaUSbh9MjkyPxMq534sOnKYeE4TQ=.f806313c-109e-4c45-820e-1ee67cc68d8b@github.com>

On Fri, 2 Sep 2022 21:35:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
>> 
>> TIA
>> 
>> [1] https://github.com/openjdk/jdk/pull/10074
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing additional test

Marked as reviewed by mcimadamore (Reviewer).

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

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

From mcimadamore at openjdk.org  Thu Sep  8 13:04:49 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Sep 2022 13:04:49 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
 <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>
Message-ID: <FXaMGUF_vi6NcrAS4G67UoDMQsuxZFSXMSPPTJujn3c=.dc1437e2-61aa-4ce9-9b9e-81757c8bd672@github.com>

On Mon, 5 Sep 2022 18:19:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/defineHiddenClass/src/HiddenInterface.java line 31:
>> 
>>> 29: public interface HiddenInterface {
>>> 30:     default void test() {
>>> 31:         record R() {}
>> 
>> surprised to see this change
>
> this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature`

I see. I understand what the fix does then.
I wonder if, moving forward, it wouldn't be better to tweak the semantics of forcePreview so that it always pollutes the classfile not matter what (which seems to be what some of the tests want). Otherwise we're stuck with these fragile tricks of using this or that feature to force javac's preview system into submission.

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

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

From vromero at openjdk.org  Thu Sep  8 14:24:52 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 Sep 2022 14:24:52 GMT
Subject: RFR: 8293051: Further refactor javac after removal of
 -source/-target/--release 7 [v2]
In-Reply-To: <FXaMGUF_vi6NcrAS4G67UoDMQsuxZFSXMSPPTJujn3c=.dc1437e2-61aa-4ce9-9b9e-81757c8bd672@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
 <Zd9m1DtvqOf4HTN1lwvbQOyc2G9sipkYOx5TAhhdsyQ=.f112171e-9621-4855-bcf7-32c1e3f7cc4b@github.com>
 <gL8iPFAP7iwhdQLT9H1XRNPox86y_tMpl7U_KEx8ZxY=.45999823-2dd3-49fa-b900-78228a5b683d@github.com>
 <9KXVsDqsx80E9jZehI4FT1cCserrTHG-16iCakaPLvI=.59431db9-b35f-416f-ae33-b2b1d34d1918@github.com>
 <FXaMGUF_vi6NcrAS4G67UoDMQsuxZFSXMSPPTJujn3c=.dc1437e2-61aa-4ce9-9b9e-81757c8bd672@github.com>
Message-ID: <ulo5n5x6SyQpzCXRN7-uMC9soHdTEovoS3R0Zvb7jxQ=.a9a6622d-3aca-4842-bace-7ca47a6a069d@github.com>

On Thu, 8 Sep 2022 13:02:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> this is was done because test: `test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java` is compiling this code with options `--enable-preview -source [latestSource] -XDforcePreview` and then checking that the obtained class file has 65535 as its minor version. This was working so far as `DEFAULT_METHODS` was one member of `com.sun.tools.javac.code.Source.Feature` but as this PR is removing `DEFAULT_METHODS` we are obtaining the same effect defining a record as `RECORDS` are still defined in `com.sun.tools.javac.code.Source.Feature`
>
> I see. I understand what the fix does then.
> I wonder if, moving forward, it wouldn't be better to tweak the semantics of forcePreview so that it always pollutes the classfile not matter what (which seems to be what some of the tests want). Otherwise we're stuck with these fragile tricks of using this or that feature to force javac's preview system into submission.

yes that would be a sensible change going forward. Thanks for the review

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

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

From vromero at openjdk.org  Thu Sep  8 14:39:05 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 Sep 2022 14:39:05 GMT
Subject: Integrated: 8293051: Further refactor javac after removal of
 -source/-target/--release 7
In-Reply-To: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
References: <qilx6l-_MKDKlL0uYwEhwF8wvirIzAMX7os6UvEE8RY=.2af39a64-722c-4afa-92e7-d118bea70a8d@github.com>
Message-ID: <nvLLOO0-QOz-Nf2gZV2-CQ5hwKJxhqxscVhGDUInY8s=.3f56391c-8f44-45e3-99f0-ab7607c085a3@github.com>

On Fri, 2 Sep 2022 21:11:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is a continuation of PR [1] which removed support for source and target 1.7 option in javac. This is is removing additional switches in javac that were providing support to legacy behavior related to source and target 1.7. What else could be missing?
> 
> TIA
> 
> [1] https://github.com/openjdk/jdk/pull/10074

This pull request has now been integrated.

Changeset: 46e6e41b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46e6e41b9a35c8665eb31be2f8c36bbdcc90564a
Stats:     256 lines in 22 files changed: 11 ins; 198 del; 47 mod

8293051: Further refactor javac after removal of -source/-target/--release 7

Reviewed-by: darcy, mcimadamore

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

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

From jlahoda at openjdk.org  Thu Sep  8 16:54:16 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 8 Sep 2022 16:54:16 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
Message-ID: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>

Consider this snippet sent to JShell:

interface I {
    void test() {
        try {
        } catch (IllegalStateException ex) {
            throw new RuntimeException(ex);
        }
    }
}


This leads to a crash:

Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
        at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
        at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
        at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
        at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
        at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
        at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
        at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
        at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
        at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
        at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
        at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
        at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
        at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
        at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
        at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
        ... 18 more
Caused by: java.lang.StackOverflowError
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
        at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
...


The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.

The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

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

Commit messages:
 - 8292755: Non-default method in interface leads to a stack overflow in JShell

Changes: https://git.openjdk.org/jdk/pull/10221/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292755
  Stats: 194 lines in 3 files changed: 185 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10221.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10221/head:pull/10221

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

From vromero at openjdk.org  Mon Sep 12 15:17:50 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Sep 2022 15:17:50 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output

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

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

From jlahoda at openjdk.org  Tue Sep 13 09:31:12 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 Sep 2022 09:31:12 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
 <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>
Message-ID: <ykq4IhuxXqh45UBQ9sBBptSA-aYnXxsZPJPyh6vpgY8=.76e66f44-2fdb-4cd2-b43c-1499edef7e74@github.com>

On Mon, 12 Sep 2022 15:15:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output

Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like:


$ cat Test.java 
public interface Test {
    default void test(Unknown1 t) {
        Unknown2 tt;
    }
}
$ javac Test.java 
Test.java:2: error: cannot find symbol
    default void test(Unknown1 t) {
                      ^
  symbol:   class Unknown1
  location: interface Test
Test.java:3: error: cannot find symbol
        Unknown2 tt;
        ^
  symbol:   class Unknown2
  location: interface Test
2 errors


I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods.

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

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

From alanb at openjdk.org  Tue Sep 13 13:17:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 13:17:34 GMT
Subject: RFR: 8289610: Degrade Thread.stop
Message-ID: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>

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.

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

Commit messages:
 - Deprecate for removal
 - Next iteration, update dates in headers
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10230/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289610
  Stats: 311 lines in 23 files changed: 114 ins; 147 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

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

From duke at openjdk.org  Tue Sep 13 13:17:35 2022
From: duke at openjdk.org (ExE Boss)
Date: Tue, 13 Sep 2022 13:17:35 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <R3vbwdphf7LyGlOStrdg-vizkYQ6WooThta7Utu_ntE=.39121758-eff2-4992-aaad-875e1fdfcfae@github.com>

On Fri, 9 Sep 2022 12:44:31 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.

src/java.base/share/classes/java/lang/ThreadDeath.java line 42:

> 40:  */
> 41: @Deprecated(since="20")
> 42: public class ThreadDeath extends Error {

Actually, `ThreadDeath` is?thrown?manually by?**JShell** instrumentation?code since?[JDK?8289613] ([GH?10166])[^1].

[JDK?8289613]: https://bugs.openjdk.org/browse/JDK-8289613
[GH?10166]: https://github.com/openjdk/jdk/pull/10166
[^1]: https://github.com/openjdk/jdk/blob/00befddd7ce97d324250807824469daaa9434eef/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java#L104-L107

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

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

From vromero at openjdk.org  Tue Sep 13 13:44:00 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 Sep 2022 13:44:00 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <6_eEE5ZIEpezCdN-BuYozkoq9B-Hl8cNKYmSj_LX6Z0=.43ad170e-854f-4c7a-addf-c3f21344a766@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.org  Tue Sep 13 13:44:00 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 Sep 2022 13:44:00 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <ykq4IhuxXqh45UBQ9sBBptSA-aYnXxsZPJPyh6vpgY8=.76e66f44-2fdb-4cd2-b43c-1499edef7e74@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
 <7sk_hL2isViH0ozSJXmAj7HC9XMxCGwgpVLZresO35A=.45f153c6-fd1b-497d-8cdd-347d9ea8fca1@github.com>
 <ykq4IhuxXqh45UBQ9sBBptSA-aYnXxsZPJPyh6vpgY8=.76e66f44-2fdb-4cd2-b43c-1499edef7e74@github.com>
Message-ID: <Lr-Tsx6OA9Hwqg1zfeIeL9ysShpNxnA8EP1sQ2p32fs=.d134a4c3-081b-460c-af57-52a796dc3bfa@github.com>

On Tue, 13 Sep 2022 09:27:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output
> 
> Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like:
> 
> ```
> $ cat Test.java 
> public interface Test {
>     default void test(Unknown1 t) {
>         Unknown2 tt;
>     }
> }
> $ javac Test.java 
> Test.java:2: error: cannot find symbol
>     default void test(Unknown1 t) {
>                       ^
>   symbol:   class Unknown1
>   location: interface Test
> Test.java:3: error: cannot find symbol
>         Unknown2 tt;
>         ^
>   symbol:   class Unknown2
>   location: interface Test
> 2 errors
> ```
> 
> I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods.

I see your point, totally agree

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

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

From rriggs at openjdk.org  Tue Sep 13 14:12:48 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Sep 2022 14:12:48 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>

On Fri, 9 Sep 2022 12:44:31 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.

core-libs parts look fine.

src/java.base/share/classes/java/lang/Thread.java line 1635:

> 1633:      *
> 1634:      * @throws  UnsupportedOperationException
> 1635:      *          always

fold with previous line.

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

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

From cjplummer at openjdk.org  Tue Sep 13 17:50:55 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 Sep 2022 17:50:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <8ZLJ1_MCq61Of0Jb2zUNFDskX7BYN1LFwGQ3JGSPcUQ=.f971b32e-491d-400d-bced-c13aabc30a0f@github.com>

On Fri, 9 Sep 2022 12:44:31 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.

serviceability changes look good

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

Marked as reviewed by cjplummer (Reviewer).

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

From mullan at openjdk.org  Tue Sep 13 19:01:51 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 13 Sep 2022 19:01:51 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>

On Fri, 9 Sep 2022 12:44:31 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.

What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change?

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

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

From eosterlund at openjdk.org  Tue Sep 13 19:09:42 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Sep 2022 19:09:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>

On Fri, 9 Sep 2022 12:44:31 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.

There is a bunch of VM code for this too. Should we clean that up separately?

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

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

From alanb at openjdk.org  Tue Sep 13 19:17:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 19:17:45 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
Message-ID: <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>

On Tue, 13 Sep 2022 19:06:14 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> There is a bunch of VM code for this too. Should we clean that up separately?

Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too.

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

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

From eosterlund at openjdk.org  Tue Sep 13 19:17:46 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 13 Sep 2022 19:17:46 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <NvkrIiKWBp863qr4zH4amdPEXgnWp64PdDnOjoab5Bs=.ac39b71a-f73b-442b-ad1e-978c186aa77f@github.com>
 <yNN_3wT_cFTtm-ZmdtbtxVE0HiHT9HKcdVYe6eV_Gn4=.f5b40a33-284f-4577-bfa3-bf9ceaaa0ef4@github.com>
Message-ID: <o-0jNj4vm7C4U-FuAnD5XzemL-oal-x-flVVPk-oyow=.e35d8591-8312-4f5d-9068-1092f4112e29@github.com>

On Tue, 13 Sep 2022 19:12:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > There is a bunch of VM code for this too. Should we clean that up separately?
> 
> 
> 
> Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too.

Sounds good.

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

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

From alanb at openjdk.org  Tue Sep 13 19:17:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Sep 2022 19:17:47 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <FccBcuRP60nXHjvizhgiU_wr0QoD7vP6ZsJJYsdheLU=.0a392f5f-f3d7-4a28-9183-d1f6a8bfc29f@github.com>
Message-ID: <g0EEBLhi7sK7lvdB8ocA1pzZungwW5grIhxctMyaiQ0=.e70a7f68-a282-4926-a40d-81836c488270@github.com>

On Tue, 13 Sep 2022 18:57:34 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change?

Ah yes, the table RuntimePermission can be updated as part of this (and the corresponding constant in sun/security/util/SecurityConstants).

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

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

From mchung at openjdk.org  Tue Sep 13 23:54:31 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Sep 2022 23:54:31 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>

On Fri, 9 Sep 2022 12:44:31 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.

The change looks good.   There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc.    Is it expected to update them in a follow-on issue?

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

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

From jlahoda at openjdk.org  Wed Sep 14 08:53:32 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Sep 2022 08:53:32 GMT
Subject: RFR: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <EwvsUISxXJN2tifqc7y6rR9kM719wnMOzdxKd56Ef58=.4f2fa3e7-baaf-4019-966f-ecf3d6c1c759@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

Thanks, Vicente!

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

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

From jlahoda at openjdk.org  Wed Sep 14 08:53:33 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Sep 2022 08:53:33 GMT
Subject: Integrated: 8292755: Non-default method in interface leads to a stack
 overflow in JShell
In-Reply-To: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
References: <bMhwY3_KoHiW81MnHoQIm_Xaw5ohAzcUk79CQ2SPPVQ=.e2ce538a-5fee-454b-b10f-bc5a2f5a9eba@github.com>
Message-ID: <htAaWqklZM-EENEx9IruqFGP-xGfKBfHnce63sZWZcE=.802ffb2c-190f-40f1-936c-b868a8051bd9@github.com>

On Thu, 8 Sep 2022 16:46:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this snippet sent to JShell:
> 
> interface I {
>     void test() {
>         try {
>         } catch (IllegalStateException ex) {
>             throw new RuntimeException(ex);
>         }
>     }
> }
> 
> 
> This leads to a crash:
> 
> Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.StackOverflowError
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
>         at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>         at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)
>         at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:161)
>         at jdk.jshell/jdk.jshell.Eval.compileAndLoad(Eval.java:1060)
>         at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:893)
>         at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:140)
>         at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3622)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1347)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1245)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1216)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1000)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>         at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> Caused by: java.lang.IllegalStateException: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
>         at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:412)
>         ... 18 more
> Caused by: java.lang.StackOverflowError
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSuperType(Types.java:1304)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1086)
>         at jdk.compiler/com.sun.tools.javac.code.Types.isSubtype(Types.java:1077)
> ...
> 
> 
> The reason is as follows: when javac's `Attr` sees a method, it checks its modifiers, and if there's a e.g. non-default method with a body in an interface, it won't attribute the body. But, JShell asks javac to go to `Flow`, so `Attr.postAttr` will fill some stub data. But the stub data then lead `Flow` to the stack overflow when checking thrown exceptions.
> 
> The proposed fix is to attribute method bodies even if the modifiers are wrong. The proper errors are reported as before, of course, but in addition the body is attributed, so that JShell and other clients can work with the body.

This pull request has now been integrated.

Changeset: 2a387918
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a3879180e63aa0a7a19479f061fe78d7885da7b
Stats:     194 lines in 3 files changed: 185 ins; 8 del; 1 mod

8292755: Non-default method in interface leads to a stack overflow in JShell

Reviewed-by: vromero

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

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

From alanb at openjdk.org  Wed Sep 14 14:09:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:52 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/380e4043..86424b65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=00-01

  Stats: 2990 lines in 108 files changed: 2115 ins; 353 del; 522 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

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

From alanb at openjdk.org  Wed Sep 14 14:09:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop
In-Reply-To: <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <GUqUvGAgZaq3V6d7zLstLPcnDXJfC3Tn9nJ7FKCP4Is=.5d7a18f1-55fb-45f6-81e3-9a1372832d38@github.com>
Message-ID: <Y68P0aWEnsCoTeHVCyMDGD0YSkvUA6Z2Szi8wKNqsZw=.bcff87c3-29b9-4c42-b84a-200d9e6efd5f@github.com>

On Tue, 13 Sep 2022 23:51:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The change looks good. There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc. Is it expected to update them in a follow-on issue?

I've been trying to keep the test cleanup separate if possible, only because the changes become unwieldy. Aside from jshell, the tests that used Thread.stop have already been changed or removed in advance of this PR. The tests that have catch blocks for ThreadDeath will work as before as there is no Thread.stop. There are one or two tests that will need special attention - the reactivestreams-tck tests that you listed is 3rd party code and we might decide to do nothing there.

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

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

From alanb at openjdk.org  Wed Sep 14 14:09:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:09:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aJKDQu_rOWDcc8-F2LXmygH9d-QBKSd5NOEAlUVI7lQ=.6235cad5-1193-4bc6-89ff-edbf75be21db@github.com>
Message-ID: <Cam8C9hPg7hx4THYlkkTjowCfvLTS_lDEFG5LdIeEHI=.62bf0954-d2fc-4991-8152-305329f2b38a@github.com>

On Tue, 13 Sep 2022 14:03:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> fold with previous line.

Done.

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

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

From jpai at openjdk.org  Wed Sep 14 14:24:42 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 14:24:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>

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

The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?

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

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

From jpai at openjdk.org  Wed Sep 14 14:29:11 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 14:29:11 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <fPWT9f28uph0lYEBP7BTDEnQLASgOa6ZRln7P0ITZd4=.854a1da6-21e1-4467-97a0-c9b17fefaacc@github.com>

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

From alanb at openjdk.org  Wed Sep 14 14:38:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Sep 2022 14:38:41 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
 <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
Message-ID: <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>

On Wed, 14 Sep 2022 14:21:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?

Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly.

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

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

From jpai at openjdk.org  Wed Sep 14 15:26:41 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 15:26:41 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <S2NGdOvBFqHCU3kZ71lO-pI_be3rgiAjWyLymGkl7IQ=.f5c55647-8862-4b3f-a1cc-c9bcb74ffaf9@github.com>

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

Marked as reviewed by jpai (Reviewer).

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

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

From jpai at openjdk.org  Wed Sep 14 15:26:42 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Sep 2022 15:26:42 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
 <mpzUIufncDST2C3xklaTg_IzMRpfF3BRD8VHQs2W0E4=.c41ae0b2-450c-4345-a551-3b2ca3c37b3e@github.com>
 <V5ZUDTNRCBqbJFWqfiDZthxL-c6rdpf9YvNrcKa3OJs=.ac4dbf11-de65-4981-b0bd-719a969cb30e@github.com>
Message-ID: <zqC1A9QUMyPBsucqh-ACPnCgu9NGXHuYEoIQVGocNDo=.aabd8baa-d81e-4c26-acd3-fad2f587404b@github.com>

On Wed, 14 Sep 2022 14:35:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too?
> 
> Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly.

Sorry, I missed your previous response to that similar question. Doing those changes separately sounds fine to me.

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

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

From rriggs at openjdk.org  Wed Sep 14 15:33:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 Sep 2022 15:33:45 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <YV7yQcn2WBeqFXs0VJYYUaE0UQxX-o6155kHHgocV-4=.cfa6c0b8-477d-4db2-83b2-11313fce5e5d@github.com>

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

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From mchung at openjdk.org  Wed Sep 14 15:59:53 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Sep 2022 15:59:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <Neq3XrV6wPCdnoNLwVcgAhgaK2Ei3hJIOZ0JARq9BNc=.1996b1f5-4220-433e-b6d2-24dd79c13200@github.com>

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

Marked as reviewed by mchung (Reviewer).

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

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

From jlahoda at openjdk.org  Wed Sep 14 17:23:20 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Sep 2022 17:23:20 GMT
Subject: RFR: 8293591: Remove use of Thread.stop from jshell tests
Message-ID: <t2SC5Xtv1kbZUB1Dw5AFaNuigUEMv33CoyIo8IEGmuA=.f8db97df-bb11-40cf-8ec5-0277595f6d18@github.com>

Two changes here:
- confirming the '/exit` command, so that the JShell instance is actually stopped
- removing the call to `Thread.stop`, which is intended to stop the test if something goes wrong unexpectedly. As we cannot use `Thread.stop` anymore, we'll rely on jtreg to stop the test.

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

Commit messages:
 - 8293591: Remove use of Thread.stop from jshell tests

Changes: https://git.openjdk.org/jdk/pull/10271/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293591
  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10271.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10271/head:pull/10271

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

From prr at openjdk.org  Wed Sep 14 17:53:55 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 Sep 2022 17:53:55 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <PD97EHa4KSPIKDKxaS9ZqxwonA3e5DPhTiaTN90Wy9Y=.6d8d9d01-f294-45d4-a817-063cf1b8d40e@github.com>

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

Marked as reviewed by prr (Reviewer).

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

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

From mullan at openjdk.org  Wed Sep 14 20:32:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Sep 2022 20:32:47 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v2]
In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com>
Message-ID: <7rR40Xh40dmqQRAmSYBOl-h7vbUwKpq204tERqKKn0Q=.c168ee8e-2cb8-4aaa-a6b4-c562367013fb@github.com>

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.base/share/classes/java/lang/Thread.java line 1642:

> 1640:      *       {@code ThreadDeath} exception propagating up the stack).  If
> 1641:      *       any of the objects previously protected by these monitors were in
> 1642:      *       an inconsistent state, the damaged objects become visible to

s/become/became/ 
(because you are writing in past tense now).

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

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

From alanb at openjdk.org  Thu Sep 15 11:14:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Sep 2022 11:14:43 GMT
Subject: RFR: 8293591: Remove use of Thread.stop from jshell tests
In-Reply-To: <t2SC5Xtv1kbZUB1Dw5AFaNuigUEMv33CoyIo8IEGmuA=.f8db97df-bb11-40cf-8ec5-0277595f6d18@github.com>
References: <t2SC5Xtv1kbZUB1Dw5AFaNuigUEMv33CoyIo8IEGmuA=.f8db97df-bb11-40cf-8ec5-0277595f6d18@github.com>
Message-ID: <Vw0GXSoRjKkOe1nOu1afs-lLovHPni7048PQ_3FvKUw=.89503d6a-2dcd-4bf9-8129-88dab78007a3@github.com>

On Wed, 14 Sep 2022 17:06:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Two changes here:
> - confirming the '/exit` command, so that the JShell instance is actually stopped
> - removing the call to `Thread.stop`, which is intended to stop the test if something goes wrong unexpectedly. As we cannot use `Thread.stop` anymore, we'll rely on jtreg to stop the test.

Leaving it to jtreg when something goes wrong and the test times out seems right. Thanks for doing this.

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

Marked as reviewed by alanb (Reviewer).

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

From jlahoda at openjdk.org  Thu Sep 15 11:30:47 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 Sep 2022 11:30:47 GMT
Subject: Integrated: 8293591: Remove use of Thread.stop from jshell tests
In-Reply-To: <t2SC5Xtv1kbZUB1Dw5AFaNuigUEMv33CoyIo8IEGmuA=.f8db97df-bb11-40cf-8ec5-0277595f6d18@github.com>
References: <t2SC5Xtv1kbZUB1Dw5AFaNuigUEMv33CoyIo8IEGmuA=.f8db97df-bb11-40cf-8ec5-0277595f6d18@github.com>
Message-ID: <lEsA1xfkl2M8U6-sajb1BDmG60Lnz9mFTL9NiG7ac3w=.ba9dc396-c50f-408d-9a98-09828bc04dba@github.com>

On Wed, 14 Sep 2022 17:06:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Two changes here:
> - confirming the '/exit` command, so that the JShell instance is actually stopped
> - removing the call to `Thread.stop`, which is intended to stop the test if something goes wrong unexpectedly. As we cannot use `Thread.stop` anymore, we'll rely on jtreg to stop the test.

This pull request has now been integrated.

Changeset: fbd8b42d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbd8b42d70f41ab322c64d7dbcb15c81e8d515dc
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8293591: Remove use of Thread.stop from jshell tests

Reviewed-by: alanb

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

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

From jlahoda at openjdk.org  Thu Sep 15 11:30:46 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 Sep 2022 11:30:46 GMT
Subject: RFR: 8293591: Remove use of Thread.stop from jshell tests
In-Reply-To: <Vw0GXSoRjKkOe1nOu1afs-lLovHPni7048PQ_3FvKUw=.89503d6a-2dcd-4bf9-8129-88dab78007a3@github.com>
References: <t2SC5Xtv1kbZUB1Dw5AFaNuigUEMv33CoyIo8IEGmuA=.f8db97df-bb11-40cf-8ec5-0277595f6d18@github.com>
 <Vw0GXSoRjKkOe1nOu1afs-lLovHPni7048PQ_3FvKUw=.89503d6a-2dcd-4bf9-8129-88dab78007a3@github.com>
Message-ID: <32t8m2b2MCOp34smrTxTjHDfok4uU3eYfIccuBiQwAw=.496c01d1-b857-48d1-ba4b-7abce2330e9e@github.com>

On Thu, 15 Sep 2022 11:10:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Leaving it to jtreg when something goes wrong and the test times out seems right. Thanks for doing this.

Thanks!

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

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

From alanb at openjdk.org  Fri Sep 16 09:45:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Sep 2022 09:45:14 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>

> 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 10 additional commits since the last revision:

 - 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
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/86424b65..a00f38a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=01-02

  Stats: 2575 lines in 102 files changed: 1741 ins; 370 del; 464 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

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

From jpai at openjdk.org  Fri Sep 16 10:03:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 Sep 2022 10:03:51 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
Message-ID: <gGA9M5tP46bhCY9PI2iJWQ_2Cn82ti6v8m3T4LgWkOg=.500b0275-0ba5-4b4b-9d42-15cee27bad5b@github.com>

On Fri, 16 Sep 2022 09:45:14 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 10 additional commits since the last revision:
> 
>  - 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
>  - Merge
>  - Initial commit

Marked as reviewed by jpai (Reviewer).

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

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

From mullan at openjdk.org  Fri Sep 16 13:16:53 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 16 Sep 2022 13:16:53 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v3]
In-Reply-To: <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <aZkbd6g9FC4Q6gGvqygI1B3F5tk6bj6JE6y17_lZGrw=.60e86c67-9f06-4b82-801a-131c3eb044bf@github.com>
Message-ID: <JdnXbrQe1rDRzupg-hiZip7CEa_7OuPafwdNWzpZods=.031f494b-eb2e-44e2-8f03-58220a34139b@github.com>

On Fri, 16 Sep 2022 09:45:14 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 10 additional commits since the last revision:
> 
>  - 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
>  - Merge
>  - Initial commit

Marked as reviewed by mullan (Reviewer).

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

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

From alanb at openjdk.org  Sat Sep 17 08:41:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Sep 2022 08:41:19 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>

> 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 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/214db2f4...93806f99

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10230/files
  - new: https://git.openjdk.org/jdk/pull/10230/files/a00f38a2..93806f99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02-03

  Stats: 5663 lines in 389 files changed: 1218 ins; 1745 del; 2700 mod
  Patch: https://git.openjdk.org/jdk/pull/10230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230

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

From dholmes at openjdk.org  Tue Sep 20 05:42:57 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Sep 2022 05:42:57 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
Message-ID: <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>

On Sat, 17 Sep 2022 08:41:19 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 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/4a31f682...93806f99

Hi Alan,

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.

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.

src/java.base/share/classes/java/lang/Shutdown.java line 132:

> 130:                 if (hook != null) hook.run();
> 131:             } catch (Throwable t) {
> 132:                 // ignore

Again change of behaviour if TD originates from debugger.

src/java.base/share/classes/java/lang/ThreadDeath.java line 30:

> 28: /**
> 29:  * An instance of {@code ThreadDeath} was originally specified to be thrown
> 30:  * by a victim thread when "stopped" with {@link Thread#stop()}.

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

src/java.base/share/classes/java/lang/ThreadGroup.java line 700:

> 698:                 ueh.uncaughtException(t, e);
> 699:             } else {
> 700:                 System.err.print("Exception in thread \"" + t.getName() + "\" ");

Again change in behaviour.

src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 37:

> 35: stop a thread removed?</h2>
> 36: <p>Because it was inherently unsafe. Stopping a thread caused it to
> 37: unlock all the monitors that it had locked. (The monitors were

Just an aside but this rationale was always a significant under-statement as async-exceptions are inherently unsafe even if no concurrency or monitors are involved.

src/java.desktop/macosx/classes/sun/lwawt/LWToolkit.java line 170:

> 168:                     }
> 169:                 }
> 170:             } catch (ThreadDeath td) {

Again change in behaviour

src/java.desktop/share/classes/java/awt/EventDispatchThread.java line 205:

> 203:             eq.dispatchEvent(event);
> 204:         }
> 205:         catch (ThreadDeath death) {

Again change in behaviour.

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

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

From alanb at openjdk.org  Tue Sep 20 06:05:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Sep 2022 06:05:14 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
Message-ID: <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>

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

From smarks at openjdk.org  Tue Sep 20 16:32:54 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 20 Sep 2022 16:32:54 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
Message-ID: <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>

On Tue, 20 Sep 2022 06:00:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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 this 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 party libraries.

I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications.

A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom.

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

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

From dholmes at openjdk.org  Wed Sep 21 06:47:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Sep 2022 06:47:58 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
 <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
Message-ID: <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>

On Tue, 20 Sep 2022 16:29:08 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> 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 this 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 party libraries.
>
> I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications.
> 
> A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom.

Okay I will defer to your views here. Thanks.

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

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

From alanb at openjdk.org  Wed Sep 21 07:52:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Sep 2022 07:52:03 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <bjXGfmDhmaMyT_j_bQhZLezMj4Jb18w0yhQsYZhlXjU=.d5f0014e-9d6d-4c5f-b84f-5446166bb767@github.com>
 <jhvaxnF1s7-oPaVsF9nf5ko8wP1gBWOo5TfO8T_j40A=.731ea409-ca17-488e-a0b1-3cb15334515a@github.com>
 <q6ToSabdUIWS0vK-13JWdvQySwco64A_gP20tVsm9FI=.7722abf4-9470-4a52-9f8e-48cb2481eb77@github.com>
 <babX5XCHpbm-0i8-pwGE7t-8E4suI6kn5k3DAzgnkGs=.66c28495-4492-409f-8bf6-c92f87a153ec@github.com>
Message-ID: <Nmq49Pi6YsAZQTWFK3729Iyyd6XCdVvCYlKFbETzv0U=.daeca85f-2d9e-4c02-af56-0754165b6466@github.com>

On Wed, 21 Sep 2022 06:43:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay I will defer to your views here. Thanks.

Thank you, I'll get the CSR moving again and we'll try to get this done.

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

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

From darcy at openjdk.org  Thu Sep 22 04:38:30 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Sep 2022 04:38:30 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
Message-ID: <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>

On Sat, 17 Sep 2022 08:41:19 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 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/c06e7ac5...93806f99

src/java.base/share/classes/java/lang/Thread.java line 1632:

> 1630: 
> 1631:     /**
> 1632:      * Throws {@code UnsupportedOperationException}.

Consider using an implSpec tag here.

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

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

From alanb at openjdk.org  Thu Sep 22 07:12:29 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Sep 2022 07:12:29 GMT
Subject: RFR: 8289610: Degrade Thread.stop [v4]
In-Reply-To: <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
 <ZTzHjlUXhJf5U3PndgGMZUpwbIJhJ0kSxL2am_PfFT8=.4279d477-9a1e-4a2c-b334-90cc60b5592b@github.com>
 <zjl7cwFlpwxgYjDbchAw8qBNLcLq5n4CP940XDIlq8s=.91594dec-7c4a-45b9-8cbe-ec7ec51dc74c@github.com>
Message-ID: <vWJUYm6IkJ8IwojilwR4D6_uBXhPU6GsOAKgFZfG7XE=.6280413f-e994-4cad-a9e6-8d9eff0bf5dd@github.com>

On Thu, 22 Sep 2022 04:36:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Consider using an implSpec tag here.

implSpec is usually for default methods or overrideable methods. In this case, Thread.stop is final so code that extends Thread can't override and change the behavior. So it's not clear to me that implSpec would be useful as it would duplicate the description in the generated javadoc.

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

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

From alanb at openjdk.org  Fri Sep 23 07:59:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 07:59:16 GMT
Subject: Integrated: 8289610: Degrade Thread.stop
In-Reply-To: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
References: <UgJsjBjMxXy3PtcyLWGNZmfbi0Cn_lLiVsPp00eQDKA=.d5da6f0f-738c-4eef-8647-87f239249b92@github.com>
Message-ID: <rApjpOiHjrtsAtbAXYhxuyOB3uAhSHS58h8VmrVi7BA=.53a55061-ea0c-4b9d-b57b-b72b34e0a0bd@github.com>

On Fri, 9 Sep 2022 12:44:31 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.

This pull request has now been integrated.

Changeset: acd5bcfc
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acd5bcfc8897908d82e9008ee2def9476f046a4d
Stats:     341 lines in 26 files changed: 115 ins; 162 del; 64 mod

8289610: Degrade Thread.stop

Reviewed-by: rriggs, cjplummer, jpai, mchung, prr, mullan

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

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

From dholmes at openjdk.org  Fri Sep 23 08:58:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 08:58:42 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup
Message-ID: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>

Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).

Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.

Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).

Testing: tiers 1-3

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

Commit messages:
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - 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
 - ... and 5 more: https://git.openjdk.org/jdk/compare/01e7b881...58bfb313

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293592
  Stats: 549 lines in 43 files changed: 134 ins; 308 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

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

From alanb at openjdk.org  Fri Sep 23 11:12:24 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Sep 2022 11:12:24 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <Bfq-Tx0S9oPszwvfoUkCtVd16ARxYp6c8Y1Oe9S1_y4=.1b7e4278-2ba0-455e-9cd8-2d0b27f49d70@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

(JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR once the list of changed files. You should be able to trim down the labels too.)

I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe.

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

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

From cjplummer at openjdk.org  Fri Sep 23 18:31:23 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 23 Sep 2022 18:31:23 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:

> 100:             try {
> 101:                 connector = connectors.next();
> 102:             } catch (Exception | Error x) {

Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:

> 124:             try {
> 125:                 transportService = transportServices.next();
> 126:             } catch (Exception | Error x) {

Another that could be just catch `Throwable`

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

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

From dholmes at openjdk.org  Fri Sep 23 21:47:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:06 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <BlMK7IMjTgIiiwSkkF_1-qLlM1AqaKAhLP55-Z1-eeI=.2383991e-22d3-4c0c-afab-353985e1f8fc@github.com>

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into 8293592-JVM_StopThread
 - Removal all special handling of ThreadDeath.
 - Remove all references to the stillborn field
 - Initial commit: remove JVM_StopThread
 - 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
 - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903

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

Changes: https://git.openjdk.org/jdk/pull/10400/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=01
  Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/10400.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400

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

From dholmes at openjdk.org  Fri Sep 23 21:47:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:08 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup
In-Reply-To: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
Message-ID: <pe2S9eAR6fAkhNMkE7zsvJjErBsmkHbm5PrW6Sm8jE4=.1c30dc46-dafb-4b16-be3f-73e27fc8e5fd@github.com>

On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610).
> 
> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started.
> 
> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same).
> 
> Testing: tiers 1-3

This PR is now back to its proper form after merging the upstream changes.  I can't say I like the "dependent PR" feature.

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

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

From dholmes at openjdk.org  Fri Sep 23 21:47:10 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Sep 2022 21:47:10 GMT
Subject: RFR: 8293592: Remove JVM_StopThread, stillborn,
 and related cleanup [v2]
In-Reply-To: <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
References: <jQ8-jXTAodciLhVseYvaHailt_gM-j6KpbBJT9Xj-eg=.4662addd-2971-4226-b1bc-110ca921b97d@github.com>
 <jPQnZdvskvzHDQZrF45DW8L9zsvSxiQKQHrODS2RAdk=.2fc75db3-f9d0-4bbb-8283-e387481cbc30@github.com>
Message-ID: <WlSewOOWwaXOlFuSI6NrOYXMvwwp1xvfYxpLZF4xAPE=.9efe45f9-a6df-4bd5-bece-7e349b092a9c@github.com>

On Fri, 23 Sep 2022 18:21:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8293592-JVM_StopThread
>>  - Removal all special handling of ThreadDeath.
>>  - Remove all references to the stillborn field
>>  - Initial commit: remove JVM_StopThread
>>  - 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
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102:
> 
>> 100:             try {
>> 101:                 connector = connectors.next();
>> 102:             } catch (Exception | Error x) {
> 
> Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here.

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126:
> 
>> 124:             try {
>> 125:                 transportService = transportServices.next();
>> 126:             } catch (Exception | Error x) {
> 
> Another that could be just catch `Throwable`

@plummercj  these changes are not actually part of this PR but came from the upstream PR this was dependent on.

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

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

From asotona at openjdk.org  Mon Sep 26 17:28:46 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Sep 2022 17:28:46 GMT
Subject: RFR: 8293000: Review running times of jshell regression tests
Message-ID: <wg7X_I5fnEq6SfyjmWxt-xm1GurP-DV39xa5-hKbldM=.54572d09-3b05-40a7-a665-820e96828832@github.com>

Some of the jshell tests have been identified as long-running.

This patch reduces tests runtimes with multiple tricks:

- local execution control is used in heavily parametrized and fragmented tests to eliminate JVM startups
- some tests have been defragmented
- unnecessary Thread::stop has been removed

Measured test run times before and after application of this patch:
- ClassMembersTest 23.964ms ->  9.195ms
- ToolBasicTest 24.281ms -> 14.955ms
- FailOverExecutionControlHangingListenTest 31.221ms -> 5.780ms
- FailOverExecutionControlDyingLaunchTest 31.221ms -> 6.050ms
- FailOverExecutionControlHangingLaunchTest 31.303ms -> 5.832ms
- CompletionSuggestionTest 10.523ms -> 4.940ms
- SimpleRegressionTest 3.629ms -> 1.304ms

Please review the test changes.

Thanks,
Adam

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

Commit messages:
 - 8293000: Review running times of jshell regression tests

Changes: https://git.openjdk.org/jdk/pull/10428/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293000
  Stats: 42 lines in 5 files changed: 23 ins; 10 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10428.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10428/head:pull/10428

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

From darcy at openjdk.org  Tue Sep 27 03:23:19 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Sep 2022 03:23:19 GMT
Subject: RFR: 8293000: Review running times of jshell regression tests
In-Reply-To: <wg7X_I5fnEq6SfyjmWxt-xm1GurP-DV39xa5-hKbldM=.54572d09-3b05-40a7-a665-820e96828832@github.com>
References: <wg7X_I5fnEq6SfyjmWxt-xm1GurP-DV39xa5-hKbldM=.54572d09-3b05-40a7-a665-820e96828832@github.com>
Message-ID: <NIbmuXRyYMpuYfDCu4OfSQfKybI1OwDnond-SMEJGH0=.a7d87f7c-f282-4cbc-841a-ada398b87587@github.com>

On Mon, 26 Sep 2022 17:21:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Some of the jshell tests have been identified as long-running.
> 
> This patch reduces tests runtimes with multiple tricks:
> 
> - local execution control is used in heavily parametrized and fragmented tests to eliminate JVM startups
> - some tests have been defragmented
> - unnecessary Thread::stop has been removed
> 
> Measured test run times before and after application of this patch:
> - ClassMembersTest 23.964ms ->  9.195ms
> - ToolBasicTest 24.281ms -> 14.955ms
> - FailOverExecutionControlHangingListenTest 31.221ms -> 5.780ms
> - FailOverExecutionControlDyingLaunchTest 31.221ms -> 6.050ms
> - FailOverExecutionControlHangingLaunchTest 31.303ms -> 5.832ms
> - CompletionSuggestionTest 10.523ms -> 4.940ms
> - SimpleRegressionTest 3.629ms -> 1.304ms
> 
> Please review the test changes.
> 
> Thanks,
> Adam

While not being familiar with the jshell test framework, the changes looks plausible. Thanks.

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

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

From prappo at openjdk.org  Tue Sep 27 11:52:57 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Sep 2022 11:52:57 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited
Message-ID: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>

This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.

JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.

That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.

To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:

    public class Subtype extends Supertype {

        @Override
        public void m() throws SuperException {
    ...

    public class Supertype {

        /**
         * @throws SuperException general problem
         * @throws SubExceptionA  specific problem A
         * @throws SubExceptionB  specific problem B
         */
        public void m() throws SuperException {
    ...

    public class SuperException extends Exception {
    ...

    public class SubExceptionA extends SuperException {
    ...

    public class SubExceptionB extends SuperException {
    ...

For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:

    public void m()
           throws SuperException

    Overrides:
        m in class Supertype
    Throws:
        SuperException - general problem
        SubExceptionA - specific problem A
        SubExceptionB - specific problem B 

It works for checked and unchecked exceptions, for methods in classes and interfaces.


If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.

Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.


[^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
[^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/10449/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294377
  Stats: 322 lines in 15 files changed: 311 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10449/head:pull/10449

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

From prappo at openjdk.org  Tue Sep 27 12:14:23 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Sep 2022 12:14:23 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
Message-ID: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>

> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
> 
> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
> 
> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
> 
> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
> 
>     public class Subtype extends Supertype {
> 
>         @Override
>         public void m() throws SuperException {
>     ...
> 
>     public class Supertype {
> 
>         /**
>          * @throws SuperException general problem
>          * @throws SubExceptionA  specific problem A
>          * @throws SubExceptionB  specific problem B
>          */
>         public void m() throws SuperException {
>     ...
> 
>     public class SuperException extends Exception {
>     ...
> 
>     public class SubExceptionA extends SuperException {
>     ...
> 
>     public class SubExceptionB extends SuperException {
>     ...
> 
> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
> 
>     public void m()
>            throws SuperException
> 
>     Overrides:
>         m in class Supertype
>     Throws:
>         SuperException - general problem
>         SubExceptionA - specific problem A
>         SubExceptionB - specific problem B 
> 
> It works for checked and unchecked exceptions, for methods in classes and interfaces.
> 
> 
> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
> 
> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
> 
> 
> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  revert an extraneous change to jdk.javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10449/files
  - new: https://git.openjdk.org/jdk/pull/10449/files/87bdbff4..d303f5ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10449&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10449.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10449/head:pull/10449

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

From dfuchs at openjdk.org  Wed Sep 28 13:38:37 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 28 Sep 2022 13:38:37 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

The changes to JNDI and NIO look reasonable to me - though I haven't verified whether anything was missing (or no longer needed). If you can assert that the generated docs are the same before and after the proposed change then that's enough for me.

src/java.naming/share/classes/javax/naming/directory/InitialDirContext.java line 186:

> 184:     /**
> 185:      * @throws  AttributeModificationException {@inheritDoc}
> 186:      */

Isn't `{@inheritDoc}` needed in this case to preserve the method & params  description?

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

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

From prappo at openjdk.org  Wed Sep 28 14:04:25 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Sep 2022 14:04:25 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
Message-ID: <AtkGrQJlrGsyJWAgtPgeUmc1nONMsxO_vzqUAFm2csk=.05cfb965-4e97-4507-b500-f95e06583ad8@github.com>

On Wed, 28 Sep 2022 13:34:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert an extraneous change to jdk.javadoc
>
> src/java.naming/share/classes/javax/naming/directory/InitialDirContext.java line 186:
> 
>> 184:     /**
>> 185:      * @throws  AttributeModificationException {@inheritDoc}
>> 186:      */
> 
> Isn't `{@inheritDoc}` needed in this case to preserve the method & params  description?

Elements of a method declaration such as formal and type parameters as well as exceptions in the `throws` clause implicitly inherit descriptions, unless those elements are described in that method declaration. The same goes for the main description of a method: unless it exists in the method declaration, it is inherited.

To sum up, those descriptions you ask about are implicitly inherited. No additional javadoc markup is needed.

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

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

From alanb at openjdk.org  Wed Sep 28 14:22:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Sep 2022 14:22:10 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <jRRrURJQpNTiCWGs_oPoRkJTFb60kh_zg2ARAg_033I=.66258e70-5760-4d88-86a9-9f7bbf47c9de@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

The updates to the channel classes look okay.

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

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

From prappo at openjdk.org  Wed Sep 28 14:22:11 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Sep 2022 14:22:11 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <WjnsB8gd3r6yurtHuMpcEK4-TJ8ox_psgBl5HRRLsLs=.512f181c-4da4-4eec-8d3d-63a8f19c2b07@github.com>
Message-ID: <xKmD22kAF0LCY9X5tja1gN_hXJdpSJl7mGI5RFNrKiY=.0911fc21-61a4-4536-bb58-1e8947aa2834@github.com>

On Wed, 28 Sep 2022 13:36:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> If you can assert that the generated docs are the same before and after the proposed change then that's enough for me.

Would it suffice if I show the result of the diff between JDK API Documentation built at the tip of this PR branch (docs) and that of the jdk/master commit (docs-old) from which this PR branches? If so, please have a look:


    % diff -qnr build/macosx-aarch64/images/docs build/macosx-aarch64/images/docs-old                                                
    Files build/macosx-aarch64/images/docs/api/index-files/index-9.html and build/macosx-aarch64/images/docs-old/api/index-files/index-9.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/Exception.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/Exception.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/Override.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/Override.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/class-use/String.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/class-use/String.html differ
    Files build/macosx-aarch64/images/docs/api/java.base/java/lang/reflect/class-use/Method.html and build/macosx-aarch64/images/docs-old/api/java.base/java/lang/reflect/class-use/Method.html differ
    Files build/macosx-aarch64/images/docs/api/jdk.jshell/jdk/jshell/execution/JdiDefaultExecutionControl.html and build/macosx-aarch64/images/docs-old/api/jdk.jshell/jdk/jshell/execution/JdiDefaultExecutionControl.html differ
    Files build/macosx-aarch64/images/docs/api/jdk.jshell/jdk/jshell/execution/RemoteExecutionControl.html and build/macosx-aarch64/images/docs-old/api/jdk.jshell/jdk/jshell/execution/RemoteExecutionControl.html differ
    Files build/macosx-aarch64/images/docs/api/member-search-index.js and build/macosx-aarch64/images/docs-old/api/member-search-index.js differ

As I said in the PR description, the differences are insignificant and confined to class-use and index structures. Well, except for jdk.jshell. But even there it might be okay for now.

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

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

From jlahoda at openjdk.org  Thu Sep 29 13:59:00 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 29 Sep 2022 13:59:00 GMT
Subject: RFR: 8294431: jshell reports error on initialisation of static final
 field of anonymous class
Message-ID: <cdy-3x_NYaQY2qGSY7nH3seslfIEiSIaYW13y0qZiBU=.3f0b1f1a-243a-425f-b202-68855ef32b3e@github.com>

When variable with an inferred type (i.e. `var`) is initialized with an anonymous class, the inferred type of the variable is the actual anonymous type. To implement this in JShell, JShell will unroll the anonymous class into a normal class, and to do this, it needs to initialize fields inside a constructor.

But, as we can have static fields in the anonymous class now, it is necessary to not try to initialize static fields in the constructor, as we would initialize them too often.

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

Commit messages:
 - 8294431: jshell reports error on initialisation of static final field of anonymous class

Changes: https://git.openjdk.org/jdk/pull/10489/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294431
  Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10489.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10489/head:pull/10489

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

From sundar at openjdk.org  Thu Sep 29 14:41:36 2022
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 29 Sep 2022 14:41:36 GMT
Subject: RFR: 8294431: jshell reports error on initialisation of static
 final field of anonymous class
In-Reply-To: <cdy-3x_NYaQY2qGSY7nH3seslfIEiSIaYW13y0qZiBU=.3f0b1f1a-243a-425f-b202-68855ef32b3e@github.com>
References: <cdy-3x_NYaQY2qGSY7nH3seslfIEiSIaYW13y0qZiBU=.3f0b1f1a-243a-425f-b202-68855ef32b3e@github.com>
Message-ID: <X_OP2hnAccaLAKQ1hWX408wGXBL0f-TNKpzhdTnAXco=.939701f2-679d-4adf-959a-b7fee1263662@github.com>

On Thu, 29 Sep 2022 13:51:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When variable with an inferred type (i.e. `var`) is initialized with an anonymous class, the inferred type of the variable is the actual anonymous type. To implement this in JShell, JShell will unroll the anonymous class into a normal class, and to do this, it needs to initialize fields inside a constructor.
> 
> But, as we can have static fields in the anonymous class now, it is necessary to not try to initialize static fields in the constructor, as we would initialize them too often.

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

From darcy at openjdk.org  Fri Sep 30 01:23:33 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Sep 2022 01:23:33 GMT
Subject: RFR: 8293000: Review running times of jshell regression tests
In-Reply-To: <wg7X_I5fnEq6SfyjmWxt-xm1GurP-DV39xa5-hKbldM=.54572d09-3b05-40a7-a665-820e96828832@github.com>
References: <wg7X_I5fnEq6SfyjmWxt-xm1GurP-DV39xa5-hKbldM=.54572d09-3b05-40a7-a665-820e96828832@github.com>
Message-ID: <obt2budnp0WYR1LKl2QVP4OVvuMYyK1dJTOT7VTSg3s=.caad0f8a-1149-46e6-97fe-2136579a8c9a@github.com>

On Mon, 26 Sep 2022 17:21:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Some of the jshell tests have been identified as long-running.
> 
> This patch reduces tests runtimes with multiple tricks:
> 
> - local execution control is used in heavily parametrized and fragmented tests to eliminate JVM startups
> - some tests have been defragmented
> - unnecessary Thread::stop has been removed
> 
> Measured test run times before and after application of this patch:
> - ClassMembersTest 23.964ms ->  9.195ms
> - ToolBasicTest 24.281ms -> 14.955ms
> - FailOverExecutionControlHangingListenTest 31.221ms -> 5.780ms
> - FailOverExecutionControlDyingLaunchTest 31.221ms -> 6.050ms
> - FailOverExecutionControlHangingLaunchTest 31.303ms -> 5.832ms
> - CompletionSuggestionTest 10.523ms -> 4.940ms
> - SimpleRegressionTest 3.629ms -> 1.304ms
> 
> Please review the test changes.
> 
> Thanks,
> Adam

Marked as reviewed by darcy (Reviewer).

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

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

From asotona at openjdk.org  Fri Sep 30 09:00:28 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Sep 2022 09:00:28 GMT
Subject: Integrated: 8293000: Review running times of jshell regression tests
In-Reply-To: <wg7X_I5fnEq6SfyjmWxt-xm1GurP-DV39xa5-hKbldM=.54572d09-3b05-40a7-a665-820e96828832@github.com>
References: <wg7X_I5fnEq6SfyjmWxt-xm1GurP-DV39xa5-hKbldM=.54572d09-3b05-40a7-a665-820e96828832@github.com>
Message-ID: <shtDPib52Q_F1t-MWgaAuzEa08g1oudIj0sVSKzk_W8=.9b8ea6a2-d32a-40fe-af53-35170b04f6d6@github.com>

On Mon, 26 Sep 2022 17:21:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Some of the jshell tests have been identified as long-running.
> 
> This patch reduces tests runtimes with multiple tricks:
> 
> - local execution control is used in heavily parametrized and fragmented tests to eliminate JVM startups
> - some tests have been defragmented
> - unnecessary Thread::stop has been removed
> 
> Measured test run times before and after application of this patch:
> - ClassMembersTest 23.964ms ->  9.195ms
> - ToolBasicTest 24.281ms -> 14.955ms
> - FailOverExecutionControlHangingListenTest 31.221ms -> 5.780ms
> - FailOverExecutionControlDyingLaunchTest 31.221ms -> 6.050ms
> - FailOverExecutionControlHangingLaunchTest 31.303ms -> 5.832ms
> - CompletionSuggestionTest 10.523ms -> 4.940ms
> - SimpleRegressionTest 3.629ms -> 1.304ms
> 
> Please review the test changes.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: b4e1e416
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b4e1e416dacb6099a780f2250cef737834c19d56
Stats:     42 lines in 5 files changed: 23 ins; 10 del; 9 mod

8293000: Review running times of jshell regression tests

Reviewed-by: darcy

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

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

From prr at openjdk.org  Fri Sep 30 19:17:22 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 30 Sep 2022 19:17:22 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java line 206:

> 204:      * @throws EOFException {@inheritDoc}
> 205:      */
> 206:     public boolean readBoolean() throws IOException {

If the docs end up the same as you say that is fine by me since for the two ImageIO classes
that seems to be what we'd want.

But inheritDoc behaviour is still "surprising".
I've never been sure I understood it and now I'm just sure I don't.

1) The two ImageIO methods don't have @override or *anything* and yet javadoc infers
they'd want to inherit the docs from the interface .. clever javadoc .. I guess I can see
that some doc is better than none so this is OK

2) When it does inherit I'd expected that it copies the EXACT and ENTIRE javadoc
from the super-interface, which for your change to work can't be all its doing.
You've added JUST
/**
 * @throws SomeExceptionSubType blah-blah
 */

and yet javadoc somehow figures out this is to be ADDED to the super-type doc
for the method and not replace it .. ???

3) What the old code was doing seems to me to be "natural" to the extent any of
this does and the fix you are preparing would add to the surprising behaviours ..

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

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