From eirbjo at openjdk.org  Tue Oct  1 07:17:36 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 07:17:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <0Ld1ZT7y9YOa5JdmwZeg4eFGrpvho6eL0r_j1WODFrI=.dffe658f-cc4e-4b2a-a09b-3d881bbda7c3@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

Is `compiler` label needed? The `jar` tool belongs in `core-libs`, right? This PR does not seem to touch anything in the compiler area?

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

PR Comment: https://git.openjdk.org/jdk/pull/21141#issuecomment-2384977590

From nbenalla at openjdk.org  Tue Oct  1 10:29:39 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 1 Oct 2024 10:29:39 GMT
Subject: Integrated: 8341201: Broken link in AbstractAnnotationValueVisitor7
 due to extra quotation mark
In-Reply-To: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
References: <swqhlCkP94sOdUSqqR17USBj6wrRTkK8WLjmLS9oJ3A=.4d6315ba-3125-4e9d-9410-23bad3ed6df1@github.com>
Message-ID: <mIFJVTLO8OOblXgCPSZ3zgkviUC1wRfWh8Bity1FiqM=.9bb4eba2-4a98-464c-8987-d4e345c2b8c1@github.com>

On Mon, 30 Sep 2024 11:43:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this trivial doc fix?
> 
> TIA

This pull request has now been integrated.

Changeset: 2dc3b1a7
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2dc3b1a71ffe71bc08ec967bb6b24ccf803037f3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8341201: Broken link in AbstractAnnotationValueVisitor7 due to extra quotation mark

Reviewed-by: iris, darcy

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

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

From jpai at openjdk.org  Tue Oct  1 11:22:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Oct 2024 11:22:39 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <FhtT353ZdudsqkGwzoRXDz2rM6IdhmrCMY3N68TGsZ0=.237c203f-1d83-4211-a559-152b51ee8ff7@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>
 <FhtT353ZdudsqkGwzoRXDz2rM6IdhmrCMY3N68TGsZ0=.237c203f-1d83-4211-a559-152b51ee8ff7@github.com>
Message-ID: <--UgqtJxOsLPF4wUxjlkXpnztA8ywLGbExhbV2BWVTo=.a0814e89-f328-43c5-88ce-0fe8406af420@github.com>

On Mon, 30 Sep 2024 15:21:31 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Some other comments also related to copied code, I can do a round of clean up.

Thank you Henry, that sounds fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1782590139

From henryjen at openjdk.org  Tue Oct  1 17:23:36 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 1 Oct 2024 17:23:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <6Rd1WefoiRuHZeJOA6PJj7NfUc-xw5J2pzFAOE-YmnQ=.7cafe564-5dbb-440c-9707-1b4887586567@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
 <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>
 <6Rd1WefoiRuHZeJOA6PJj7NfUc-xw5J2pzFAOE-YmnQ=.7cafe564-5dbb-440c-9707-1b4887586567@github.com>
Message-ID: <gYIDXh7P-jHAuCQbpSjo9v2m7avPxNsCWJty9nfnb9I=.d3cadb75-943b-463e-8e1e-09ccb2f2d1e2@github.com>

On Mon, 30 Sep 2024 15:51:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I considered that, but didn't implement it after confirmed other similar options didn't display any warning.
>> I do think it make sense to show a warning when using an option not valid in specific mode.
>
>> I considered that, but didn't implement it after confirmed other similar options didn't display any warning. I do think it make sense to show a warning when using an option not valid in specific mode.
> 
> We do display a warning/error is some cases:  For example when we specify 'c' and 'x' we get the following message
> 
> 
> jar cxvf foo.jar
> You may not specify more than one '-cuxtid' options
> Try `jar --help' for more information.
> 
> 
> given '-k' is only relevant when used with the  '-x' option, we could specify a warning (or indicate it is ignored...

OK, I will add a message. The other option I am talking about is specific mode options, like compression or manifest instead of main options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1783229550

From henryjen at openjdk.org  Tue Oct  1 17:26:34 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 1 Oct 2024 17:26:34 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <0Ld1ZT7y9YOa5JdmwZeg4eFGrpvho6eL0r_j1WODFrI=.dffe658f-cc4e-4b2a-a09b-3d881bbda7c3@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <0Ld1ZT7y9YOa5JdmwZeg4eFGrpvho6eL0r_j1WODFrI=.dffe658f-cc4e-4b2a-a09b-3d881bbda7c3@github.com>
Message-ID: <Wpckkpi9RMqW5XxAamp_8lyAlm84uGp5wuQWrnpjxbs=.dcdbbb38-b081-4200-a03a-632d0fab2ced@github.com>

On Tue, 1 Oct 2024 07:15:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Is `compiler` label needed? The `jar` tool belongs in `core-libs`, right? This PR does not seem to touch anything in the compiler area?

Automatically added by the bot. I agree it's not related to compiler at all. I'll manually remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21141#issuecomment-2386565199

From darcy at openjdk.org  Tue Oct  1 23:05:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 1 Oct 2024 23:05:38 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
Message-ID: <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>

On Sat, 28 Sep 2024 22:31:14 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing line

If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2387232149

From jlahoda at openjdk.org  Wed Oct  2 08:53:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Oct 2024 08:53:16 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile [v2]
In-Reply-To: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
Message-ID: <SnsitbkX-dwLThUb9zmieqnZn50ROHBfB7mTX27xTnM=.1449d6d5-6ee1-472a-b1d0-24d553c1e89a@github.com>

> Consider code like this:
> 
>     int nestedSwitchesInArgumentPosition(Object o1) {
>         return id(switch (o1) {
>             case R(var o2) -> switch (o2) {
>                 case R(String s) -> s;
>                 default -> "n";
>             };
>             default -> "";
>         });
>     }
> 
>     int id(String s) {
>         return s.length();
>     }
> 
>     int id(int i) {
>         return i;
>     }
> 
> 
> Compiling this fails with a `StackOverflowError`, because:
>  - there are speculative attribution happening for the switch expressions,
>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
> 
> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
> 
> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
> 
> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
> 
> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
> 
> The intent is that the public API behavior for the `unknownType` should remain the same.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup - removing the unknownType.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20990/files
  - new: https://git.openjdk.org/jdk/pull/20990/files/71942f9d..4ef410fe

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

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

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

From duke at openjdk.org  Wed Oct  2 09:46:37 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 2 Oct 2024 09:46:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
 <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
Message-ID: <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>

On Tue, 1 Oct 2024 23:02:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.

Hello! I am not familiar with CSR process. I tried to find a way to file it using java bug database, but could not find anything. Could you tell me what should I do and where, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2388105307

From jlahoda at openjdk.org  Wed Oct  2 11:57:39 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Oct 2024 11:57:39 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
Message-ID: <mNLGsMt4GR481EC7WPKqtbHoC_9ayhjPYctAVZujcME=.a7f45ed5-3ede-45c4-a3ae-020528c379e5@github.com>

On Sat, 28 Sep 2024 22:31:14 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing line

Overall, I think this is good. Left some comments to make the test and style similar to what is generally used in javac, at least in my opinion. Thanks for doing this change!

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 427:

> 425:                 (env.enclClass.sym == sym.owner // fast special case
> 426:                  ||
> 427:                  env.info.isPermitsClause

I would suggest to have parentheses around the new test, i.e. around `env.info.isPermitsClause && ((JCClassDecl) env.tree).sym.outermostClass() == sym.owner.outermostClass()`, to make it clearer what is happening.

I would also suggest to reorder the tests, so that this new test is after the existing `env.enclClass.sym.outermostClass() == sym.owner.outermostClass()` (even at the cost of modifying the existing line to remove the `)`. It seems unnecessary to make almost all code go through the `env.info.isPermitsClause` check. I don't think there will be any real runtime difference, but still better to do the more common tests first. It is also, I think, better for reading the code to have the common cases earlier, unless there's another reason for the ordering.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 465:

> 463:         }
> 464:     }
> 465: 

Nit: please revert this change.

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 24:

> 22:  */
> 23: 
> 24: import java.nio.file.Path;

Nit: we usually (try to) put the jtreg tags/header right after the license header (if there's any), and put imports after that. The import is part of the test, the jtreg header is test configuration.

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 33:

> 31:  * @modules jdk.compiler/com.sun.tools.javac.api
> 32:  * jdk.compiler/com.sun.tools.javac.main
> 33:  * jdk.compiler/com.sun.tools.javac.util

Nit:
Suggestion:

 * @modules jdk.compiler/com.sun.tools.javac.api
 *                     jdk.compiler/com.sun.tools.javac.main
 *                     jdk.compiler/com.sun.tools.javac.util

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 74:

> 72:     public void givenPrivateClassOfOtherTopLevelClassInPermitsClause_whenCompiling_thenShouldFail() throws Exception {
> 73:         var root = Path.of("src");
> 74:         tb.writeJavaFiles(root,

Nit, up to you if you want to make the change: the `writeJavaFile` takes multiple `String`s, and can generate any number of files under the given directory. So the two calls to `writeJavaFile` can be coalesced to one.

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 92:

> 90:         new toolbox.JavacTask(tb)
> 91:             .files(root.resolve("S.java"), root.resolve("T.java"))
> 92:             .run(toolbox.Task.Expect.FAIL);

Negative tests should, unless there is a very good reason not to, verify the exact errors printed. Use `-XDrawDiagnostics` option, and `.getOutputLines(Task.OutputKind.DIRECT)` on the result to get the output lines. (And, preferably also `.writeAll()` on all `toolbox.JavacTask` runs, passing or failing.) See for example here:

https://github.com/openjdk/jdk/blob/855c8a7def21025bc2fc47594f7285a55924c213/test/langtools/tools/javac/ImportModule.java#L175

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

PR Review: https://git.openjdk.org/jdk/pull/20718#pullrequestreview-2342652009
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784351154
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784327802
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784355593
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784356470
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784353437
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784332032

From jlahoda at openjdk.org  Wed Oct  2 11:57:39 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Oct 2024 11:57:39 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
 <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
 <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>
Message-ID: <WagWd5GrHqyv04Mo1zuGVak4vYoI8IPncdR5KBpc3Es=.e9063e25-eb2f-4128-afbc-f1de864cd3fc@github.com>

On Wed, 2 Oct 2024 09:44:27 GMT, Evemose <duke at openjdk.org> wrote:

> > If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.
> 
> Hello! I am not familiar with CSR process. I tried to find a way to file it using java bug database, but could not find anything. Could you tell me what should I do and where, please?

In JBS, in the bug, there is "More", and if you click on that, there is "Create CSR". Click on that, and fill in the details in the text, as described in the template. When reviewing, I'll try to fill any flags that need to be filled (so that you know what gets filled next time).

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2388457216

From vromero at openjdk.org  Wed Oct  2 17:25:39 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Oct 2024 17:25:39 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
Message-ID: <xyEarL6bhaKHDTgyyBY56jyVLrJPrbZ4LNlE1icQvX0=.abb93d48-65ff-47d3-bb7a-31e0972656d1@github.com>

On Sat, 28 Sep 2024 22:31:14 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove trailing line

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java line 97:

> 95:     /** Are we attributing a permits clause?
> 96:      */
> 97:     boolean isPermitsClause = false;

you need to copy the value of this field in the ::dup method as it is done for other fields in this class

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 982:

> 980:                 ListBuffer<Symbol> permittedSubtypeSymbols = new ListBuffer<>();
> 981:                 List<JCExpression> permittedTrees = tree.permitting;
> 982:                 baseEnv.info.isPermitsClause = true;

usually we save the previous value of the field before setting a new value, then inside a `try` we invoke the code that should be aware of the field and then in the `finally` we restore the previous value of the field, see for example how we do for field `AttrContext::ctorPrologue`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784917292
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1784921558

From duke at openjdk.org  Thu Oct  3 04:22:41 2024
From: duke at openjdk.org (duke)
Date: Thu, 3 Oct 2024 04:22:41 GMT
Subject: Withdrawn: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <u2WvIWqFFjnC0lCbafiCTzZG-u8RaIiPoLi53W82Fn8=.6fb82cef-b9fa-40c6-867b-2f1821ca0758@github.com>

On Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
> 
> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.org  Thu Oct  3 10:24:37 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Oct 2024 10:24:37 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v7]
In-Reply-To: <wswtVZdd0051RvTCRTA26gOAP94wSiF0LKU4KTsCNtk=.a21f262c-bce2-4153-ad62-5e799298091e@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <wswtVZdd0051RvTCRTA26gOAP94wSiF0LKU4KTsCNtk=.a21f262c-bce2-4153-ad62-5e799298091e@github.com>
Message-ID: <dl3Y5IVUSaPQHyrBWosnRWo-wq5-rrs2YqOaziEJqcE=.615e56f1-68de-487f-b2b2-f058f5e7d721@github.com>

On Thu, 26 Sep 2024 08:48:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
>> 
>> #### Member inner classes
>> 
>> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
>> 
>> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
>> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
>> * `C` is a subclass of `M`?s enclosing class.
>> 
>> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
>> 
>> This check is defined in `Reslve::findSelfContaining`.
>> 
>> #### Local and anonymous inner classes
>> 
>> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
>> 
>> This check is defined in `Reslve::findLocalClassOwner`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak comments

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 53:

> 51: import com.sun.tools.javac.comp.DeferredAttr.AttrMode;
> 52: import com.sun.tools.javac.comp.MatchBindingsComputer.MatchBindings;
> 53: import com.sun.tools.javac.comp.Resolve.InvalidSymbolError;

Nit: these imports appear to be unused.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3790:

> 3788:                     Env<AttrContext> env,
> 3789:                     TypeSymbol c,
> 3790:                     Name name,

It is probably a matter of style, but for me, it would be easier if `name` would be dropped, and `names._this` would be used in `findFirst`. It took me a while before I realized `name` can only be `this`, so there cannot be more than one, so `findFirst` is "find it or return null", not "if there are multiple, return one of them".

test/langtools/tools/javac/LocalFreeVarStaticInstantiate.java line 19:

> 17:             }
> 18:         }
> 19:     }

I wonder if the test case should be enhanced with something like:

    Runnable r = () -> {
        Object there = "";
        class Local {
            {
                there.hashCode();
            }
            static {
                new Local();    // can't get there from here
            }
        }
    };


It works currently, as lambdas get a fake method owner if needed, so it would be just to make sure it remains working even if the handling of the lambdas changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19904#discussion_r1785973831
PR Review Comment: https://git.openjdk.org/jdk/pull/19904#discussion_r1785981909
PR Review Comment: https://git.openjdk.org/jdk/pull/19904#discussion_r1785966618

From mcimadamore at openjdk.org  Thu Oct  3 11:18:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Oct 2024 11:18:38 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v7]
In-Reply-To: <dl3Y5IVUSaPQHyrBWosnRWo-wq5-rrs2YqOaziEJqcE=.615e56f1-68de-487f-b2b2-f058f5e7d721@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <wswtVZdd0051RvTCRTA26gOAP94wSiF0LKU4KTsCNtk=.a21f262c-bce2-4153-ad62-5e799298091e@github.com>
 <dl3Y5IVUSaPQHyrBWosnRWo-wq5-rrs2YqOaziEJqcE=.615e56f1-68de-487f-b2b2-f058f5e7d721@github.com>
Message-ID: <tT0AxfJhnEPlrFmqFEJOrJYKMc9YD8mHYnmAscPd_80=.a9a75a38-2da3-401f-b639-733a877ebc6b@github.com>

On Thu, 3 Oct 2024 10:20:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3790:
> 
>> 3788:                     Env<AttrContext> env,
>> 3789:                     TypeSymbol c,
>> 3790:                     Name name,
> 
> It is probably a matter of style, but for me, it would be easier if `name` would be dropped, and `names._this` would be used in `findFirst`. It took me a while before I realized `name` can only be `this`, so there cannot be more than one, so `findFirst` is "find it or return null", not "if there are multiple, return one of them".

Good catch - this was mostly a leftover from the previous code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19904#discussion_r1786049501

From mcimadamore at openjdk.org  Thu Oct  3 12:07:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Oct 2024 12:07:45 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v7]
In-Reply-To: <dl3Y5IVUSaPQHyrBWosnRWo-wq5-rrs2YqOaziEJqcE=.615e56f1-68de-487f-b2b2-f058f5e7d721@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <wswtVZdd0051RvTCRTA26gOAP94wSiF0LKU4KTsCNtk=.a21f262c-bce2-4153-ad62-5e799298091e@github.com>
 <dl3Y5IVUSaPQHyrBWosnRWo-wq5-rrs2YqOaziEJqcE=.615e56f1-68de-487f-b2b2-f058f5e7d721@github.com>
Message-ID: <ArlWHGGlVul7XLYUt1SeEZexIDeOBLIKpkIzrUg08HQ=.d1294233-ed1a-49ed-a347-31c52f63a612@github.com>

On Thu, 3 Oct 2024 10:08:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak comments
>
> test/langtools/tools/javac/LocalFreeVarStaticInstantiate.java line 19:
> 
>> 17:             }
>> 18:         }
>> 19:     }
> 
> I wonder if the test case should be enhanced with something like:
> 
>     Runnable r = () -> {
>         Object there = "";
>         class Local {
>             {
>                 there.hashCode();
>             }
>             static {
>                 new Local();    // can't get there from here
>             }
>         }
>     };
> 
> 
> It works currently, as lambdas get a fake method owner if needed, so it would be just to make sure it remains working even if the handling of the lambdas changes.

I've beefed up the test. While doing so I realized that the generated diagnostic was suboptimal, so I've fixed that too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19904#discussion_r1786104947

From cushon at openjdk.org  Thu Oct  3 23:53:00 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 3 Oct 2024 23:53:00 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v2]
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <opgHOr0g42UIgDxQYf9H3Px_svuNGQOR3ZCsf17AbDw=.7cda0cb7-3f38-4aea-ba2a-9bc793eeb3cb@github.com>

> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
> 
> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.

Liam Miller-Cushon 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 four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8332744
 - Merge remote-tracking branch 'origin/master' into JDK-8332744
 - Use jdk.internal.misc.Unsafe instead of sun.misc.Unsafe in microbenchmarks to avoid a sunapi warning
 - [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19397/files
  - new: https://git.openjdk.org/jdk/pull/19397/files/6cd4fed2..e8ba518a

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

  Stats: 366039 lines in 4795 files changed: 284117 ins; 54835 del; 27087 mod
  Patch: https://git.openjdk.org/jdk/pull/19397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19397/head:pull/19397

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

From cushon at openjdk.org  Fri Oct  4 00:02:52 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 4 Oct 2024 00:02:52 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>

> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
> 
> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Migrate another use of sun.misc.Unsafewq

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19397/files
  - new: https://git.openjdk.org/jdk/pull/19397/files/e8ba518a..aa688777

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

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

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

From darcy at openjdk.org  Fri Oct  4 04:16:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 04:16:07 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
Message-ID: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>

Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

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

Commit messages:
 - JDK-8341483: Clarify special case handling of Types.getArrayType

Changes: https://git.openjdk.org/jdk/pull/21346/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21346&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341483
  Stats: 64 lines in 3 files changed: 52 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21346/head:pull/21346

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

From darcy at openjdk.org  Fri Oct  4 04:16:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 04:16:07 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <oKGRII7QwkhQcbnqfSJDihgMuzjQdb0UsnfYaiZRLJM=.f4bbf078-c58a-4017-a372-59fb667e2791@github.com>

On Fri, 4 Oct 2024 04:10:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

Different sections of the JLS imply an array of null type is outside of the language:

Per JLS 10.1:

"An array type is written as the name of an element type followed by some number of empty pairs of square brackets []"

Therefore, since the null type is not denotable, in other words from JLS 4.1

"Because the null type has no name, it is impossible to declare a variable of the null type or to cast to the null type. "

it is not possible to declare an array of null type.

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

PR Comment: https://git.openjdk.org/jdk/pull/21346#issuecomment-2392752997

From liach at openjdk.org  Fri Oct  4 04:36:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 04:36:33 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <hFCuZRiQ0mDVqCO1VfG4v54F_sKZx5_HPQXUGr2AjNQ=.9598e48a-93e9-4c89-945b-5f859b2d0dd2@github.com>

On Fri, 4 Oct 2024 04:10:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

Are array types valid component types of array types? Not sure how it works in the language, but an array type is not a valid component type if it has 255 dimensions.

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

PR Comment: https://git.openjdk.org/jdk/pull/21346#issuecomment-2392801335

From duke at openjdk.org  Fri Oct  4 08:50:53 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 4 Oct 2024 08:50:53 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v8]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <ZBPy74QBeXFxwQMWzJHUTx62V9-KXp5dpi_MJxoQF2w=.9058b71d-d084-42e7-9252-f02269c16571@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  address reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/3d6d5749..a81efa3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=06-07

  Stats: 71 lines in 4 files changed: 38 ins; 18 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/20718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20718/head:pull/20718

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

From darcy at openjdk.org  Fri Oct  4 17:24:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 17:24:06 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
Message-ID: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>

Fix broken links.

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

Commit messages:
 - JDK-8341541: Wrong anchor in wrapper classes links

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

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

From darcy at openjdk.org  Fri Oct  4 17:33:45 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 17:33:45 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
In-Reply-To: <hFCuZRiQ0mDVqCO1VfG4v54F_sKZx5_HPQXUGr2AjNQ=.9598e48a-93e9-4c89-945b-5f859b2d0dd2@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
 <hFCuZRiQ0mDVqCO1VfG4v54F_sKZx5_HPQXUGr2AjNQ=.9598e48a-93e9-4c89-945b-5f859b2d0dd2@github.com>
Message-ID: <UYFtJdG9a1GBY456qPJNfj8LR5vL_ph42ZtW1jqJKLY=.cc6e36cb-a7c9-4f5a-9a25-830f00caf26b@github.com>

On Fri, 4 Oct 2024 04:33:39 GMT, Chen Liang <liach at openjdk.org> wrote:

> Are array types valid component types of array types? Not sure how it works in the language, but an array type is not a valid component type if it has 255 dimensions.

Yes; an array type is a reference type and a multi-dimensional array is modeled as an array-of-arrays. I don't know if this particular build would check for the dimensional limit, but it wouldn't be an unreasonable case to add to the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/21346#issuecomment-2394207382

From duke at openjdk.org  Fri Oct  4 17:48:00 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 4 Oct 2024 17:48:00 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v9]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <mNCWwmFy6lSCR0jqlIKnBG0j-ubvi-fySyM5SalSY68=.343247c5-ff31-4b19-954a-afda98e7eb90@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  fix test failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/a81efa3d..a699206d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=07-08

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

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

From vromero at openjdk.org  Fri Oct  4 18:05:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Oct 2024 18:05:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v8]
In-Reply-To: <ZBPy74QBeXFxwQMWzJHUTx62V9-KXp5dpi_MJxoQF2w=.9058b71d-d084-42e7-9252-f02269c16571@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <ZBPy74QBeXFxwQMWzJHUTx62V9-KXp5dpi_MJxoQF2w=.9058b71d-d084-42e7-9252-f02269c16571@github.com>
Message-ID: <R3_qnb2AaUWWNXCsH9eQTr1HXvu1h7BJG7koHyKpLcY=.5f5ad1a8-efad-40d5-aa8c-79e8baaa3aef@github.com>

On Fri, 4 Oct 2024 08:50:53 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 59:

> 57: 
> 58:     @Test
> 59:     public void givenPrivateClassInPermitsClause_whenCompiling_thenShouldCompile() throws Exception {

I would use shorter method names, you can probably add more details about what the test does using javadoc or an internal comment

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 75:

> 73: 
> 74:     @Test
> 75:     public void givenPrivateClassOfOtherTopLevelClassInPermitsClause_whenCompiling_thenShouldFail() throws Exception {

this test is failing for me

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 146:

> 144: 
> 145:     @Test
> 146:     public void givenPrivateClassInPermitsClause_whenThanCompilingOtherClassThatReferencesPrivateClassInPermitsClause_thenShouldFail() throws Exception {

this one is failing for me too

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1788101400
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1788103398
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1788104962

From duke at openjdk.org  Fri Oct  4 18:15:50 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 4 Oct 2024 18:15:50 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v8]
In-Reply-To: <R3_qnb2AaUWWNXCsH9eQTr1HXvu1h7BJG7koHyKpLcY=.5f5ad1a8-efad-40d5-aa8c-79e8baaa3aef@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <ZBPy74QBeXFxwQMWzJHUTx62V9-KXp5dpi_MJxoQF2w=.9058b71d-d084-42e7-9252-f02269c16571@github.com>
 <R3_qnb2AaUWWNXCsH9eQTr1HXvu1h7BJG7koHyKpLcY=.5f5ad1a8-efad-40d5-aa8c-79e8baaa3aef@github.com>
Message-ID: <LdsNSJ-aF6reQ6uUWq9gN17KaGhxz8dl6YkxuxQhpYk=.e3989ed4-5e06-42bd-a2d2-92c6dba6899c@github.com>

On Fri, 4 Oct 2024 18:01:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address reviews
>
> test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 59:
> 
>> 57: 
>> 58:     @Test
>> 59:     public void givenPrivateClassInPermitsClause_whenCompiling_thenShouldCompile() throws Exception {
> 
> I would use shorter method names, you can probably add more details about what the test does using javadoc or an internal comment

it may be the way, but comments could become danglig over time, not sure if its the way. If I were writing with junit, I would use @DisplayName, not sure if there is something like this in jtreg. I will se what can be done though

> test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 146:
> 
>> 144: 
>> 145:     @Test
>> 146:     public void givenPrivateClassInPermitsClause_whenThanCompilingOtherClassThatReferencesPrivateClassInPermitsClause_thenShouldFail() throws Exception {
> 
> this one is failing for me too

It may be. I run heavy machine learning model on y pc right now, so i prefer to run tests using CI to not blow up my PC. I hope this doesnt bother anyone too much so I can figure out correct error messages that are expected in a few iterations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1788116720
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1788115036

From dlsmith at openjdk.org  Fri Oct  4 18:34:36 2024
From: dlsmith at openjdk.org (Dan Smith)
Date: Fri, 4 Oct 2024 18:34:36 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <d0iMJyaE6Sm8NmCjpR4HzIWGoryHkxtqroCNJ86zpgs=.1654e011-d717-4c6c-9565-db80ebf79d14@github.com>

On Fri, 4 Oct 2024 04:10:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

Looks good to me

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

Marked as reviewed by dlsmith (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21346#pullrequestreview-2348856779

From liach at openjdk.org  Fri Oct  4 18:44:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 18:44:34 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <9A9n_kh90foAPY3TC-druCNKy_Es7ZoMpJ7o09NV4u4=.c9087683-5d46-4a3e-a65f-9c2bf831b382@github.com>

On Fri, 4 Oct 2024 04:10:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

Please forgive my derp, that I forgot array types are reference types.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21346#pullrequestreview-2348871438

From prappo at openjdk.org  Fri Oct  4 19:02:43 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Oct 2024 19:02:43 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <vncyBiQ50RNmyW-eZeUdMYRDhkVjNbBpFButTvnz0aw=.a48afd74-4f3c-4847-a05f-46fd64a32e4b@github.com>

On Fri, 4 Oct 2024 04:10:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

src/java.compiler/share/classes/javax/lang/model/util/Types.java line 268:

> 266:      *          an array. All valid types are {@linkplain ReferenceType
> 267:      *          reference types} or {@linkplain PrimitiveType primitive types}.
> 268:      *          Invalid types include null, executable, package, module, and wildcard types.

Should it be somehow more clear that it's not `null`, but the __Null Type__. Maybe you can link to it as follows?

    {@linkplain NullType null}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21346#discussion_r1788122949

From prappo at openjdk.org  Fri Oct  4 19:10:36 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Oct 2024 19:10:36 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <e1CbjyeT_cI-uEbQS7Tga4TV1t0bIWwI1kaARXV89OU=.40c066a7-d676-4683-bdad-6ab7e488a989@github.com>

On Fri, 4 Oct 2024 04:10:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21346#pullrequestreview-2348916022

From hannesw at openjdk.org  Fri Oct  4 19:20:35 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Oct 2024 19:20:35 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
References: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
Message-ID: <7kax833PYl8WKYdCMBzMIpjAQb5eKpkrrcP-JM_pv50=.8eeaeda9-d7eb-42ba-9258-bedfebdd9951@github.com>

On Fri, 4 Oct 2024 17:17:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix broken links.

I hadn't caught the use of the plural form anchor in `Types.java`. Looks good.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21360#pullrequestreview-2348949061

From liach at openjdk.org  Fri Oct  4 19:25:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 19:25:34 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
References: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
Message-ID: <6-vPTk4_HOoFZnZnwMX9ZgSrlWvuPcww-ihZhcctHAM=.32ca16da-52cd-4934-baae-cfca1d089174@github.com>

On Fri, 4 Oct 2024 17:17:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix broken links.

Thanks, hannes' pr popped up first in the PR list so I omitted this one.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21360#pullrequestreview-2348973542

From darcy at openjdk.org  Fri Oct  4 19:27:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 19:27:16 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
 [v2]
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <S4J8gJTHt4DHFMFPKKRbZzOoefgl5uRNxc5YCPg_BTE=.4fda68c8-7e04-4867-a889-2b1d2f2f7b32@github.com>

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21346/files
  - new: https://git.openjdk.org/jdk/pull/21346/files/222cfa97..c016fb63

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

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

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

From darcy at openjdk.org  Fri Oct  4 19:27:17 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 19:27:17 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
 [v2]
In-Reply-To: <vncyBiQ50RNmyW-eZeUdMYRDhkVjNbBpFButTvnz0aw=.a48afd74-4f3c-4847-a05f-46fd64a32e4b@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
 <vncyBiQ50RNmyW-eZeUdMYRDhkVjNbBpFButTvnz0aw=.a48afd74-4f3c-4847-a05f-46fd64a32e4b@github.com>
Message-ID: <lAA8BQnKEeVus0rxo9WXz5pyU_3HRxFkeJ6S_jGwGpE=.e2004811-3455-4649-b54c-4e60fc591fd5@github.com>

On Fri, 4 Oct 2024 18:18:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.compiler/share/classes/javax/lang/model/util/Types.java line 268:
> 
>> 266:      *          an array. All valid types are {@linkplain ReferenceType
>> 267:      *          reference types} or {@linkplain PrimitiveType primitive types}.
>> 268:      *          Invalid types include null, executable, package, module, and wildcard types.
> 
> Should it be somehow more clear that it's not `null`, but the __Null Type__. Maybe you can link to it as follows?
> 
>     {@linkplain NullType null}

> Should it be somehow more clear that it's not `null`, but the **Null Type**. Maybe you can link to it as follows?
> 
> ```
> {@linkplain NullType null}
> ```

Good suggestion; implemented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21346#discussion_r1788210165

From darcy at openjdk.org  Fri Oct  4 19:28:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 19:28:40 GMT
Subject: Integrated: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
References: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
Message-ID: <TvBAO9E2bIG2QAM3lVMEkUe7zIOnleOq7nWDqHg4eGE=.b557ac6f-a716-4d3e-bf78-04d2086c8249@github.com>

On Fri, 4 Oct 2024 17:17:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix broken links.

This pull request has now been integrated.

Changeset: e70cbcfd
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e70cbcfd0c07c0334bf3d5fe20da806129d7565e
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8341541: Wrong anchor in wrapper classes links

Reviewed-by: hannesw, liach

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

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

From duke at openjdk.org  Fri Oct  4 19:33:14 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 4 Oct 2024 19:33:14 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v10]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <tf0ik3qnu5tY16_nbOnVdosTQmI5mg8qYglxnkwENrM=.567e7a3f-4d47-4ef2-8737-0bf1db142e06@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  fix test failures 2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/a699206d..70ba2755

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=08-09

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

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

From liach at openjdk.org  Fri Oct  4 19:36:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 19:36:36 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
 [v2]
In-Reply-To: <S4J8gJTHt4DHFMFPKKRbZzOoefgl5uRNxc5YCPg_BTE=.4fda68c8-7e04-4867-a889-2b1d2f2f7b32@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
 <S4J8gJTHt4DHFMFPKKRbZzOoefgl5uRNxc5YCPg_BTE=.4fda68c8-7e04-4867-a889-2b1d2f2f7b32@github.com>
Message-ID: <C4lY4TlLDqJkD2sIf7qIjZOTX5YXoV71XUGDakB1NQk=.a0b8ad2e-d139-42b9-a231-0a5b6a4da80d@github.com>

On Fri, 4 Oct 2024 19:27:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

The null type was confusing to me too.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21346#pullrequestreview-2349000118

From prappo at openjdk.org  Fri Oct  4 19:36:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Oct 2024 19:36:35 GMT
Subject: RFR: 8341483: Clarify special case handling of Types.getArrayType
 [v2]
In-Reply-To: <S4J8gJTHt4DHFMFPKKRbZzOoefgl5uRNxc5YCPg_BTE=.4fda68c8-7e04-4867-a889-2b1d2f2f7b32@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
 <S4J8gJTHt4DHFMFPKKRbZzOoefgl5uRNxc5YCPg_BTE=.4fda68c8-7e04-4867-a889-2b1d2f2f7b32@github.com>
Message-ID: <fFhGmel0YURmJHVNAJLzLMsW7oq9ihLc0WEbBKLa_O8=.068f1554-11d2-4577-ba93-216b18c3f9a3@github.com>

On Fri, 4 Oct 2024 19:27:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21346#pullrequestreview-2348998158

From darcy at openjdk.org  Fri Oct  4 20:34:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 20:34:40 GMT
Subject: Integrated: 8341483: Clarify special case handling of
 Types.getArrayType
In-Reply-To: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
References: <0eaoqpL2wsFx0cNrOj8N6xrPIVjl0TlL1mZByL6erH0=.b94d5425-ba73-4a25-8bf1-82ffcfd00ea6@github.com>
Message-ID: <tdPGQbI9-MPFtQUNU86iNco2oxOJQ0diiNob4qU7Qu4=.7d2ebe4a-c398-4cd3-8f38-36e4b71a33d7@github.com>

On Fri, 4 Oct 2024 04:10:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add specification and tests for invalid inputs to getArrayType that generation an exception. As initially written, this PR changes the behavior on NONE and the null type.

This pull request has now been integrated.

Changeset: a3e23572
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3e23572d5e879bd1c3b1755cf7be4601d03b62e
Stats:     65 lines in 3 files changed: 53 ins; 0 del; 12 mod

8341483: Clarify special case handling of Types.getArrayType

Reviewed-by: liach, prappo, dlsmith

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

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

From darcy at openjdk.org  Fri Oct  4 20:36:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 20:36:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <WagWd5GrHqyv04Mo1zuGVak4vYoI8IPncdR5KBpc3Es=.e9063e25-eb2f-4128-afbc-f1de864cd3fc@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
 <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
 <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>
 <WagWd5GrHqyv04Mo1zuGVak4vYoI8IPncdR5KBpc3Es=.e9063e25-eb2f-4128-afbc-f1de864cd3fc@github.com>
Message-ID: <HXsYYrnisntN4PKpZTtReiX9K1_DMvh52OfZAp_NffY=.769f07ea-cf5e-44e3-ba8b-a00475f8f7d9@github.com>

On Wed, 2 Oct 2024 11:54:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.
> 
> Hello! I am not familiar with CSR process. I tried to find a way to file it using java bug database, but could not find anything. Could you tell me what should I do and where, please?

The CSR process is documented at https://wiki.openjdk.org/display/csr/Main. To create a CSR from a JBS issue, go to "More -> Create CSR."

Myself and the other reviewers can help guide you in the process.

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2394527444

From duke at openjdk.org  Fri Oct  4 20:51:15 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 4 Oct 2024 20:51:15 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v11]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <ORiDFzZN1FRkEVlOf_P89BYj5H44NDfiOj8bpxPYQSM=.3a56071c-4c54-473e-9e38-e47e3222dd96@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  fix test failures 3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/70ba2755..18d346e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=09-10

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

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

From acobbs at openjdk.org  Fri Oct  4 21:38:41 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 4 Oct 2024 21:38:41 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
Message-ID: <FeGeskzaJqXqqZtaV-EkjsCNBbKwocddNMqYkUiQZeg=.94554539-8643-4010-8eb0-49c1635396bc@github.com>

On Fri, 6 Sep 2024 16:34:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337980
>  - Avoid crash caused by failure to resolve a valid AmbiguityError.

pingbot

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

PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2394702374

From duke at openjdk.org  Sat Oct  5 07:58:36 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 5 Oct 2024 07:58:36 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <HXsYYrnisntN4PKpZTtReiX9K1_DMvh52OfZAp_NffY=.769f07ea-cf5e-44e3-ba8b-a00475f8f7d9@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
 <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
 <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>
 <WagWd5GrHqyv04Mo1zuGVak4vYoI8IPncdR5KBpc3Es=.e9063e25-eb2f-4128-afbc-f1de864cd3fc@github.com>
 <HXsYYrnisntN4PKpZTtReiX9K1_DMvh52OfZAp_NffY=.769f07ea-cf5e-44e3-ba8b-a00475f8f7d9@github.com>
Message-ID: <kV--jpt4tLVP6EcgCHIZMjZ5XgJaVCbJizShJsvncF0=.48d274b1-ee6b-4d17-9b8a-b9844a4bcdcf@github.com>

On Fri, 4 Oct 2024 20:34:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > > If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.
> > 
> > 
> > Hello! I am not familiar with CSR process. I tried to find a way to file it using java bug database, but could not find anything. Could you tell me what should I do and where, please?
> 
> The CSR process is documented at https://wiki.openjdk.org/display/csr/Main. To create a CSR from a JBS issue, go to "More -> Create CSR."
> 
> Myself and the other reviewers can help guide you in the process.

I`m sorry, but I can not find any "More" button on bug page. Do I need an account in JBS in order to file CSR (i assume do since on page load there is a blinking second button new "Open" one that asks me to log in)? I am not an Oracle employee so I don't have one, and I am also not the one to report this issue

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2394971238

From duke at openjdk.org  Sun Oct  6 18:12:13 2024
From: duke at openjdk.org (Evemose)
Date: Sun, 6 Oct 2024 18:12:13 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v12]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <AkWcoAprApbF_8ox1mDn8UZ4xCoxienAPHUqIwNe3nE=.8679ca3e-9072-4007-9456-840f60115fa0@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  make method names shorter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/18d346e2..439aa2c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=10-11

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

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

From jpai at openjdk.org  Mon Oct  7 05:06:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 05:06:23 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v12]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <KwAOxEn-drtOn2AXIrNyqSptpJBD7gseQjYWX4zSeMA=.fd36cd19-02c4-403f-9b94-1a4ea7c5a5dc@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Christian's suggestion - keep OTHER as the last enum value
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - ... and 13 more: https://git.openjdk.org/jdk/compare/20f36c66...73f6d6e7

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=11
  Stats: 567 lines in 4 files changed: 558 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

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

From jpai at openjdk.org  Mon Oct  7 05:06:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 05:06:23 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v10]
In-Reply-To: <sc-iMOjzfOGiJEBtQYG2FOTR17IPNwA55xb_drW3dKM=.f36dc70e-9506-4cb8-b048-2981ef64fe60@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>
 <sc-iMOjzfOGiJEBtQYG2FOTR17IPNwA55xb_drW3dKM=.f36dc70e-9506-4cb8-b048-2981ef64fe60@github.com>
Message-ID: <6n34SVdshg9MTQDQSbG6qGAN2QICPNFNCig2M7sffN8=.2e006bba-265e-4e5b-95c9-55164e544d89@github.com>

On Tue, 10 Sep 2024 05:36:17 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - cleanup testExtractNoDestDirWithPFlag() test
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - convert the new test to junit
>>  - merge latest from master branch
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/56387a09...129375da
>
> src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 268:
> 
>> 266:         CREATE_UPDATE_INDEX("create.update.index"),
>> 267:         OTHER("other"),
>> 268:         EXTRACT("extract");
> 
> Is the order number important in this non-public `enum`? If not, I would expect `OTHER` to remain the last/highest entry.

Hello Christian, I've now updated the PR to keep `OTHER` as the last enum value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r1789496446

From jpai at openjdk.org  Mon Oct  7 05:58:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 05:58:53 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v13]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - use a fixed locale in the test to prevent failures on environments that are not en_US
 - add a test to verify extraction to a non-directory fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/73f6d6e7..0b8d5aaa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=11-12

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

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

From duke at openjdk.org  Mon Oct  7 11:29:37 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 7 Oct 2024 11:29:37 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
Message-ID: <brr4vH-y7IZwcJWI9XfH42xBcwWuDaDNFgh0YpqEQUY=.08f21cf4-081f-42a4-9d31-91b8d05d86dd@github.com>

On Mon, 3 Jun 2024 11:42:08 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> I fixed to get Charset from native.encoding instead of Charset.defaultCharset() when reading a file to which the output of javac run in the test was redirected.
> The modified code is based on the alternatives given in JEP400.
> I verified that the test passed on Windows in both Japanese and English locales with this fix.

I would appreciate it if someone could review it.

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

PR Comment: https://git.openjdk.org/jdk/pull/19519#issuecomment-2396659348

From darcy at openjdk.org  Mon Oct  7 15:33:44 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 7 Oct 2024 15:33:44 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <kV--jpt4tLVP6EcgCHIZMjZ5XgJaVCbJizShJsvncF0=.48d274b1-ee6b-4d17-9b8a-b9844a4bcdcf@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
 <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
 <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>
 <WagWd5GrHqyv04Mo1zuGVak4vYoI8IPncdR5KBpc3Es=.e9063e25-eb2f-4128-afbc-f1de864cd3fc@github.com>
 <HXsYYrnisntN4PKpZTtReiX9K1_DMvh52OfZAp_NffY=.769f07ea-cf5e-44e3-ba8b-a00475f8f7d9@github.com>
 <kV--jpt4tLVP6EcgCHIZMjZ5XgJaVCbJizShJsvncF0=.48d274b1-ee6b-4d17-9b8a-b9844a4bcdcf@github.com>
Message-ID: <ANOfyRE2bM33bZZp7kkUXWHbAIhxLz38QOZ-7LVXRd8=.d22728a7-0908-479b-9c03-54adf060edf3@github.com>

On Sat, 5 Oct 2024 07:56:23 GMT, Evemose <duke at openjdk.org> wrote:

> > > > If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.
> > > 
> > > 
> > > Hello! I am not familiar with CSR process. I tried to find a way to file it using java bug database, but could not find anything. Could you tell me what should I do and where, please?
> > 
> > 
> > The CSR process is documented at https://wiki.openjdk.org/display/csr/Main. To create a CSR from a JBS issue, go to "More -> Create CSR."
> > Myself and the other reviewers can help guide you in the process.
> 
> I`m sorry, but I can not find any "More" button on bug page. Do I need an account in JBS in order to file CSR (i assume do since on page load there is a blinking second button new "Open" one that asks me to log in)? I am not an Oracle employee so I don't have one, and I am also not the one to report this issue

Yes; someone with a JBS account will need to create the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2397255291

From mcimadamore at openjdk.org  Mon Oct  7 15:53:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 15:53:40 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
Message-ID: <Cb3puhnlrJyN1KFSgn2yxFAcji1amt-zO5BQVPUcF_c=.a9128f5b-269b-4511-afb8-1b6fb218435a@github.com>

On Fri, 6 Sep 2024 16:34:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337980
>  - Avoid crash caused by failure to resolve a valid AmbiguityError.

test/langtools/tools/javac/resolve/MethodAmbiguityCrash2.java line 23:

> 21: 
> 22:         public C() {
> 23:             this(op());     // compile should fail here

Question: the `mergeAbstracts` method IIRC returns a new method symbol whose owner and flags are those of the most specific signature. So, I wonder, if `B::op` returned `Object` and `A::op` returned `String`, would we still see the problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20533#discussion_r1790481359

From vromero at openjdk.org  Mon Oct  7 17:54:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Oct 2024 17:54:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <ANOfyRE2bM33bZZp7kkUXWHbAIhxLz38QOZ-7LVXRd8=.d22728a7-0908-479b-9c03-54adf060edf3@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
 <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
 <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>
 <WagWd5GrHqyv04Mo1zuGVak4vYoI8IPncdR5KBpc3Es=.e9063e25-eb2f-4128-afbc-f1de864cd3fc@github.com>
 <HXsYYrnisntN4PKpZTtReiX9K1_DMvh52OfZAp_NffY=.769f07ea-cf5e-44e3-ba8b-a00475f8f7d9@github.com>
 <kV--jpt4tLVP6EcgCHIZMjZ5XgJaVCbJizShJsvncF0=.48d274b1-ee6b-4d17-9b8a-b9844a4bcdcf@github.com>
 <ANOfyRE2bM33bZZp7kkUXWHbAIhxLz38QOZ-7LVXRd8=.d22728a7-0908-479b-9c03-54adf060edf3@github.com>
Message-ID: <_xtiIzqpfj7t50tnR6CTLxk1bUtENcrvxWFMNjuaJVw=.27a8181c-0410-477c-9240-8eb531316107@github.com>

On Mon, 7 Oct 2024 15:30:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > > > > If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.
> > > > 
> > > > 
> > > > Hello! I am not familiar with CSR process. I tried to find a way to file it using java bug database, but could not find anything. Could you tell me what should I do and where, please?
> > > 
> > > 
> > > The CSR process is documented at https://wiki.openjdk.org/display/csr/Main. To create a CSR from a JBS issue, go to "More -> Create CSR."
> > > Myself and the other reviewers can help guide you in the process.
> > 
> > 
> > I`m sorry, but I can not find any "More" button on bug page. Do I need an account in JBS in order to file CSR (i assume do since on page load there is a blinking second button new "Open" one that asks me to log in)? I am not an Oracle employee so I don't have one, and I am also not the one to report this issue
> 
> Yes; someone with a JBS account will need to create the CSR.

I have just created a blank one: https://bugs.openjdk.org/browse/JDK-8341669

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2397542956

From acobbs at openjdk.org  Mon Oct  7 18:00:38 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 7 Oct 2024 18:00:38 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <Cb3puhnlrJyN1KFSgn2yxFAcji1amt-zO5BQVPUcF_c=.a9128f5b-269b-4511-afb8-1b6fb218435a@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
 <Cb3puhnlrJyN1KFSgn2yxFAcji1amt-zO5BQVPUcF_c=.a9128f5b-269b-4511-afb8-1b6fb218435a@github.com>
Message-ID: <53AaPQTLvmqOCzsjarxKbge0MT4js8nKkg6gkF0aAOs=.a9f1ddb6-14c8-48f3-b7ed-25692a38cce6@github.com>

On Mon, 7 Oct 2024 15:51:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8337980
>>  - Avoid crash caused by failure to resolve a valid AmbiguityError.
>
> test/langtools/tools/javac/resolve/MethodAmbiguityCrash2.java line 23:
> 
>> 21: 
>> 22:         public C() {
>> 23:             this(op());     // compile should fail here
> 
> Question: the `mergeAbstracts` method IIRC returns a new method symbol whose owner and flags are those of the most specific signature. So, I wonder, if `B::op` returned `Object` and `A::op` returned `String`, would we still see the problem?

By the time `mergeAbstracts` is called in the patched version of the code, the problem in the original version of the code has already occurred, i.e., the behavior of `mergeAbstracts` is not involved in how the bug happens. I verified that with those changes (`B::op` returning `Object` and `A::op` returning `String`) the verify error still occurs - even when you change the other constructor to `public C(String x)` (so that `B::op` would have an incompatible return value). I also verified that the modified example also works correctly with the PR applied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20533#discussion_r1790654078

From mcimadamore at openjdk.org  Mon Oct  7 18:54:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 18:54:39 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <53AaPQTLvmqOCzsjarxKbge0MT4js8nKkg6gkF0aAOs=.a9f1ddb6-14c8-48f3-b7ed-25692a38cce6@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
 <Cb3puhnlrJyN1KFSgn2yxFAcji1amt-zO5BQVPUcF_c=.a9128f5b-269b-4511-afb8-1b6fb218435a@github.com>
 <53AaPQTLvmqOCzsjarxKbge0MT4js8nKkg6gkF0aAOs=.a9f1ddb6-14c8-48f3-b7ed-25692a38cce6@github.com>
Message-ID: <oag7tP4Y52DEpYc31xBWaVTcVSKlwIi8YpsEyZOFinM=.225a1d8b-e199-41aa-91ef-bf22f59a0e59@github.com>

On Mon, 7 Oct 2024 17:57:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> test/langtools/tools/javac/resolve/MethodAmbiguityCrash2.java line 23:
>> 
>>> 21: 
>>> 22:         public C() {
>>> 23:             this(op());     // compile should fail here
>> 
>> Question: the `mergeAbstracts` method IIRC returns a new method symbol whose owner and flags are those of the most specific signature. So, I wonder, if `B::op` returned `Object` and `A::op` returned `String`, would we still see the problem?
>
> By the time `mergeAbstracts` is called in the patched version of the code, the problem in the original version of the code has already occurred, i.e., the behavior of `mergeAbstracts` is not involved in how the bug happens. I verified that with those changes (`B::op` returning `Object` and `A::op` returning `String`) the verify error still occurs - even when you change the other constructor to `public C(String x)` (so that `B::op` would have an incompatible return value). I also verified that the modified example also works correctly with the PR applied.

I guess what I'm asking is whether there's some way to alter the declaration of the problematic methods so that the early-constructor context error is not reported - this seems possible if mergeAbstracts merges info using the interface method as a base symbol?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20533#discussion_r1790721118

From lancea at openjdk.org  Mon Oct  7 18:58:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 18:58:38 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v13]
In-Reply-To: <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
Message-ID: <I_Jq2GyqoX4dBeAZV0C3_bGvC5BePg-iPyNY9My2MAA=.9c2e09f8-bb40-40bd-a328-ad80a38b46be@github.com>

On Mon, 7 Oct 2024 05:58:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use a fixed locale in the test to prevent failures on environments that are not en_US
>  - add a test to verify extraction to a non-directory fails

Thank you Jai for getting this long outstanding PR across the finish line

looks good to me

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/2752#pullrequestreview-2352707299

From acobbs at openjdk.org  Mon Oct  7 20:01:36 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 7 Oct 2024 20:01:36 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <oag7tP4Y52DEpYc31xBWaVTcVSKlwIi8YpsEyZOFinM=.225a1d8b-e199-41aa-91ef-bf22f59a0e59@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
 <Cb3puhnlrJyN1KFSgn2yxFAcji1amt-zO5BQVPUcF_c=.a9128f5b-269b-4511-afb8-1b6fb218435a@github.com>
 <53AaPQTLvmqOCzsjarxKbge0MT4js8nKkg6gkF0aAOs=.a9f1ddb6-14c8-48f3-b7ed-25692a38cce6@github.com>
 <oag7tP4Y52DEpYc31xBWaVTcVSKlwIi8YpsEyZOFinM=.225a1d8b-e199-41aa-91ef-bf22f59a0e59@github.com>
Message-ID: <0-cXqA7Hw8UfY8H94xTH6jU9O0OdEu8w2OU-elPC60k=.d0341d37-823f-496d-8c69-388a11c62ed3@github.com>

On Mon, 7 Oct 2024 18:52:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> By the time `mergeAbstracts` is called in the patched version of the code, the problem in the original version of the code has already occurred, i.e., the behavior of `mergeAbstracts` is not involved in how the bug happens. I verified that with those changes (`B::op` returning `Object` and `A::op` returning `String`) the verify error still occurs - even when you change the other constructor to `public C(String x)` (so that `B::op` would have an incompatible return value). I also verified that the modified example also works correctly with the PR applied.
>
> I guess what I'm asking is whether there's some way to alter the declaration of the problematic methods so that the early-constructor context error is not reported - this seems possible if mergeAbstracts merges info using the interface method as a base symbol?

I think I understand what you're saying (but apologies in advance if not :)

This particular bug can only occur in situations where an error should be reported, but you're wondering whether a similar situation could happen in valid code, which would mean the `AmbiguityError` is allowed to float downstream and possibly cause problems later... is that correct?

I believe that this can't happen because it always eventually gets resolved via `BasicLookupHelper.lookup()` which is used by `resolveMethod()`, `resolveQualifiedMethod()`, etc.

For example, this class:

public class D {

    public interface A {
        String op();
    }

    public abstract static class B {
        public abstract Object op();
    }

    public abstract static class C extends B implements A {

        public void foo(Object x) {
        }

        public void bar() {
            foo(op());
        }
    }
} 

compiles successfully, and `D.C.bar()` will invoke the `A.op` variant:

public abstract class D$C extends D$B implements D$A {
...
  public void bar();
    Code:
       0: aload_0
       1: aload_0
       2: invokevirtual #7                  // Method op:()Ljava/lang/String;
       5: invokevirtual #13                 // Method foo:(Ljava/lang/Object;)V
       8: return
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20533#discussion_r1790799254

From duke at openjdk.org  Mon Oct  7 20:39:16 2024
From: duke at openjdk.org (Evemose)
Date: Mon, 7 Oct 2024 20:39:16 GMT
Subject: RFR: 8341669: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v13]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <tMHgU5s2yUih5x7qR5_uJk97Dmq1UT-2febQ7aKyQeE=.b9df8345-9ae8-44d3-80f6-f7150c4a4067@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  Change bugid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/439aa2c4..441adf9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=11-12

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

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

From duke at openjdk.org  Mon Oct  7 20:39:16 2024
From: duke at openjdk.org (Evemose)
Date: Mon, 7 Oct 2024 20:39:16 GMT
Subject: RFR: 8341669: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v7]
In-Reply-To: <_xtiIzqpfj7t50tnR6CTLxk1bUtENcrvxWFMNjuaJVw=.27a8181c-0410-477c-9240-8eb531316107@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <nDHugAkbbxSulC-_2eaO3_rMSo-YxwKt2BgujIF7I6o=.4be528b2-1950-4a30-b9de-d2ef3f36e46e@github.com>
 <Z9EwdqxcfpSCBSasK2hh1Ov6vIhzf3aCf-Etg07Ww6Q=.d7bbacb2-cead-4815-ab2f-bca743559d2a@github.com>
 <4rj5s3WUO9zD_W3WD77SSz8NAENujhe4cSwXQFMuhZ4=.801e4e5b-0fc3-4575-8878-f1d50810fcc6@github.com>
 <WagWd5GrHqyv04Mo1zuGVak4vYoI8IPncdR5KBpc3Es=.e9063e25-eb2f-4128-afbc-f1de864cd3fc@github.com>
 <HXsYYrnisntN4PKpZTtReiX9K1_DMvh52OfZAp_NffY=.769f07ea-cf5e-44e3-ba8b-a00475f8f7d9@github.com>
 <kV--jpt4tLVP6EcgCHIZMjZ5XgJaVCbJizShJsvncF0=.48d274b1-ee6b-4d17-9b8a-b9844a4bcdcf@github.com>
 <ANOfyRE2bM33bZZp7kkUXWHbAIhxLz38QOZ-7LVXRd8=.d22728a7-0908-479b-9c03-54adf060edf3@github.com>
 <_xtiIzqpfj7t50tnR6CTLxk1bUtENcrvxWFMNjuaJVw=.27a8181c-0410-477c-9240-8eb531316107@github.com>
Message-ID: <kgA24XUw41r0IodgJ_0Hxobcwn0jCWHikNIc7hZlv5w=.07cdbec4-438f-4e1f-9806-cefc33ec31d4@github.com>

On Mon, 7 Oct 2024 17:52:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > > > > > If this fix is proposing to align javac behavior with the JLS, while no spec change would be needed. A CSR would need to be filed for the behavioral change.
> > > > > 
> > > > > 
> > > > > Hello! I am not familiar with CSR process. I tried to find a way to file it using java bug database, but could not find anything. Could you tell me what should I do and where, please?
> > > > 
> > > > 
> > > > The CSR process is documented at https://wiki.openjdk.org/display/csr/Main. To create a CSR from a JBS issue, go to "More -> Create CSR."
> > > > Myself and the other reviewers can help guide you in the process.
> > > 
> > > 
> > > I`m sorry, but I can not find any "More" button on bug page. Do I need an account in JBS in order to file CSR (i assume do since on page load there is a blinking second button new "Open" one that asks me to log in)? I am not an Oracle employee so I don't have one, and I am also not the one to report this issue
> > 
> > 
> > Yes; someone with a JBS account will need to create the CSR.
> 
> I have just created a blank one: https://bugs.openjdk.org/browse/JDK-8341669, I will write the text of the CSR

Thanks. I have changed bugid in test and pr

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2397842882

From mcimadamore at openjdk.org  Mon Oct  7 20:53:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 20:53:35 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <0-cXqA7Hw8UfY8H94xTH6jU9O0OdEu8w2OU-elPC60k=.d0341d37-823f-496d-8c69-388a11c62ed3@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
 <Cb3puhnlrJyN1KFSgn2yxFAcji1amt-zO5BQVPUcF_c=.a9128f5b-269b-4511-afb8-1b6fb218435a@github.com>
 <53AaPQTLvmqOCzsjarxKbge0MT4js8nKkg6gkF0aAOs=.a9f1ddb6-14c8-48f3-b7ed-25692a38cce6@github.com>
 <oag7tP4Y52DEpYc31xBWaVTcVSKlwIi8YpsEyZOFinM=.225a1d8b-e199-41aa-91ef-bf22f59a0e59@github.com>
 <0-cXqA7Hw8UfY8H94xTH6jU9O0OdEu8w2OU-elPC60k=.d0341d37-823f-496d-8c69-388a11c62ed3@github.com>
Message-ID: <C4H8RCg3SueCFC6VcCtI96uCejduNSTirHUoXlIa7fQ=.d8a93bc4-718a-45c2-9295-f2a5df90da01@github.com>

On Mon, 7 Oct 2024 19:58:44 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I guess what I'm asking is whether there's some way to alter the declaration of the problematic methods so that the early-constructor context error is not reported - this seems possible if mergeAbstracts merges info using the interface method as a base symbol?
>
> I think I understand what you're saying (but apologies in advance if not :)
> 
> This particular bug can only occur in situations where an error should be reported, but you're wondering whether a similar situation could happen in valid code, which would mean the `AmbiguityError` is allowed to float downstream and possibly cause problems later... is that correct?
> 
> I believe that this can't happen because it always eventually gets resolved via `BasicLookupHelper.lookup()` which is used by `resolveMethod()`, `resolveQualifiedMethod()`, etc.
> 
> For example, this class:
> 
> public class D {
> 
>     public interface A {
>         String op();
>     }
> 
>     public abstract static class B {
>         public abstract Object op();
>     }
> 
>     public abstract static class C extends B implements A {
> 
>         public void foo(Object x) {
>         }
> 
>         public void bar() {
>             foo(op());
>         }
>     }
> } 
> 
> compiles successfully, and `D.C.bar()` will invoke the `A.op` variant:
> 
> public abstract class D$C extends D$B implements D$A {
> ...
>   public void bar();
>     Code:
>        0: aload_0
>        1: aload_0
>        2: invokevirtual #7                  // Method op:()Ljava/lang/String;
>        5: invokevirtual #13                 // Method foo:(Ljava/lang/Object;)V
>        8: return
> }

What I'm worried about is a situation where:
* multiple abstract methods are applicable
* one of the abstract method belongs to a class in an early construction context
* their signature needs to be merged
* when the signature is merged we use an interface as the owner for the symbol
* as a result, the early construction context error is missed (and I think the generated code will not pass the verifier)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20533#discussion_r1790860559

From acobbs at openjdk.org  Mon Oct  7 23:04:57 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 7 Oct 2024 23:04:57 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <C4H8RCg3SueCFC6VcCtI96uCejduNSTirHUoXlIa7fQ=.d8a93bc4-718a-45c2-9295-f2a5df90da01@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
 <Cb3puhnlrJyN1KFSgn2yxFAcji1amt-zO5BQVPUcF_c=.a9128f5b-269b-4511-afb8-1b6fb218435a@github.com>
 <53AaPQTLvmqOCzsjarxKbge0MT4js8nKkg6gkF0aAOs=.a9f1ddb6-14c8-48f3-b7ed-25692a38cce6@github.com>
 <oag7tP4Y52DEpYc31xBWaVTcVSKlwIi8YpsEyZOFinM=.225a1d8b-e199-41aa-91ef-bf22f59a0e59@github.com>
 <0-cXqA7Hw8UfY8H94xTH6jU9O0OdEu8w2OU-elPC60k=.d0341d37-823f-496d-8c69-388a11c62ed3@github.com>
 <C4H8RCg3SueCFC6VcCtI96uCejduNSTirHUoXlIa7fQ=.d8a93bc4-718a-45c2-9295-f2a5df90da01@github.com>
Message-ID: <3rcJ7vyvFNH_wgwdNmXxJd-O44_6-SmMf2W5MkPYeGU=.06e3fbad-b755-46db-97ff-c71b216731c1@github.com>

On Mon, 7 Oct 2024 20:51:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> one of the abstract method belongs to a class in an early construction context

I was thinking that because the two methods are inherited by a common subclass, and we are talking about an invocation `op()` in the context of that common subclass, then for any class `D` both method invocations are going to result in the same "class or interface to search" per ?15.12.1 "Compile-Time Step 1: Determine Type to Search". And so then (the flexible constructors version of) ?15.12.3 applies the same for both:

> Otherwise, let T be the class or interface to search (15.12.1). It is a compile-time error if ... the method invocation occurs in an early construction context (8.8.7.1) of class T...

In other words, it wouldn't be possible for one of the methods to "belong to a class in an early construction context" and the other not to... which would imply your scenario can't happen, right? Can you come up with an example where that isn't true?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20533#discussion_r1790983118

From cstein at openjdk.org  Tue Oct  8 05:26:08 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 8 Oct 2024 05:26:08 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v13]
In-Reply-To: <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
Message-ID: <JYvOQEE5QZI4NqeiYbqmJHM-UsOgeT_3xmVzqrlVWgY=.800f4316-6531-4446-98c8-48d32e6eb19e@github.com>

On Mon, 7 Oct 2024 05:58:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use a fixed locale in the test to prevent failures on environments that are not en_US
>  - add a test to verify extraction to a non-directory fails

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/2752#pullrequestreview-2353419284

From jpai at openjdk.org  Tue Oct  8 09:37:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 09:37:36 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v14]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <EJ6v8Htfhqy5Z_saZL57stAHUGaYkfHGSEN5MP-CDPI=.59cd7aac-ad17-4568-bb00-8fef5824358d@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update the man page of jar tool for the new option

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/0b8d5aaa..d4bce414

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=12-13

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

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

From jpai at openjdk.org  Tue Oct  8 09:47:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 09:47:02 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v14]
In-Reply-To: <EJ6v8Htfhqy5Z_saZL57stAHUGaYkfHGSEN5MP-CDPI=.59cd7aac-ad17-4568-bb00-8fef5824358d@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <EJ6v8Htfhqy5Z_saZL57stAHUGaYkfHGSEN5MP-CDPI=.59cd7aac-ad17-4568-bb00-8fef5824358d@github.com>
Message-ID: <rPZcHxZsU6tN4qQGxDisLhTgNqpsd8z8-WBIAwPPcBY=.6e120b7b-4b4a-4151-b378-8ecb782c7535@github.com>

On Tue, 8 Oct 2024 09:37:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the man page of jar tool for the new option

Thank you Lance and Christian for the reviews. Joe, in the CSR, rightly noted that I had missed including the man page changes. I've now updated the PR to include the man page update for the `jar` tool and also updated the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/2752#issuecomment-2399372409

From mcimadamore at openjdk.org  Tue Oct  8 12:59:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 12:59:02 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
Message-ID: <izjDvPHtnfT7T-vLqoGqIGMxViBL19EuSOBoKH0qgAk=.13b8d6e4-64e9-4e65-9300-7b733adf613b@github.com>

On Fri, 6 Sep 2024 16:34:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337980
>  - Avoid crash caused by failure to resolve a valid AmbiguityError.

I've double checked the code again, and I think I see where I made a wrong assumption. The "early construction" check in the code is based on the `env`. As such, it does not depend on whatever symbol is returned by `mergeAbstracts`. The code in this PR is ok.

Ultimately, this bug has to do with `findMethod` being called in a place (`findFun`) that does not follow up with the correct call to `mergeAbstract` (as this call is typically part of the `lookup` method in a `LookupHelper` - see e.g. `resolveMethod/resolveQualifiedMethod`).

What I'm a bit worried about with this fix is that it results in `mergeAbstracts` to be called *twice* when the code is correct. This seems bad, as `mergeAbstracts` is quite a complex routine. Ideally, `findFun` should return immediately if the result of `findMethod` "exists", and defer the check for static/early construction context to _after_ (e.g. when `mergeAbstracts` is normally called). Which I realize is challenging because by the time we call `mergeAbstract` outside `findFun`, we no longer have the `env` in which the symbol was found...

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

PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2399774573

From mcimadamore at openjdk.org  Tue Oct  8 13:04:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 13:04:01 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
Message-ID: <r3lKhhzfuf_85YssEtaDDiytur1VKCCwNn7LARjwCtc=.8cd19650-ca0d-4b54-8c08-c0930fa9ccd9@github.com>

On Fri, 6 Sep 2024 16:34:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337980
>  - Avoid crash caused by failure to resolve a valid AmbiguityError.

> I've double checked the code again, and I think I see where I made a wrong assumption. The "early construction" check in the code is based on the `env`. As such, it does not depend on whatever symbol is returned by `mergeAbstracts`. The code in this PR is ok.
> 
> Ultimately, this bug has to do with `findMethod` being called in a place (`findFun`) that does not follow up with the correct call to `mergeAbstract` (as this call is typically part of the `lookup` method in a `LookupHelper` - see e.g. `resolveMethod/resolveQualifiedMethod`).
> 
> What I'm a bit worried about with this fix is that it results in `mergeAbstracts` to be called _twice_ when the code is correct. This seems bad, as `mergeAbstracts` is quite a complex routine. Ideally, `findFun` should return immediately if the result of `findMethod` "exists", and defer the check for static/early construction context to _after_ (e.g. when `mergeAbstracts` is normally called). Which I realize is challenging because by the time we call `mergeAbstract` outside `findFun`, we no longer have the `env` in which the symbol was found...

A possible (albeit hacky) solution might be to return `checkSym`, not just sym. This way, the second call to mergeAbstract will be skipped.

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

PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2399784214

From mcimadamore at openjdk.org  Tue Oct  8 13:34:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 13:34:13 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
Message-ID: <I69HahRhzEsaQgQmnZGMPYfpO8clZFW-uojrzvZppNQ=.6a75bc29-beba-4ebf-b3d7-edd898e0049b@github.com>

On Fri, 6 Sep 2024 16:34:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337980
>  - Avoid crash caused by failure to resolve a valid AmbiguityError.

Something like this seems to work ok:


$ git diff
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 5bf1bc0ead1..55293535ff8 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -1853,6 +1853,10 @@ Symbol findMethod(Env<AttrContext> env,
                           bestSoFar,
                           allowBoxing,
                           useVarargs);
+        if (bestSoFar.kind == AMBIGUOUS) {
+            AmbiguityError a_err = (AmbiguityError)bestSoFar.baseSymbol();
+            bestSoFar = a_err.mergeAbstracts(site);
+        }
         return bestSoFar;
     }
     // where
@@ -2757,7 +2761,7 @@ Symbol resolveMethod(DiagnosticPosition pos,
         return lookupMethod(env, pos, env.enclClass.sym, resolveMethodCheck,
                 new BasicLookupHelper(name, env.enclClass.sym.type, argtypes, typeargtypes) {
                     @Override
-                    Symbol doLookup(Env<AttrContext> env, MethodResolutionPhase phase) {
+                    Symbol lookup(Env<AttrContext> env, MethodResolutionPhase phase) {
                         return findFun(env, name, argtypes, typeargtypes,
                                 phase.isBoxingRequired(),
                                 phase.isVarargsRequired());
@@ -2789,7 +2793,7 @@ private Symbol resolveQualifiedMethod(MethodResolutionContext resolveContext,
                                   List<Type> typeargtypes) {
         return lookupMethod(env, pos, location, resolveContext, new BasicLookupHelper(name, site, argtypes, typeargtypes) {
             @Override
-            Symbol doLookup(Env<AttrContext> env, MethodResolutionPhase phase) {
+            Symbol lookup(Env<AttrContext> env, MethodResolutionPhase phase) {
                 return findMethod(env, site, name, argtypes, typeargtypes,
                         phase.isBoxingRequired(),
                         phase.isVarargsRequired());
@@ -2913,7 +2917,7 @@ private Symbol resolveConstructor(MethodResolutionContext resolveContext,
                               List<Type> typeargtypes) {
         return lookupMethod(env, pos, site.tsym, resolveContext, new BasicLookupHelper(names.init, site, argtypes, typeargtypes) {
             @Override
-            Symbol doLookup(Env<AttrContext> env, MethodResolutionPhase phase) {
+            Symbol lookup(Env<AttrContext> env, MethodResolutionPhase phase) {
                 return findConstructor(pos, env, site, argtypes, typeargtypes,
                         phase.isBoxingRequired(),
                         phase.isVarargsRequired());
@@ -2972,7 +2976,7 @@ Symbol resolveDiamond(DiagnosticPosition pos,
         return lookupMethod(env, pos, site.tsym, resolveMethodCheck,
                 new BasicLookupHelper(names.init, site, argtypes, typeargtypes) {
                     @Override
-                    Symbol doLookup(Env<AttrContext> env, MethodResolutionPhase phase) {
+                    Symbol lookup(Env<AttrContext> env, MethodResolutionPhase phase) {
                         return findDiamond(pos, env, site, argtypes, typeargtypes,
                                 phase.isBoxingRequired(),
                                 phase.isVarargsRequired());
@@ -3503,18 +3507,6 @@ abstract class BasicLookupHelper extends LookupHelper {
             super(name, site, argtypes, typeargtypes, maxPhase);
         }
 
-        @Override
-        final Symbol lookup(Env<AttrContext> env, MethodResolutionPhase phase) {
-            Symbol sym = doLookup(env, phase);
-            if (sym.kind == AMBIGUOUS) {
-                AmbiguityError a_err = (AmbiguityError)sym.baseSymbol();
-                sym = a_err.mergeAbstracts(site);
-            }
-            return sym;
-        }
-
-        abstract Symbol doLookup(Env<AttrContext> env, MethodResolutionPhase phase);
-
         @Override
         Symbol access(Env<AttrContext> env, DiagnosticPosition pos, Symbol location, Symbol sym) {
             if (sym.kind.isResolutionError()) {
@@ -3561,10 +3553,6 @@ ReferenceLookupHelper unboundLookup(InferenceContext inferenceContext) {
         abstract JCMemberReference.ReferenceKind referenceKind(Symbol sym);
 
         Symbol access(Env<AttrContext> env, DiagnosticPosition pos, Symbol location, Symbol sym) {
-            if (sym.kind == AMBIGUOUS) {
-                AmbiguityError a_err = (AmbiguityError)sym.baseSymbol();
-                sym = a_err.mergeAbstracts(site);
-            }
             //skip error reporting
             return sym;
         }


(not saying you have to use this, mostly trying to explain more clearly what I meant with the above)

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

PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2399858704

From mcimadamore at openjdk.org  Tue Oct  8 14:42:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 14:42:07 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v7]
In-Reply-To: <wswtVZdd0051RvTCRTA26gOAP94wSiF0LKU4KTsCNtk=.a21f262c-bce2-4153-ad62-5e799298091e@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <wswtVZdd0051RvTCRTA26gOAP94wSiF0LKU4KTsCNtk=.a21f262c-bce2-4153-ad62-5e799298091e@github.com>
Message-ID: <ID0S-LHIZT5m_-lSj_TX1J6xhLfl9wyYQFgDqw5zEf4=.4530c760-26e0-4cdd-8412-f4a00b67dad1@github.com>

On Thu, 26 Sep 2024 08:48:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
>> 
>> #### Member inner classes
>> 
>> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
>> 
>> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
>> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
>> * `C` is a subclass of `M`?s enclosing class.
>> 
>> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
>> 
>> This check is defined in `Reslve::findSelfContaining`.
>> 
>> #### Local and anonymous inner classes
>> 
>> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
>> 
>> This check is defined in `Reslve::findLocalClassOwner`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak comments

I'm closing this pull request. I will be opening a new one shortly, with same code, but new JBS issue: JDK-8338288

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

PR Comment: https://git.openjdk.org/jdk/pull/19904#issuecomment-2400043404

From mcimadamore at openjdk.org  Tue Oct  8 15:08:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 15:08:24 GMT
Subject: RFR: 8338288: Compiler Implementation for Flexible Constructor Bodies
 (Third Preview)
Message-ID: <1cf2tlH_kW7ZZbm6tliHUuiFjK8GeJ5Oc2_66naUbGI=.4d9e60a8-9a1a-4dff-8518-f71e4a59b53c@github.com>

This PR contains the implementation for the third iteration of the [Flexible Constructor Bodies](https://openjdk.org/jeps/492) feature.

While the feature remains largely unchanged from the previous iteration, this PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via new, or, indirectly, via super. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what should happen, in the various cases.

#### Member inner classes

Whenever we see `new M()` where `M` is a member inner class, we need to lookup some `E.this` (where `E` is a class enclosing `M`), given none is provided. This same issue is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking `new M()`.

The lookup process for should look at all the enclosing instances available to us, and pick the innermost enclosing instance of type `E` such that `E` is a subclass of `M`'s enclosing class. It should be the case that  `E.this` is accessible (e.g. not in E?s early construction context) or a compile-time error should occur.

This new check is defined in `Resolve::findSelfContaining`.

#### Local and anonymous inner classes

When creating local and anonymous inner classes defined in a `static` method, we should *not* check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this (such classes have no enclosing instance). What matters, for local and anon classes defined in `static` methods, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.

This new check is defined in `Resolve::findLocalClassOwner`. While writing the code and looking at tests, I realized that existing diagnostics were not sufficient to capture this new condition. So I added a new one.

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

Commit messages:
 - Address review comments
 - Tweak comments
 - Tweak test and add positive test case
 - Avoid spurious errors in anon class constructor
 - Do not skip over classes in early construction context
 - Address review comment
 - Fix test summary
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/21410/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21410&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338288
  Stats: 479 lines in 19 files changed: 314 ins; 140 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/21410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21410/head:pull/21410

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

From acobbs at openjdk.org  Tue Oct  8 15:18:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Oct 2024 15:18:39 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <r3lKhhzfuf_85YssEtaDDiytur1VKCCwNn7LARjwCtc=.8cd19650-ca0d-4b54-8c08-c0930fa9ccd9@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
 <r3lKhhzfuf_85YssEtaDDiytur1VKCCwNn7LARjwCtc=.8cd19650-ca0d-4b54-8c08-c0930fa9ccd9@github.com>
Message-ID: <HsyRh-R_fT6Quzw9fri5iabfHT4Oc1_8EprROBWbYU0=.4334efd6-cb52-4f4b-8e50-54211095f23b@github.com>

On Tue, 8 Oct 2024 13:01:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What I'm a bit worried about with this fix is that it results in `mergeAbstracts` to be called _twice_ when the code is correct.

OK now I understand your concern. This didn't occur to me before because I was assuming that `mergeAbstracts` did not modify any existing data. From a superficial look, that appears to be the case, but regardless as you might guess by my original comment that "It's possible there is an opportunity for a more thorough refactoring here" I like your patch much better. I was already wondering why the ambiguity resolution logic wasn't being incorporated into `findMethod()` (the method is named `findMethod()` not `almostFindMethod()` after all!) as you have done and assumed there was some mysterious reason for it. Apparently not. So let's go with your patch - thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2400135979

From acobbs at openjdk.org  Tue Oct  8 15:18:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Oct 2024 15:18:39 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v3]
In-Reply-To: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
Message-ID: <gAZola0lca_k_IQ4tylHc64TQWfDtR2Jl1Eb-bo8-VM=.195d019c-6342-43cc-840f-176511cd4571@github.com>

> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
> 
> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
> 
> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
> 
> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
> 
> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
> 
> public class Bug {
> 
>     public interface A {
>         int op();
>     }
> 
>     public abstract static class B {
>         public abstract int op();
>     }
> 
>     public abstract static class C extends B implements A {
> 
>         public int test() {
>             return op();   // findMethod("op") returns both A.op() and B.op() here
>         }
>     }
> }
> 
> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Refactor patch to resolve AmbiguityError's eagerly within findMethod().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20533/files
  - new: https://git.openjdk.org/jdk/pull/20533/files/e0470d52..64264cfd

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

  Stats: 35 lines in 1 file changed: 4 ins; 21 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20533/head:pull/20533

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

From mcimadamore at openjdk.org  Tue Oct  8 15:32:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 15:32:00 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v2]
In-Reply-To: <HsyRh-R_fT6Quzw9fri5iabfHT4Oc1_8EprROBWbYU0=.4334efd6-cb52-4f4b-8e50-54211095f23b@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <eDexbR8U-s9zkJLlI75TG_aWopScslzx8_sLx45ZQGY=.4488dad7-8c30-4acd-8297-c2809c730412@github.com>
 <r3lKhhzfuf_85YssEtaDDiytur1VKCCwNn7LARjwCtc=.8cd19650-ca0d-4b54-8c08-c0930fa9ccd9@github.com>
 <HsyRh-R_fT6Quzw9fri5iabfHT4Oc1_8EprROBWbYU0=.4334efd6-cb52-4f4b-8e50-54211095f23b@github.com>
Message-ID: <wctxN4WHZutoTuR9Z5G2Doz3mxyAT8vlQw1rxhyFzzo=.8738e170-4db2-49a4-bbe7-6d64ee7b694a@github.com>

On Tue, 8 Oct 2024 15:14:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> OK now I understand your concern. This didn't occur to me before because I was assuming that `mergeAbstracts` did not modify any existing data. From a superficial look, that appears to be the case

This is indeed the case - the method doesn't change existing data. So we can call it multiple times. But it's a complex method doing some complex analysis to scan all the applicable abstract symbols and merge them into a new method. Doing all that work just to throw it a way - and then doing it all over again is a bit sad (but we can obviously live with that).

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

PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2400172077

From mcimadamore at openjdk.org  Tue Oct  8 15:35:09 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 15:35:09 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v3]
In-Reply-To: <gAZola0lca_k_IQ4tylHc64TQWfDtR2Jl1Eb-bo8-VM=.195d019c-6342-43cc-840f-176511cd4571@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <gAZola0lca_k_IQ4tylHc64TQWfDtR2Jl1Eb-bo8-VM=.195d019c-6342-43cc-840f-176511cd4571@github.com>
Message-ID: <T4834vMDj9g2iC95u0t5zSWkq18RGj6wMvB4UEC0I3Q=.2841bc44-c6d1-4131-925d-00d143288f47@github.com>

On Tue, 8 Oct 2024 15:18:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor patch to resolve AmbiguityError's eagerly within findMethod().

Marked as reviewed by mcimadamore (Reviewer).

@vicente-romero-oracle or @lahodaj please take a look. Thanks.

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

PR Review: https://git.openjdk.org/jdk/pull/20533#pullrequestreview-2354862586
PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2400179518

From acobbs at openjdk.org  Tue Oct  8 20:00:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Oct 2024 20:00:39 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
Message-ID: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>

This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.

This allows code like this to compile:

for (int i = 1; i <= 3; i++) {
    Runnable r = () -> System.out.println(i);
}

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

Commit messages:
 - Loosen conditions required for basic for() loop iteration variables to be captured in the loop body.

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

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

From mcimadamore at openjdk.org  Tue Oct  8 21:21:57 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 21:21:57 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <pLYjyCpv5wBxkxXsDg2Xgy3oNLExqTMHyZ789wsTTqo=.be708134-5992-475b-a075-d68bb981dc65@github.com>

On Tue, 8 Oct 2024 19:53:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2729:

> 2727:                     uninitsSkip.inclRange(firstadr, nextadr);
> 2728:                 }
> 2729:                 final Bits reassignedInForLoopBodyPrev = reassignedInForLoopBody;

My memory of this code is a bit rusty, so please bear with me... I seem to recall we mark all variables as effectively final, and then "unmark" them if see see them in `letInit`. If this is correct, could we simply re-force the effectively final flag of a loop variable before the loop body?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1792523413

From acobbs at openjdk.org  Tue Oct  8 22:19:01 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 8 Oct 2024 22:19:01 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <pLYjyCpv5wBxkxXsDg2Xgy3oNLExqTMHyZ789wsTTqo=.be708134-5992-475b-a075-d68bb981dc65@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <pLYjyCpv5wBxkxXsDg2Xgy3oNLExqTMHyZ789wsTTqo=.be708134-5992-475b-a075-d68bb981dc65@github.com>
Message-ID: <MeDVwbcqZJsee-fodMoKfPPfm_zT2f3aOGoAv1Wxp08=.a01e749c-f982-4b73-b0c4-e76d80f3f06a@github.com>

On Tue, 8 Oct 2024 21:19:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> could we simply re-force the effectively final flag of a loop variable before the loop body?

That's perfectly natural idea and at first I even tried it :)

The problem is that `AssignAnalyzer` is where DA/DU analysis happens, "effectively final" is computed, and where `letInit()` lives, but `CaptureAnalysis` is where we actually test for whether a lambda may capture a variable, and those are currently two independent steps, so it can't all be done "inline" in one pass.

Since "effectively final" is a global property of a variable that is independent of location, whereas the property we want to check is more like "effectively final in the associated loop body" (aka. "not reassigned in the loop body"), we need a new flag in order to pass along this new information.

Side note: flags seem in short supply, and both of these flags are only used within `Flow.java`, so instead of using flags we could keep this information private to `Flow.java`, e.g.:

    AssignAnalyzer aa = new AssignAnalyzer();
    aa.analyzeTree(env, make);
    ...
    new CaptureAnalyzer(aa).analyzeTree(env, make);
    ...

This would better follow the good housekeeping principle of limiting state to the minimum possible scope.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1792570262

From forax at openjdk.org  Wed Oct  9 05:05:57 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 9 Oct 2024 05:05:57 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <lKtqx_MlEGtCEAn2enyNm6ZvTmY-j6GjazyoZOjy54M=.37293432-87ab-4ff0-ab76-8db802abbf3f@github.com>

On Tue, 8 Oct 2024 19:53:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

Hello Archie, i'm very pleased you are working on this,
this is one issue we (the lambda expert group) wanted to fix but could not deliver in time for Java 8.

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

PR Comment: https://git.openjdk.org/jdk/pull/21415#issuecomment-2401322269

From jwaters at openjdk.org  Wed Oct  9 07:32:58 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Oct 2024 07:32:58 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <lKtqx_MlEGtCEAn2enyNm6ZvTmY-j6GjazyoZOjy54M=.37293432-87ab-4ff0-ab76-8db802abbf3f@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <lKtqx_MlEGtCEAn2enyNm6ZvTmY-j6GjazyoZOjy54M=.37293432-87ab-4ff0-ab76-8db802abbf3f@github.com>
Message-ID: <5tZsYhoPIclTjvphWeHosoaat_S70Riu33fdR-CRTJQ=.e234b5c9-e65c-441b-9e79-63034c23559f@github.com>

On Wed, 9 Oct 2024 05:03:29 GMT, R?mi Forax <forax at openjdk.org> wrote:

> Hello Archie, i'm very pleased you are working on this, this is one issue we (the lambda expert group) wanted to fix but could not deliver in time for Java 8.

Wow, seems like it was forgotten about for a long time if it was planned all the way back in Java 8

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

PR Comment: https://git.openjdk.org/jdk/pull/21415#issuecomment-2401549439

From forax at openjdk.org  Wed Oct  9 07:45:56 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 9 Oct 2024 07:45:56 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <MVPgCVuEUQ9NlEnqvUL0r9CuNUc29YWMUrb5U99v5U8=.350267f9-0ac7-4ecb-8b28-bdaeb737ded0@github.com>

On Tue, 8 Oct 2024 19:53:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

That's the curse of small language improvements, there is always a bigger one more important to spec/implement.

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

PR Comment: https://git.openjdk.org/jdk/pull/21415#issuecomment-2401577660

From mcimadamore at openjdk.org  Wed Oct  9 09:08:56 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Oct 2024 09:08:56 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <MeDVwbcqZJsee-fodMoKfPPfm_zT2f3aOGoAv1Wxp08=.a01e749c-f982-4b73-b0c4-e76d80f3f06a@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <pLYjyCpv5wBxkxXsDg2Xgy3oNLExqTMHyZ789wsTTqo=.be708134-5992-475b-a075-d68bb981dc65@github.com>
 <MeDVwbcqZJsee-fodMoKfPPfm_zT2f3aOGoAv1Wxp08=.a01e749c-f982-4b73-b0c4-e76d80f3f06a@github.com>
Message-ID: <nXe2Q-ggQUI33-XMPyv8f6hd0Zd4UVq-udTQyxXfjMw=.8572aaf0-3a2c-4ae2-8603-b053a8dac949@github.com>

On Tue, 8 Oct 2024 22:16:46 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> That's perfectly natural idea and at first I even tried it :)
> 
> The problem is that `AssignAnalyzer` is where DA/DU analysis happens, "effectively final" is computed, and where `letInit()` lives, but `CaptureAnalysis` is where we actually test for whether a lambda may capture a variable, and those are currently two independent steps, so it can't all be done "inline" in one pass.

I see the problem - thanks for the explanation. Now that I remember more of the code, there's a reason why effective finality is determined as part of DA/DU - that has to do with some enhancements we did in Java 8 to allow for "blank" effectively final variables. That is a variable like this:


int i;
if (cond) {
   i = 2;
} else {
   i = 3;
}


Is considered effectively final (unless is further mutated), even though it lacks an initializer and there is some control flow. So we settled to do that in the two passes you describe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1793153372

From mcimadamore at openjdk.org  Wed Oct  9 09:16:57 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Oct 2024 09:16:57 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>

On Tue, 8 Oct 2024 19:53:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2733:

> 2731:                 try {
> 2732:                     scan(tree.body);
> 2733:                     for (int adr = forLoopVarMin; adr < forLoopVarMax; adr++) {

Question: since we already have a dedicated flag for loop variables - could we set the flag on _all_ loop variables (before the body), and then remove it in `letInit` (same as we do for effectively final flag) ? This way, at the end of the loop, the variables that still have the flag set will be the ones that have not been reassigned, correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1793165126

From mcimadamore at openjdk.org  Wed Oct  9 09:23:56 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Oct 2024 09:23:56 GMT
Subject: RFR: 8341782: Allow lamba capture of basic for() loop variables as
 with enhanced for()
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <719UfuCfy368ec9yZ-OaWLLlmLYeyAonawEE8TN8s64=.e12b46c0-1495-4359-8dea-d29d9ded47ef@github.com>

On Tue, 8 Oct 2024 19:53:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3486:

> 3484:             // Collect the for() loop iteration variables with the FOR_LOOP_BODY_MAY_CAPTURE flag
> 3485:             HashSet<VarSymbol> capturableForLoopVars = null;
> 3486:             if (tree.init != null) {

This is a bit unfortunate. In principle, a variable has `FOR_LOOP_BODY_MAY_CAPTURE` should just be  `EFFECTIVELY_FINAL` - at least in the context of the for loop body. I suppose there's still a problem that we'd have to unset `EFFECTIVELY_FINAL` after the loop body... but I wonder, do we care? After all, we have already flow-analyzed the other for-loop parts (condition and step), so perhaps we just set `EFFECTIVELY_FINAL` before scanning the loop body, and leave it there?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1793174708

From jlahoda at openjdk.org  Wed Oct  9 10:52:01 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Oct 2024 10:52:01 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v3]
In-Reply-To: <gAZola0lca_k_IQ4tylHc64TQWfDtR2Jl1Eb-bo8-VM=.195d019c-6342-43cc-840f-176511cd4571@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <gAZola0lca_k_IQ4tylHc64TQWfDtR2Jl1Eb-bo8-VM=.195d019c-6342-43cc-840f-176511cd4571@github.com>
Message-ID: <nmwFA_Prj5Fbn0cqwiczQwHzv2Oe8nOdoy2O-db6wfA=.f3a16834-cf58-42d8-93b5-5d1b5b4a22cf@github.com>

On Tue, 8 Oct 2024 15:18:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor patch to resolve AmbiguityError's eagerly within findMethod().

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20533#pullrequestreview-2356777862

From mcimadamore at openjdk.org  Wed Oct  9 11:15:59 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Oct 2024 11:15:59 GMT
Subject: RFR: 8341669: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v13]
In-Reply-To: <tMHgU5s2yUih5x7qR5_uJk97Dmq1UT-2febQ7aKyQeE=.b9df8345-9ae8-44d3-80f6-f7150c4a4067@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <tMHgU5s2yUih5x7qR5_uJk97Dmq1UT-2febQ7aKyQeE=.b9df8345-9ae8-44d3-80f6-f7150c4a4067@github.com>
Message-ID: <2PaSVFRAJ3wtFddhY0KgB0BELSSI82tVDMYCzZxeSaA=.3ed42a72-c65f-405f-bb57-06bdf635a471@github.com>

On Mon, 7 Oct 2024 20:39:16 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change bugid

Marked as reviewed by mcimadamore (Reviewer).

The fix looks good, and it seems to reflect the spirit of the JLS.

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

PR Review: https://git.openjdk.org/jdk/pull/20718#pullrequestreview-2356834916
PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2402028815

From duke at openjdk.org  Wed Oct  9 11:34:24 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 9 Oct 2024 11:34:24 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v14]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  Revert bugid change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/441adf9f..efefc762

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=12-13

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

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

From acobbs at openjdk.org  Wed Oct  9 15:41:00 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Oct 2024 15:41:00 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
Message-ID: <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>

On Wed, 9 Oct 2024 09:13:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
>> 
>> This allows code like this to compile:
>> 
>> for (int i = 1; i <= 3; i++) {
>>     Runnable r = () -> System.out.println(i);
>> }
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2733:
> 
>> 2731:                 try {
>> 2732:                     scan(tree.body);
>> 2733:                     for (int adr = forLoopVarMin; adr < forLoopVarMax; adr++) {
> 
> Question: since we already have a dedicated flag for loop variables - could we set the flag on _all_ loop variables (before the body), and then remove it in `letInit` (same as we do for effectively final flag) ? This way, at the end of the loop, the variables that still have the flag set will be the ones that have not been reassigned, correct?

Yes - that could be a simpler way to do it. It would allow for the elimination of the `reassignedInForLoopBodyPrev` bit set, which is currently serving the same purpose (but in reverse). However, there would be two new concerns:
* We would need a new flag that says "we are currently in the for() loop body" and not, for example, in the step, where we should leave the flag alone.
* We would also need to ensure we don't get confused with nested `for()` loops. So the aforementioned flag can't just be a boolean (because otherwise which `for()` loop are we talking about?). For example, a symbol address range instead.

That would end up looking something like this... WDYT?

index 29ab8435ada..aa908902059 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
@@ -2146,6 +2148,12 @@ public class AssignAnalyzer extends BaseAnalyzer {
          */
         WriteableScope unrefdResources;
 
+        /** In a basic for() loop body, this is the address range of the loop variables.
+         *  If we see a reassignment to any of these variables, we clear the variable's
+         *  FOR_LOOP_BODY_MAY_CAPTURE flag (where "reassigned" means "assigned when not DU").
+         */
+        AddressRange forLoopVarsInBody;
+
         /** Modified when processing a loop body the second time for DU analysis. */
         FlowKind flowKind = FlowKind.NORMAL;
 
@@ -2231,6 +2239,11 @@ void newVar(JCVariableDecl varDecl) {
          */
         void letInit(DiagnosticPosition pos, VarSymbol sym) {
             if (sym.adr >= firstadr && trackable(sym)) {
+
+                // In basic for() loop bodies, variables that are reassigned can no longer be captured
+                if (forLoopVarsInBody != null && forLoopVarsInBody.test(sym.adr) && !uninits.isMember(sym.adr))
+                    sym.flags_field &= ~FOR_LOOP_BODY_MAY_CAPTURE;
+
                 if ((sym.flags() & EFFECTIVELY_FINAL) != 0) {
                     if (!uninits.isMember(sym.adr)) {
                         //assignment targeting an effectively final variable
@@ -2691,6 +2704,7 @@ public void visitForLoop(JCForLoop tree) {
             flowKind = FlowKind.NORMAL;
             int nextadrPrev = nextadr;
             scan(tree.init);
+            final AddressRange loopVars = new AddressRange(nextadrPrev, nextadr);
             final Bits initsSkip = new Bits(true);
             final Bits uninitsSkip = new Bits(true);
             pendingExits = new ListBuffer<>();
@@ -2712,7 +2726,16 @@ public void visitForLoop(JCForLoop tree) {
                     uninitsSkip.assign(uninits);
                     uninitsSkip.inclRange(firstadr, nextadr);
                 }
-                scan(tree.body);
+                final AddressRange forLoopVarsInBodyPrev = forLoopVarsInBody;
+                forLoopVarsInBody = loopVars;
+                try {
+                    loopVars.stream()
+                      .mapToObj(adr -> vardecls[adr].sym)
+                      .forEach(sym -> sym.flags_field |= FOR_LOOP_BODY_MAY_CAPTURE);
+                    scan(tree.body);
+                } finally {
+                    forLoopVarsInBody = forLoopVarsInBodyPrev;
+                }
                 resolveContinues(tree);
                 scan(tree.step);
                 if (log.nerrors != prevErrors ||
@@ -3270,6 +3293,20 @@ public void analyzeTree(Env<?> env, JCTree tree, TreeMaker make) {
         }
     }
 
+    /** A contiguous range of symbol addresses.
+     */
+    record AddressRange(int min, int max) implements IntPredicate {
+
+        @Override
+        public boolean test(int adr) {
+            return adr >= this.min() && adr < this.max();
+        }
+
+        public IntStream stream() {
+            return IntStream.range(this.min(), this.max());
+        }
+    }
+
     /**
      * This pass implements the last step of the dataflow analysis, namely
      * the effectively-final analysis check. This checks that every local variable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1793750314

From acobbs at openjdk.org  Wed Oct  9 15:59:07 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Oct 2024 15:59:07 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <719UfuCfy368ec9yZ-OaWLLlmLYeyAonawEE8TN8s64=.e12b46c0-1495-4359-8dea-d29d9ded47ef@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <719UfuCfy368ec9yZ-OaWLLlmLYeyAonawEE8TN8s64=.e12b46c0-1495-4359-8dea-d29d9ded47ef@github.com>
Message-ID: <qFhiZemSLzRllrfKcB2Z_N6D4tZZXjlb94mVmUv-AEE=.1743248e-f9e7-4997-bbb8-e2443a9ede9b@github.com>

On Wed, 9 Oct 2024 09:20:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
>> 
>> This allows code like this to compile:
>> 
>> for (int i = 1; i <= 3; i++) {
>>     Runnable r = () -> System.out.println(i);
>> }
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3486:
> 
>> 3484:             // Collect the for() loop iteration variables with the FOR_LOOP_BODY_MAY_CAPTURE flag
>> 3485:             HashSet<VarSymbol> capturableForLoopVars = null;
>> 3486:             if (tree.init != null) {
> 
> This is a bit unfortunate. In principle, a variable has `FOR_LOOP_BODY_MAY_CAPTURE` should just be  `EFFECTIVELY_FINAL` - at least in the context of the for loop body. I suppose there's still a problem that we'd have to unset `EFFECTIVELY_FINAL` after the loop body... but I wonder, do we care? After all, we have already flow-analyzed the other for-loop parts (condition and step), so perhaps we just set `EFFECTIVELY_FINAL` before scanning the loop body, and leave it there?

We can't really mess with `EFFECTIVELY_FINAL` at all, because we need to preserve the current behavior in the init, condition, and step, so that you still get an error in this example:

for (int i = 0;
  i++ + ((IntSupplier)() -> i).getAsInt() < 3; ) {      // error - i is not effectively final
    ((IntSupplier)() -> i).getAsInt();                  // ok - i is effectively final in the body
}

Put another way, I don't see how we could avoid having two separate "effectively final" flags - one for the loop body, and the original one for everything else, at least, not without combining `AssignAnalyzer` and `CaptureAnalyzer`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1793776827

From acobbs at openjdk.org  Wed Oct  9 16:07:18 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Oct 2024 16:07:18 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance
 method from a static method [v3]
In-Reply-To: <gAZola0lca_k_IQ4tylHc64TQWfDtR2Jl1Eb-bo8-VM=.195d019c-6342-43cc-840f-176511cd4571@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
 <gAZola0lca_k_IQ4tylHc64TQWfDtR2Jl1Eb-bo8-VM=.195d019c-6342-43cc-840f-176511cd4571@github.com>
Message-ID: <cOAocyJvpx6rWvwWjuvurgfZK5DNSi6ew7NRtsnYRuE=.7e523680-bbc2-4514-98ab-61e2483ec355@github.com>

On Tue, 8 Oct 2024 15:18:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
>> 
>> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
>> 
>> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
>> 
>> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
>> 
>> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
>> 
>> public class Bug {
>> 
>>     public interface A {
>>         int op();
>>     }
>> 
>>     public abstract static class B {
>>         public abstract int op();
>>     }
>> 
>>     public abstract static class C extends B implements A {
>> 
>>         public int test() {
>>             return op();   // findMethod("op") returns both A.op() and B.op() here
>>         }
>>     }
>> }
>> 
>> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor patch to resolve AmbiguityError's eagerly within findMethod().

Thanks for the reviews! I'm glad that it resulted in a nice code simplification as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20533#issuecomment-2402732862

From acobbs at openjdk.org  Wed Oct  9 16:07:19 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Oct 2024 16:07:19 GMT
Subject: Integrated: 8337980: Javac allows invocation of an inherited instance
 method from a static method
In-Reply-To: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
References: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>
Message-ID: <szw9AnIDAPY_qYtV_HQ12FnNepWvWwNFL2gzA7XJ5Yw=.7f5c8172-ad0c-4706-9d46-aca2a9c44969@github.com>

On Fri, 9 Aug 2024 20:45:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.
> 
> In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.
> 
> However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.
> 
> When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.
> 
> Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:
> 
> public class Bug {
> 
>     public interface A {
>         int op();
>     }
> 
>     public abstract static class B {
>         public abstract int op();
>     }
> 
>     public abstract static class C extends B implements A {
> 
>         public int test() {
>             return op();   // findMethod("op") returns both A.op() and B.op() here
>         }
>     }
> }
> 
> The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.

This pull request has now been integrated.

Changeset: 38c1d651
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38c1d6514881363ffa4ed20b34bd8cdfd8343f5f
Stats:     77 lines in 5 files changed: 57 ins; 16 del; 4 mod

8337980: Javac allows invocation of an inherited instance method from a static method

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore, jlahoda

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

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

From jlahoda at openjdk.org  Wed Oct  9 20:16:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Oct 2024 20:16:19 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second Preview)
Message-ID: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>

This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.

The main changes are:
- `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
- the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
- the types imported through module imports can be shadowed using on-demand imports. So, for example, having:

import module java.base;
import module java.desktop;
...
List l;//ambigous

but:

import module java.base;
import module java.desktop;
import java.util.*;
...
List l;//not ambigous, reference to java.util.List

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

Commit messages:
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - Adding a separate scope for module imports.
 - Cleanup.
 - Make very sure java.base is completed.
 - Keep jdk.internal.javac qualified export from java.base.
 - Adding forgotten change.
 - java.se is participating in preview.
 - Adding forgotten change.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/8c8f0d85...18554144

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335989
  Stats: 707 lines in 26 files changed: 550 ins; 44 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/21431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21431/head:pull/21431

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

From acobbs at openjdk.org  Wed Oct  9 20:26:19 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Oct 2024 20:26:19 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <5tZsYhoPIclTjvphWeHosoaat_S70Riu33fdR-CRTJQ=.e234b5c9-e65c-441b-9e79-63034c23559f@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <lKtqx_MlEGtCEAn2enyNm6ZvTmY-j6GjazyoZOjy54M=.37293432-87ab-4ff0-ab76-8db802abbf3f@github.com>
 <5tZsYhoPIclTjvphWeHosoaat_S70Riu33fdR-CRTJQ=.e234b5c9-e65c-441b-9e79-63034c23559f@github.com>
Message-ID: <SfbWV6v7iv-RAVlEZf4h2kiSNhRR1KJmM7pjG3cs9cc=.6f5b606f-f27d-4453-8f20-2fe9f33b25b9@github.com>

On Wed, 9 Oct 2024 07:30:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Hello Archie, i'm very pleased you are working on this,
> this is one issue we (the lambda expert group) wanted to fix but could not deliver in time for Java 8.

Hi R?mi, thanks - happy to help. The little bits are more my size :)

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

PR Comment: https://git.openjdk.org/jdk/pull/21415#issuecomment-2403362985

From mcimadamore at openjdk.org  Wed Oct  9 21:27:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Oct 2024 21:27:12 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
Message-ID: <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>

On Wed, 9 Oct 2024 15:38:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> * We would need a new flag that says "we are currently in the for() loop body" and not, for example, in the step, where we should leave the flag alone.

Well, my idea for doing that was to just set the flag on the loop variables before scanning the loop body (as you seem to do in the patch you show)

> 
> * We would also need to ensure we don't get confused with nested `for()` loops. So the aforementioned flag can't just be a boolean (because otherwise which `for()` loop are we talking about?). For example, a symbol address range instead.

This I don't get. If you have a loop nested inside another loop, you want assignments in the inner loop to affect whether the outer loop variable is considered a "loop capturable variable" or not. So I'm not sure - it seems to me `letInit` should happily remove flags for any variable it sees marked with `FOR_LOOP_BODY_MAY_CAPTURE` (as that is surely a variable of a for loop and we must be in that loop's body for the variable to have that flag set?)

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 3486:
>> 
>>> 3484:             // Collect the for() loop iteration variables with the FOR_LOOP_BODY_MAY_CAPTURE flag
>>> 3485:             HashSet<VarSymbol> capturableForLoopVars = null;
>>> 3486:             if (tree.init != null) {
>> 
>> This is a bit unfortunate. In principle, a variable has `FOR_LOOP_BODY_MAY_CAPTURE` should just be  `EFFECTIVELY_FINAL` - at least in the context of the for loop body. I suppose there's still a problem that we'd have to unset `EFFECTIVELY_FINAL` after the loop body... but I wonder, do we care? After all, we have already flow-analyzed the other for-loop parts (condition and step), so perhaps we just set `EFFECTIVELY_FINAL` before scanning the loop body, and leave it there?
>
> We can't really mess with `EFFECTIVELY_FINAL` at all, because we need to preserve the current behavior in the init, condition, and step, so that you still get an error in this example:
> 
> for (int i = 0;
>   i++ + ((IntSupplier)() -> i).getAsInt() < 3; ) {      // error - i is not effectively final
>     ((IntSupplier)() -> i).getAsInt();                  // ok - i is effectively final in the body
> }
> 
> Put another way, I don't see how we could avoid having two separate "effectively final" flags - one for the loop body, and the original one for everything else, at least, not without combining `AssignAnalyzer` and `CaptureAnalyzer`.

True. The sequencing between the two visitors is problematic here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1794242314
PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1794244820

From mcimadamore at openjdk.org  Wed Oct  9 21:27:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Oct 2024 21:27:13 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
Message-ID: <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>

On Wed, 9 Oct 2024 21:19:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So I'm not sure - it seems to me `letInit` should happily remove flags for any variable it sees marked with `FOR_LOOP_BODY_MAY_CAPTURE` (as that is surely a variable of a for loop and we must be in that loop's body for the variable to have that flag set?)

Concretely, why not, in `letInit`:


// In basic for() loop bodies, variables that are reassigned can no longer be captured
if ((sym.flags_field & FOR_LOOP_BODY_MAY_CAPTURE) != 0 && !uninits.isMember(sym.adr)) {
    sym.flags_field &= ~FOR_LOOP_BODY_MAY_CAPTURE;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1794246067

From acobbs at openjdk.org  Wed Oct  9 21:51:12 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Oct 2024 21:51:12 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
Message-ID: <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>

On Wed, 9 Oct 2024 21:23:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> * We would need a new flag that says "we are currently in the for() loop body" and not, for example, in the step, where we should leave the flag alone.
>> 
>> Well, my idea for doing that was to just set the flag on the loop variables before scanning the loop body (as you seem to do in the patch you show)
>> 
>>> 
>>> * We would also need to ensure we don't get confused with nested `for()` loops. So the aforementioned flag can't just be a boolean (because otherwise which `for()` loop are we talking about?). For example, a symbol address range instead.
>> 
>> This I don't get. If you have a loop nested inside another loop, you want assignments in the inner loop to affect whether the outer loop variable is considered a "loop capturable variable" or not. So I'm not sure - it seems to me `letInit` should happily remove flags for any variable it sees marked with `FOR_LOOP_BODY_MAY_CAPTURE` (as that is surely a variable of a for loop and we must be in that loop's body for the variable to have that flag set?)
>
>> So I'm not sure - it seems to me `letInit` should happily remove flags for any variable it sees marked with `FOR_LOOP_BODY_MAY_CAPTURE` (as that is surely a variable of a for loop and we must be in that loop's body for the variable to have that flag set?)
> 
> Concretely, why not, in `letInit`:
> 
> 
> // In basic for() loop bodies, variables that are reassigned can no longer be captured
> if ((sym.flags_field & FOR_LOOP_BODY_MAY_CAPTURE) != 0 && !uninits.isMember(sym.adr)) {
>     sym.flags_field &= ~FOR_LOOP_BODY_MAY_CAPTURE;
> }

> This I don't get. If you have a loop nested inside another loop, you want assignments in the inner loop to affect whether the outer loop variable is considered a "loop capturable variable" or not. So I'm not sure - it seems to me `letInit` should happily remove flags for any variable it sees marked with `FOR_LOOP_BODY_MAY_CAPTURE` (as that is surely a variable of a for loop and we must be in that loop's body for the variable to have that flag set?)

I think you are correct, but I think we're referring to different flags. I was referring to this flag:

> We would need a new flag that says "we are currently in the for() loop body"

That's would be a flag in `AssignAnalyzer`, not `Symbol`. Sorry for the mixing of terminology.

To be clear, here's the (first) problem I was worried about:

for (int i = 1; i <= 3; i++) {
    for (int j = 1; j <= 3; j++) {
        Runnable r = () -> System.out.println(j);   // false error here
    }
}

Explanation: We set the boolean flag `WeAreCurrentlyInTheForLoopBody` just before entering the outer loop body. Then when entering the inner loop step (which occurs prior entering to the inner loop body), the flag is still set, and so then we would incorrectly mark `j` has being reassigned in the body - but it's the wrong body that the flag is referring to. We're in the outer loop body but not the inner loop body.

This could be addressed by a stash/pop bracketing of the `WeAreCurrentlyInTheForLoopBody` flag around the _entire_ `visitForLoop()` method instead of only around the recursion into the body.

But then you still have a second problem, as shown in this example:


for (int i = 1; i <= 3; i++) {
    for (int j = 1; j <= 3; i++, j++) {
        Runnable r = () -> System.out.println(i);
    }
}

Now the `i++` that is the inner loop step does not invalidate the capture of `i` as it should, because `WeAreCurrentlyInTheForLoopBody` will be false.  So in summary `WeAreCurrentlyInTheForLoopBody` can't just be a boolean flag because: Which loop are we talking about?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1794283192

From acobbs at openjdk.org  Wed Oct  9 22:07:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Oct 2024 22:07:11 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
Message-ID: <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>

On Wed, 9 Oct 2024 21:48:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> So I'm not sure - it seems to me `letInit` should happily remove flags for any variable it sees marked with `FOR_LOOP_BODY_MAY_CAPTURE` (as that is surely a variable of a for loop and we must be in that loop's body for the variable to have that flag set?)
>> 
>> Concretely, why not, in `letInit`:
>> 
>> 
>> // In basic for() loop bodies, variables that are reassigned can no longer be captured
>> if ((sym.flags_field & FOR_LOOP_BODY_MAY_CAPTURE) != 0 && !uninits.isMember(sym.adr)) {
>>     sym.flags_field &= ~FOR_LOOP_BODY_MAY_CAPTURE;
>> }
>
>> This I don't get. If you have a loop nested inside another loop, you want assignments in the inner loop to affect whether the outer loop variable is considered a "loop capturable variable" or not. So I'm not sure - it seems to me `letInit` should happily remove flags for any variable it sees marked with `FOR_LOOP_BODY_MAY_CAPTURE` (as that is surely a variable of a for loop and we must be in that loop's body for the variable to have that flag set?)
> 
> I think you are correct, but I think we're referring to different flags. I was referring to this flag:
> 
>> We would need a new flag that says "we are currently in the for() loop body"
> 
> That's would be a flag in `AssignAnalyzer`, not `Symbol`. Sorry for the mixing of terminology.
> 
> To be clear, here's the (first) problem I was worried about:
> 
> for (int i = 1; i <= 3; i++) {
>     for (int j = 1; j <= 3; j++) {
>         Runnable r = () -> System.out.println(j);   // false error here
>     }
> }
> 
> Explanation: We set the boolean flag `WeAreCurrentlyInTheForLoopBody` just before entering the outer loop body. Then when entering the inner loop step (which occurs prior entering to the inner loop body), the flag is still set, and so then we would incorrectly mark `j` has being reassigned in the body - but it's the wrong body that the flag is referring to. We're in the outer loop body but not the inner loop body.
> 
> This could be addressed by a stash/pop bracketing of the `WeAreCurrentlyInTheForLoopBody` flag around the _entire_ `visitForLoop()` method instead of only around the recursion into the body.
> 
> But then you still have a second problem, as shown in this example:
> 
> 
> for (int i = 1; i <= 3; i++) {
>     for (int j = 1; j <= 3; i++, j++) {
>         Runnable r = () -> System.out.println(i);
>     }
> }
> 
> Now the `i++` that is the inner loop step does not invalidate the capture of `i` as it should, because `WeAreCurrentlyInTheForLoopBody` will be false.  So in summary `WeAreCurrentlyInTheForLoopBody` can't just be a boolean flag because: Which loop are we talking about?

> Concretely, why not, in `letInit`:

Because `visitForLoop()` itself has a loop and recurses into the parts of the `for()` statement multiple times. So when you loop back to visit `step` after visiting `body` for the first time, the flag would get reset.

So then you say, "Let's set a flag that let's this code know that we're in the _body_ of the loop" like this:

// In basic for() loop bodies, variables that are reassigned can no longer be captured
if (inForLoopBody && (sym.flags_field & FOR_LOOP_BODY_MAY_CAPTURE) != 0 && !uninits.isMember(sym.adr)) {
    sym.flags_field &= ~FOR_LOOP_BODY_MAY_CAPTURE;
}

and then you realize a boolean flag is not sufficient, and then ... well, see previous discussion :)

Another probem is that after the first loop, the variable is no longer DU...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1794297333

From vromero at openjdk.org  Wed Oct  9 23:13:16 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Oct 2024 23:13:16 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v14]
In-Reply-To: <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
Message-ID: <47TZdLZogJ81PGmaCHmXqDvCnhv4i9Vmp4LZ49g9MYU=.138c5422-ef52-414f-afe3-e5bbf54d23a2@github.com>

On Wed, 9 Oct 2024 11:34:24 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert bugid change

lgtm, thanks for fixing this

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20718#pullrequestreview-2358510460

From vromero at openjdk.org  Wed Oct  9 23:16:13 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Oct 2024 23:16:13 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v14]
In-Reply-To: <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
Message-ID: <eryqOkpXsg9ob43DXoKs8o5q2vpjSv2KSWUDE524KOE=.8db5bfc0-8088-4de2-b7ad-32452793debe@github.com>

On Wed, 9 Oct 2024 11:34:24 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert bugid change

I need a reviewer for the CSR, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2403600456

From alanb at openjdk.org  Thu Oct 10 05:03:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 05:03:12 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview)
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <fLVhcJ4GM-NSzzLdwMyr3BcUU836F8ecoUWIA4_1kZ4=.f5dd6d89-0cb9-4264-bcae-e67afc6e5f03@github.com>

On Wed, 9 Oct 2024 19:22:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

test/jdk/java/lang/module/ModuleDescriptorTest.java line 1574:

> 1572:     }
> 1573: 
> 1574:     private byte[] setClassFileVersion(int major, int minor, byte[] bytecode) {

Would it be possible to add a method description and re-format the overly long lines as it's currently impossible to look at the change side-by-side.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1794655877

From alanb at openjdk.org  Thu Oct 10 05:12:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 05:12:11 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview)
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <cpFwTgAHcCf32egTLY70rLKOi0LPb388Q3EitYMs4Eg=.7518dd7f-f1f0-4cfb-94ef-f29f601bbc2a@github.com>

On Wed, 9 Oct 2024 19:22:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Can you check if test/jdk/java/lang/module/ClassFileVersionsTest.java should be updated too?

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 193:

> 191:         int minor_version = in.readUnsignedShort();
> 192:         int major_version = in.readUnsignedShort();
> 193:         boolean previewClassfile = minor_version == ClassFile.PREVIEW_MINOR_VERSION;

If you rename this to isPreview then it would make the uses further down easier to read.

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 417:

> 415:                          //java.* modules are deemed participating in preview
> 416:                          //and are allowed to use requires transitive java.base:
> 417:                          !mn.startsWith("java."))

A block comment before the `if` statement would be a lot clearer here.

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

PR Comment: https://git.openjdk.org/jdk/pull/21431#issuecomment-2404032481
PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1794661012
PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1794662049

From mcimadamore at openjdk.org  Thu Oct 10 11:24:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Oct 2024 11:24:12 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
Message-ID: <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>

On Wed, 9 Oct 2024 22:04:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Because `visitForLoop()` itself has a loop and recurses into the parts of the `for()` statement multiple times.

I believe this was the source of the misunderstanding. The `scan(tree.body)` in `AssignAnalyzer` is indeed buried in a loop as we need a couple of passes to make sure to detect bad cases of multiple assignments e.g. to the same blank final variable.

Note that even in the current PR you `letInit` will be called twice, which in principle can be problematic in cases like:


for (int i ; ,..) {
    i = m();
    ...
}


If I understand correctly, the way the code in this PR works for the above is:
* in the first DA/DU pass of the loop body (`flowKind` == `NORMAL`), `i` is DU when it's assigned. So it is *not* added to the list of loop variable reassigned in body
* at the end of the pass, we see that `i` is not reassigned, so we augment it with the `FOR_LOOP_BODY_MAY_CAPTURE` flag
* then we do a second DA/DU pass of the loop body (`flowKind` == `SPECULATIVE`), which calls `letInit` again. This time `i` is not DU when assigned, so `i` ends up in the list of reassigned loop variables.
* at the end of the pass we do nothing (since we see `i` as reassigned). Luckily, the flag set in the first DA/DU pass is still there, and will be used by `CaptuerAnalyzer`.

This begs the question: should `letInit` even bother to deal with reassigned loop variables in the speculative DA/DU pass? Seems to me that pass will generally cause spurious results because of the changed DA/DU status of the variables involved.

Regardless, I think I found an issue with the current implementation when there are nested loops:


    void test() {
        for (int i = 0; ; ) {
            for (; ;) {
                i = 42;
                Runnable r = () -> System.out.println(i);
            }
        }
    }


This compiles fine, even though `i` is reassigned when DA. The problem seems to be that we lose track of the reassigned bit set (e.g. the inner loop will overwrite that), and since the variable is reassigned from the inner loop, that is problematic. Removing the inner loop results in a compile-time error, as expected.

We should either track "active" loop variables in a list when we append/remove from. Or, we should use the various Bits::incl/excl methods. E.g. flow should not create a new bit set on each loop, but augment the existing bit set (the initial could be the "all zero" set) with the bits corresponding to the variables of the loop under consideration. Then, once we have finished inspecting a loop, we "exclude" its variable bits from the sets before returning from the visitor. This way the "outer" loop will be able to "see" reassignments happening in inner loops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1795238267

From mcimadamore at openjdk.org  Thu Oct 10 11:38:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Oct 2024 11:38:14 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
Message-ID: <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>

On Thu, 10 Oct 2024 11:21:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Regardless, I think I found an issue with the current implementation when there are nested loops:
> 
> ```
>     void test() {
>         for (int i = 0; ; ) {
>             for (; ;) {
>                 i = 42;
>                 Runnable r = () -> System.out.println(i);
>             }
>         }
>     }
> ```

Issues aside, I think a related example:


void test() {
        for (int i ; ; ) {
            for (; ;) {
                i = 42;
                Runnable r = () -> System.out.println(i);
            }
        }
    }

Poses an interesting question: should `i` be capturable from the PoV of the inner loop? After all, in the inner loop we know there one value for `i` on each iteration.

Relatedly, what about this?


void test(int x) {
        int i = 42;
        if (x > 42) {
            i = 43;
        } else {
            Runnable r = () -> System.out.println(i);
        }
    }


We know that `x` is not reassigned in the `else` branch. But the analysis we have now is not sophisticated enough to detect that.

I think there seem to be some more general principle here that is struggling to get out: sometimes there might be region of code where we know a variable can hold only one value (even if in other regions that variable might be reassigned multiple times). In such case you can imagine to take the content of the variable and assign it to a _new_ variable, local to that "well-behaved" region. That new variable could, of course, be captured. The loop case (handled by this patch) seems to be a special case of this situation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1795257228

From jlahoda at openjdk.org  Thu Oct 10 11:50:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Oct 2024 11:50:00 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v2]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <D8GBIUOfMbHC6-5jyZgnO-tlV1LRfoXRSueLQY-SzCs=.ef354328-b724-4648-a630-bcc8c90da6f1@github.com>

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21431/files
  - new: https://git.openjdk.org/jdk/pull/21431/files/18554144..b7c871da

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

  Stats: 78 lines in 3 files changed: 37 ins; 7 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/21431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21431/head:pull/21431

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

From jlahoda at openjdk.org  Thu Oct 10 11:52:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Oct 2024 11:52:09 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview)
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <Uoc5e3iaQnvSD8Dkycm9UzUKMXxzvdplnSiNL42R07Q=.437b6b3e-647c-484d-bd57-814c5cb45cda@github.com>

On Wed, 9 Oct 2024 19:22:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Thanks for the comments so far! Here I tried to reflect them:
https://github.com/openjdk/jdk/pull/21431/commits/b7c871dab8357864b532a1f217ed26c3b40d50f4

(For `ClassFileVersionsTest.java`, it seemed unnecessarily complex to position the test cases into specific array positions, so I re-wrote that to use `ArrayList`. My goal was take the focus of the data preparation from how to place the test cases into the correct buckets, and more to the data. I kept pre-sizing of the `ArrayList` to avoid resizing it, although I could see an argument to remove that as well.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21431#issuecomment-2404877409

From jlahoda at openjdk.org  Thu Oct 10 13:12:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Oct 2024 13:12:18 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v14]
In-Reply-To: <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
Message-ID: <9-0LsSkT3pRCYMshFKTb4Zqh2vaQ9jyy1vkAKUwtwyU=.41d7f6d7-93c2-45b4-b82f-4d45ae4a9c42@github.com>

On Wed, 9 Oct 2024 11:34:24 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert bugid change

I am sorry for not fully realizing this sooner, I forgot about it. But, the JLS older than 19 didn't have this provision for the nested private classes, I believe. Do we need to limit this to only `-source 19+`?

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2405050222

From asotona at openjdk.org  Thu Oct 10 14:04:09 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 10 Oct 2024 14:04:09 GMT
Subject: RFR: 8341070: javac fails with an exception when compiling import
 module under source level 8
In-Reply-To: <HhFPc6CZ0T3UYP0G524s1J41pNAvcAsc1lYpaod2IJ8=.dc80a438-120f-4fbb-9aaa-3187181e5db6@github.com>
References: <HhFPc6CZ0T3UYP0G524s1J41pNAvcAsc1lYpaod2IJ8=.dc80a438-120f-4fbb-9aaa-3187181e5db6@github.com>
Message-ID: <f12jlsLPxT0OTPluq0zgtmh4bW6_Dh6eHWjXUWCU3aA=.68e307b9-a8f6-4de8-98e0-f7ea3fb57168@github.com>

On Mon, 30 Sep 2024 11:37:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package test;
> 
> import module java.base;
> 
> public class Test {
>     List<String> l;
> }
> 
> 
> Compiling this may cause javac to fail with an exception under some circumstances:
> 
> $ javac --source 8 -XDshould-stop.at=FLOW -XDdev /tmp/Test.java
> warning: [options] bootstrap class path is not set in conjunction with -source 8
>   not setting the bootstrap class path may lead to class files that cannot run on JDK 8
>     --release 8 is recommended instead of -source 8 because it sets the bootstrap class path automatically
> warning: [options] source value 8 is obsolete and will be removed in a future release
> warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
> /tmp/Test.java:3: error: module imports are a preview feature and are disabled by default.
> import module java.base;
>        ^
>   (use --enable-preview to enable module imports)
> 1 error
> 3 warnings
> An exception has occurred in the compiler (23-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot invoke "java.util.Set.contains(Object)" because "this.env.toplevel.modle.readModules" is null
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doModuleImport(TypeEnter.java:477)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:414)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.runPhase(TypeEnter.java:318)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.doCompleteEnvs(TypeEnter.java:279)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:248)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.complete(TypeEnter.java:195)
>         at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:687)
>         at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1455)
>         at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:632)
>         at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:599)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(J...

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21262#pullrequestreview-2360473715

From vromero at openjdk.org  Thu Oct 10 15:08:11 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 10 Oct 2024 15:08:11 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v14]
In-Reply-To: <9-0LsSkT3pRCYMshFKTb4Zqh2vaQ9jyy1vkAKUwtwyU=.41d7f6d7-93c2-45b4-b82f-4d45ae4a9c42@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
 <9-0LsSkT3pRCYMshFKTb4Zqh2vaQ9jyy1vkAKUwtwyU=.41d7f6d7-93c2-45b4-b82f-4d45ae4a9c42@github.com>
Message-ID: <z_-IkUHL7IfOWGvPCu1Y6HajOTOV_yDFSNqwChR3tZg=.3dd1e9fe-b06e-43e0-80f1-e90fa4f33a5b@github.com>

On Thu, 10 Oct 2024 13:09:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I am sorry for not fully realizing this sooner, I forgot about it. But, the JLS older than 19 didn't have this provision for the nested private classes, I believe. Do we need to limit this to only `-source 19+`?

good catch, yes I agree

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2405384320

From acobbs at openjdk.org  Thu Oct 10 15:54:13 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Oct 2024 15:54:13 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
Message-ID: <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>

On Thu, 10 Oct 2024 11:35:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Regardless, I think I found an issue with the current implementation when there are nested loops:

Yep - thanks, very interesting. To clarify the intent, a variable is capturable if it is not **reassigned in the loop**, which is defined as:

* Wherever the variable occurs as the left hand side in an assignment expression, it is definitely unassigned
* The variable never occurs as the operand of a prefix or postfix increment or decrement operator

In your example with `i = 42`, the variable `i` is not DU at that point (even though it takes two loops around the inner loop in `AssignAnalyzer` to figure that out). So according to the original intent, it should not be capturable.

I'll work on fixing this (and add a new test case).

> I think there seem to be some more general principle here that is struggling to get out...

Agreed... I had a similar vague thought while wondering "What about `while { }` and `do { }` loops?" In other words, is there some coherent way that we could we spread this new capturable goodness more widely?

One simple idea for generalizing the current approach: Within any scope _S_, any normal variable _v_ that is visible in _S_ is capturable if it is not reassigned in _S_. I don't know if the JLS actually defines "scope" but you know the idea: a region of code in which variables can be declared and be visible; so `{ ... }` curly braces obviously, but also the body of a `for()` statement.

An example that would then be allowed:

int i, j = 0;
while (true) {
  j += i;
  {
    Runnable action = () -> foo(i + j);
    try {
        this.executor.submit(action).get();
    } catch (InterruptedException e) {
        break;
    }
  }
  i++;
}

Note the extra curly braces required to create the "well-behaved" region.

It's almost as if the "well-behaved" region "captures" the variables that it uses and makes them temporarily effectively final... which then begs the question, why not just cut out the middle man? That would then put us in a situation where any variable could be captured anywhere (which some have argued for), i.e., everything is effectively final at the point of capture.

So I'm not sure if a coherent middle ground exists or what it would be.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1795713812

From mcimadamore at openjdk.org  Thu Oct 10 17:27:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Oct 2024 17:27:11 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
 <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
Message-ID: <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtFhOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>

On Thu, 10 Oct 2024 15:51:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> Regardless, I think I found an issue with the current implementation when there are nested loops:
>>> 
>>> ```
>>>     void test() {
>>>         for (int i = 0; ; ) {
>>>             for (; ;) {
>>>                 i = 42;
>>>                 Runnable r = () -> System.out.println(i);
>>>             }
>>>         }
>>>     }
>>> ```
>> 
>> Issues aside, I think a related example:
>> 
>> 
>> void test() {
>>         for (int i ; ; ) {
>>             for (; ;) {
>>                 i = 42;
>>                 Runnable r = () -> System.out.println(i);
>>             }
>>         }
>>     }
>> 
>> Poses an interesting question: should `i` be capturable from the PoV of the inner loop? After all, in the inner loop we know there one value for `i` on each iteration.
>> 
>> Relatedly, what about this?
>> 
>> 
>> void test(int x) {
>>         int i = 42;
>>         if (x > 42) {
>>             i = 43;
>>         } else {
>>             Runnable r = () -> System.out.println(i);
>>         }
>>     }
>> 
>> 
>> We know that `x` is not reassigned in the `else` branch. But the analysis we have now is not sophisticated enough to detect that.
>> 
>> I think there seem to be some more general principle here that is struggling to get out: sometimes there might be region of code where we know a variable can hold only one value (even if in other regions that variable might be reassigned multiple times). In such case you can imagine to take the content of the variable and assign it to a _new_ variable, local to that "well-behaved" region. That new variable could, of course, be captured. The loop case (handled by this PR) seems to be a special case of this situation.
>
>> Regardless, I think I found an issue with the current implementation when there are nested loops:
> 
> Yep - thanks, very interesting. To clarify the intent, a variable is capturable if it is not **reassigned in the loop**, which is defined as:
> 
> * Wherever the variable occurs as the left hand side in an assignment expression, it is definitely unassigned
> * The variable never occurs as the operand of a prefix or postfix increment or decrement operator
> 
> In your example with `i = 42`, the variable `i` is not DU at that point (even though it takes two loops around the inner loop in `AssignAnalyzer` to figure that out). So according to the original intent, it should not be capturable.
> 
> I'll work on fixing this (and add a new test case).
> 
>> I think there seem to be some more general principle here that is struggling to get out...
> 
> Agreed... I had a similar vague thought while wondering "What about `while { }` and `do { }` loops?" In other words, is there some coherent way that we could we spread this new capturable goodness more widely?
> 
> One simple idea for generalizing the current approach: Within any scope _S_, any normal variable _v_ that is visible in _S_ is capturable if it is not reassigned in _S_. I don't know if the JLS actually defines "scope" but you know the idea: a region of code in which variables can be declared and be visible; so `{ ... }` curly braces obviously, but also the body of a `for()` statement.
> 
> An example that would then be allowed:
> 
> int i, j = 0;
> while (true) {
>   j += i;
>   {
>     Runnable action = () -> foo(i + j);
>     try {
>         this.executor.submit(action).get();
>     } catch (InterruptedException e) {
>         break;
>     }
>   }
>   i++;
> }
> 
> Note the extra curly braces required to create the "well-behaved" region.
> 
> It's almost as if the "well-behaved" region "captures" the variables that it uses and makes them temporarily effectively final... which then begs the question, why not just cut out the middle man? That would then put us in a situation where any variable could be captured anywhere (which some have argued for), i.e., everything is effectively final at the point of capture.
> 
> So I'm not sure if a coherent middle ground exists or what it would be.

> An example that would then be allowed:
> 
> ```java
> int i, j = 0;
> while (true) {
>   j += i;
>   {
>     Runnable action = () -> foo(i + j);
>     try {
>         this.executor.submit(action).get();
>     } catch (InterruptedException e) {
>         break;
>     }
>   }
>   i++;
> }
> ```

I tend to agree with this line of thinking. And this is IMHO, a sign that the design has not yet fully settled. The main thing to notice is that there's two stable design points:
1. only capture effectively final vars (where the language is today);
2. capture every variable - with the understanding that what's being captured is the _current_ value (and not a "mutable box" which keeps changing in real time - that would be awful).

Having special rules for loop variables is sending us down the slippery slope of finding the next stable point between (1) and (2) - assuming one exists. The risk here is that once we start relaxing things in some areas (e.g. loops) you can quickly run into issues where other deficiencies in capture become even more apparent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1795837784

From acobbs at openjdk.org  Thu Oct 10 17:53:13 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Oct 2024 17:53:13 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtFhOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
 <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
 <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtF
 hOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>
Message-ID: <us-34oxLnSav3DgS3En9dcXam-f5DV7hWG84ucKAYcg=.3f99bcb9-f772-4c79-9886-2b9e88fcce7d@github.com>

On Thu, 10 Oct 2024 17:24:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Having special rules for loop variables is sending us down the slippery slope of finding the next stable point between (1) and (2) - assuming one exists. The risk here is that once we start relaxing things in some areas (e.g. loops) you can quickly run into issues where other deficiencies in capture become even more apparent.

I agree with all of that as well. There is one valid counter-argument though (reflected in the JEP draft) which is that we have already taken this current step with enhanced `for()` loops, so we're not really establishing any much of a new "frontier" with this feature by adding the same thing to basic `for()`. In other words, enhanced `for()` is an intermediate design point that's already been taken, for better or worse, so we might as well make the most of it. Or put more plaintively, "Please don't blame this feature for all the world's problems" :)

Regarding the bigger picture question, I'm skeptical that there exists any other design point between 1 and 2 that would be preferable to just jumping straight to 2, i.e., capture anything that's DA anywhere, but of course anything's possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1795868774

From acobbs at openjdk.org  Thu Oct 10 23:45:45 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Oct 2024 23:45:45 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v2]
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <Mfii3-9gmrUVvPItZJhcJYFdgqNbkTyqjV-S4L61z_Y=.43bfda35-c9c3-4cec-a161-9b2fb2ebb545@github.com>

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug pointed out by Maurizio & do some other cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21415/files
  - new: https://git.openjdk.org/jdk/pull/21415/files/1a5859d9..00181f7f

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

  Stats: 64 lines in 3 files changed: 30 ins; 12 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/21415.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21415/head:pull/21415

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

From acobbs at openjdk.org  Thu Oct 10 23:45:45 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Oct 2024 23:45:45 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v2]
In-Reply-To: <us-34oxLnSav3DgS3En9dcXam-f5DV7hWG84ucKAYcg=.3f99bcb9-f772-4c79-9886-2b9e88fcce7d@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
 <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
 <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtF
 hOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>
 <us-34oxLnSav3DgS3En9dcXam-f5DV7hWG84ucKAYcg=.3f99bcb9-f772-4c79-9886-2b9e88fcce7d@github.com>
Message-ID: <e7IS5lgW2JumFkTbpPep9mNKcPneXkuiaTVBy8Uy6IA=.ede76da0-8fee-4b38-8a01-78ef58118d0c@github.com>

On Thu, 10 Oct 2024 17:50:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> An example that would then be allowed:
>>> 
>>> ```java
>>> int i, j = 0;
>>> while (true) {
>>>   j += i;
>>>   {
>>>     Runnable action = () -> foo(i + j);
>>>     try {
>>>         this.executor.submit(action).get();
>>>     } catch (InterruptedException e) {
>>>         break;
>>>     }
>>>   }
>>>   i++;
>>> }
>>> ```
>> 
>> I tend to agree with this line of thinking. And this is IMHO, a sign that the design has not yet fully settled. The main thing to notice is that there's two stable design points:
>> 1. only capture effectively final vars (where the language is today);
>> 2. capture every variable - with the understanding that what's being captured is the _current_ value (and not a "mutable box" which keeps changing in real time - that would be awful).
>> 
>> Having special rules for loop variables is sending us down the slippery slope of finding the next stable point between (1) and (2) - assuming one exists. The risk here is that once we start relaxing things in some areas (e.g. loops) you can quickly run into issues where other deficiencies in capture become even more apparent.
>
>> Having special rules for loop variables is sending us down the slippery slope of finding the next stable point between (1) and (2) - assuming one exists. The risk here is that once we start relaxing things in some areas (e.g. loops) you can quickly run into issues where other deficiencies in capture become even more apparent.
> 
> I agree with all of that as well. There is one valid counter-argument though (reflected in the JEP draft) which is that we have already taken this current step with enhanced `for()` loops, so we're not really establishing any much of a new "frontier" with this feature by adding the same thing to basic `for()`. In other words, enhanced `for()` is an intermediate design point that's already been taken, for better or worse, so we might as well make the most of it. Or put more plaintively, "Please don't blame this feature for all the world's problems" :)
> 
> Regarding the bigger picture question, I'm skeptical that there exists any other design point between 1 and 2 that would be preferable to just jumping straight to 2, i.e., capture anything that's DA anywhere, but of course anything's possible.

Thanks for the bug fix suggestion. Should be fixed in 00181f7f1b4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1796228126

From jjg3 at pobox.com  Thu Oct 10 22:14:09 2024
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Thu, 10 Oct 2024 15:14:09 -0700
Subject: Result: New Compiler Group Lead: Maurizio Cimadamore
Message-ID: <52EFD6EB-CB0A-485D-A7C2-33B75D546D84@pobox.com>

Voting for Compiler Group Lead Maurizio Cimadamore [1] is now closed.

Yes: 3
No: 0
Abstain: 0

According to the Bylaws definition of Simple Majority, this is
sufficient to approve the new Group Lead.  The OpenJDK Lead will
ask the Governing Board to ratify this nomination.

? Jonathan Gibbons

[1] https://mail.openjdk.org/pipermail/compiler-dev/2024-September/027726.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241010/bf0a3d9f/attachment.htm>

From jrose at openjdk.org  Fri Oct 11 00:46:11 2024
From: jrose at openjdk.org (John R Rose)
Date: Fri, 11 Oct 2024 00:46:11 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v2]
In-Reply-To: <e7IS5lgW2JumFkTbpPep9mNKcPneXkuiaTVBy8Uy6IA=.ede76da0-8fee-4b38-8a01-78ef58118d0c@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
 <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
 <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtF
 hOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>
 <us-34oxLnSav3DgS3En9dcXam-f5DV7hWG84ucKAYcg=.3f99bcb9-f772-4c79-9886-2b9e88fcce7d@github.com>
 <e7IS5lgW2JumFkTbpPep9mNKcPneXkuiaTVBy8Uy6IA=.ede76da0-8fee-4b38-8a01-78ef58118d0c@github.com>
Message-ID: <LbSrnhyHBIs4op5kAEICiT34Vz4g9VWK1wIOsL5bNv4=.71c11ae0-02f3-4724-abbc-5b09686ee726@github.com>

On Thu, 10 Oct 2024 23:42:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> Having special rules for loop variables is sending us down the slippery slope of finding the next stable point between (1) and (2) - assuming one exists. The risk here is that once we start relaxing things in some areas (e.g. loops) you can quickly run into issues where other deficiencies in capture become even more apparent.
>> 
>> I agree with all of that as well. There is one valid counter-argument though (reflected in the JEP draft) which is that we have already taken this current step with enhanced `for()` loops, so we're not really establishing any much of a new "frontier" with this feature by adding the same thing to basic `for()`. In other words, enhanced `for()` is an intermediate design point that's already been taken, for better or worse, so we might as well make the most of it. Or put more plaintively, "Please don't blame this feature for all the world's problems" :)
>> 
>> Regarding the bigger picture question, I'm skeptical that there exists any other design point between 1 and 2 that would be preferable to just jumping straight to 2, i.e., capture anything that's DA anywhere, but of course anything's possible.
>
> Thanks for the bug fix suggestion. Should be fixed in 00181f7f1b4.

> It's almost as if the "well-behaved" region "captures" the variables that it uses and makes them temporarily effectively final... which then begs the question, why not just cut out the middle man? That would then put us in a situation where any variable could be captured anywhere (which some have argued for), i.e., everything is effectively final at the point of capture.

I am a long-time requester of this feature, in JDK-8300691.  I also considered whether other loops have a generalization, but gave it up after some thought.  I realized that the distinctive feature of old-for loops is their ability to bind variables that are not visible outside of the for loop, and also in the distinction between the region of the for loop header and for loop body.  Due to the traditional way these loops are used, it is very common (though not 100% universal) that such variables may be mutated in the header but are not mutated in the body.  The presence of two syntactic regions, one where variation is OK and one where variation is absent.  In the latter region, there is no benefit to telling the user "do not capture this because it might be different later on" (the rationale for non-capture of non-finals) because the only "later on" is another execution of the same loop body, in a different trip of the loop.

All this is to suggest why I think this request (and mine) should be _specifically and exactly only for old-for loops_, because they key off of specific and unique syntactic features (variable declaration + two syntax regions).

Therefore, I am pleading that we not confuse ourselves by attempting a generalization here.  Discarding the specifics of old-for loops in quest of some greater generalization is (IMO) a doomed effort, and even if it ultimately pans out, it should not stop us from dealing with the specifics of old-for loops.  If we are smart enough to come up with such a generalization, we will be smart enough to fit it into the current proposal, which is limited to the hardwired specifics of old-for loops.

I am the originator of the rule that forbids capture of non-finals (in Java 1.1).  I can tell you why it got there (if not how people think about it today).

The decision was made (after prototyping) _not to capture_ a full mutable state.  (?Such as a constant pointer to a one-element mutable array.)  There are numerous non-obvious reasons why that is a doomed decision. It's doomed even if good languages have done so ? and as a Common Lisp user I saw the very sharp edges from the interaction between mutable variable capture and non-sequential executions the observe the mutable variables.  (Non-sequential includes saving a callback that reads the loop variable, and forking a thread in the loop.)

So, if we were not going to save access to the future states of the mutable variable, we had to take a snapshot.  That's nice, but then another problem appears:  How do you explain to the user that if he changes the value of the variable later on, a lambda made before won't see the change, while a lambda made after will see it?  Such a user will rightly think the language is keeping double copies of the variable, which a bad way to implement a variable.  The way out of the dilemma, in 1.1, was to insist that only final variables can be captured (and they must be definitely assigned with their one and only value).  This way you can have multiple copies under the hood, and there's no state to be shared, and the user's code will see a consistent binding for that variable.

It was not clear we could do better than that, but Java 8 made a step forward with the concept of "effectively final" variables, which are variables that "might as well" have final declaration; such variables can be captured by lambdas as well.

What we don't cover, now, are codes like either of these two examples:


// Ex 1: multiple assignments before the variable stabilizes
int K = 1;
if (p())  K = 2;
//FIX:  effectively-final int K = p() ? 2 : 1;
return () -> K;  //BAD cannot be effectively final


Here, you might be able fix the problem by refactoring the final so that it is defined by one expression, or defined by disjoint (nonoverlapping) assignments from a blank state.  (Blank finals were introduced by us in 1.1 as well, to open up more natural usages of final locals and final instance variables.)


final int K;  // blank
if (p())  K = 2;
else  K = 1;
return () -> K;  //OK


Second example:


// Ex 2: re-assignment where the user expects two values from one var
int V = 1;
Globals.T = new Thread(() -> V);  //will not end well

//maybe: if (p()) V = 2;
V = 2;  // update V for next lambda
return () -> V;  //BAD cannot be effectively final

//FIX:  split V into V1 and V2


It is clear that the V has two disjoint episodes, which could be renamed V1 and V2.  Could there be a predictable, understandable rule which would perform this split automatically (when a lambda needs it)?  Maybe, but it probably becomes difficult to do this automatically in all cases; some code will allow V to split cleanly, and other code won't.  It's not clear there is a viable user model here, that makes the splitting predictable and intuitive.

In the end, I doubt that the above examples can be made fit for lambdas without manual intervention (magic "implicitly split" or "implicitly disjointly initialized" features look unlikely to me).  But it might be possible to give users an explicit way to "lock down" a variable which is not yet final, so that (hereafter) it becomes subsequently final.  If the "lock-down" is limited to an enclosing block you might be able to salvage both of the examples above.

The feature I'm talking about (and maybe some of you may remember me talking about this before) is a re-declaration of a previously declared variable as (now) being final.  Let's call it "subsequently-final":



// Ex 1: multiple assignments before the variable stabilizes
int K = 1;
if (p())  K = 2;
subsequently-final K;
// sugar for final var K$ = K; 
// and with remaining K occurrences in current scope rewritten to K$
return () -> K;  //OK, rewritten to () -> K$

// Ex 2: re-assignment where the user expects two values from one var
int V = 1;

{  // the fix requires this bracket (so it cannot be fully automatic)
  subsequently-final V;
  // sugar for final var V$1 = V; 
  Globals.T = new Thread(() -> V);  // () -> V$1 instead
  // at end of scope, V$1 goes away, but V remains
}

//maybe: if (p()) V = 2;
V = 2;  // update V for next lambda
subsequently-final V;
// sugar for final var V$2 = V; 

return () -> V;  //OK, () -> V$2

//FIXED:  split V into V$1 and V$2


Such a subsequently-final feature provides an accounting (retroactive I trust) of how the current proposal works:


for (int N = 0, M = A.length; N < M; N++) {
   subsequently-final N;
   // capture N$ at will
}


The proposal here might be thought of "effectively-subsequently-final for variables declared by old-for loops".  In conclusion, it's a very specific patch to a commonly used syntax, which is reasonable by itself, and is unlikely to interfere with future changes to the language.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1796275438

From liach at openjdk.org  Fri Oct 11 05:44:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 05:44:19 GMT
Subject: RFR: 8341924: Improve error message with structurally malformed Code
 array
Message-ID: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>

Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.

Before:

$ javap -c BadSwitch.class
Compiled from "BadSwitch.java"
final class BadSwitch {
  static void work(int);
    Code:
Error: error at or after byte 0
}


Now:

$ $localjdk2/bin/javap -c BadSwitch.class
Compiled from "BadSwitch.java"
final class BadSwitch {
  static void work(int);
    Code:
       0: iload_0
Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
}

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

Commit messages:
 - 8341924: Improve error message with structurally malformed Code array

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

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

From asotona at openjdk.org  Fri Oct 11 08:01:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Oct 2024 08:01:11 GMT
Subject: RFR: 8341924: Improve error message with structurally malformed
 Code array
In-Reply-To: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
References: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
Message-ID: <r7LuAv5VfvyxcXRESMeNV4Yqb95K3w4Lgoe0M3dX7vs=.95461bfe-d84e-4f4e-8147-c1e0ed0332ba@github.com>

On Fri, 11 Oct 2024 05:39:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.
> 
> Before:
> 
> $ javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
> Error: error at or after byte 0
> }
> 
> 
> Now:
> 
> $ $localjdk2/bin/javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
>        0: iload_0
> Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
> }

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21463#pullrequestreview-2362194526

From jlahoda at openjdk.org  Fri Oct 11 10:10:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 11 Oct 2024 10:10:18 GMT
Subject: Integrated: 8341070: javac fails with an exception when compiling
 import module under source level 8
In-Reply-To: <HhFPc6CZ0T3UYP0G524s1J41pNAvcAsc1lYpaod2IJ8=.dc80a438-120f-4fbb-9aaa-3187181e5db6@github.com>
References: <HhFPc6CZ0T3UYP0G524s1J41pNAvcAsc1lYpaod2IJ8=.dc80a438-120f-4fbb-9aaa-3187181e5db6@github.com>
Message-ID: <c8Zs90-NghGClvIp7pkFitq46hQPV6ek0PgL-dU_4Bg=.fd32ac18-86d9-4424-a245-9adb033f7d5c@github.com>

On Mon, 30 Sep 2024 11:37:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package test;
> 
> import module java.base;
> 
> public class Test {
>     List<String> l;
> }
> 
> 
> Compiling this may cause javac to fail with an exception under some circumstances:
> 
> $ javac --source 8 -XDshould-stop.at=FLOW -XDdev /tmp/Test.java
> warning: [options] bootstrap class path is not set in conjunction with -source 8
>   not setting the bootstrap class path may lead to class files that cannot run on JDK 8
>     --release 8 is recommended instead of -source 8 because it sets the bootstrap class path automatically
> warning: [options] source value 8 is obsolete and will be removed in a future release
> warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
> /tmp/Test.java:3: error: module imports are a preview feature and are disabled by default.
> import module java.base;
>        ^
>   (use --enable-preview to enable module imports)
> 1 error
> 3 warnings
> An exception has occurred in the compiler (23-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot invoke "java.util.Set.contains(Object)" because "this.env.toplevel.modle.readModules" is null
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.doModuleImport(TypeEnter.java:477)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.handleImports(TypeEnter.java:414)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.resolveImports(TypeEnter.java:389)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.runPhase(TypeEnter.java:318)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.doCompleteEnvs(TypeEnter.java:279)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter$Phase.completeEnvs(TypeEnter.java:248)
>         at jdk.compiler/com.sun.tools.javac.comp.TypeEnter.complete(TypeEnter.java:195)
>         at jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:687)
>         at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1455)
>         at jdk.compiler/com.sun.tools.javac.comp.Enter.complete(Enter.java:632)
>         at jdk.compiler/com.sun.tools.javac.comp.Enter.main(Enter.java:599)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(J...

This pull request has now been integrated.

Changeset: 61338661
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6133866150cf6131ab578f1537f84c239703fa67
Stats:     82 lines in 2 files changed: 63 ins; 19 del; 0 mod

8341070: javac fails with an exception when compiling import module under source level 8

Reviewed-by: asotona

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

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

From mcimadamore at openjdk.org  Fri Oct 11 10:16:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Oct 2024 10:16:10 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v2]
In-Reply-To: <LbSrnhyHBIs4op5kAEICiT34Vz4g9VWK1wIOsL5bNv4=.71c11ae0-02f3-4724-abbc-5b09686ee726@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
 <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
 <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtF
 hOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>
 <us-34oxLnSav3DgS3En9dcXam-f5DV7hWG84ucKAYcg=.3f99bcb9-f772-4c79-9886-2b9e88fcce7d@github.com>
 <e7IS5lgW2JumFkTbpPep9mNKcPneXkuiaTVBy8Uy6IA=.ede76da0-8fee-4b38-8a01-78ef58118d0c@github.com>
 <LbSrnhyHBIs4op5kAEICiT34Vz4g9VWK1wIOsL5bNv4=.71c11ae0-02f3-4724-abbc-5b09686ee726@github.com>
Message-ID: <S9lHx-Nu0sZsmufL-o0Z6vczOAYHUNQa24YwWmr6ksU=.cff4901c-a278-473e-8db4-823f58fc3897@github.com>

On Fri, 11 Oct 2024 00:43:47 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Thanks for the bug fix suggestion. Should be fixed in 00181f7f1b4.
>
>> It's almost as if the "well-behaved" region "captures" the variables that it uses and makes them temporarily effectively final... which then begs the question, why not just cut out the middle man? That would then put us in a situation where any variable could be captured anywhere (which some have argued for), i.e., everything is effectively final at the point of capture.
> 
> I am a long-time requester of this feature, in JDK-8300691.  I also considered whether other loops have a generalization, but gave it up after some thought.  I realized that the distinctive feature of old-for loops is their ability to bind variables that are not visible outside of the for loop, and also is the distinction between the region of the for loop header and for loop body.  Due to the traditional way these loops are used, it is very common (though not 100% universal) that such variables may be mutated in the header but are not mutated in the body.  The presence of two syntactic regions, one where variation is OK and one where variation is absent, is a very special feature of old-for, and one which frustrates folks that want to use lambdas in the _latter_ region.  In the latter region, there is no benefit to telling the user "do not capture this because it might be different later on" (the rationale for non-capture of non-finals) because the only "later on" is another execu
 tion of the same loop body, in a different trip of the loop.
> 
> All this is to suggest why I think this request (and mine) should be _specifically and exactly only for old-for loops_, because they key off of specific and unique syntactic features (variable declaration + two syntax regions).
> 
> Therefore, I am pleading that we not confuse ourselves by attempting a generalization here.  Discarding the specifics of old-for loops in quest of some greater generalization is (IMO) a doomed effort, and even if it ultimately pans out, it should not stop us from dealing with the specifics of old-for loops.  If we are smart enough to come up with such a generalization, we will be smart enough to fit it into the current proposal, which is limited to the hardwired specifics of old-for loops.
> 
> I am the originator of the rule that forbids capture of non-finals (in Java 1.1).  I can tell you why it got there (if not how people think about it today).
> 
> The decision was made (after prototyping) _not to capture_ a full mutable state.  (?Such as a constant pointer to a one-element mutable array.)  There are numerous non-obvious reason...

> Thanks for the bug fix suggestion. Should be fixed in [00181f7](https://github.com/openjdk/jdk/commit/00181f7f1b458ab38efc8ffee933e97f5f07419a).

Looks good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1796744055

From acobbs at openjdk.org  Fri Oct 11 14:16:13 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Oct 2024 14:16:13 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v2]
In-Reply-To: <S9lHx-Nu0sZsmufL-o0Z6vczOAYHUNQa24YwWmr6ksU=.cff4901c-a278-473e-8db4-823f58fc3897@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
 <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
 <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtF
 hOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>
 <us-34oxLnSav3DgS3En9dcXam-f5DV7hWG84ucKAYcg=.3f99bcb9-f772-4c79-9886-2b9e88fcce7d@github.com>
 <e7IS5lgW2JumFkTbpPep9mNKcPneXkuiaTVBy8Uy6IA=.ede76da0-8fee-4b38-8a01-78ef58118d0c@github.com>
 <LbSrnhyHBIs4op5kAEICiT34Vz4g9VWK1wIOsL5bNv4=.71c11ae0-02f3-4724-abbc-5b09686ee726@github.com>
 <S9lHx-Nu0sZsmufL-o0Z6vczOAYHUNQa24YwWmr6ksU=.cff4901c-a278-473e-8db4-823f58fc3897@github.com>
Message-ID: <d6xaz2cf7tWi2o1wsl8SyHkALms2QVYYwIi0F7qKLdA=.9dde2812-eb8f-41b6-8656-80a3bbe1d770@github.com>

On Fri, 11 Oct 2024 10:13:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> It's almost as if the "well-behaved" region "captures" the variables that it uses and makes them temporarily effectively final... which then begs the question, why not just cut out the middle man? That would then put us in a situation where any variable could be captured anywhere (which some have argued for), i.e., everything is effectively final at the point of capture.
>> 
>> I am a long-time requester of this feature, in JDK-8300691.  I also considered whether other loops have a generalization, but gave it up after some thought.  I realized that the distinctive feature of old-for loops is their ability to bind variables that are not visible outside of the for loop, and also is the distinction between the region of the for loop header and for loop body.  Due to the traditional way these loops are used, it is very common (though not 100% universal) that such variables may be mutated in the header but are not mutated in the body.  The presence of two syntactic regions, one where variation is OK and one where variation is absent, is a very special feature of old-for, and one which frustrates folks that want to use lambdas in the _latter_ region.  In the latter region, there is no benefit to telling the user "do not capture this because it might be different later on" (the rationale for non-capture of non-finals) because the only "later on" is another exec
 ution of the same loop body, in a different trip of the loop.
>> 
>> All this is to suggest why I think this request (and mine) should be _specifically and exactly only for old-for loops_, because they key off of specific and unique syntactic features (variable declaration + two syntax regions).
>> 
>> Therefore, I am pleading that we not confuse ourselves by attempting a generalization here.  Discarding the specifics of old-for loops in quest of some greater generalization is (IMO) a doomed effort, and even if it ultimately pans out, it should not stop us from dealing with the specifics of old-for loops.  If we are smart enough to come up with such a generalization, we will be smart enough to fit it into the current proposal, which is limited to the hardwired specifics of old-for loops.
>> 
>> I am the originator of the rule that forbids capture of non-finals (in Java 1.1).  I can tell you why it got there (if not how people think about it today).
>> 
>> The decision was made (after prototyping) _not to capture_ a full mutable state.  (?Such as a constant pointer to a one-element mutable array.)  There are numero...
>
>> Thanks for the bug fix suggestion. Should be fixed in [00181f7](https://github.com/openjdk/jdk/commit/00181f7f1b458ab38efc8ffee933e97f5f07419a).
> 
> Looks good!

[ Caveat: we're obviously spilling outside this bounds of this PR but hey it's an interesting discussion... ]

> The feature I'm talking about (and maybe some of you may remember me talking about this before) is a re-declaration of a previously declared variable as (now) being final. Let's call it "subsequently-final":

That's a neat idea - thanks for that perspective. Essentially, this would allow you to apply the `final` keyword at any point along the control flow path(s) in which a variable is visible, instead of only at its declaration. In fact, why not just reuse the `final` keyword (thus back-porting its meaning to be "Can't be reassigned from here on out")?

Of course this would be a compile-time thing; as one might expect, there is a parallel runtime concept/debate around "freezing" etc.

All of which points to the central importance of immutability and also therefore treading carefully to get the language concepts right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1797022767

From ihse at openjdk.org  Fri Oct 11 14:23:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Oct 2024 14:23:12 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <fFJQlcs5vLsVKQTfdkws1uvf8My2vG9YfTXouF7XDm0=.e799ab93-7d90-47ef-851e-1faeb822cf34@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
 <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>
 <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>
 <fFJQlcs5vLsVKQTfdkws1uvf8My2vG9YfTXouF7XDm0=.e799ab93-7d90-47ef-851e-1faeb822cf34@github.com>
Message-ID: <gXcrN3fEZX3JScmqhJUb1oHEoiwJ4zc_L60Pn6UK5UY=.9d160d68-ffac-4ba2-a1ff-8636904fc58e@github.com>

On Tue, 24 Sep 2024 00:56:46 GMT, toshiogata <duke at openjdk.org> wrote:

>>> > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named?
>>> 
>>> Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations.
>>> 
>>> In the meantime, renaming the files to avoid the problem is the recommended solution.
>> 
>> Filed https://bugs.openjdk.org/browse/CODETOOLS-7903803
>
> @jonathan-gibbons 
> I was wondering if you have had a chance to see my response and aivanov-jdk's question. I would appreciate your reaction. Thank you.

@toshiogata Jon Gibbons is no longer working on Oracle. I can't say if that means he will no longer be active at all in the OpenJDK community, but you might want to lower your expectations of getting a reply, and I suggest proceeding with this PR without awaiting a response from him.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2407520270

From jjg at openjdk.org  Fri Oct 11 15:31:20 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 11 Oct 2024 15:31:20 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <fFJQlcs5vLsVKQTfdkws1uvf8My2vG9YfTXouF7XDm0=.e799ab93-7d90-47ef-851e-1faeb822cf34@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
 <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>
 <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>
 <fFJQlcs5vLsVKQTfdkws1uvf8My2vG9YfTXouF7XDm0=.e799ab93-7d90-47ef-851e-1faeb822cf34@github.com>
Message-ID: <TwwB0x7MbC5HZ7LcdwmaodtWZsQMVSlFqhfvQZzTEZ4=.cafe8d74-1128-4375-8e3a-ed8704f5e3af@github.com>

On Tue, 24 Sep 2024 00:56:46 GMT, toshiogata <duke at openjdk.org> wrote:

>>> > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named?
>>> 
>>> Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations.
>>> 
>>> In the meantime, renaming the files to avoid the problem is the recommended solution.
>> 
>> Filed https://bugs.openjdk.org/browse/CODETOOLS-7903803
>
> @jonathan-gibbons 
> I was wondering if you have had a chance to see my response and aivanov-jdk's question. I would appreciate your reaction. Thank you.

> @toshiogata Jon Gibbons is no longer working on Oracle. I can't say if that means he will no longer be active at all in the OpenJDK community, but you might want to lower your expectations of getting a reply, and I suggest proceeding with this PR without awaiting a response from him.

I'm still around, and working to regain access to participate in OpenJDK, albeit at a significantly reduced level.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2407653093

From jjg at openjdk.org  Fri Oct 11 15:36:12 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 11 Oct 2024 15:36:12 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
Message-ID: <LtFy354kVHT-EhhnIpjfPLgEfCeC18mmL4tkc2qi1eA=.8bfdb7f0-281c-4528-ba52-fbb27808e2a1@github.com>

On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata <duke at openjdk.org> wrote:

>> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
>> Testing: modified tests
>
> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Move jtreg tags and expand wildcard imports"
>   
>   This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.

I see this is already approved/"ready".  I see no reason to disagree with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2407661898

From jjg at openjdk.org  Fri Oct 11 15:36:12 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 11 Oct 2024 15:36:12 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <5m5fXgRoiwNZBV49deCIdmBxsGff6gOJ_Z99zr_Pyfc=.96edb6e6-231f-4771-8362-28131c46c613@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
 <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
 <G6Ionzwifny03fp6nYvqmwTEnxs1e71AZ1-wVmz2WrU=.80f1eeb9-0850-4ae8-a54d-094668df9252@github.com>
 <p22z4EdyOjFd4N0BKDYEcv806a_wXV4VjxL8xBbc2mU=.7b61c522-ca36-49ea-a9ea-54f12875de9f@github.com>
 <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com>
 <Hc2wcnI9clPcuTWcr3KkxEFq1EFIPnkdaUO0dazvNKQ=.744e78cd-230e-4725-955c-c2569aa89981@github.com>
 <5m5fXgRoiwNZBV49deCIdmBxsGff6gOJ_Z99zr_Pyfc=.96edb6e6-231f-4771-8362-28131c46c613@github.com>
Message-ID: <fjiQVcUibBWf-8hEzIu4vBT5fLfBlqQ_f9rbMqHLZfM=.573dcc1b-06dc-46c3-a3aa-f8f19f2b0ca1@github.com>

On Tue, 27 Aug 2024 12:54:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> With my official `jtreg` hat on, I recommend always placing the `jtreg` tags immediately after any legal header comments and _before_ any and all of the source code that comprises the test.
>
>> With my official `jtreg` hat on, I recommend always placing the `jtreg` tags immediately after any legal header comments and _before_ any and all of the source code that comprises the test.
> 
> @jonathan-gibbons Are there any disadvantages to placing jtreg tags right before the test class declaration, after all the import statements? It is more convenient when viewing test code in IDE: the jtreg tags are clearly visible. If the tags are after the legal header, they're collapsed together with the legal header (and imports).

There are no technical disadvantages, but I stand by my recommendation to place the test description before any Java code constructions like package, import or type declarations.

We should not change the prevailing style just because of some new prevailing behavior in any given IDE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1797123563

From mcimadamore at openjdk.org  Fri Oct 11 17:33:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 11 Oct 2024 17:33:14 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v2]
In-Reply-To: <d6xaz2cf7tWi2o1wsl8SyHkALms2QVYYwIi0F7qKLdA=.9dde2812-eb8f-41b6-8656-80a3bbe1d770@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <2-ZWbjgWHifvWcvSTZ3-DyVF-G1M23bCKrnomdJTeHU=.109da7e1-7627-4a31-8b33-cce64a66e42c@github.com>
 <PK9VT_Hw92J_a3zznMHTr0-3Jrnx9W6h7mnZhi0JsVM=.8c0b2b4e-e80f-48e0-95cd-106ab540b979@github.com>
 <WMB1Oe2erj1qHEqIECFOBiV1ZdlNkXErNXJ595HbQUM=.3c6eae47-2497-492e-99dc-816693695d04@github.com>
 <Blb-rlzImAFaXh3w2_JAJCRQyw1hCjtlJ5Rbm2sueeY=.e7bbc6da-8421-4853-a391-7102d75d7c33@github.com>
 <2UWErRkO-MtovwppgLWbdA4UKYhONnlsp9uNjJW4iDw=.39aad7e9-bcb8-4ea6-ae5f-07f4e3852347@github.com>
 <0PkYePWu3lfKpbnSvk9PTRL0OZltAeQUspWjhRq2_hA=.6bf2048e-4ae9-488c-a734-02c34b1654be@github.com>
 <JUNwQBJXHnHiOabyKBUdJkumIRqEiT6NUza6JBjtXos=.25a83ca5-6c64-4c3a-8045-05e328df163f@github.com>
 <HQSoPnFKxtM-joFwA6eZgjyVBBMbK1az5lux2HVubDQ=.32550ee1-03a3-4351-8b43-30395d318991@github.com>
 <VBjqnggGvvJ5vxoBk4gIMMcVg_y9nW_jQOgi_MMfzX8=.46fbef33-773e-4773-94e5-00efa6e356cf@github.com>
 <PL9fO5ay78fcSp8MnKh6Y3C3V1d0LJfZXtF
 hOqrHCvA=.1d89bf7c-142e-4e62-a01a-1c4479c9d23c@github.com>
 <us-34oxLnSav3DgS3En9dcXam-f5DV7hWG84ucKAYcg=.3f99bcb9-f772-4c79-9886-2b9e88fcce7d@github.com>
 <e7IS5lgW2JumFkTbpPep9mNKcPneXkuiaTVBy8Uy6IA=.ede76da0-8fee-4b38-8a01-78ef58118d0c@github.com>
 <LbSrnhyHBIs4op5kAEICiT34Vz4g9VWK1wIOsL5bNv4=.71c11ae0-02f3-4724-abbc-5b09686ee726@github.com>
 <S9lHx-Nu0sZsmufL-o0Z6vczOAYHUNQa24YwWmr6ksU=.cff4901c-a278-473e-8db4-823f58fc3897@github.com>
 <d6xaz2cf7tWi2o1wsl8SyHkALms2QVYYwIi0F7qKLdA=.9dde2812-eb8f-41b6-8656-80a3bbe1d770@github.com>
Message-ID: <f5uOSypazgvrVEIi6X1KfVDtD0HNxEZ_ZMMDzbh-s2Q=.3088d259-8e50-4ac3-94f1-43dc618d0af8@github.com>

On Fri, 11 Oct 2024 14:13:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> Thanks for the bug fix suggestion. Should be fixed in [00181f7](https://github.com/openjdk/jdk/commit/00181f7f1b458ab38efc8ffee933e97f5f07419a).
>> 
>> Looks good!
>
> [ Caveat: we're obviously spilling outside this bounds of this PR but hey it's an interesting discussion... ]
> 
>> The feature I'm talking about (and maybe some of you may remember me talking about this before) is a re-declaration of a previously declared variable as (now) being final. Let's call it "subsequently-final":
> 
> That's a neat idea - thanks for that perspective. Essentially, this would allow you to apply the `final` keyword at any point along the control flow path(s) in which a variable is visible, instead of only at its declaration. In fact, why not just reuse the `final` keyword (thus back-porting its meaning to be "Can't be reassigned from here on out")?
> 
> Of course this would be a compile-time thing; as one might expect, there is a parallel runtime concept/debate around "freezing" etc.
> 
> All of which points to the central importance of immutability and also therefore treading carefully to get the language concepts right.

> How do you explain to the user that if he changes the value of the variable later on, a lambda made before won't see the change, while a lambda made after will see it? Such a user will rightly think the language is keeping double copies of the variable, which a bad way to implement a variable. The way out of the dilemma, in 1.1, was to insist that only final variables can be captured (and they must be definitely assigned with their one and only value). This way you can have multiple copies under the hood, and there's no state to be shared, and the user's code will see a consistent binding for that variable.

I tend to agree with what you say here. To me though, I admit, the proposed new rules seem to push the language in the very direction that the careful design of the inner class mechanism wanted to avoid. I understand that you can think of an imperative, well-behaved loop induction variable behaving "as if" it was created fresh each time. And yet, according to the JLS, that variable is actually reassigned (case in point: you cannot make the lop variable `final`).

Overall, both the loop-only changes and your more general "subsequently-final" feature seem to defeat the very principles set out in the above: that allowing for multiple copies to be kept under the hood is confusing, and potentially surprising. For instance, the proposed changes allow this:


    record Box(int x) { }
    
    for (Box b = new Box(0) ; b.x < 10 ; b = new Box(b.x + 1)) {
            Runnable r = () -> System.out.println(b);
        }
    }

I think users will be surprised to realize that some "old" `Box` instances might be kept alive by `Runnable` (which might leak somewhere else).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21415#discussion_r1797247056

From acobbs at openjdk.org  Fri Oct 11 19:50:34 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 11 Oct 2024 19:50:34 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v3]
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <gt2FxUgQepXW7DOBW8PQJLiRQUbs4JTCLmFhvTrSXmc=.d8339b0f-1859-430d-8cab-3e4bbaadbd4c@github.com>

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21415/files
  - new: https://git.openjdk.org/jdk/pull/21415/files/00181f7f..76d5c5e7

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

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

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

From duke at openjdk.org  Sat Oct 12 14:24:29 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 12 Oct 2024 14:24:29 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v15]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <yPBvDN_ySzNpKbHcRI1_ltcSxYzAIIZPLDbuIohhtQI=.90bd7c70-8b2c-4a3d-b92b-d20d848ae3a6@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

Evemose has updated the pull request incrementally with three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
 - report feature error
 - add feature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/efefc762..7efb56e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=13-14

  Stats: 58 lines in 4 files changed: 54 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20718/head:pull/20718

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

From duke at openjdk.org  Sat Oct 12 14:24:29 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 12 Oct 2024 14:24:29 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v14]
In-Reply-To: <z_-IkUHL7IfOWGvPCu1Y6HajOTOV_yDFSNqwChR3tZg=.3dd1e9fe-b06e-43e0-80f1-e90fa4f33a5b@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <eMsX0btNLzQSgB9mXJw82CG3bTFZx2y7xgLNuJpB_Ik=.814bb2f5-287f-4ab8-bcdb-fd4aa1e2dd52@github.com>
 <9-0LsSkT3pRCYMshFKTb4Zqh2vaQ9jyy1vkAKUwtwyU=.41d7f6d7-93c2-45b4-b82f-4d45ae4a9c42@github.com>
 <z_-IkUHL7IfOWGvPCu1Y6HajOTOV_yDFSNqwChR3tZg=.3dd1e9fe-b06e-43e0-80f1-e90fa4f33a5b@github.com>
Message-ID: <MD8y1urqDSGFP00Y7v0ZhUwnvZ5WVp2JLZJXYvz1xVo=.9ac45f33-1e17-41ed-b232-21b62e17557e@github.com>

On Thu, 10 Oct 2024 15:05:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > I am sorry for not fully realizing this sooner, I forgot about it. But, the JLS older than 19 didn't have this provision for the nested private classes, I believe. Do we need to limit this to only `-source 19+`?
> 
> good catch, yes I agree. @Evemose I think that we will need to add a new feature, to `com.sun.tools.javac.code.Source.Feature`. This PR is a recent-ish example: `https://github.com/openjdk/jdk/pull/12893`

I have added feature, but would apreciate any advice on how to improve error reporting. You could see currecnt behaviour in added test, but I feel like it could be improved, specifically position reporting and erroneous symbol reporting, but I am not really sure how its done properly

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2408581446

From duke at openjdk.org  Sat Oct 12 14:42:08 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sat, 12 Oct 2024 14:42:08 GMT
Subject: RFR: 8341924: Improve error message with structurally malformed
 Code array
In-Reply-To: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
References: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
Message-ID: <_0TgCGtzxVQ1PjYkSyDCNHrbe0iFLDdLYGkXmAegY2s=.41106b35-fe21-4370-abb5-ed38826f768f@github.com>

On Fri, 11 Oct 2024 05:39:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.
> 
> Before:
> 
> $ javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
> Error: error at or after byte 0
> }
> 
> 
> Now:
> 
> $ $localjdk2/bin/javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
>        0: iload_0
> Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
> }

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/21463#pullrequestreview-2363921436

From acobbs at openjdk.org  Sun Oct 13 16:24:41 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 13 Oct 2024 16:24:41 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v4]
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <PrqG9pZw0UDmi7zxuipbUhY6HiSYwA-S7HJ2Pa2aAKA=.cca950a0-b30f-4eec-abb2-898007574fd8@github.com>

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Make "effectively final in the loop" work with try-with-resources statements.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21415/files
  - new: https://git.openjdk.org/jdk/pull/21415/files/76d5c5e7..9494473a

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

  Stats: 19 lines in 2 files changed: 17 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21415.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21415/head:pull/21415

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

From jlahoda at openjdk.org  Mon Oct 14 05:40:46 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 05:40:46 GMT
Subject: RFR: 8341966: Broken annotated module may lead to an exception in
 javac
Message-ID: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>

Consider a `module-info.class`, that both:
 - is wrong, so it will produce a bad-classfile error, for example due to an illegal `requires transitive java.base;`
 - and the module is annotated

If the javac proceeds to resolve the annotations (which is not the default, but can be pushed to do it), it will crash with an `AssertionError` while trying to un-proxy the annotations. This is because there's an assert that `requestingOwner.owner.kind == MDL`, but since the module is erroneous, the kind is `ERR`, and the assert fails.

The proposal is to loosen the assert a bit, and require `requestingOwner.owner instanceof ModuleSymbol`. That should still be sufficiently strong, while permitting broken modules to be handled.

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

Commit messages:
 - 8341966: Broken annotated module may lead to an exception in javac

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

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

From liach at openjdk.org  Mon Oct 14 05:49:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Oct 2024 05:49:10 GMT
Subject: RFR: 8341966: Broken annotated module may lead to an exception in
 javac
In-Reply-To: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
References: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
Message-ID: <A6Wd9ElLhaDHYeTIY30ZogZvq92nRLaECEMiK9mQ7to=.bb7df572-a4d8-499a-a554-1da6b12ddda7@github.com>

On Mon, 14 Oct 2024 05:35:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a `module-info.class`, that both:
>  - is wrong, so it will produce a bad-classfile error, for example due to an illegal `requires transitive java.base;`
>  - and the module is annotated
> 
> If the javac proceeds to resolve the annotations (which is not the default, but can be pushed to do it), it will crash with an `AssertionError` while trying to un-proxy the annotations. This is because there's an assert that `requestingOwner.owner.kind == MDL`, but since the module is erroneous, the kind is `ERR`, and the assert fails.
> 
> The proposal is to loosen the assert a bit, and require `requestingOwner.owner instanceof ModuleSymbol`. That should still be sufficiently strong, while permitting broken modules to be handled.

test/langtools/tools/javac/modules/AnnotationsOnModules.java line 755:

> 753:         byte[] newBytes = ClassFile.of().transformClass(cm1, new ClassTransform() {
> 754:             @Override
> 755:             public void accept(ClassBuilder builder, ClassElement element) {

Is there any restriction so that you cannot use a lambda here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21486#discussion_r1798775877

From jlahoda at openjdk.org  Mon Oct 14 06:01:49 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 06:01:49 GMT
Subject: RFR: 8341966: Broken annotated module may lead to an exception in
 javac [v2]
In-Reply-To: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
References: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
Message-ID: <GgDTKH8FEpzwftuGUlN4S5i6fB3xXEexXH3Aq2eQHjg=.194b0c22-5b34-40ad-855c-655e393a8bac@github.com>

> Consider a `module-info.class`, that both:
>  - is wrong, so it will produce a bad-classfile error, for example due to an illegal `requires transitive java.base;`
>  - and the module is annotated
> 
> If the javac proceeds to resolve the annotations (which is not the default, but can be pushed to do it), it will crash with an `AssertionError` while trying to un-proxy the annotations. This is because there's an assert that `requestingOwner.owner.kind == MDL`, but since the module is erroneous, the kind is `ERR`, and the assert fails.
> 
> The proposal is to loosen the assert a bit, and require `requestingOwner.owner instanceof ModuleSymbol`. That should still be sufficiently strong, while permitting broken modules to be handled.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback - using lambda instead of an anonymous innerclass.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21486/files
  - new: https://git.openjdk.org/jdk/pull/21486/files/c93ad264..d23195b3

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

  Stats: 39 lines in 1 file changed: 12 ins; 15 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21486.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21486/head:pull/21486

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

From jlahoda at openjdk.org  Mon Oct 14 06:07:11 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 06:07:11 GMT
Subject: RFR: 8341966: Broken annotated module may lead to an exception in
 javac [v2]
In-Reply-To: <A6Wd9ElLhaDHYeTIY30ZogZvq92nRLaECEMiK9mQ7to=.bb7df572-a4d8-499a-a554-1da6b12ddda7@github.com>
References: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
 <A6Wd9ElLhaDHYeTIY30ZogZvq92nRLaECEMiK9mQ7to=.bb7df572-a4d8-499a-a554-1da6b12ddda7@github.com>
Message-ID: <koNic7KlR4zT8XAxRAMac6ADoXTCexE5vEtFyTZ1vw0=.ff6fe917-d54f-4b3a-b856-c6ec69e0a650@github.com>

On Mon, 14 Oct 2024 05:46:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback - using lambda instead of an anonymous innerclass.
>
> test/langtools/tools/javac/modules/AnnotationsOnModules.java line 755:
> 
>> 753:         byte[] newBytes = ClassFile.of().transformClass(cm1, new ClassTransform() {
>> 754:             @Override
>> 755:             public void accept(ClassBuilder builder, ClassElement element) {
> 
> Is there any restriction so that you cannot use a lambda here?

No, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21486#discussion_r1798794453

From jlahoda at openjdk.org  Mon Oct 14 12:46:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 12:46:29 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - Adding a separate scope for module imports.
 - Cleanup.
 - Make very sure java.base is completed.
 - Keep jdk.internal.javac qualified export from java.base.
 - Adding forgotten change.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

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

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=02
  Stats: 761 lines in 27 files changed: 580 ins; 46 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/21431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21431/head:pull/21431

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

From jlahoda at openjdk.org  Mon Oct 14 14:04:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 14:04:30 GMT
Subject: RFR: 8341901: Using 'var' keyword switch pattern matching causes
 compiler error
Message-ID: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>

Consider code like:

public class T {
   record R(N.I i) {}
   int test(Object o) {
       return switch (o) {
           case R(var nested) -> 0;
           default -> 0;
       };
   }
   static class N<T> {
       interface I {}
   }
}


This fails to compile since JDK 23, due to:

$ javac T.java 
error: cannot select a static class from a parameterized type
1 error


The reason for the error is this: the type of `nested` is inferred to `T.N.I`. This is correct. javac will then construct a synthetic AST for it, and the AST will be structurally correct as well: `T.N.I`. But a) the `Type` attached to `T.N` will be `T.N<T>` (which by itself is not correct), and b) after the synthetic AST is created, `Check.validate` is called on the type's AST, and fails, as the types is sees correspond to `T.N<T>.I`, which is illegal.

Note the synthetic AST is also set for local variable type inference, but the `validate` is called *before* the synthetic AST is created.

This PR proposes to do two things:
- move the `validate` call before the synthetic AST creation for `visitBindingPattern`, to mimic the behavior for `var`s.
- the `TreeMaker` is tweaked to inject erased types instead of parameterized types when generating qualified identifiers for classes or interfaces. This should correspond more closely to what happens when one types `T.N.I` in the source code.

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

Commit messages:
 - Removing trailing whitespace.
 - Only erase in QualIdent
 - Only erase types for classes
 - 8341901: Using 'var' keyword switch pattern matching causes compiler error

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

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

From alanb at openjdk.org  Mon Oct 14 14:26:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Oct 2024 14:26:15 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <Rd5Q3wc6sWFHwg1UH6WJjCjX2wDXhXxRFbKYJJ43ttk=.c160e1cf-0b9f-40bb-a922-756bcc1018ee@github.com>

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 350:

> 348:      */
> 349:     private Builder readModuleAttribute(DataInput in, ConstantPool cpool, int major,
> 350:                                         boolean previewClassfile)

It's isPreview in the caller, would be clearer to use the same here.

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 421:

> 419:                     && ((mods.contains(Requires.Modifier.TRANSITIVE) &&
> 420:                          !previewClassfile &&
> 421:                          !mn.startsWith("java."))

Just to double, will be JLS update specify that it's only allow for java.* aggregator modules?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1799608875
PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1799610658

From liach at openjdk.org  Mon Oct 14 17:25:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Oct 2024 17:25:22 GMT
Subject: Integrated: 8341924: Improve error message with structurally malformed
 Code array
In-Reply-To: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
References: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
Message-ID: <7ko6G-uetrubRkroxD2h-2Vi4mAbzNljFGb24KENj1w=.a683dd73-b87f-42cb-8c12-1081850775b9@github.com>

On Fri, 11 Oct 2024 05:39:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.
> 
> Before:
> 
> $ javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
> Error: error at or after byte 0
> }
> 
> 
> Now:
> 
> $ $localjdk2/bin/javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
>        0: iload_0
> Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
> }

This pull request has now been integrated.

Changeset: bd626442
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd6264420b9f248999dd8387c25c549b08bd193a
Stats:     9 lines in 1 file changed: 2 ins; 0 del; 7 mod

8341924: Improve error message with structurally malformed Code array

Reviewed-by: asotona

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

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

From jlahoda at openjdk.org  Mon Oct 14 19:44:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 19:44:15 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <Rd5Q3wc6sWFHwg1UH6WJjCjX2wDXhXxRFbKYJJ43ttk=.c160e1cf-0b9f-40bb-a922-756bcc1018ee@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <Rd5Q3wc6sWFHwg1UH6WJjCjX2wDXhXxRFbKYJJ43ttk=.c160e1cf-0b9f-40bb-a922-756bcc1018ee@github.com>
Message-ID: <6uy_EuWrx1eCnZ9s5Ots60R5SnAYR8Ux6FbyvF8ZoHA=.d093896d-fa7f-4ad3-ba45-a45fd5b45813@github.com>

On Mon, 14 Oct 2024 14:23:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 421:
> 
>> 419:                     && ((mods.contains(Requires.Modifier.TRANSITIVE) &&
>> 420:                          !previewClassfile &&
>> 421:                          !mn.startsWith("java."))
> 
> Just to double check, will be JLS update specify that it's only allow for java.* aggregator modules?

Only modules that participate in preview should be able to use `requires transitive java.base;` without having the preview flag set. And only modules in the JDK can participate in preview. I believe the JVMS will be updated to cover this.

We may want to restrict the condition here to only `java.se`, I am not sure. (Unless there are other modules that would use the directive, but I am not aware about any right now.)

Normally, the modules that "participate in preview" are those to which `java.base` exports the `jdk.internal.javac` package (and hence can use the `ParticipatesInPreview` annotation), but it didn't seem I can check the `java.base`'s exports at this place, so resorted to this hard-coded check. Hopefully, should only be temporary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1799993112

From duke at openjdk.org  Tue Oct 15 00:00:12 2024
From: duke at openjdk.org (toshiogata)
Date: Tue, 15 Oct 2024 00:00:12 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <gXcrN3fEZX3JScmqhJUb1oHEoiwJ4zc_L60Pn6UK5UY=.9d160d68-ffac-4ba2-a1ff-8636904fc58e@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
 <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>
 <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>
 <fFJQlcs5vLsVKQTfdkws1uvf8My2vG9YfTXouF7XDm0=.e799ab93-7d90-47ef-851e-1faeb822cf34@github.com>
 <gXcrN3fEZX3JScmqhJUb1oHEoiwJ4zc_L60Pn6UK5UY=.9d160d68-ffac-4ba2-a1ff-8636904fc58e@github.com>
Message-ID: <9TEAbmaFUrAU-8ZonR70lCO0OixoX2HVX7oohjbco8w=.20d9216d-951f-4f70-aa1d-f1f1df45f0d4@github.com>

On Fri, 11 Oct 2024 14:20:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @jonathan-gibbons 
>> I was wondering if you have had a chance to see my response and aivanov-jdk's question. I would appreciate your reaction. Thank you.
>
> @toshiogata Jon Gibbons is no longer working on Oracle. I can't say if that means he will no longer be active at all in the OpenJDK community, but you might want to lower your expectations of getting a reply, and I suggest proceeding with this PR without awaiting a response from him.

@magicus @jonathan-gibbons 
Thank you for your comments. I will proceed with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2412543606

From duke at openjdk.org  Tue Oct 15 00:00:12 2024
From: duke at openjdk.org (duke)
Date: Tue, 15 Oct 2024 00:00:12 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
Message-ID: <s6ZKvCsy7GqNMzFI1pTW8ox8b-IY9Q0iY7Is7X9dF8M=.d821535f-36ea-4017-b1b4-851eb3364bd0@github.com>

On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata <duke at openjdk.org> wrote:

>> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
>> Testing: modified tests
>
> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Move jtreg tags and expand wildcard imports"
>   
>   This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.

@toshiogata 
Your change (at version b1b2b5fe5767071ba1712dec4b385c8d7a3719e3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2412545481

From cstein at openjdk.org  Tue Oct 15 07:47:14 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Oct 2024 07:47:14 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
Message-ID: <hDqJ7sxCdMDJ47EFLZ_Qsut54RELxzpKxhbfWJvyDYY=.cd8d6b33-fb92-4a58-8e2c-4eb66adb79e2@github.com>

On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata <duke at openjdk.org> wrote:

>> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
>> Testing: modified tests
>
> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Move jtreg tags and expand wildcard imports"
>   
>   This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.

Renames/moves look also good to me, thus I'll sponsor this PR.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20475#pullrequestreview-2368442006

From duke at openjdk.org  Tue Oct 15 07:50:16 2024
From: duke at openjdk.org (toshiogata)
Date: Tue, 15 Oct 2024 07:50:16 GMT
Subject: Integrated: 8337851: Some tests have name which confuse jtreg
In-Reply-To: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
Message-ID: <kTn0Vof35lvIOFDG1FpMKI0jCCG4JyykY5wf7ISoMYs=.12fb2e0d-662c-42af-8c13-aaaad9353d5e@github.com>

On Tue, 6 Aug 2024 05:51:35 GMT, toshiogata <duke at openjdk.org> wrote:

> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
> Testing: modified tests

This pull request has now been integrated.

Changeset: e6698f51
Author:    t.ogata <ogata.toshitaka at fujitsu.com>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6698f51a1977d553ce4e1dd14b43b0d325224fa
Stats:     0 lines in 4 files changed: 0 ins; 0 del; 0 mod

8337851: Some tests have name which confuse jtreg

Reviewed-by: aivanov, prr, cstein

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

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

From hannesw at openjdk.org  Tue Oct 15 10:46:26 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 15 Oct 2024 10:46:26 GMT
Subject: RFR: 8321500: javadoc rejects '@' in multi-line attribute value
Message-ID: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>

Please review the removal of code in `DocCommentParser` that created an error when encountering a spurious "@" character in an HTML attribute value after a line break. 

The removed code (which was added in its current form in 2012) seemed to assume that such a "@" character was part of a block tag and therefore an indication of an unclosed attribute value. However, both line breaks and "@" are valid characters in HTML attributes. Note that valid content for HTML attributes in `DocCommentParser` is [text and entities as per HTML5][html5-attributes] as well as JavaDoc inline tags, but not block tags.

[html5-attributes]: https://html.spec.whatwg.org/multipage/syntax.html#syntax-attribute-value

The change adds two doctree tests, one to make sure HTML attributes with mixed values (text, line breaks, entities, inline tags, "@") are parsed correctly, and a second one to make sure actual unclosed attribute values are still recognized as errors.

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

Commit messages:
 - JDK-8321500: javadoc rejects '@' in multi-line attribute value

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

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

From mullan at openjdk.org  Tue Oct 15 13:03:33 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
Message-ID: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>

This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.

NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.

The code changes can be broken down into roughly the following categories:

1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.

There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 

Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most familiar with.

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

Commit messages:
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge
 - fix setOpenURIHandler docs
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Fix whitespace
 - Merge
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove windows-specific policy file as it is no longer needed.
 - clientlibs: Updated Problemlist JBS ID for javax/swing/JPopupMenu/6694823/bug6694823.java
 - Merge
 - ... and 73 more: https://git.openjdk.org/jdk/compare/a601cd2e...d05122fb

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338411
  Stats: 63777 lines in 1825 files changed: 935 ins; 59236 del; 3606 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From liach at openjdk.org  Tue Oct 15 13:03:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <UeySvh7AQqeSsG8yAZRYFmWTuf83RoFP5lMQgxVOLt4=.a8119b9a-13ad-4079-a67a-7d930aa271df@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

@seanjmullan I think you can use many lines of command in one github comment, like

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2411850563

From dfuchs at openjdk.org  Tue Oct 15 15:19:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:19:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Impressive work. I had a look at everything source in `net`, `logging`, `jmx` and `httpclient`.

Mostly good, but I was surprised to see an explicit new `throw new SecurityException()` in `java.util.logging`; Also JMX still supports authentication and coarse authorisation, which means that `SecurityException` can still be thrown by the `JMXAuthenticator` / `MBeanServerAccessController` on the server side and thrown on the client side. I have made some suggestions.

src/java.base/share/classes/java/net/URLClassLoader.java line 667:

> 665:      * @param codesource the codesource
> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
> 667:      * @return the permissions for the codesource

Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

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

> 2428:     @Deprecated(since="17", forRemoval=true)
> 2429:     public void checkAccess() {
> 2430:         throw new SecurityException();

Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:

> 157:      * is specified for the MBean.
> 158:      * @throws SecurityException if the client does not have permission
> 159:      * to perform this operation.

Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.

So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.

An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:

> 65:      *
> 66:      * @exception SecurityException if the server cannot authenticate the user
> 67:      * with the provided credentials.

Should this be reverted? Authentication has not been removed.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:

> 223:      *
> 224:      * @exception SecurityException if the connection cannot be made
> 225:      * for security reasons.

I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369425602
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801215698
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801291195
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801341618
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801357691
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801362306

From alanb at openjdk.org  Tue Oct 15 15:24:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:24:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>

On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
> 
>> 2428:     @Deprecated(since="17", forRemoval=true)
>> 2429:     public void checkAccess() {
>> 2430:         throw new SecurityException();
> 
> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801415455

From dfuchs at openjdk.org  Tue Oct 15 15:36:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:36:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
Message-ID: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>

On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>> 
>>> 2428:     @Deprecated(since="17", forRemoval=true)
>>> 2429:     public void checkAccess() {
>>> 2430:         throw new SecurityException();
>> 
>> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?
>
> This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801445724

From ihse at openjdk.org  Tue Oct 15 15:42:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 15:42:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <V_CgYKM3b79sS7MTegDSIISOX92kZVccIePJlJ4hFzk=.b9cabb49-8f94-4d8b-80a5-c8cd66a2821d@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369826643

From duke at openjdk.org  Tue Oct 15 15:55:17 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 15:55:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
Message-ID: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>

On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a bit of forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.
>
> OK

While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:


if (System.getSecurityManager() != null) {
    foo.checkAccess();
}


I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.

But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801484176

From mullan at openjdk.org  Tue Oct 15 16:17:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 16:17:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
Message-ID: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>

On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OK
>
> While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:
> 
> 
> if (System.getSecurityManager() != null) {
>     foo.checkAccess();
> }
> 
> 
> I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.
> 
> But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801518838

From jjg at openjdk.org  Tue Oct 15 16:32:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 15 Oct 2024 16:32:13 GMT
Subject: RFR: 8321500: javadoc rejects '@' in multi-line attribute value
In-Reply-To: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
References: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
Message-ID: <EyMsoEceVwSYc7HWVqOgiwUExcVqHksVKzqcdSu60ks=.03a027a7-f00f-45f1-9ace-235b22521ed4@github.com>

On Tue, 15 Oct 2024 10:41:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review the removal of code in `DocCommentParser` that created an error when encountering a spurious "@" character in an HTML attribute value after a line break. 
> 
> The removed code (which was added in its current form in 2012) seemed to assume that such a "@" character was part of a block tag and therefore an indication of an unclosed attribute value. However, both line breaks and "@" are valid characters in HTML attributes. Note that valid content for HTML attributes in `DocCommentParser` is [text and entities as per HTML5][html5-attributes] as well as JavaDoc inline tags, but not block tags.
> 
> [html5-attributes]: https://html.spec.whatwg.org/multipage/syntax.html#syntax-attribute-value
> 
> The change adds two doctree tests, one to make sure HTML attributes with mixed values (text, line breaks, entities, inline tags, "@") are parsed correctly, and a second one to make sure actual unclosed attribute values are still recognized as errors.

The original behavior for javadoc (I hesitate to call it a spec) was that any and every occurrence at the beginning of a line (after any leading whitespace) was the beginning of a block tag. This predated the introduction of `DocCommentParser` and was related to (not sure which was cause or effect) the way that the comment was "parsed" by breaking into an initial description followed by block tags, almost completely ignoring any HTML content within those sections.

That behavior was honored when `DocCommentParser` was introduced, and remained in place until it was modified to allow leading `@` characters inside inline tags, to work around the "annotation problem" in code samples, whether using `{@code}` or `{@snippet}`.

I don't disagree that this change might be a good one, but it is a deliberate change in documented and/or long-standing behavior, and so needs a CSR and probably a spec update somewhere.

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

PR Comment: https://git.openjdk.org/jdk/pull/21520#issuecomment-2414489475

From sgehwolf at openjdk.org  Tue Oct 15 16:37:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:37:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:


        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
        ...
        }


Intentional?

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369966554

From duke at openjdk.org  Tue Oct 15 16:37:22 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 16:37:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
Message-ID: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>

On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.

These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).

Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801549133

From dfuchs at openjdk.org  Tue Oct 15 16:44:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 16:44:16 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <00frHPVuBzy1HhWEnmBtfSS4CeXN3uOVVilYbvntplY=.40626317-3ede-4a7f-b906-a8fa7829a418@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

@jerboaa  Yes - this is intentional:
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414512674

From sgehwolf at openjdk.org  Tue Oct 15 16:57:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <kht8vPv-muz8n2rWPcwE6tr_AIfxSHjqRdW85e7qxQA=.3f1ea0f1-51d8-4b31-ace9-74e00b0f0152@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

> @jerboaa Yes - this is intentional:
> 
> > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414541204

From mullan at openjdk.org  Tue Oct 15 17:04:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 17:04:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
Message-ID: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>

On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>
>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
> 
> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
> 
> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
> 
> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801595566

From erikj at openjdk.org  Tue Oct 15 17:52:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <8aC3jj6-F-URh3DOk-64i-0FSHKwpUX7gPAvP70FUnI=.b8b29107-9a65-403f-8292-1613a401a3d3@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370152926

From cjplummer at openjdk.org  Tue Oct 15 17:52:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <kAgds4PDaZp8jva1ib1vtT7Tcj2kOOf3SbiOkHnYIZE=.2c46f0ff-0a3d-43a7-900e-482ab38f03ce@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

jdk.jdi and jdk.attach changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370157272

From coleenp at openjdk.org  Tue Oct 15 18:51:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Oct 2024 18:51:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <fedkR8waMXM0YzqN0-EynQLWQ03lqgpylDzmPbAXOP0=.a774e759-073e-4e77-85de-49c69acf4904@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

HotSpot changes look great.  Will clean out the rest in [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370289526

From naoto at openjdk.org  Tue Oct 15 18:51:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Oct 2024 18:51:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <4WtQzf1WGGjNSzOuxPNvYOub8uuVyYhaad13b4RfMDI=.d7e704b1-68af-4ddd-b221-77b76c179f98@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

This is a great work! I looked through the following areas that relate to i18n/charset/console/javatime, and they all look good to me.

src/java.base/share/classes/java/util/Locale.java
src/java.base/share/classes/java/util/ResourceBundle.java
src/java.base/share/classes/java/util/TimeZone.java
src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java

test/jdk/java/io/Console/
test/jdk/java/nio/charset/spi/
test/jdk/java/time/nontestng/java/time/chrono/
test/jdk/java/util/PluggableLocale/
test/jdk/java/util/ResourceBundle/
test/jdk/java/util/TimeZone/
test/jdk/java/util/spi/ResourceBundleControlProvider/
test/jdk/sun/nio/cs/
test/jdk/sun/util/locale/provider/

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370292817

From hannesw at openjdk.org  Tue Oct 15 19:30:11 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 15 Oct 2024 19:30:11 GMT
Subject: RFR: 8321500: javadoc rejects '@' in multi-line attribute value
In-Reply-To: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
References: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
Message-ID: <wSYGXzJNo5mTiIe-8qH444QOvgEyoZQ1KZm57gFCr-Q=.cc80f7a6-99d8-417e-b3fa-13055763b184@github.com>

On Tue, 15 Oct 2024 10:41:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review the removal of code in `DocCommentParser` that created an error when encountering a spurious "@" character in an HTML attribute value after a line break. 
> 
> The removed code (which was added in its current form in 2012) seemed to assume that such a "@" character was part of a block tag and therefore an indication of an unclosed attribute value. However, both line breaks and "@" are valid characters in HTML attributes. Note that valid content for HTML attributes in `DocCommentParser` is [text and entities as per HTML5][html5-attributes] as well as JavaDoc inline tags, but not block tags.
> 
> [html5-attributes]: https://html.spec.whatwg.org/multipage/syntax.html#syntax-attribute-value
> 
> The change adds two doctree tests, one to make sure HTML attributes with mixed values (text, line breaks, entities, inline tags, "@") are parsed correctly, and a second one to make sure actual unclosed attribute values are still recognized as errors.

Thanks for the context, Jon. I wrote a [lengthy comment][comment] on the JBS issue, unfortunately before I saw your comment above, because it would have answered most of my questions. As explained in my JBS comment I would still consider the current behavior a bug, but I understand why it might be a good idea to do a CSR and spec change.

[comment]: https://bugs.openjdk.org/browse/JDK-8321500?focusedId=14713202&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14713202

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

PR Comment: https://git.openjdk.org/jdk/pull/21520#issuecomment-2414837003

From mchung at openjdk.org  Tue Oct 15 19:36:24 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Oct 2024 19:36:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Source changes in `java.base/java/lang/**`, `java.management`, and `jdk.management` module look good.  Also hotspot change.

src/java.base/share/classes/java/lang/SecurityManager.java line 72:

> 70:     private static class StackWalkerHolder {
> 71:         static final StackWalker STACK_WALKER =
> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);

Suggestion:

            StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));


Method info is not needed.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370337536
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801781277

From prr at openjdk.org  Tue Oct 15 21:39:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Oct 2024 21:39:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

I have looked at the source code changes in java.desktop
They are mostly OK.
I have noted text that was removed in two places in java.awt.Robot where the removal should be reverted.
I have also "grepped" the sandbox repo to identify any errors of omission - pertaining to the SE API specification, not internals - and found none.

I also noted a couple of Permission classes we should deprecate - and filed bugs on them.

I have not yet examined any of the test updates. That looks like a big job.

src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:

> 37:  * @apiNote
> 38:  * This permission cannot be used for controlling access to resources anymore
> 39:  * as the Security Manager is no longer supported.

After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

src/java.desktop/share/classes/java/awt/Robot.java line 433:

> 431:      * then a {@code SecurityException} may be thrown,
> 432:      * or the content of the returned {@code Color} is undefined.
> 433:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/java/awt/Robot.java line 460:

> 458:      * then a {@code SecurityException} may be thrown,
> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
> 460:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java line 36:

> 34:  * actions list; you either have the named permission or you don't.
> 35:  * <p>
> 36:  * The target name is the name of the audio permission.

AudioPermission is another class we should deprecate

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370309133
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801765010
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031119
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031524
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802042388

From mullan at openjdk.org  Tue Oct 15 22:12:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:12:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>

On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
> 
>> 665:      * @param codesource the codesource
>> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
>> 667:      * @return the permissions for the codesource
> 
> Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

Yes, I think that is a good suggestion. Let me think about whether it should be done as part of this JEP or if we can do it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802073264

From mullan at openjdk.org  Tue Oct 15 22:19:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
Message-ID: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>

On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
> 
>> 70:     private static class StackWalkerHolder {
>> 71:         static final StackWalker STACK_WALKER =
>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> 
> Suggestion:
> 
>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
> 
> 
> Method info is not needed.

Thanks, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077370

From mullan at openjdk.org  Tue Oct 15 22:19:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>

On Tue, 15 Oct 2024 21:17:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.desktop/share/classes/java/awt/Robot.java line 433:
> 
>> 431:      * then a {@code SecurityException} may be thrown,
>> 432:      * or the content of the returned {@code Color} is undefined.
>> 433:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

> src/java.desktop/share/classes/java/awt/Robot.java line 460:
> 
>> 458:      * then a {@code SecurityException} may be thrown,
>> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
>> 460:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077916
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802078111

From mullan at openjdk.org  Tue Oct 15 22:19:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>

On Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
> 
>> 223:      *
>> 224:      * @exception SecurityException if the connection cannot be made
>> 225:      * for security reasons.
> 
> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802076052

From jjg3 at pobox.com  Wed Oct 16 01:03:38 2024
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Tue, 15 Oct 2024 18:03:38 -0700
Subject: Obscure build failure
Message-ID: <552FCF4A-6748-41AD-9A7B-E0B62ECB026C@pobox.com>

I am trying to build a fresh new unmodified copy of OpenJDK, and have run into the following obscure error.  I?m using JDK 23.0.1 as the boot JDK.
The significant line is: 
    Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type

This is on a Mac, with latest Sonoma OS, and latest Xcode, although the failure is more in the Java/JDK parts of the system.  Could it be related to the new classfile library?

? Jon

Creating support/modules_cmds/jdk.jdeps/jdeprscan from 1 file(s)
Creating support/modules_cmds/jdk.jdi/jdb from 1 file(s)
Creating support/modules_cmds/jdk.jfr/jfr from 1 file(s)
Creating support/modules_cmds/jdk.jlink/jimage from 1 file(s)
Creating jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/jpackageapplauncher from 16 file(s)
Creating support/modules_cmds/jdk.jlink/jlink from 1 file(s)
Creating support/modules_cmds/jdk.jlink/jmod from 1 file(s)
Creating support/modules_cmds/jdk.jpackage/jpackage from 1 file(s)
Creating support/modules_cmds/jdk.jshell/jshell from 1 file(s)
Creating support/modules_libs/jdk.net/libextnet.dylib <http://jdk.net/libextnet.dylib> from 1 file(s)
Creating support/modules_cmds/jdk.jstatd/jstatd from 1 file(s)
Creating support/modules_libs/jdk.security.auth/libjaas.dylib from 1 file(s)
Compiling up to 4 files for COMPILE_CREATE_SYMBOLS
Compiling up to 70 files for COMPILE_CREATE_SYMBOLS
Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
make[3]: *** [/Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1
make[2]: *** [jdk.compiler-gendata] Error 2
make[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'jdk-image' in configuration 'macosx-aarch64-server-release' (exit code 2) 
Stopping javac server

=== Output from failing command(s) repeated here ===
* For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)

* All command lines available in /Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241015/82e0a1f7/attachment-0001.htm>

From jai.forums2013 at gmail.com  Wed Oct 16 01:47:00 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 16 Oct 2024 07:17:00 +0530
Subject: Obscure build failure
In-Reply-To: <552FCF4A-6748-41AD-9A7B-E0B62ECB026C@pobox.com>
References: <552FCF4A-6748-41AD-9A7B-E0B62ECB026C@pobox.com>
Message-ID: <d56108d8-35d5-40c9-ab00-02f7ecb3299e@gmail.com>

Hello Jon,

This issue is discussed at https://bugs.openjdk.org/browse/JDK-8340341. 
It's a bug in the clang++ compiler shipped with Xcode 16.

-Jaikiran

On 16/10/24 6:33 am, Jonathan Gibbons wrote:
> I am trying to build a fresh new unmodified copy of OpenJDK, and have 
> run into the following obscure error. ?I?m using JDK 23.0.1 as the 
> boot JDK.
> The significant line is:
> ? ? Exception in thread "main" java.lang.ClassFormatError: 
> StackMapTable format error: bad verification type
>
> This is on a Mac, with latest Sonoma OS, and latest Xcode, although 
> the failure is more in the Java/JDK parts of the system. ?Could it be 
> related to the new classfile library?
>
> ? Jon
>
> Creating support/modules_cmds/jdk.jdeps/jdeprscan from 1 file(s)
> Creating support/modules_cmds/jdk.jdi/jdb from 1 file(s)
> Creating support/modules_cmds/jdk.jfr/jfr from 1 file(s)
> Creating support/modules_cmds/jdk.jlink/jimage from 1 file(s)
> Creating 
> jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/jpackageapplauncher 
> from 16 file(s)
> Creating support/modules_cmds/jdk.jlink/jlink from 1 file(s)
> Creating support/modules_cmds/jdk.jlink/jmod from 1 file(s)
> Creating support/modules_cmds/jdk.jpackage/jpackage from 1 file(s)
> Creating support/modules_cmds/jdk.jshell/jshell from 1 file(s)
> Creating support/modules_libs/jdk.net/libextnet.dylib 
> <http://jdk.net/libextnet.dylib>?from 1 file(s)
> Creating support/modules_cmds/jdk.jstatd/jstatd from 1 file(s)
> Creating support/modules_libs/jdk.security.auth/libjaas.dylib from 1 
> file(s)
> Compiling up to 4 files for COMPILE_CREATE_SYMBOLS
> Compiling up to 70 files for COMPILE_CREATE_SYMBOLS
> Exception in thread "main" java.lang.ClassFormatError: StackMapTable 
> format error: bad verification type
> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
> make[3]: *** 
> [/Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] 
> Error 1
> make[2]: *** [jdk.compiler-gendata] Error 2
> make[2]: *** Waiting for unfinished jobs....
>
> ERROR: Build failed for target 'jdk-image' in configuration 
> 'macosx-aarch64-server-release' (exit code 2)
> Stopping javac server
>
> === Output from failing command(s) repeated here ===
> * For target 
> buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> Exception in thread "main" java.lang.ClassFormatError: StackMapTable 
> format error: bad verification type
> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>
> * All command lines available in 
> /Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/make-support/failure-logs.
> === End of repeated output ===
>
> No indication of failed target found.
> HELP: Try searching the build log for '] Error'.
> HELP: Run 'make doctor' to diagnose build problems.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241016/a43d7c8a/attachment.htm>

From jjg3 at pobox.com  Wed Oct 16 02:56:33 2024
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Tue, 15 Oct 2024 19:56:33 -0700
Subject: Obscure build failure
In-Reply-To: <d56108d8-35d5-40c9-ab00-02f7ecb3299e@gmail.com>
References: <552FCF4A-6748-41AD-9A7B-E0B62ECB026C@pobox.com>
 <d56108d8-35d5-40c9-ab00-02f7ecb3299e@gmail.com>
Message-ID: <6A00CDFE-178E-47D0-A475-BC453C963CAD@pobox.com>

Hi Jaikiran,

Thanks for the reference; yes I now remember seeing this discussion recently.

As for me, I didn?t so much upgrade my local XCode, so much as I had to move to a new laptop. ;-)

? Jon

> On Oct 15, 2024, at 6:47?PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Hello Jon,
> 
> This issue is discussed at https://bugs.openjdk.org/browse/JDK-8340341. It's a bug in the clang++ compiler shipped with Xcode 16.
> 
> -Jaikiran
> 
> On 16/10/24 6:33 am, Jonathan Gibbons wrote:
>> I am trying to build a fresh new unmodified copy of OpenJDK, and have run into the following obscure error.  I?m using JDK 23.0.1 as the boot JDK.
>> The significant line is: 
>>     Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>> 
>> This is on a Mac, with latest Sonoma OS, and latest Xcode, although the failure is more in the Java/JDK parts of the system.  Could it be related to the new classfile library?
>> 
>> ? Jon
>> 
>> Creating support/modules_cmds/jdk.jdeps/jdeprscan from 1 file(s)
>> Creating support/modules_cmds/jdk.jdi/jdb from 1 file(s)
>> Creating support/modules_cmds/jdk.jfr/jfr from 1 file(s)
>> Creating support/modules_cmds/jdk.jlink/jimage from 1 file(s)
>> Creating jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/jpackageapplauncher from 16 file(s)
>> Creating support/modules_cmds/jdk.jlink/jlink from 1 file(s)
>> Creating support/modules_cmds/jdk.jlink/jmod from 1 file(s)
>> Creating support/modules_cmds/jdk.jpackage/jpackage from 1 file(s)
>> Creating support/modules_cmds/jdk.jshell/jshell from 1 file(s)
>> Creating support/modules_libs/jdk.net/libextnet.dylib <http://jdk.net/libextnet.dylib> from 1 file(s)
>> Creating support/modules_cmds/jdk.jstatd/jstatd from 1 file(s)
>> Creating support/modules_libs/jdk.security.auth/libjaas.dylib from 1 file(s)
>> Compiling up to 4 files for COMPILE_CREATE_SYMBOLS
>> Compiling up to 70 files for COMPILE_CREATE_SYMBOLS
>> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>> make[3]: *** [/Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1
>> make[2]: *** [jdk.compiler-gendata] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>> 
>> ERROR: Build failed for target 'jdk-image' in configuration 'macosx-aarch64-server-release' (exit code 2) 
>> Stopping javac server
>> 
>> === Output from failing command(s) repeated here ===
>> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
>> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>> 
>> * All command lines available in /Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241015/9cb0ae53/attachment-0001.htm>

From alanb at openjdk.org  Wed Oct 16 06:31:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:31:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
Message-ID: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>

On Tue, 15 Oct 2024 22:15:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
>> 
>>> 70:     private static class StackWalkerHolder {
>>> 71:         static final StackWalker STACK_WALKER =
>>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>> 
>> Suggestion:
>> 
>>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
>> 
>> 
>> Method info is not needed.
>
> Thanks, will fix.

SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have not in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802437558

From jpai at openjdk.org  Wed Oct 16 06:51:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 06:51:58 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v15]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <SuHtP5h78fEQlin6Vvr0CufbI7H3yRuwx8cfO2KRumM=.c8d67072-df0b-49f8-8b11-c6251622000f@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update man page after Roger's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/d4bce414..bb63acba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=13-14

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

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

From alanb at openjdk.org  Wed Oct 16 07:01:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 07:01:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
Message-ID: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>

On Tue, 15 Oct 2024 22:16:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Robot.java line 433:
>> 
>>> 431:      * then a {@code SecurityException} may be thrown,
>>> 432:      * or the content of the returned {@code Color} is undefined.
>>> 433:      * </p>
>> 
>> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.
>
> Ok, I will revert it.

The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802471843

From alanb at openjdk.org  Wed Oct 16 08:37:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:37:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <eDT17ezlw65yxabhUuwqn337hsf_yb9aZyjc7Cs2TTw=.60e28c95-d6e4-4d23-a9b6-bc0b1e0cdd55@github.com>

On Tue, 15 Oct 2024 18:57:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:
> 
>> 37:  * @apiNote
>> 38:  * This permission cannot be used for controlling access to resources anymore
>> 39:  * as the Security Manager is no longer supported.
> 
> After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

JEP 486 lists deprecating the permission classes as future work. It would be very disruptive to do this now, but will be a lot easier once the JEP is integrated and the post-JEP tasks to remove the hundreds of usages in the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802617206

From abimpoudis at openjdk.org  Wed Oct 16 09:23:13 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 16 Oct 2024 09:23:13 GMT
Subject: RFR: 8341901: Using 'var' keyword switch pattern matching causes
 compiler error
In-Reply-To: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
References: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
Message-ID: <ivLGGfUK-K6DU-_ZD16hIcNIAM9VapFV_QLVgtKcStE=.61d9ff7a-1452-4b38-932c-efdfd108ddc0@github.com>

On Mon, 14 Oct 2024 13:20:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class T {
>    record R(N.I i) {}
>    int test(Object o) {
>        return switch (o) {
>            case R(var nested) -> 0;
>            default -> 0;
>        };
>    }
>    static class N<T> {
>        interface I {}
>    }
> }
> 
> 
> This fails to compile since JDK 23, due to:
> 
> $ javac T.java 
> error: cannot select a static class from a parameterized type
> 1 error
> 
> 
> The reason for the error is this: the type of `nested` is inferred to `T.N.I`. This is correct. javac will then construct a synthetic AST for it, and the AST will be structurally correct as well: `T.N.I`. But a) the `Type` attached to `T.N` will be `T.N<T>` (which by itself is not correct), and b) after the synthetic AST is created, `Check.validate` is called on the type's AST, and fails, as the types is sees correspond to `T.N<T>.I`, which is illegal.
> 
> Note the synthetic AST is also set for local variable type inference, but the `validate` is called *before* the synthetic AST is created.
> 
> This PR proposes to do two things:
> - move the `validate` call before the synthetic AST creation for `visitBindingPattern`, to mimic the behavior for `var`s.
> - the `TreeMaker` is tweaked to inject erased types instead of parameterized types when generating qualified identifiers for classes or interfaces. This should correspond more closely to what happens when one types `T.N.I` in the source code.

According to my understanding, this bug is fixed by adjusting the `TreeMaker` to use the erased types. As a result the path `T.N.I ` is correct and the tests pass, correctly. Moving `chk.validate` is an optimization right? In this case `tree.var.vartype` will be null for both tests so the validate does nothing.

Otherwise LGTM

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21495#pullrequestreview-2371780920

From weijun at openjdk.org  Wed Oct 16 13:32:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Oct 2024 13:32:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

`java.security.jgss`, `jdk.security.auth`, and `jdk.security.jgss` look mostly fine except for [one question](https://github.com/openjdk/jdk/pull/21498#pullrequestreview-2372476763).

src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:

> 29: 
> 30: /**
> 31:  * This class is for GSS security context permissions.

Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2372479736
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803106645

From jjg3 at pobox.com  Wed Oct 16 15:04:20 2024
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Wed, 16 Oct 2024 08:04:20 -0700
Subject: Obscure build failure
In-Reply-To: <6A00CDFE-178E-47D0-A475-BC453C963CAD@pobox.com>
References: <552FCF4A-6748-41AD-9A7B-E0B62ECB026C@pobox.com>
 <d56108d8-35d5-40c9-ab00-02f7ecb3299e@gmail.com>
 <6A00CDFE-178E-47D0-A475-BC453C963CAD@pobox.com>
Message-ID: <D6D42E5F-323D-499A-952B-9C30C692854A@pobox.com>

Jaikiran,

Thank you again for your help yesterday. I have now downloaded Xcode 15.4 and managed to build my OpenJDK repo.

? Jon


> On Oct 15, 2024, at 7:56?PM, Jonathan Gibbons <jjg3 at pobox.com> wrote:
> 
> Hi Jaikiran,
> 
> Thanks for the reference; yes I now remember seeing this discussion recently.
> 
> As for me, I didn?t so much upgrade my local XCode, so much as I had to move to a new laptop. ;-)
> 
> ? Jon
> 
>> On Oct 15, 2024, at 6:47?PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
>> 
>> Hello Jon,
>> 
>> This issue is discussed at https://bugs.openjdk.org/browse/JDK-8340341. It's a bug in the clang++ compiler shipped with Xcode 16.
>> 
>> -Jaikiran
>> 
>> On 16/10/24 6:33 am, Jonathan Gibbons wrote:
>>> I am trying to build a fresh new unmodified copy of OpenJDK, and have run into the following obscure error.  I?m using JDK 23.0.1 as the boot JDK.
>>> The significant line is: 
>>>     Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>>> 
>>> This is on a Mac, with latest Sonoma OS, and latest Xcode, although the failure is more in the Java/JDK parts of the system.  Could it be related to the new classfile library?
>>> 
>>> ? Jon
>>> 
>>> Creating support/modules_cmds/jdk.jdeps/jdeprscan from 1 file(s)
>>> Creating support/modules_cmds/jdk.jdi/jdb from 1 file(s)
>>> Creating support/modules_cmds/jdk.jfr/jfr from 1 file(s)
>>> Creating support/modules_cmds/jdk.jlink/jimage from 1 file(s)
>>> Creating jdk/modules/jdk.jpackage/jdk/jpackage/internal/resources/jpackageapplauncher from 16 file(s)
>>> Creating support/modules_cmds/jdk.jlink/jlink from 1 file(s)
>>> Creating support/modules_cmds/jdk.jlink/jmod from 1 file(s)
>>> Creating support/modules_cmds/jdk.jpackage/jpackage from 1 file(s)
>>> Creating support/modules_cmds/jdk.jshell/jshell from 1 file(s)
>>> Creating support/modules_libs/jdk.net/libextnet.dylib <http://jdk.net/libextnet.dylib> from 1 file(s)
>>> Creating support/modules_cmds/jdk.jstatd/jstatd from 1 file(s)
>>> Creating support/modules_libs/jdk.security.auth/libjaas.dylib from 1 file(s)
>>> Compiling up to 4 files for COMPILE_CREATE_SYMBOLS
>>> Compiling up to 70 files for COMPILE_CREATE_SYMBOLS
>>> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>>> make[3]: *** [/Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1
>>> make[2]: *** [jdk.compiler-gendata] Error 2
>>> make[2]: *** Waiting for unfinished jobs....
>>> 
>>> ERROR: Build failed for target 'jdk-image' in configuration 'macosx-aarch64-server-release' (exit code 2) 
>>> Stopping javac server
>>> 
>>> === Output from failing command(s) repeated here ===
>>> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
>>> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
>>> at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
>>> at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>>> 
>>> * All command lines available in /Users/jsqrdg/OpenJDK/jdk/jdk.ref/build/macosx-aarch64-server-release/make-support/failure-logs.
>>> === End of repeated output ===
>>> 
>>> No indication of failed target found.
>>> HELP: Try searching the build log for '] Error'.
>>> HELP: Run 'make doctor' to diagnose build problems.
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241016/afe088a0/attachment-0001.htm>

From asotona at openjdk.org  Wed Oct 16 15:08:15 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 16 Oct 2024 15:08:15 GMT
Subject: RFR: 8341966: Broken annotated module may lead to an exception in
 javac [v2]
In-Reply-To: <GgDTKH8FEpzwftuGUlN4S5i6fB3xXEexXH3Aq2eQHjg=.194b0c22-5b34-40ad-855c-655e393a8bac@github.com>
References: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
 <GgDTKH8FEpzwftuGUlN4S5i6fB3xXEexXH3Aq2eQHjg=.194b0c22-5b34-40ad-855c-655e393a8bac@github.com>
Message-ID: <QbNh2d0KxTfewkD4jT2j6VwV8SGj9MLIJoqU_2p7xKg=.ed52da03-45ab-4fea-88d9-0a0fcbca6b84@github.com>

On Mon, 14 Oct 2024 06:01:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider a `module-info.class`, that both:
>>  - is wrong, so it will produce a bad-classfile error, for example due to an illegal `requires transitive java.base;`
>>  - and the module is annotated
>> 
>> If the javac proceeds to resolve the annotations (which is not the default, but can be pushed to do it), it will crash with an `AssertionError` while trying to un-proxy the annotations. This is because there's an assert that `requestingOwner.owner.kind == MDL`, but since the module is erroneous, the kind is `ERR`, and the assert fails.
>> 
>> The proposal is to loosen the assert a bit, and require `requestingOwner.owner instanceof ModuleSymbol`. That should still be sufficiently strong, while permitting broken modules to be handled.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - using lambda instead of an anonymous innerclass.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21486#pullrequestreview-2372799098

From jjg at openjdk.org  Wed Oct 16 15:12:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 16 Oct 2024 15:12:13 GMT
Subject: RFR: 8321500: javadoc rejects '@' in multi-line attribute value
In-Reply-To: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
References: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
Message-ID: <Pjjl8v2U71AkbgyRvIQj5L4GCuRjGvMwarWd9IOTkKE=.9abf3346-2f22-4b9f-ba97-99c9bb1d3672@github.com>

On Tue, 15 Oct 2024 10:41:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review the removal of code in `DocCommentParser` that created an error when encountering a spurious "@" character in an HTML attribute value after a line break. 
> 
> The removed code (which was added in its current form in 2012) seemed to assume that such a "@" character was part of a block tag and therefore an indication of an unclosed attribute value. However, both line breaks and "@" are valid characters in HTML attributes. Note that valid content for HTML attributes in `DocCommentParser` is [text and entities as per HTML5][html5-attributes] as well as JavaDoc inline tags, but not block tags.
> 
> [html5-attributes]: https://html.spec.whatwg.org/multipage/syntax.html#syntax-attribute-value
> 
> The change adds two doctree tests, one to make sure HTML attributes with mixed values (text, line breaks, entities, inline tags, "@") are parsed correctly, and a second one to make sure actual unclosed attribute values are still recognized as errors.

For sure the change will have almost no negative impact, because you will simply permitting a previously effectively invalid sequence of characters. You could reasonably say the bug was not going "all-in" on HTML parsing in the original implementation of `DocCommentParser`.  Maybe it would be enough to do a Release Note.

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

PR Comment: https://git.openjdk.org/jdk/pull/21520#issuecomment-2417117945

From duke at openjdk.org  Wed Oct 16 15:34:24 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 16 Oct 2024 15:34:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
Message-ID: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>

On Wed, 16 Oct 2024 06:28:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks, will fix.
>
> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

**SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.

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

See?also:
- https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803352590

From vromero at openjdk.org  Wed Oct 16 15:40:16 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Oct 2024 15:40:16 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <LZJ1kn-yCJ66HlIfPxBubV1QN-dtiJS03SsDKOuX91Q=.14721970-2d75-4863-8960-a3508b2355a2@github.com>

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2372901360

From alanb at openjdk.org  Wed Oct 16 15:56:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 15:56:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
Message-ID: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>

On Wed, 16 Oct 2024 15:31:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.
>
> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
> 
> --------------------------------------------------------------------------------
> 
> See?also:
> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803388208

From joehw at openjdk.org  Wed Oct 16 18:03:23 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 16 Oct 2024 18:03:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <8MHic1Yb7xtxtU0HM8yKLAjD2pYzTWs6Z6G-Adsqcvg=.e5ea6cd4-c3bd-44cb-9b9c-c87ed2f3d0b7@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Changes in source src/java.xml, JAXP tests under test/jaxp, look good. I double-checked my notes on the test changes, they were mostly about removing the runs with Security Manager.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2373273367

From mullan at openjdk.org  Wed Oct 16 20:17:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:17:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
Message-ID: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>

On Wed, 16 Oct 2024 15:53:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
>> 
>> --------------------------------------------------------------------------------
>> 
>> See?also:
>> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565
>
> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803740577

From mullan at openjdk.org  Wed Oct 16 20:45:38 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:45:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
Message-ID: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>

On Wed, 16 Oct 2024 06:58:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I will revert it.
>
> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803774792

From mullan at openjdk.org  Wed Oct 16 20:54:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:54:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
Message-ID: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>

On Wed, 16 Oct 2024 13:28:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This class is for GSS security context permissions.
> 
> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.

If there are other Permission classes you think should have their text modified or removed, let me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803784698

From jpai at openjdk.org  Thu Oct 17 04:51:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Oct 2024 04:51:53 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Lance's man page inputs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/bb63acba..9ebbc06e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=14-15

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

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

From alanb at openjdk.org  Thu Oct 17 05:57:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 05:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
Message-ID: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>

On Wed, 16 Oct 2024 20:14:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.
>
> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804151450

From jlahoda at openjdk.org  Thu Oct 17 09:29:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 17 Oct 2024 09:29:16 GMT
Subject: Integrated: 8341966: Broken annotated module may lead to an exception
 in javac
In-Reply-To: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
References: <Sf-PaO2JXXbhGdaoDl9HCnpoAg_kyL7ye-hitTsy2og=.75c9614f-d49f-4e7a-9831-4b70953a75cc@github.com>
Message-ID: <ONqq3u0RgoizJYfV5vjIES8RzYpi99fYN9MC0irqorg=.942021f0-32b0-4eef-a06f-e308eb02501a@github.com>

On Mon, 14 Oct 2024 05:35:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a `module-info.class`, that both:
>  - is wrong, so it will produce a bad-classfile error, for example due to an illegal `requires transitive java.base;`
>  - and the module is annotated
> 
> If the javac proceeds to resolve the annotations (which is not the default, but can be pushed to do it), it will crash with an `AssertionError` while trying to un-proxy the annotations. This is because there's an assert that `requestingOwner.owner.kind == MDL`, but since the module is erroneous, the kind is `ERR`, and the assert fails.
> 
> The proposal is to loosen the assert a bit, and require `requestingOwner.owner instanceof ModuleSymbol`. That should still be sufficiently strong, while permitting broken modules to be handled.

This pull request has now been integrated.

Changeset: 7ff4ea8d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ff4ea8d01c681b90ad59be04007557d84c8db94
Stats:     94 lines in 2 files changed: 90 ins; 0 del; 4 mod

8341966: Broken annotated module may lead to an exception in javac

Reviewed-by: asotona

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

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

From lancea at openjdk.org  Thu Oct 17 10:56:21 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 10:56:21 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
Message-ID: <COWrLW14fysR_5V1eH1mwTzaLQ5XgnKMzPXtJwowJjw=.2cdaf856-1f7a-4fc1-bc10-89cf6c36c25c@github.com>

On Thu, 17 Oct 2024 04:51:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's man page inputs

Looks good Jai

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/2752#pullrequestreview-2374864115

From vromero at openjdk.org  Thu Oct 17 11:17:12 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Oct 2024 11:17:12 GMT
Subject: RFR: 8341901: Using 'var' keyword switch pattern matching causes
 compiler error
In-Reply-To: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
References: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
Message-ID: <Wnty-sitBXqh7zNulKAlhgq15s4SzoE9ZaMm3q8DQfs=.324f5087-70b8-4df3-8c8c-939872a1723a@github.com>

On Mon, 14 Oct 2024 13:20:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class T {
>    record R(N.I i) {}
>    int test(Object o) {
>        return switch (o) {
>            case R(var nested) -> 0;
>            default -> 0;
>        };
>    }
>    static class N<T> {
>        interface I {}
>    }
> }
> 
> 
> This fails to compile since JDK 23, due to:
> 
> $ javac T.java 
> error: cannot select a static class from a parameterized type
> 1 error
> 
> 
> The reason for the error is this: the type of `nested` is inferred to `T.N.I`. This is correct. javac will then construct a synthetic AST for it, and the AST will be structurally correct as well: `T.N.I`. But a) the `Type` attached to `T.N` will be `T.N<T>` (which by itself is not correct), and b) after the synthetic AST is created, `Check.validate` is called on the type's AST, and fails, as the types is sees correspond to `T.N<T>.I`, which is illegal.
> 
> Note the synthetic AST is also set for local variable type inference, but the `validate` is called *before* the synthetic AST is created.
> 
> This PR proposes to do two things:
> - move the `validate` call before the synthetic AST creation for `visitBindingPattern`, to mimic the behavior for `var`s.
> - the `TreeMaker` is tweaked to inject erased types instead of parameterized types when generating qualified identifiers for classes or interfaces. This should correspond more closely to what happens when one types `T.N.I` in the source code.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 749:

> 747: 
> 748:         if (sym.kind == TYP) {
> 749:             result.setType(types.erasure(sym.type));

can we do this outside of TreeMaker? I mean TreeMaker could be used to generate trees for a phase for which erasure hasn't occurred yet. It should be the caller's option to decide if the obtained tree should be erased or not

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21495#discussion_r1804577637

From weijun at openjdk.org  Thu Oct 17 11:27:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Oct 2024 11:27:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
Message-ID: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>

On Wed, 16 Oct 2024 20:51:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
>> 
>>> 29: 
>>> 30: /**
>>> 31:  * This class is for GSS security context permissions.
>> 
>> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.
>
> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
> 
> If there are other Permission classes you think should have their text modified or removed, let me know.

All JGSS permission classes follow the same style:

In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.
 ```
In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804590136

From abimpoudis at openjdk.org  Thu Oct 17 11:42:17 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 17 Oct 2024 11:42:17 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <VRI5dtGUy8-7LPMyYP7qyLU31oLxxnLvPGG1X8xUjb4=.2009b0ce-094d-4247-a455-fd68e68b9a06@github.com>

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 159:

> 157:     enum ScopeType {
> 158:         ORDINARY,
> 159:         START_IMPORT,

Is this a "start" import or a "star"*  import? ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1804609420

From jlahoda at openjdk.org  Thu Oct 17 11:49:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 17 Oct 2024 11:49:18 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <VRI5dtGUy8-7LPMyYP7qyLU31oLxxnLvPGG1X8xUjb4=.2009b0ce-094d-4247-a455-fd68e68b9a06@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <VRI5dtGUy8-7LPMyYP7qyLU31oLxxnLvPGG1X8xUjb4=.2009b0ce-094d-4247-a455-fd68e68b9a06@github.com>
Message-ID: <vAxuMlrhQk9kUPI4gI0PXo1FL47Pnz4wM8Tnla5xRRM=.03404217-58f4-4df2-87ea-f54cfe760b28@github.com>

On Thu, 17 Oct 2024 11:39:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 159:
> 
>> 157:     enum ScopeType {
>> 158:         ORDINARY,
>> 159:         START_IMPORT,
> 
> Is this a "start" import or a "star"*  import? ?

Star import. Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1804617634

From jlahoda at openjdk.org  Thu Oct 17 12:46:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 17 Oct 2024 12:46:10 GMT
Subject: RFR: 8341901: Using 'var' keyword switch pattern matching causes
 compiler error
In-Reply-To: <Wnty-sitBXqh7zNulKAlhgq15s4SzoE9ZaMm3q8DQfs=.324f5087-70b8-4df3-8c8c-939872a1723a@github.com>
References: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
 <Wnty-sitBXqh7zNulKAlhgq15s4SzoE9ZaMm3q8DQfs=.324f5087-70b8-4df3-8c8c-939872a1723a@github.com>
Message-ID: <zGwQ5Nf3iVj4ywCoy_sT-c9AvL2aGLrIQybs-wmMlgA=.c5be4cdf-d373-4a03-a282-0d72171252a5@github.com>

On Thu, 17 Oct 2024 11:14:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class T {
>>    record R(N.I i) {}
>>    int test(Object o) {
>>        return switch (o) {
>>            case R(var nested) -> 0;
>>            default -> 0;
>>        };
>>    }
>>    static class N<T> {
>>        interface I {}
>>    }
>> }
>> 
>> 
>> This fails to compile since JDK 23, due to:
>> 
>> $ javac T.java 
>> error: cannot select a static class from a parameterized type
>> 1 error
>> 
>> 
>> The reason for the error is this: the type of `nested` is inferred to `T.N.I`. This is correct. javac will then construct a synthetic AST for it, and the AST will be structurally correct as well: `T.N.I`. But a) the `Type` attached to `T.N` will be `T.N<T>` (which by itself is not correct), and b) after the synthetic AST is created, `Check.validate` is called on the type's AST, and fails, as the types is sees correspond to `T.N<T>.I`, which is illegal.
>> 
>> Note the synthetic AST is also set for local variable type inference, but the `validate` is called *before* the synthetic AST is created.
>> 
>> This PR proposes to do two things:
>> - move the `validate` call before the synthetic AST creation for `visitBindingPattern`, to mimic the behavior for `var`s.
>> - the `TreeMaker` is tweaked to inject erased types instead of parameterized types when generating qualified identifiers for classes or interfaces. This should correspond more closely to what happens when one types `T.N.I` in the source code.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 749:
> 
>> 747: 
>> 748:         if (sym.kind == TYP) {
>> 749:             result.setType(types.erasure(sym.type));
> 
> can we do this outside of TreeMaker? I mean TreeMaker could be used to generate trees for a phase for which erasure hasn't occurred yet. It should be the caller's option to decide if the obtained tree should be erased or not

Doing this outside of TreeMaker would be fairly difficult (as that would mean the caller would need to traverse the created tree and clean the types).

This change is not strictly necessary to solve the problem - moving the `chk.validate` is enough. But, it seems to me that type attributes in the AST that are produced by the `TreeMaker.QualIdent` do not make much sense. Specifically, passing the ClassSymbol for `java.util.List` here will produce a tree whose `.type` will be `java.util.List<E>`, where `E` is the type variable from `java.util.List`, which has no meaning outside of `java.util.List`. In general, calling `QualIdent` with a `ClassSymbol`, I don't see how any type other than the erased one would make sense.

That sad - I can easily remove this part of the patch, the AST distortion is fairly small, at least at this time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21495#discussion_r1804717527

From duke at openjdk.org  Thu Oct 17 13:15:19 2024
From: duke at openjdk.org (duke)
Date: Thu, 17 Oct 2024 13:15:19 GMT
Subject: Withdrawn: 8338815: Add separation to exception message in
 JavacFileManager.DirectoryContainer
In-Reply-To: <pJ1L0oIu6pvlMgtcBGXtSuWF7QlAIYJ3jy_DOHHAR7s=.daa5c44e-a877-4ea7-a886-3683e849a41b@github.com>
References: <pJ1L0oIu6pvlMgtcBGXtSuWF7QlAIYJ3jy_DOHHAR7s=.daa5c44e-a877-4ea7-a886-3683e849a41b@github.com>
Message-ID: <l9z-SxcmzkV1bmV-DYmQi2Hes9JxdKdwE6GquXfx_FQ=.f7b0db07-0353-4416-9169-3e72596c49d5@github.com>

On Thu, 22 Aug 2024 08:08:57 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this trivial PR which injects a `": "` separator between the directory name and the exeption toString when constructing the IOException message in `JavacFileManager.DirectoryContainer.list`.
> 
> This changes the javac error message from:
> 
> `error accessing directory Z:\invalid-pathjava.nio.file.InvalidPathException: Illegal char <:> at index 4: file:txt`
> 
> into:
> 
> `error accessing directory Z:\invalid-path: java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:txt`
> 
> We could alternatively use some other separator, such as a `", "`.

This pull request has been closed without being integrated.

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

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

From mullan at openjdk.org  Thu Oct 17 18:03:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Oct 2024 18:03:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
Message-ID: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>

On Thu, 17 Oct 2024 11:24:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
>> 
>> If there are other Permission classes you think should have their text modified or removed, let me know.
>
> All JGSS permission classes follow the same style:
> 
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.
>  ```
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.

I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1805188374

From jpai at openjdk.org  Fri Oct 18 00:51:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Oct 2024 00:51:58 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
Message-ID: <xfIZlbcYvMcXmJHGX16PouQv99R4Ga8x1a2EeKc8YFE=.02e2d84b-48da-4c75-b9d3-426455efbada@github.com>

On Thu, 17 Oct 2024 04:51:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's man page inputs

The CSR has been approved. I'll go ahead and integrate this now. Thank you everyone for the inputs and reviews here on the PR and elsewhere.

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

PR Comment: https://git.openjdk.org/jdk/pull/2752#issuecomment-2420999286

From jpai at openjdk.org  Fri Oct 18 00:54:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Oct 2024 00:54:30 GMT
Subject: Integrated: 8173970: jar tool should have a way to extract to a
 directory
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <rpzTOuR14TYvVlDThd16XRcynjNMIbW57J9jQmPYcXE=.2a3c95c8-b693-4997-b9c7-17cdbd15003a@github.com>

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

This pull request has now been integrated.

Changeset: ffe60919
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffe60919df59196d65832b8ce6b2cd38099d64df
Stats:     617 lines in 5 files changed: 605 ins; 0 del; 12 mod

8173970: jar tool should have a way to extract to a directory

Reviewed-by: lancea, cstein

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

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

From abimpoudis at openjdk.org  Fri Oct 18 08:30:44 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 18 Oct 2024 08:30:44 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <7-Avj4deqgRbrdSLUYjssAoC2XeAAjyN7sd_-K0hiOg=.195e4158-bc74-4bfa-81e4-ef675ffbc42c@github.com>

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

LGTM

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2377389927

From vromero at openjdk.org  Fri Oct 18 14:54:27 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 18 Oct 2024 14:54:27 GMT
Subject: RFR: 8341901: Using 'var' keyword switch pattern matching causes
 compiler error
In-Reply-To: <zGwQ5Nf3iVj4ywCoy_sT-c9AvL2aGLrIQybs-wmMlgA=.c5be4cdf-d373-4a03-a282-0d72171252a5@github.com>
References: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
 <Wnty-sitBXqh7zNulKAlhgq15s4SzoE9ZaMm3q8DQfs=.324f5087-70b8-4df3-8c8c-939872a1723a@github.com>
 <zGwQ5Nf3iVj4ywCoy_sT-c9AvL2aGLrIQybs-wmMlgA=.c5be4cdf-d373-4a03-a282-0d72171252a5@github.com>
Message-ID: <hGRfFZMs-A2XXTT3GUJmzNA7EFziM2FKemxNXhZu1fY=.f6a41d62-29de-47f7-9e38-049348ac17a8@github.com>

On Thu, 17 Oct 2024 12:43:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 749:
>> 
>>> 747: 
>>> 748:         if (sym.kind == TYP) {
>>> 749:             result.setType(types.erasure(sym.type));
>> 
>> can we do this outside of TreeMaker? I mean TreeMaker could be used to generate trees for a phase for which erasure hasn't occurred yet. It should be the caller's option to decide if the obtained tree should be erased or not
>
> Doing this outside of TreeMaker would be fairly difficult (as that would mean the caller would need to traverse the created tree and clean the types).
> 
> This change is not strictly necessary to solve the problem - moving the `chk.validate` is enough. But, it seems to me that type attributes in the AST that are produced by the `TreeMaker.QualIdent` do not make much sense. Specifically, passing the ClassSymbol for `java.util.List` here will produce a tree whose `.type` will be `java.util.List<E>`, where `E` is the type variable from `java.util.List`, which has no meaning outside of `java.util.List`. In general, calling `QualIdent` with a `ClassSymbol`, I don't see how any type other than the erased one would make sense.
> 
> That sad - I can easily remove this part of the patch, the AST distortion is fairly small, at least at this time.

I see what you mean, then I think we should document in the method that the produced AST will be erased, also please check double check if the type of JCFieldAccess::selected needs to be erased too, I think we should be fine but just to make sure

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21495#discussion_r1806636077

From vromero at openjdk.org  Fri Oct 18 15:42:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 18 Oct 2024 15:42:38 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v15]
In-Reply-To: <yPBvDN_ySzNpKbHcRI1_ltcSxYzAIIZPLDbuIohhtQI=.90bd7c70-8b2c-4a3d-b92b-d20d848ae3a6@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <yPBvDN_ySzNpKbHcRI1_ltcSxYzAIIZPLDbuIohhtQI=.90bd7c70-8b2c-4a3d-b92b-d20d848ae3a6@github.com>
Message-ID: <sDVHN0akoLGLARDbKdhuWJdigVV-TLPr5qx6m5wiMJ8=.ac9b6997-633c-4d29-9cbb-ea7c095e276e@github.com>

On Sat, 12 Oct 2024 14:24:29 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - report feature error
>  - add feature

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 471:

> 469:                 return true;
> 470:             } else {
> 471:                 log.error(env.tree.pos(), Errors.PrivateMembersInPermitsClause);

we don't issue a compiler error while checking if a symbol is accessible or not, it should be the caller's responsibility to decide if a compiler error should be issued or not as it is done in other cases

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 475:

> 473:             }
> 474:         }
> 475:         return false;

shouldn't we return true here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1806699145
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1806699538

From mullan at openjdk.org  Fri Oct 18 19:03:30 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:03:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
 - Sanitize the class descriptions of DelegationPermission and ServicePermission
   by removing text that refers to granting permissions, but avoid changes that
   affect the API specification, such as the description and format of input
   parameters.
 - Restored methods in RMIConnection to throw SecurityExceptions again but
   with adjusted text that avoids the word "permission".
 - Add text to class description of MBeanServer stating that implementations
   may throw SecurityException if authorization doesn't allow access to resource.
 - Restore text about needing permissions from the desktop environment in the
   getPixelColor and createScreenCapture methods.
 - Add api note to getClassContext to use StackWalker instead and
   add DROP_METHOD_INFO option to StackWalker.
 - Change checkAccess() methods to be no-ops, rather than throwing
   SecurityException.
 - Merge
 - Merge
 - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=01
  Stats: 63792 lines in 1825 files changed: 932 ins; 59211 del; 3649 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From mullan at openjdk.org  Fri Oct 18 19:46:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
 <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
Message-ID: <WQXBnhvSCgaSLXJytauYL7d7V9avIZVl75sej33nL0o=.82c6cfc9-a4fd-4b44-84f1-0a268a501d04@github.com>

On Thu, 17 Oct 2024 05:54:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.
>
> Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/7ea65a6febd18ad8f8fa99cfbb8687e761558594

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806946629

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
 <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
Message-ID: <uqSjjeE7SYkvbhHNrZhbu1LjbFxWuU7ZJDWMAjWf_g0=.801e961d-5085-48d8-9bff-0029b1459e94@github.com>

On Wed, 16 Oct 2024 20:42:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.
>
> Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

I restored the text in https://github.com/openjdk/jdk/pull/21498/commits/adf5ed789b0437fa57c87f29e6a4e6b6f7f0c92b. I've left the `@throws SecurityException` text the same, but let me know if you want that changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806948352

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
 <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
Message-ID: <YpVEi_vehntFxBVQBqfYUlJsU5xAAEphz2giQrbbHeQ=.3094111c-c59c-45b2-a13e-140c8b3d6ad3@github.com>

On Tue, 15 Oct 2024 17:01:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>> 
>> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
>> 
>> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
>> 
>> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.
>
> I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

I have changed `LogManager.checkAccess`, `Thread.checkAccess`, `ThreadGroup.checkAccess` to always do nothing. See the fixes in https://github.com/openjdk/jdk/pull/21498/commits/2ebb6de50194770658462507cee28b785fb30dbd and https://github.com/openjdk/jdk/pull/21498/commits/16e17b89b3dbce4f49706c032c315977dd54c315.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806950866

From mullan at openjdk.org  Fri Oct 18 19:56:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <W8LF9xitgnrJ0GXvQ2clisM9wQDS32sfJ_1w3xFvbTo=.5391529e-f6b5-40fd-a829-9803c0fdb206@github.com>

On Tue, 15 Oct 2024 14:50:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:
> 
>> 157:      * is specified for the MBean.
>> 158:      * @throws IOException if a general communication exception occurred.
>> 159:      * @throws UnsupportedOperationException if {@code delegationSubject} is non-null.
> 
> Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.
> 
> So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.
> 
> An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

I restored the changes to `RMIConnection` to throw `SecurityException` but adjusted the text to say "is not authorized" instead of "does not have permission". See https://github.com/openjdk/jdk/pull/21498/commits/86ff71461ef1d695c02497626facda63c496a287.

As we discussed offline, I also added a sentence to the `MBeanServer` class description to state that it and its subclasses may throw `SecurityException`s if the implementation doesn't authorize access to the underlying resource: https://github.com/openjdk/jdk/pull/21498/commits/44432e56a91a992150ee873e81282d1fe21e69ea.

> src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:
> 
>> 65:      */
>> 66:     public Subject authenticate(Object credentials);
>> 67: }
> 
> Should this be reverted? Authentication has not been removed.

Yes. See the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806952922
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953524

From mullan at openjdk.org  Fri Oct 18 19:56:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
Message-ID: <hOWAuNpI0Pigr9zYPACJJ68_-Q6uBQZuDWDD322bfg8=.ffe44b98-01a9-4125-90dc-318e48fc87b1@github.com>

On Tue, 15 Oct 2024 22:14:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
>> 
>>> 223:      */
>>> 224:     public static JMXConnector connect(JMXServiceURL serviceURL)
>>> 225:             throws IOException {
>> 
>> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.
>
> Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

Yes, see the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953911

From mullan at openjdk.org  Fri Oct 18 19:56:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
Message-ID: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>

On Thu, 17 Oct 2024 17:59:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> All JGSS permission classes follow the same style:
>> 
>> In `javax.security.auth.kerberos.DelegationPermission`:
>> 
>>  * This class is used to restrict the usage of the Kerberos
>>  * delegation model, ie: forwardable and proxiable tickets.
>>  ```
>> In `javax.security.auth.kerberos.ServicePermission`:
>> 
>>  * This class is used to protect Kerberos services and the
>>  * credentials necessary to access those services. There is a one to
>> 
>> (Updated)
>
> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806957907

From duke at openjdk.org  Fri Oct 18 20:16:43 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 18 Oct 2024 20:16:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <V9F38E82rWG3ydtcBhl-buCMyD8G8VnLPMZtODTvpC0=.d084324c-f851-4bb6-98f5-a392e65baa24@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Marked as reviewed by dmlloyd at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2378900585

From kevinw at openjdk.org  Fri Oct 18 20:54:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 18 Oct 2024 20:54:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <AlbXwhSqJ6KlhPzDu_C7N1p84ZxgYsYImht8GW56D4k=.0283a056-f5ee-4650-b8c9-0df0aaee1797@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for updating the wording on the JMX/management classes, looks good.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java
No longer has any changes other than (C), so that should be reverted also. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423214468

From duke at openjdk.org  Fri Oct 18 21:52:47 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 18 Oct 2024 21:52:47 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v16]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <T1JoQekPlD66_gWg9TZfQb9gkO7aMDAbK1Dn5gNL9ZA=.9740b460-0e94-4bab-9b40-2340cdb08343@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  remove logging error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/7efb56e9..91689784

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=14-15

  Stats: 11 lines in 3 files changed: 0 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20718/head:pull/20718

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

From duke at openjdk.org  Fri Oct 18 21:52:47 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 18 Oct 2024 21:52:47 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v15]
In-Reply-To: <sDVHN0akoLGLARDbKdhuWJdigVV-TLPr5qx6m5wiMJ8=.ac9b6997-633c-4d29-9cbb-ea7c095e276e@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <yPBvDN_ySzNpKbHcRI1_ltcSxYzAIIZPLDbuIohhtQI=.90bd7c70-8b2c-4a3d-b92b-d20d848ae3a6@github.com>
 <sDVHN0akoLGLARDbKdhuWJdigVV-TLPr5qx6m5wiMJ8=.ac9b6997-633c-4d29-9cbb-ea7c095e276e@github.com>
Message-ID: <2KBOqH9kYsEKgcaLY27zPHM5m-qgUCv31Zgb6ND0dNk=.4102eb3e-3d54-456c-b815-6d7c70a20f45@github.com>

On Fri, 18 Oct 2024 15:39:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>>  - report feature error
>>  - add feature
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 471:
> 
>> 469:                 return true;
>> 470:             } else {
>> 471:                 log.error(env.tree.pos(), Errors.PrivateMembersInPermitsClause);
> 
> we don't issue a compiler error while checking if a symbol is accessible or not, it should be the caller's responsibility to decide if a compiler error should be issued or not as it is done in other cases

thanks for the note, will keep in mind from now on

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 475:
> 
>> 473:             }
>> 474:         }
>> 475:         return false;
> 
> shouldn't we return true here?

No, method name is privateMemberInPermitsClause if allowed, and return is:
1. If condition in if is met, then return whether feature is enabled or not (value of field allowPrivateMembersInPermitsClause)
2. If condition is not met, then this is NOT privateMemberInPermitsClause, so return false

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1807042268
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1807044737

From alanb at openjdk.org  Sat Oct 19 11:56:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Oct 2024 11:56:53 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423661302

From duke at openjdk.org  Sat Oct 19 11:57:08 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 19 Oct 2024 11:57:08 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v17]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <783S4wS6h1j_ejoU_dOx9WmjDgYW8hWEltgn6nLH9wo=.c3deb952-207a-4212-8dff-2c859e41076f@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

 - Merge branch 'openjdk:master' into selaed-permits-allow-private-members
 - remove logging error
 - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
 - Revert bugid change
 - Change bugid
 - report feature error
 - add feature
 - make method names shorter
 - fix test failures 3
 - fix test failures 2
 - ... and 10 more: https://git.openjdk.org/jdk/compare/84894c4b...38dd1b5a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/91689784..38dd1b5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=15-16

  Stats: 269822 lines in 2827 files changed: 236078 ins; 18169 del; 15575 mod
  Patch: https://git.openjdk.org/jdk/pull/20718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20718/head:pull/20718

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

From acobbs at openjdk.org  Sun Oct 20 23:10:41 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 20 Oct 2024 23:10:41 GMT
Subject: RFR: 8338288: Compiler Implementation for Flexible Constructor
 Bodies (Third Preview)
In-Reply-To: <1cf2tlH_kW7ZZbm6tliHUuiFjK8GeJ5Oc2_66naUbGI=.4d9e60a8-9a1a-4dff-8518-f71e4a59b53c@github.com>
References: <1cf2tlH_kW7ZZbm6tliHUuiFjK8GeJ5Oc2_66naUbGI=.4d9e60a8-9a1a-4dff-8518-f71e4a59b53c@github.com>
Message-ID: <a9Db7lx74FuuaoYLThCGB9W3NnmPh_SkNNN0d-ELnNo=.1abcba08-631e-490a-bbbf-08cda515cbe6@github.com>

On Tue, 8 Oct 2024 14:42:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the implementation for the third iteration of the [Flexible Constructor Bodies](https://openjdk.org/jeps/492) feature.
> 
> While the feature remains largely unchanged from the previous iteration, this PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via new, or, indirectly, via super. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what should happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to lookup some `E.this` (where `E` is a class enclosing `M`), given none is provided. This same issue is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking `new M()`.
> 
> The lookup process for should look at all the enclosing instances available to us, and pick the innermost enclosing instance of type `E` such that `E` is a subclass of `M`'s enclosing class. It should be the case that  `E.this` is accessible (e.g. not in E?s early construction context) or a compile-time error should occur.
> 
> This new check is defined in `Resolve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes defined in a `static` method, we should *not* check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this (such classes have no enclosing instance). What matters, for local and anon classes defined in `static` methods, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This new check is defined in `Resolve::findLocalClassOwner`. While writing the code and looking at tests, I realized that existing diagnostics were not sufficient to capture this new condition. So I added a new one.

FYI, I verified that this patch also fixes [JDK-8330037](https://bugs.openjdk.org/browse/JDK-8330037), which is a variant of the "you can't capture a free variable across a static method boundary" problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/21410#issuecomment-2425278162

From asotona at openjdk.org  Mon Oct 21 06:34:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 21 Oct 2024 06:34:03 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v7]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
   #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
   #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
   #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
   #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
   #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
   #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
   #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
   #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
   #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
   #	src/java.base/share/classes/java/lang/classfile/Instruction.java
   #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/DynamicConstantPoolEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/FieldRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/InterfaceMethodRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/LoadableConstantEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/MethodRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ModuleEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PackageEntry.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/NewMultiArrayInstruction.java
 - Updated copyright years
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
   #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

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

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=06
  Stats: 800 lines in 165 files changed: 0 ins; 488 del; 312 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

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

From mcimadamore at openjdk.org  Mon Oct 21 11:06:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:06:31 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <6t6044s7pqcy0dM-zUTzDTXjd1IVwMoge7ckm9WpvSs=.0f4027e4-f0c3-43cc-9f62-97d51fa446a6@github.com>

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1141:

> 1139:             return true;
> 1140:         } else if (sym.kind == TYP && toplevel != null) {
> 1141:             for (Scope scope : new Scope[] {toplevel.namedImportScope,

I wonder if we could deal with this with a compound scope? (and avoid the loop)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1808556685

From mcimadamore at openjdk.org  Mon Oct 21 11:10:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:10:13 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <uD112ODmoRFV9yjnbRButsddn0PrLVQpPACxoSsI604=.d0b48602-d286-4832-9c3e-17428f7fa5d4@github.com>

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 454:

> 452:                 // Import on demand.
> 453:                 chk.checkCanonical(imp.selected);
> 454:                 if (tree.staticImport) {

I note a discrepancy here - static imports are reflected in the AST, but module import aren't. This is why we need to pass an extra parameter to this method, I believe. Should we generalize the import tree node to have a bunch of flags?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1808564862

From mcimadamore at openjdk.org  Mon Oct 21 11:15:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:15:14 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <uD112ODmoRFV9yjnbRButsddn0PrLVQpPACxoSsI604=.d0b48602-d286-4832-9c3e-17428f7fa5d4@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <uD112ODmoRFV9yjnbRButsddn0PrLVQpPACxoSsI604=.d0b48602-d286-4832-9c3e-17428f7fa5d4@github.com>
Message-ID: <zcZ2U7dbPKEM_HMfiu3Ssw_Yqamzy6WpAAgsPdpcM30=.7dd453f1-7811-428c-b49d-ace27ebad1f2@github.com>

On Mon, 21 Oct 2024 11:07:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 454:
> 
>> 452:                 // Import on demand.
>> 453:                 chk.checkCanonical(imp.selected);
>> 454:                 if (tree.staticImport) {
> 
> I note a discrepancy here - static imports are reflected in the AST, but module import aren't. This is why we need to pass an extra parameter to this method, I believe. Should we generalize the import tree node to have a bunch of flags?

Nevermind, I see why you need the flag - the code is building synthetic import statements on the fly, based on the packages exported by a module - and then you need to import these synthetic imports, but remember that they originated from an import module...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1808573586

From mcimadamore at openjdk.org  Mon Oct 21 11:19:50 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:19:50 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <bRfaQwnJwA5RA0qRoBKrXPZpXk2b4tx4Ibwb7CV40Yg=.323e59ca-20e0-4b87-97c7-5f3d75bb6fbd@github.com>

On Mon, 14 Oct 2024 12:46:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

The changes in the import machinery look good (TypeEnter/Resolve).

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2381722159

From jlahoda at openjdk.org  Mon Oct 21 11:26:36 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 11:26:36 GMT
Subject: RFR: 8338288: Compiler Implementation for Flexible Constructor
 Bodies (Third Preview)
In-Reply-To: <1cf2tlH_kW7ZZbm6tliHUuiFjK8GeJ5Oc2_66naUbGI=.4d9e60a8-9a1a-4dff-8518-f71e4a59b53c@github.com>
References: <1cf2tlH_kW7ZZbm6tliHUuiFjK8GeJ5Oc2_66naUbGI=.4d9e60a8-9a1a-4dff-8518-f71e4a59b53c@github.com>
Message-ID: <Dc0B8x1z9zp3VFDLsg9ks3oukF5Zv2J4Z0vxhr3kTZ8=.4f9466ca-8c34-458a-ad2d-fb5400e9fd0c@github.com>

On Tue, 8 Oct 2024 14:42:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the implementation for the third iteration of the [Flexible Constructor Bodies](https://openjdk.org/jeps/492) feature.
> 
> While the feature remains largely unchanged from the previous iteration, this PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via new, or, indirectly, via super. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what should happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to lookup some `E.this` (where `E` is a class enclosing `M`), given none is provided. This same issue is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking `new M()`.
> 
> The lookup process for should look at all the enclosing instances available to us, and pick the innermost enclosing instance of type `E` such that `E` is a subclass of `M`'s enclosing class. It should be the case that  `E.this` is accessible (e.g. not in E?s early construction context) or a compile-time error should occur.
> 
> This new check is defined in `Resolve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes defined in a `static` method, we should *not* check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this (such classes have no enclosing instance). What matters, for local and anon classes defined in `static` methods, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This new check is defined in `Resolve::findLocalClassOwner`. While writing the code and looking at tests, I realized that existing diagnostics were not sufficient to capture this new condition. So I added a new one.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21410#pullrequestreview-2381748224

From abimpoudis at openjdk.org  Mon Oct 21 11:29:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 11:29:14 GMT
Subject: RFR: 8342679: Cleanup PreviewFeature.Feature
Message-ID: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>

After doing a build + bootcycle build confirms that these constants can be removed.

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

Commit messages:
 - 8342679: Cleanup PreviewFeature.Feature

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

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

From abimpoudis at openjdk.org  Mon Oct 21 12:07:23 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 12:07:23 GMT
Subject: RFR: 8340145: Problem with generic pattern matching results in
 internal compiler error
Message-ID: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>

In the following code, when calculating recursively the covered binding patterns, the nested case assumed that the direct supertype of `T2` will always be represented by a `ClassSymbol`. This PR intervenes the erasure calculation.


static <T, T2 extends T> T unwrapOrElse(Option<T2> option, T defaultValue) {
  return switch (option) {
     case Option.Some(T2 value) -> value;
     case Option.None<T2> _ -> defaultValue;
  };
}

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

Commit messages:
 - 8340145: Problem with generic pattern matching results in internal compiler error

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

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

From liach at openjdk.org  Mon Oct 21 12:11:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 12:11:19 GMT
Subject: RFR: 8342679: Cleanup PreviewFeature.Feature
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <Zi0T9xSr7vy7CknAu2Vi4rqNMyYvbuFRn_5lyHbeRuM=.59c0800c-13e7-4bc6-9b10-bbff8f14df9a@github.com>

On Mon, 21 Oct 2024 11:23:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> After doing a build + bootcycle build confirms that these constants can be removed.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 67:

> 65:      */
> 66:     public enum Feature {
> 67:         // not used, but required for interim javac to not warn.

Maybe we should update this comment to note their removal depends on the boot JDK version?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21605#discussion_r1808669294

From darcy at openjdk.org  Mon Oct 21 13:08:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 13:08:37 GMT
Subject: Integrated: JDK-8282411: Add useful predicates to ElementKind
Message-ID: <yWddqvypCSGP3OHB0r9LAvvEs_HAZYgCMn6V60aav80=.c92aa560-471e-4944-968d-116357d8fe72@github.com>

Discussion from a recent review in javadoc, adding some more functionality to ElementKind predicates.

Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282461

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

Commit messages:
 - Improve whitespace.
 - Merge branch 'master' into JDK-8282411
 - Add tests.
 - JDK-8282411: Add useful predicates to ElementKind

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

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

From prappo at openjdk.org  Mon Oct 21 13:08:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 21 Oct 2024 13:08:37 GMT
Subject: Integrated: JDK-8282411: Add useful predicates to ElementKind
In-Reply-To: <yWddqvypCSGP3OHB0r9LAvvEs_HAZYgCMn6V60aav80=.c92aa560-471e-4944-968d-116357d8fe72@github.com>
References: <yWddqvypCSGP3OHB0r9LAvvEs_HAZYgCMn6V60aav80=.c92aa560-471e-4944-968d-116357d8fe72@github.com>
Message-ID: <2Abpa_o-LgZzltH-6yM3aS3f83CqWxa401w_EIb6mdE=.6fd1bd87-651c-4d81-971f-6103b9c81eb6@github.com>

On Mon, 28 Feb 2022 21:33:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Discussion from a recent review in javadoc, adding some more functionality to ElementKind predicates.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282461

Other than unusual indentation in isExecutable and isInitializer, looks good. Thanks!

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/7637#pullrequestreview-896667156

From darcy at openjdk.org  Mon Oct 21 13:08:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 13:08:37 GMT
Subject: Integrated: JDK-8282411: Add useful predicates to ElementKind
In-Reply-To: <yWddqvypCSGP3OHB0r9LAvvEs_HAZYgCMn6V60aav80=.c92aa560-471e-4944-968d-116357d8fe72@github.com>
References: <yWddqvypCSGP3OHB0r9LAvvEs_HAZYgCMn6V60aav80=.c92aa560-471e-4944-968d-116357d8fe72@github.com>
Message-ID: <ZIQbLIm7cgdtvXr_5COD7FDOHlDU-F_cZxBQq2t46FY=.73938f31-ae03-4a96-a65a-a87fcfda97f0@github.com>

On Mon, 28 Feb 2022 21:33:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Discussion from a recent review in javadoc, adding some more functionality to ElementKind predicates.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282461

This pull request has now been integrated.

Changeset: 732d891f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/732d891f9f8987edfc188c049eb19de6ba790c42
Stats:     102 lines in 2 files changed: 97 ins; 0 del; 5 mod

8282411: Add useful predicates to ElementKind

Reviewed-by: prappo

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

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

From dfuchs at openjdk.org  Mon Oct 21 13:32:28 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 13:32:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <RR8acwmQK7Tsg7HTc70yDPcGNetx4ATXhqTt3W0A_kA=.73aff4cf-e9f3-4846-87d8-1866a60c4c74@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for the changes in JMX and java.logging. Looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382119997

From weijun at openjdk.org  Mon Oct 21 13:40:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 13:40:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
 <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
Message-ID: <-Bc_cBbnZLLWUhNTjFI_T-LLSRXSnDUS-EnV0DTQwVc=.460efd25-1595-4ff6-a262-3c1c90c7ebd0@github.com>

On Fri, 18 Oct 2024 19:52:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.
>
> See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

I see. I was wondering why some files are modified and some are not. The new text looks fine to me. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1808841888

From abimpoudis at openjdk.org  Mon Oct 21 14:22:39 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 14:22:39 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v2]
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <fiIkJ4OMRZYDJj01pLrONG5khI0rg-0hUfIi3XX9jsM=.697c65cb-5879-437b-b9cb-902ecc6084b7@github.com>

> After doing a build + bootcycle build confirms that these constants can be removed.

Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - Update comment
 - 8342679: Clean up PreviewFeature.Feature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21605/files
  - new: https://git.openjdk.org/jdk/pull/21605/files/8c948d22..0ff12dac

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

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

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

From liach at openjdk.org  Mon Oct 21 14:28:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 14:28:11 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v2]
In-Reply-To: <fiIkJ4OMRZYDJj01pLrONG5khI0rg-0hUfIi3XX9jsM=.697c65cb-5879-437b-b9cb-902ecc6084b7@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
 <fiIkJ4OMRZYDJj01pLrONG5khI0rg-0hUfIi3XX9jsM=.697c65cb-5879-437b-b9cb-902ecc6084b7@github.com>
Message-ID: <9mU4A27EpOH-_Bw16No2S1TfjTBxxnTpwtYQ3xWalWg=.8216b367-e142-452e-847b-d6f39b64fd2c@github.com>

On Mon, 21 Oct 2024 14:22:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After doing a build + bootcycle build confirms that these constants can be removed.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Update comment
>  - 8342679: Clean up PreviewFeature.Feature

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 70:

> 68:         // keeping the constant of a feature that has been integrated or dropped, serves the purpose of muting such warnings.
> 69: 
> 70:         ////

Suggestion:

        //---

Don't accidentally write markdown javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21605#discussion_r1808928576

From abimpoudis at openjdk.org  Mon Oct 21 14:49:34 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 14:49:34 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v3]
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>

> After doing a build + bootcycle build confirms that these constants can be removed.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21605/files
  - new: https://git.openjdk.org/jdk/pull/21605/files/0ff12dac..8b778aff

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

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

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

From weijun at openjdk.org  Mon Oct 21 14:57:39 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 14:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ytYO_77QWIG71O6PlwBm-HJ_k6VqU2-p3Gg56o98SPI=.7e182f8b-45cb-4bd4-83ce-1e5090e3020d@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

The security-related test updates seem good to me. I noticed a few minor issues and pushed three commits (https://github.com/openjdk/jdk-sandbox/commit/807eb6e363cd78f7051ab2512fbb9fe7f72a036c, https://github.com/openjdk/jdk-sandbox/commit/b4f68e36260cba4cb9e3f72e86674666ee04f15b, and https://github.com/openjdk/jdk-sandbox/commit/02b4bf177555eaf2fa732e918448af9ff1efa8bf).

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2426923546

From liach at openjdk.org  Mon Oct 21 14:57:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 14:57:24 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v3]
In-Reply-To: <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
 <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
Message-ID: <CWwLkCyGuMhGg0p07nfGUk5mxzbpQDgEWi--u7RTeTA=.9f922c23-e557-479c-95d4-9ee247687133@github.com>

On Mon, 21 Oct 2024 14:49:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After doing a build + bootcycle build confirms that these constants can be removed.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Thanks Aggelos, this change looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21605#pullrequestreview-2382376964

From abimpoudis at openjdk.org  Mon Oct 21 15:34:48 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 15:34:48 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview)
Message-ID: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>

This PR prepares the improvement for JEP 488.

The proposed approach is described in the CSR.

In terms of compiler implementation, we add the related translation in `TransPatterns`. Interestingly, this issue would be ideally addressed in `TransTypes`. However, there are some conveniences in `TransPatterns` that would need to be pulled into `TransTypes` to make this work: 1) the dependency to `makeBinary` and transitively to `operators` and 2) a lot of ceremony around `currentMethodSym` is already setup nicely in `TransPatterns`.

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

Commit messages:
 - 8341408: Implement JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)

Changes: https://git.openjdk.org/jdk/pull/21539/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21539&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341408
  Stats: 139 lines in 4 files changed: 133 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21539/head:pull/21539

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

From dfuchs at openjdk.org  Mon Oct 21 15:41:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 15:41:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <LgcZ50hJkMyYZe-v5naaW8WmGArxPnhYHfk6SaGqNO0=.a3d70032-1ca1-4e70-af37-40dfb2f52ddf@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

For the record I have also reviewed the `java.naming` and `jdk.httpserver` source changes. They look good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427040743

From duke at openjdk.org  Mon Oct 21 16:00:38 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Oct 2024 16:00:38 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v7]
In-Reply-To: <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@github.com>
Message-ID: <doMm2Xlr7u8znabCBkNwAE7ildmYuQyCriNDZLwGZtc=.00a16391-f2a5-43c7-a56d-3158799f13ba@github.com>

On Mon, 21 Oct 2024 06:34:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/DynamicConstantPoolEntry.java
>    #	src/java.base/share/cl...

src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1:

> 1: /*

It?should?probably be?possible for?`ClassFile?::verify(?)` to?be?able to?verify the?bytecode of?`java.lang.Object`, `java.lang.Class`, `java.lang.String`, and?`java.lang.Throwable`, as?the?main?reason the?HotSpot?verifier skips?those is?that?there?s circular?verification bootstrap?dependencies between?those, but?the?Class?File API?verifier uses?the?offline `ClassHierarchyResolver`?instead for?determining assignability?checks.

https://github.com/openjdk/jdk/blob/18bcbf7941f7567449983b3f317401efb3e34d39/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java#L144-L150

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1809083465

From kevinw at openjdk.org  Mon Oct 21 16:12:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 21 Oct 2024 16:12:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <omJgksIX-GqCbQ_Q7xELjlDjaYtk8TlnCfXapHH1EzM=.8baa30f6-5bd9-424b-9cb7-e1e683f04e16@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewing for management, src and test changes look good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382585178

From mullan at openjdk.org  Mon Oct 21 17:24:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Oct 2024 17:24:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
Message-ID: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>

On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427301539

From vromero at openjdk.org  Mon Oct 21 18:00:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Oct 2024 18:00:17 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
Message-ID: <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>

On Fri, 4 Oct 2024 00:02:52 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
>> 
>> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Migrate another use of sun.misc.Unsafewq

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19397#pullrequestreview-2382925864

From vromero at openjdk.org  Mon Oct 21 19:25:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Oct 2024 19:25:26 GMT
Subject: RFR: 8339296: Record deconstruction pattern in switch fails to
 compile [v2]
In-Reply-To: <SnsitbkX-dwLThUb9zmieqnZn50ROHBfB7mTX27xTnM=.1449d6d5-6ee1-472a-b1d0-24d553c1e89a@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
 <SnsitbkX-dwLThUb9zmieqnZn50ROHBfB7mTX27xTnM=.1449d6d5-6ee1-472a-b1d0-24d553c1e89a@github.com>
Message-ID: <kWR1rl4HwoEYCQsx1iVGjnN4X3YaSV_YDDEPqwo_f2Y=.322a0147-dace-46de-8ad3-4df0c9403ddc@github.com>

On Wed, 2 Oct 2024 08:53:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like this:
>> 
>>     int nestedSwitchesInArgumentPosition(Object o1) {
>>         return id(switch (o1) {
>>             case R(var o2) -> switch (o2) {
>>                 case R(String s) -> s;
>>                 default -> "n";
>>             };
>>             default -> "";
>>         });
>>     }
>> 
>>     int id(String s) {
>>         return s.length();
>>     }
>> 
>>     int id(int i) {
>>         return i;
>>     }
>> 
>> 
>> Compiling this fails with a `StackOverflowError`, because:
>>  - there are speculative attribution happening for the switch expressions,
>>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
>> 
>> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
>> 
>> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
>> 
>> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
>> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
>> 
>> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
>> 
>> The intent is that the public API behavior for the `unknownType` should remain the same.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup - removing the unknownType.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20990#pullrequestreview-2383127754

From vromero at openjdk.org  Mon Oct 21 19:44:15 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Oct 2024 19:44:15 GMT
Subject: RFR: 8338288: Compiler Implementation for Flexible Constructor
 Bodies (Third Preview)
In-Reply-To: <1cf2tlH_kW7ZZbm6tliHUuiFjK8GeJ5Oc2_66naUbGI=.4d9e60a8-9a1a-4dff-8518-f71e4a59b53c@github.com>
References: <1cf2tlH_kW7ZZbm6tliHUuiFjK8GeJ5Oc2_66naUbGI=.4d9e60a8-9a1a-4dff-8518-f71e4a59b53c@github.com>
Message-ID: <dN1abYOTPxHVP_CY1nvx9W0l7xXmmApbRApZfh_irME=.a89f470a-db00-4c28-b8f7-dfcdf6488189@github.com>

On Tue, 8 Oct 2024 14:42:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the implementation for the third iteration of the [Flexible Constructor Bodies](https://openjdk.org/jeps/492) feature.
> 
> While the feature remains largely unchanged from the previous iteration, this PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via new, or, indirectly, via super. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what should happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to lookup some `E.this` (where `E` is a class enclosing `M`), given none is provided. This same issue is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking `new M()`.
> 
> The lookup process for should look at all the enclosing instances available to us, and pick the innermost enclosing instance of type `E` such that `E` is a subclass of `M`'s enclosing class. It should be the case that  `E.this` is accessible (e.g. not in E?s early construction context) or a compile-time error should occur.
> 
> This new check is defined in `Resolve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes defined in a `static` method, we should *not* check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this (such classes have no enclosing instance). What matters, for local and anon classes defined in `static` methods, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This new check is defined in `Resolve::findLocalClassOwner`. While writing the code and looking at tests, I realized that existing diagnostics were not sufficient to capture this new condition. So I added a new one.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21410#pullrequestreview-2383159930

From vromero at openjdk.org  Mon Oct 21 20:38:29 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Oct 2024 20:38:29 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v3]
In-Reply-To: <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
 <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
Message-ID: <OzKoqfXxuV9C4keBLVbuKd2EPNv0LLRlYX4eZwGmP44=.465f49f1-9538-49e8-ac21-106f68e69f2a@github.com>

On Mon, 21 Oct 2024 14:49:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After doing a build + bootcycle build confirms that these constants can be removed.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21605#pullrequestreview-2383257496

From vromero at openjdk.org  Mon Oct 21 21:16:13 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Oct 2024 21:16:13 GMT
Subject: RFR: 8340145: Problem with generic pattern matching results in
 internal compiler error
In-Reply-To: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>
References: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>
Message-ID: <Vixxx9wLxcb4eILMDugrBqF7jSKpI1kkkAelQNNXecE=.bbafec8b-b5ac-4d5b-832e-981362304550@github.com>

On Mon, 21 Oct 2024 12:01:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In the following code, when calculating recursively the covered binding patterns, the nested case assumed that the direct supertype of `T2` will always be represented by a `ClassSymbol`. This PR intervenes the erasure calculation.
> 
> 
> static <T, T2 extends T> T unwrapOrElse(Option<T2> option, T defaultValue) {
>   return switch (option) {
>      case Option.Some(T2 value) -> value;
>      case Option.None<T2> _ -> defaultValue;
>   };
> }

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 913:

> 911: 
> 912:                     for (Type sup : types.directSupertypes(bpOne.type)) {
> 913:                         ClassSymbol clazz = (ClassSymbol) types.erasure(sup).tsym;

general comment: I think that erasure should happen in the desugaring phase, we are already doing some erasure in Flow and all of it is related to patterns. I think that we should consider moving all these erasure to either TransTypes or TransPatterns

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21606#discussion_r1809544754

From prr at openjdk.org  Mon Oct 21 21:24:30 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Oct 2024 21:24:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 55:

> 53:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false w.policy
> 54:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false rw.policy
> 55:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest true rwd.policy

Looks to me like we should delete these 3 policy files.
Also this test isn't about Permissions anymore. So should be renamed to CacheUsedTest 
Then we can get rid of the misspelt directory. in a follow up.Probably do this

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:

> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
> 75: 
> 76:         if (args.length > 1) {

The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?

Also the messing around with exceptions at the end of the test is pointless

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809540920
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809544420

From psadhukhan at openjdk.org  Tue Oct 22 08:11:35 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:11:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:

> 24: import javax.swing.SwingUtilities;
> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
> 26: /*

I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810185617

From psadhukhan at openjdk.org  Tue Oct 22 08:19:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:19:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:

> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
> 48:     }
> 49: 

Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810199838

From psadhukhan at openjdk.org  Tue Oct 22 09:01:38 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:01:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1EhcQfR-j3LoYCg_GkqbbJGXZEEF7PQgXtEfq_MZFZw=.6db08c42-646e-4cc1-b704-07820ae128bb@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:

> 29: /**
> 30:  * @test
> 31:  * @key headful

javadoc style /** at the beginning

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810285947

From psadhukhan at openjdk.org  Tue Oct 22 09:07:51 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:07:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <YNmEi00IsUjIq2jyebS_mjfWgyUlkz9lx4Hlw2PE5yc=.e917162c-9b2c-4c14-ace0-f4fe31e4cf5a@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:

> 46:         test.setupUI();
> 47:         test.testApplication();
> 48:         test.testApplet();

I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810297085

From psadhukhan at openjdk.org  Tue Oct 22 09:12:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:12:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <rb-fYphAyA6BGkUU1fouWA9XPKElgZTf13MGIgbv2gc=.1d78026e-00e6-4f0e-b194-a4df08e8688e@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:

> 64:         }
> 65: 
> 66:         // Show popup as if from an applet

remove applet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810309276

From psadhukhan at openjdk.org  Tue Oct 22 09:19:31 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:19:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1rvnBCeqVl1aLtZcR0YYv7abOQlZ7WNQrOQgH359CVw=.ad43bb44-7be8-429b-aea7-ea4cd8ad507c@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:

> 115:             }
> 116:             popup.setVisible(false);
> 117:             frame.dispose();

The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:

> 27:  * @test
> 28:  * @bug 6622002
> 29:  * @author Alexander Potochkin

remove @author tag

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810327184
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810331078

From psadhukhan at openjdk.org  Tue Oct 22 09:32:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:32:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:

> 43:         JTable table = new JTable();
> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
> 45:         if (de == null) {

I guess we can test this without SM since it tests SwingLazyValue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810353747

From abimpoudis at openjdk.org  Tue Oct 22 09:42:25 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 22 Oct 2024 09:42:25 GMT
Subject: Integrated: 8342679: Clean up PreviewFeature.Feature
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <QxcIEUBFKsKwzI8Z5Png5WWdCbTyGoWlpZ58BySJK1c=.ab0a8174-4537-4443-bea2-f3e705f75465@github.com>

On Mon, 21 Oct 2024 11:23:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> After doing a build + bootcycle build confirms that these constants can be removed.

This pull request has now been integrated.

Changeset: c9f38409
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9f38409ccb84f315fa61490baacea9f070b646d
Stats:     5 lines in 1 file changed: 0 ins; 1 del; 4 mod

8342679: Clean up PreviewFeature.Feature

Reviewed-by: liach, vromero

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

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

From redestad at openjdk.org  Tue Oct 22 09:48:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 09:48:58 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable
Message-ID: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>

- Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
- Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
- Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):


Name                  Cnt         Base         Error          Test         Error   Unit  Change
testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
  :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
  :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
  :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
  :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
  * = significant

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

Commit messages:
 - copyright
 - Add internStringTable micro
 - More micro tuning
 - Tune micro
 - Fully desugar
 - Add micro
 - Allocating capturing lambda in StringNameTable

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

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

From mcimadamore at openjdk.org  Tue Oct 22 09:57:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Oct 2024 09:57:18 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable
In-Reply-To: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
Message-ID: <mzvaprb3dX00E0Q-nNna160X9y16d7065rrlvl3BjEo=.370f93c8-2533-4099-9db1-2080296d7d5d@github.com>

On Tue, 22 Oct 2024 09:43:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
> 
> 
> Name                  Cnt         Base         Error          Test         Error   Unit  Change
> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>   * = significant

Looks good - thanks!
It is a bit sad that each name has to carry a pointer back to the name table - especially now that with string-based names the table has become a lot less important. Outside the scope of this PR of course, but it feels like this area is in need for some kind of revisit.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 65:

> 63:     @Override
> 64:     public Name fromString(String string) {
> 65:         Name name = this.nameMap.get(string);

stylistic - do we need the `this.` qualifiers?

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21631#pullrequestreview-2384642162
PR Review Comment: https://git.openjdk.org/jdk/pull/21631#discussion_r1810397494

From redestad at openjdk.org  Tue Oct 22 10:02:30 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 10:02:30 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable
In-Reply-To: <mzvaprb3dX00E0Q-nNna160X9y16d7065rrlvl3BjEo=.370f93c8-2533-4099-9db1-2080296d7d5d@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <mzvaprb3dX00E0Q-nNna160X9y16d7065rrlvl3BjEo=.370f93c8-2533-4099-9db1-2080296d7d5d@github.com>
Message-ID: <X75jqeAcOVsLvXZCxbFvmby-f5etv9y77L6F9HL0y5I=.23b7ed39-2ea6-479b-88d0-b351ecc2aeda@github.com>

On Tue, 22 Oct 2024 09:53:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
>> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
>> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
>> 
>> 
>> Name                  Cnt         Base         Error          Test         Error   Unit  Change
>> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
>> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
>> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
>> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>>   * = significant
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 65:
> 
>> 63:     @Override
>> 64:     public Name fromString(String string) {
>> 65:         Name name = this.nameMap.get(string);
> 
> stylistic - do we need the `this.` qualifiers?

No, I just went along with pre-existing style here. If there's a preference to avoid redundant `this.` I can remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21631#discussion_r1810406409

From redestad at openjdk.org  Tue Oct 22 10:14:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 10:14:05 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v2]
In-Reply-To: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
Message-ID: <rfaPmWlKMAMi2S1te9waU_h41Wpe_sCHGC9UAX-DiOI=.fab43d3a-157b-4761-9d03-411d7c0ee853@github.com>

> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
> 
> 
> Name                  Cnt         Base         Error          Test         Error   Unit  Change
> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>   * = significant

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  de-this

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21631/files
  - new: https://git.openjdk.org/jdk/pull/21631/files/22c50339..3f1fe191

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

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

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

From redestad at openjdk.org  Tue Oct 22 11:11:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 11:11:11 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v2]
In-Reply-To: <mzvaprb3dX00E0Q-nNna160X9y16d7065rrlvl3BjEo=.370f93c8-2533-4099-9db1-2080296d7d5d@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <mzvaprb3dX00E0Q-nNna160X9y16d7065rrlvl3BjEo=.370f93c8-2533-4099-9db1-2080296d7d5d@github.com>
Message-ID: <fSvJRPAF25DLx1sVveousnvm0ee9e7l_rS3gKxKKjWU=.bf04606e-e79e-4327-b7e0-3a3b881dfc4c@github.com>

On Tue, 22 Oct 2024 09:54:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks good - thanks!

Thanks!

> It is a bit sad that each name has to carry a pointer back to the name table - especially now that with string-based names the table has become a lot less important. Outside the scope of this PR of course, but it feels like this area is in need for some kind of revisit.

Agree, but since we multiple kinds of tables it might be tricky to unravel this. 

(Needs re-approval after fixing nits)

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

PR Comment: https://git.openjdk.org/jdk/pull/21631#issuecomment-2428986773

From liach at openjdk.org  Tue Oct 22 11:27:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 11:27:39 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v2]
In-Reply-To: <rfaPmWlKMAMi2S1te9waU_h41Wpe_sCHGC9UAX-DiOI=.fab43d3a-157b-4761-9d03-411d7c0ee853@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <rfaPmWlKMAMi2S1te9waU_h41Wpe_sCHGC9UAX-DiOI=.fab43d3a-157b-4761-9d03-411d7c0ee853@github.com>
Message-ID: <MNIRTo68HWKOuhJMxbPE63j-bjbGrGRdonSBCS1eSKE=.4f616fe1-6c61-43a9-aff5-30d737b9fbfe@github.com>

On Tue, 22 Oct 2024 10:14:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
>> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
>> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
>> 
>> 
>> Name                  Cnt         Base         Error          Test         Error   Unit  Change
>> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
>> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
>> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
>> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   de-this

src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 68:

> 66:         if (name == null) {
> 67:             name = new NameImpl(this, intern ? string.intern() : string);
> 68:             nameMap.put(string, name);

Since we are interning, can we use the possibly-interned result as map key when we put the name? This will be another bug fixed by desugaring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21631#discussion_r1810540329

From redestad at openjdk.org  Tue Oct 22 11:30:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 11:30:41 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v3]
In-Reply-To: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
Message-ID: <vnr2vqwvPTMOg0vpCcZw5ZWXeQQMU5IyHOTAHz59nS0=.d1e57243-ec19-4a02-8954-b079b1c27828@github.com>

> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
> 
> 
> Name                  Cnt         Base         Error          Test         Error   Unit  Change
> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>   * = significant

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Use interned string as key

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21631/files
  - new: https://git.openjdk.org/jdk/pull/21631/files/3f1fe191..94b8f6d1

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

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

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

From redestad at openjdk.org  Tue Oct 22 11:30:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 11:30:41 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v2]
In-Reply-To: <MNIRTo68HWKOuhJMxbPE63j-bjbGrGRdonSBCS1eSKE=.4f616fe1-6c61-43a9-aff5-30d737b9fbfe@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <rfaPmWlKMAMi2S1te9waU_h41Wpe_sCHGC9UAX-DiOI=.fab43d3a-157b-4761-9d03-411d7c0ee853@github.com>
 <MNIRTo68HWKOuhJMxbPE63j-bjbGrGRdonSBCS1eSKE=.4f616fe1-6c61-43a9-aff5-30d737b9fbfe@github.com>
Message-ID: <GOjfzaSB44_obGR4Kyk16K2fBwl-LMaK6txaOWHrQ8I=.9aa04044-4b86-4966-beb5-55467ef91cf8@github.com>

On Tue, 22 Oct 2024 11:24:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   de-this
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 68:
> 
>> 66:         if (name == null) {
>> 67:             name = new NameImpl(this, intern ? string.intern() : string);
>> 68:             nameMap.put(string, name);
> 
> Since we are interning, can we use the possibly-interned result as map key when we put the name? This will be another bug fixed by desugaring.

Nice catch! I don't think we use the interning today since performance was subpar, and this might be a contributing factor. Re-running the micros.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21631#discussion_r1810544892

From liach at openjdk.org  Tue Oct 22 11:41:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 11:41:18 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v3]
In-Reply-To: <vnr2vqwvPTMOg0vpCcZw5ZWXeQQMU5IyHOTAHz59nS0=.d1e57243-ec19-4a02-8954-b079b1c27828@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <vnr2vqwvPTMOg0vpCcZw5ZWXeQQMU5IyHOTAHz59nS0=.d1e57243-ec19-4a02-8954-b079b1c27828@github.com>
Message-ID: <O7lmu-DJoFSceHeGGU0aP_xKm1hh_KzoQ7WWFvQNSUc=.5c1fc52e-ac94-4f68-88de-40de728270c7@github.com>

On Tue, 22 Oct 2024 11:30:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
>> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
>> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
>> 
>> 
>> Name                  Cnt         Base         Error          Test         Error   Unit  Change
>> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
>> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
>> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
>> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use interned string as key

The latest version with key interning looks good to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21631#pullrequestreview-2384928860

From michaelm at openjdk.org  Tue Oct 22 11:53:39 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 22 Oct 2024 11:53:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

test/jdk/java/net/URLPermission/OpenURL.java line 30:

> 28:  * @run main/othervm OpenURL
> 29:  */
> 30: 

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2384948510
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810575350

From mcimadamore at openjdk.org  Tue Oct 22 11:56:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 22 Oct 2024 11:56:12 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v3]
In-Reply-To: <vnr2vqwvPTMOg0vpCcZw5ZWXeQQMU5IyHOTAHz59nS0=.d1e57243-ec19-4a02-8954-b079b1c27828@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <vnr2vqwvPTMOg0vpCcZw5ZWXeQQMU5IyHOTAHz59nS0=.d1e57243-ec19-4a02-8954-b079b1c27828@github.com>
Message-ID: <FhBgrT-DnBpN3-QGFxxwsXGZVPoBpS0dC6nEKLDKpT0=.6e3135b8-9c11-4e41-86eb-f5c1927f881c@github.com>

On Tue, 22 Oct 2024 11:30:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
>> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
>> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
>> 
>> 
>> Name                  Cnt         Base         Error          Test         Error   Unit  Change
>> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
>> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
>> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
>> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use interned string as key

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21631#pullrequestreview-2384963967

From redestad at openjdk.org  Tue Oct 22 11:56:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 11:56:13 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v2]
In-Reply-To: <GOjfzaSB44_obGR4Kyk16K2fBwl-LMaK6txaOWHrQ8I=.9aa04044-4b86-4966-beb5-55467ef91cf8@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <rfaPmWlKMAMi2S1te9waU_h41Wpe_sCHGC9UAX-DiOI=.fab43d3a-157b-4761-9d03-411d7c0ee853@github.com>
 <MNIRTo68HWKOuhJMxbPE63j-bjbGrGRdonSBCS1eSKE=.4f616fe1-6c61-43a9-aff5-30d737b9fbfe@github.com>
 <GOjfzaSB44_obGR4Kyk16K2fBwl-LMaK6txaOWHrQ8I=.9aa04044-4b86-4966-beb5-55467ef91cf8@github.com>
Message-ID: <JZ-Y3c0qL1YddmuEL2W3h7sTpHXwZFGKiUi2IRyc2Do=.56d81ea0-54f1-4f8d-a6bd-6f63a430d12f@github.com>

On Tue, 22 Oct 2024 11:27:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/StringNameTable.java line 68:
>> 
>>> 66:         if (name == null) {
>>> 67:             name = new NameImpl(this, intern ? string.intern() : string);
>>> 68:             nameMap.put(string, name);
>> 
>> Since we are interning, can we use the possibly-interned result as map key when we put the name? This will be another bug fixed by desugaring.
>
> Nice catch! I don't think we use the interning today since performance was subpar, and this might be a contributing factor. Re-running the micros.

No significant difference on the micros. Theoretically reduces the retained set during a compilation, though, so can't hurt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21631#discussion_r1810576010

From dfuchs at openjdk.org  Tue Oct 22 13:37:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 13:37:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
Message-ID: <AOTi73-spmeUDB5J44UY2JsXYmZN9rNHl8oXlXTlgDQ=.f159726c-1867-4c4e-9a44-86bd185f763c@github.com>

On Tue, 22 Oct 2024 11:50:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/URLPermission/OpenURL.java line 30:
> 
>> 28:  * @run main/othervm OpenURL
>> 29:  */
>> 30: 
> 
> Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

It could - but technically openConnection / getInputStream could still throw if there was an issue with the provided URL. The difference here is that with a SecurityManager the connection would be rejected with a SecurityException before the connection was made. Without a security manager, the connection will go through, so you need the server simulation (can't rely on getting IOException assuming nobody would be listening).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810741690

From hannesw at openjdk.org  Tue Oct 22 13:41:27 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 13:41:27 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
Message-ID: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>

Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.

We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.

I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

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

Commit messages:
 - 8342827: Fix order of @param tags in other modules

Changes: https://git.openjdk.org/jdk/pull/21637/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342827
  Stats: 144 lines in 28 files changed: 58 ins; 58 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21637/head:pull/21637

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

From dfuchs at openjdk.org  Tue Oct 22 14:15:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 14:15:40 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Changes to java.management, java.naming, and sctp look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2385344473

From redestad at openjdk.org  Tue Oct 22 14:32:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 14:32:16 GMT
Subject: RFR: 8342806: Desugar capturing lambda in StringNameTable [v3]
In-Reply-To: <vnr2vqwvPTMOg0vpCcZw5ZWXeQQMU5IyHOTAHz59nS0=.d1e57243-ec19-4a02-8954-b079b1c27828@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
 <vnr2vqwvPTMOg0vpCcZw5ZWXeQQMU5IyHOTAHz59nS0=.d1e57243-ec19-4a02-8954-b079b1c27828@github.com>
Message-ID: <8XH3kkzqNCBZa6_122n6HXVI8Qahn9XHttZToR8HkwQ=.f24dc22d-6907-4847-ba7d-4445f6c8b1bc@github.com>

On Tue, 22 Oct 2024 11:30:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
>> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
>> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
>> 
>> 
>> Name                  Cnt         Base         Error          Test         Error   Unit  Change
>> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
>> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
>> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
>> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use interned string as key

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21631#issuecomment-2429449411

From redestad at openjdk.org  Tue Oct 22 14:32:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 14:32:17 GMT
Subject: Integrated: 8342806: Desugar capturing lambda in StringNameTable
In-Reply-To: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
References: <6kCHDlf6pFOnteRzKfpZE46vbgJwSz1j24pMGwZ7vok=.91d7c522-3ca9-4b7a-a5ea-b95575569cc7@github.com>
Message-ID: <R11tql51CCXovjoR5WqXa7B7u7B_q4KXVC3PBo38zbk=.72929b25-88a7-4c71-a34f-82227b60fb89@github.com>

On Tue, 22 Oct 2024 09:43:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Desugar `computeIfAbsent` to `get` & `put` to avoid a capturing lambda. Since the map is a non-synchronized `HashMap` this is just as non-thread-safe as before.
> - Salvage the microbenchmark added as a JBS comment to https://bugs.openjdk.org/browse/JDK-8268622 
> - Microbenchmark show a modest reduction in allocations for tests stressing `StringNameTable` (Macbook M1):
> 
> 
> Name                  Cnt         Base         Error          Test         Error   Unit  Change
> testInternStringTable  10       55,731 ?       3,701        51,083 ?       2,062  ms/op   1,09x (p = 0,000*)
>   :gc.alloc.rate.norm     54705366,956 ?  375197,844  53936224,624 ? 1421298,600   B/op   0,99x (p = 0,031 )
> testSharedTable        10       47,997 ?       5,802        48,022 ?       4,968  ms/op   1,00x (p = 0,988 )
>   :gc.alloc.rate.norm     56562680,368 ? 1535117,433  53403645,438 ?  218526,779   B/op   0,94x (p = 0,000*)
> testStringTable        10       45,933 ?       2,542        44,094 ?       1,360  ms/op   1,04x (p = 0,009*)
>   :gc.alloc.rate.norm     56244541,359 ? 1019940,919  53226602,956 ?  510018,314   B/op   0,95x (p = 0,000*)
> testUnsharedTable      10       60,474 ?       1,912        59,068 ?       1,038  ms/op   1,02x (p = 0,008*)
>   :gc.alloc.rate.norm     66970079,820 ? 1402704,512  67285851,746 ?  883540,307   B/op   1,00x (p = 0,377 )
>   * = significant

This pull request has now been integrated.

Changeset: af5e5324
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af5e53241b5f05ef56a437b66b2ad8c5eea5462c
Stats:     155 lines in 2 files changed: 153 ins; 0 del; 2 mod

8342806: Desugar capturing lambda in StringNameTable

Reviewed-by: mcimadamore, liach

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

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

From jpai at openjdk.org  Tue Oct 22 15:08:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Oct 2024 15:08:16 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Hello Hannes, since `@param` requires a parameter name and since javadoc already warns about incorrect `@param` names (that don't match the name of the method parameter), does the order in which the `@param` is listed in the javadoc text matter? I looked at https://bugs.openjdk.org/browse/JDK-8279931 but that doesn't tell why the order would be important.

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

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429541439

From mullan at openjdk.org  Tue Oct 22 15:28:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Oct 2024 15:28:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
Message-ID: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>

On Tue, 22 Oct 2024 08:09:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
> 
>> 24: import javax.swing.SwingUtilities;
>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>> 26: /*
> 
> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
> 
>> 29: /**
>> 30:  * @test
>> 31:  * @key headful
> 
> javadoc style /** at the beginning

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:
> 
>> 64:         }
>> 65: 
>> 66:         // Show popup as if from an applet
> 
> remove applet

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 6622002
>> 29:  * @author Alexander Potochkin
> 
> remove @author tag

Not specific to JEP 486, this should be done as part of a different issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810939227
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810942471
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943153
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943359

From redestad at openjdk.org  Tue Oct 22 15:34:47 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 15:34:47 GMT
Subject: Integrated: 8342839: Malformed copyright in StringNameTable since
 JDK-8342806
Message-ID: <-gAyQRowmnkFywNHb1ijY5HsrVFqfvKXcp41nP03xl8=.f5d0a4ff-80a5-4d1d-b277-d138b96672ad@github.com>

Trivially add a missing comma to satisfy Oracle-internal build check.

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

Commit messages:
 - Missing comma

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

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

From thartmann at openjdk.org  Tue Oct 22 15:34:47 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 22 Oct 2024 15:34:47 GMT
Subject: Integrated: 8342839: Malformed copyright in StringNameTable since
 JDK-8342806
In-Reply-To: <-gAyQRowmnkFywNHb1ijY5HsrVFqfvKXcp41nP03xl8=.f5d0a4ff-80a5-4d1d-b277-d138b96672ad@github.com>
References: <-gAyQRowmnkFywNHb1ijY5HsrVFqfvKXcp41nP03xl8=.f5d0a4ff-80a5-4d1d-b277-d138b96672ad@github.com>
Message-ID: <4mThdGz6EDilv5ji5INhNQcg-FyrxtNSh35pbBeQUXg=.49d24f69-db1e-48a4-af54-c0b43d495eb6@github.com>

On Tue, 22 Oct 2024 15:28:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially add a missing comma to satisfy Oracle-internal build check.

Good and trivial.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21640#pullrequestreview-2385578181

From redestad at openjdk.org  Tue Oct 22 15:34:47 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 15:34:47 GMT
Subject: Integrated: 8342839: Malformed copyright in StringNameTable since
 JDK-8342806
In-Reply-To: <-gAyQRowmnkFywNHb1ijY5HsrVFqfvKXcp41nP03xl8=.f5d0a4ff-80a5-4d1d-b277-d138b96672ad@github.com>
References: <-gAyQRowmnkFywNHb1ijY5HsrVFqfvKXcp41nP03xl8=.f5d0a4ff-80a5-4d1d-b277-d138b96672ad@github.com>
Message-ID: <uYgqUTG_vlz4rdt8QLJQ2cPKq-B3RIDwkGOUJJCqjDM=.b819da4b-d9b3-40dd-920d-135c2e0cf7e0@github.com>

On Tue, 22 Oct 2024 15:28:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially add a missing comma to satisfy Oracle-internal build check.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21640#issuecomment-2429603048

From redestad at openjdk.org  Tue Oct 22 15:34:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 15:34:48 GMT
Subject: Integrated: 8342839: Malformed copyright in StringNameTable since
 JDK-8342806
In-Reply-To: <-gAyQRowmnkFywNHb1ijY5HsrVFqfvKXcp41nP03xl8=.f5d0a4ff-80a5-4d1d-b277-d138b96672ad@github.com>
References: <-gAyQRowmnkFywNHb1ijY5HsrVFqfvKXcp41nP03xl8=.f5d0a4ff-80a5-4d1d-b277-d138b96672ad@github.com>
Message-ID: <SEVii9LPAwdDRdf3aaiaEnmzQQDKQb7-rugRLJTr9wc=.660f11e7-058e-4ca4-b219-8cb1e7ed5791@github.com>

On Tue, 22 Oct 2024 15:28:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially add a missing comma to satisfy Oracle-internal build check.

This pull request has now been integrated.

Changeset: f9852aea
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9852aea8b45853544b7acd45ba21b10ab20a1ad
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8342839: Malformed copyright in StringNameTable since JDK-8342806

Reviewed-by: thartmann

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

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

From hannesw at openjdk.org  Tue Oct 22 16:52:37 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 16:52:37 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>
Message-ID: <6rbSFaQrFn1gW7D8VtU2EqAQr4WoZKBdnapd9w3yEIU=.50bab757-b312-4b84-a220-e88fdd1f3bed@github.com>

On Tue, 22 Oct 2024 15:05:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hello Hannes, since `@param` requires a parameter name and since javadoc already warns about incorrect `@param` names (that don't match the name of the method parameter), does the order in which the `@param` is listed in the javadoc text matter? I looked at https://bugs.openjdk.org/browse/JDK-8279931 but that doesn't tell why the order would be important.

@jaikiran it does not matter for the generated documentation because we already [put the tags in the correct order][JDK-8234682]. So it's purely a code hygiene issue to make doc comments easier to read and maintain. 

[JDK-8234682]: https://bugs.openjdk.org/browse/JDK-8234682

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

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429770979

From prr at openjdk.org  Tue Oct 22 16:53:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Oct 2024 16:53:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
Message-ID: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>

On Tue, 22 Oct 2024 15:22:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
>> 
>>> 24: import javax.swing.SwingUtilities;
>>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>>> 26: /*
>> 
>> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
>
> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

Agreed. This is not a "clean up / update tests" task.
If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

>> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
>> 
>>> 29: /**
>>> 30:  * @test
>>> 31:  * @key headful
>> 
>> javadoc style /** at the beginning
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed. No need to touch.

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
>> 
>>> 27:  * @test
>>> 28:  * @bug 6622002
>>> 29:  * @author Alexander Potochkin
>> 
>> remove @author tag
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811067982
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811068956
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811070418

From hannesw at openjdk.org  Tue Oct 22 16:52:44 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 16:52:44 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>
Message-ID: <Ts-V7wU5tk83HEaK9oM4ECkbp8gfZF5vUPceOTp75sY=.4dd2318d-bfdd-4f40-956f-fe4fe3268585@github.com>

On Tue, 22 Oct 2024 14:12:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Changes to java.management, java.naming, and sctp look good to me.

Thanks @dfuch, setting reviewers to 2 for changes in the the remaining modules.

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

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429782605

From honkar at openjdk.org  Tue Oct 22 20:52:28 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:52:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <CkRcFjfurFSz7TjPgF5jqUyjfutH-vBHQvmHLYXNB7Y=.cd1bac46-fd00-4186-aca8-91476983b976@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

@prsadhuk Addressed review comments in the following jep486 branch commit: 
https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e

1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430237067

From honkar at openjdk.org  Tue Oct 22 20:58:31 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:58:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
Message-ID: <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>

On Tue, 22 Oct 2024 08:16:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
> 
>> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>> 48:     }
>> 49: 
> 
> Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

Updated

> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:
> 
>> 46:         test.setupUI();
>> 47:         test.testApplication();
>> 48:         test.testApplet();
> 
> I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

Updated. Repurposed the test.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:
> 
>> 115:             }
>> 116:             popup.setVisible(false);
>> 117:             frame.dispose();
> 
> The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811381885
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382077
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382336

From honkar at openjdk.org  Tue Oct 22 21:04:30 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 21:04:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
Message-ID: <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>

On Tue, 22 Oct 2024 09:29:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
> 
>> 43:         JTable table = new JTable();
>> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
>> 45:         if (de == null) {
> 
> I guess we can test this without SM since it tests SwingLazyValue?

I believe I had removed this test because it wasn't testing anything significant. But I have re-added it please re-review and let me know if it holds value to be retained.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811400040

From mchung at openjdk.org  Tue Oct 22 21:39:31 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 21:39:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:

> 29:  * @summary test that all fields returned by getDeclaredFields() can be
> 30:  *          set accessible if the right permission is granted; this test
> 31:  *          also verifies that Class.classLoader final private field is

"if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 338:

> 336: 
> 337:     public static enum TestCase {
> 338:         UNSECURE;

Better to drop this enum entirely.   Simply call `FieldSetAccessibleTest::run` as it's the only test case.

test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:

> 43: 
> 44:     public static void main(String... args) throws Throwable {
> 45:         System.err.println("Test without security manager.");

Security manager is not relevant any more.  Suggest to drop this println.

test/jdk/java/lang/invoke/RevealDirectTest.java line 33:

> 31:  * @test
> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest

line 36 can also be removed.


* $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

test/jdk/java/lang/invoke/callerSensitive/csm/jdk/test/MethodInvokeTest.java line 77:

> 75:             @Override
> 76:             public boolean implies(ProtectionDomain domain, Permission p) {
> 77:                 return perms.implies(p) || DEFAULT_POLICY.implies(domain, p);

static variable `DEFAULT_POLICY` (line 48) can be removed.

test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:

> 81:     }
> 82: 
> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";

This constant is no longer needed.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2383401067
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809627796
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809631220
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811445313
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811458290
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811462419
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809602637

From vromero at openjdk.org  Tue Oct 22 23:20:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 22 Oct 2024 23:20:17 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects
Message-ID: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>

Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,

TIA

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

Commit messages:
 - adding bug id
 - Merge branch 'JDK-8342090' of https://github.com/vicente-romero-oracle/jdk into JDK-8342090
 - 8342090: Test jdk/classfile/AnnotationTest.java failed to compile
 - 8342090: Infer::IncorporationBinaryOp::equals can produce side-effects

Changes: https://git.openjdk.org/jdk/pull/21651/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21651&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342090
  Stats: 115 lines in 3 files changed: 98 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21651/head:pull/21651

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

From vromero at openjdk.org  Tue Oct 22 23:20:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 22 Oct 2024 23:20:17 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <7Y5_NJJQxhNTa8pbQtBbFIJObwjr70oANVw4MpWOGec=.34b6c2f3-d524-49b9-a784-5e32fd7bda66@github.com>

On Tue, 22 Oct 2024 23:09:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

tests still running

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

PR Comment: https://git.openjdk.org/jdk/pull/21651#issuecomment-2430488344

From psadhukhan at openjdk.org  Wed Oct 23 03:10:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>

On Tue, 22 Oct 2024 16:44:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.
>
> Agreed. This is not a "clean up / update tests" task.
> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811704257

From psadhukhan at openjdk.org  Wed Oct 23 03:10:32 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <BhXyfrLOvAdzoIDfhbCHSeahv9kA7Yt6g9bTufm394k=.cb3057f8-aeef-42cf-8a23-71602c0531cb@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 36:

> 34: import javax.swing.SwingUtilities;
> 35: 
> 36: /*

this here the order is changed...

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 24:

> 22:  */
> 23: 
> 24: /**

again here the import and tag order is changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811705627
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811706135

From psadhukhan at openjdk.org  Wed Oct 23 03:19:28 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:19:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <hBSgrNiQ1XrBiepIl60-kesAatcE7Flw6_cRwQRDIpA=.846ab6c0-0855-4f0d-a9d8-91831587dfae@github.com>

On Tue, 22 Oct 2024 16:46:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Not specific to JEP 486, this should be done as part of a different issue.
>
> agreed

there were many tests modified in javax_swing in this PR where the author tag is removed, only this is missed so I pointed it out...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811724308

From psadhukhan at openjdk.org  Wed Oct 23 05:14:36 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 05:14:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
> 
>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
> 
>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
> 
>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
> 
>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
> 
> 
> Left out comments that fall into out-of-scope/clean-up for jep486.

looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430919687

From vromero at openjdk.org  Wed Oct 23 05:22:47 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 23 Oct 2024 05:22:47 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v2]
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <B5m5-0WQmAC_Uk27h4VnRT0KVZSCQBkpqTjU-OfqbHI=.42ba9535-b385-4092-b8cc-59f10e27da9e@github.com>

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

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

  stress tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21651/files
  - new: https://git.openjdk.org/jdk/pull/21651/files/0285ae2c..8e5477be

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

  Stats: 1705 lines in 1391 files changed: 1529 ins; 6 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/21651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21651/head:pull/21651

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

From mcimadamore at openjdk.org  Wed Oct 23 10:23:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 23 Oct 2024 10:23:06 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v2]
In-Reply-To: <B5m5-0WQmAC_Uk27h4VnRT0KVZSCQBkpqTjU-OfqbHI=.42ba9535-b385-4092-b8cc-59f10e27da9e@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
 <B5m5-0WQmAC_Uk27h4VnRT0KVZSCQBkpqTjU-OfqbHI=.42ba9535-b385-4092-b8cc-59f10e27da9e@github.com>
Message-ID: <lYuV5YNCijQMzzO1VjMlsizAOaeoon8-azJFF07j2ak=.791d5c0b-e08d-4bbe-8241-a2abb32b8508@github.com>

On Wed, 23 Oct 2024 05:22:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stress tests

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 1276:

> 1274:          */
> 1275:         Type undetVarToTVar(Type t) {
> 1276:             return types.subst(t, ic.undetvars, ic.inferencevars);

Maybe this should be another mapping in the InferenceContext - similar to how we deal with `asInst` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21651#discussion_r1812428265

From mcimadamore at openjdk.org  Wed Oct 23 10:32:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 23 Oct 2024 10:32:06 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v2]
In-Reply-To: <B5m5-0WQmAC_Uk27h4VnRT0KVZSCQBkpqTjU-OfqbHI=.42ba9535-b385-4092-b8cc-59f10e27da9e@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
 <B5m5-0WQmAC_Uk27h4VnRT0KVZSCQBkpqTjU-OfqbHI=.42ba9535-b385-4092-b8cc-59f10e27da9e@github.com>
Message-ID: <w2-92cpLG4AmpRpwEepROr_5tTR7DeDuzd9PL-scAsY=.126b52dc-3ee3-43e7-9a8b-e22d571164d6@github.com>

On Wed, 23 Oct 2024 05:22:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stress tests

Looks good. I've suggested a couple of simplifications.
I believe we need another way to test. I think, for now, let's include the tests we have in related JBS issues, and run them with both normal and alternate (`-XX:hash=2`) strategies. Then, in a separate JBS issue, maybe figure out how to run a subset of tests automatically, using the alternate hashing.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java line 1253:

> 1251:             return (o instanceof IncorporationBinaryOp incorporationBinaryOp)
> 1252:                     && opKind == incorporationBinaryOp.opKind
> 1253:                     && types.isSameType(undetVarToTVar(op1), undetVarToTVar(incorporationBinaryOp.op1))

I believe we probably need to compute these things only once - as these mappings are expensive. I wonder if this code is trying to do too much. All we are after here is a way to check that we haven't already executed an incorporation op. This is only really created in one place (`doIncorporationOp`). So I suggest a reshuffling:

* rename this class IncorporationBinaryOpKey, and make it a record
* the key record will always hold "unmapped types" (the record constructor can do the unmapping)
* get rid of the `apply` method
* in `doIncorporationOp`, create a key, check if a result is already in the cache. If so return it. If not, compute a new result, by calling `apply` on the incorporation op kind (with the "original" types).

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

PR Review: https://git.openjdk.org/jdk/pull/21651#pullrequestreview-2388140758
PR Review Comment: https://git.openjdk.org/jdk/pull/21651#discussion_r1812441797

From vromero at openjdk.org  Wed Oct 23 11:15:13 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 23 Oct 2024 11:15:13 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v3]
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <QG9eYHQMfT7bDY0l6_SlI14YGZWn0DshR6vruAF3cKM=.f7f6d4a1-8a49-47b6-9b05-1de8a4cd13bf@github.com>

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

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

  remove changes to non-related tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21651/files
  - new: https://git.openjdk.org/jdk/pull/21651/files/8e5477be..0d2eecd3

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

  Stats: 1705 lines in 1391 files changed: 6 ins; 1529 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/21651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21651/head:pull/21651

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

From alanb at openjdk.org  Wed Oct 23 11:52:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:52:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
 <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
Message-ID: <EEdxqnOAo9_wdmwyW4F-nsSKR-G1K_Lgy-TQHEfPB74=.38278323-1010-4b56-955e-4ad3fe4b0c91@github.com>

On Mon, 21 Oct 2024 17:20:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.
> 
> Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

I checked the commit in the sandbox and it looks okay. It may be some future maintenance in these micros may do some pruning as aren't too useful now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2431865182

From alanb at openjdk.org  Wed Oct 23 11:57:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:57:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:

> 340:         throws Exception
> 341:     {
> 342:         action.run();

testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812582305

From alanb at openjdk.org  Wed Oct 23 12:01:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:01:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>

On Tue, 22 Oct 2024 21:20:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
> 
>> 31:  * @test
>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
> 
> line 36 can also be removed.
> 
> 
> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

hasSM and the code that only runs when true can be deleted too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812587449

From alanb at openjdk.org  Wed Oct 23 12:17:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:17:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:

> 239:         Properties props = System.getProperties();
> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
> 241:         System.setSecurityManager(new SecurityMan());

I assume SecurityMan should be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812614134

From coleenp at openjdk.org  Wed Oct 23 12:47:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 12:47:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/hotspot/share/prims/jvm.cpp line 1272:

> 1270: 
> 1271: 
> 1272: // Returns the inherited_access_control_context field of the running thread.

There's some code in this file in 
static void trace_class_resolution_impl(Klass* to_class, TRAPS) {

That does this:


    while (!vfst.at_end()) {
      Method* m = vfst.method();
      if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
          !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
          !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
        break;
      }
      last_caller = m;
      vfst.next();
    }


Is this dead code that should be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812677985

From alanb at openjdk.org  Wed Oct 23 12:56:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:56:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
Message-ID: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>

On Wed, 23 Oct 2024 12:44:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/hotspot/share/prims/jvm.cpp line 1272:
> 
>> 1270: 
>> 1271: 
>> 1272: // Returns the inherited_access_control_context field of the running thread.
> 
> There's some code in this file in 
> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
> 
> That does this:
> 
> 
>     while (!vfst.at_end()) {
>       Method* m = vfst.method();
>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>         break;
>       }
>       last_caller = m;
>       vfst.next();
>     }
> 
> 
> Is this dead code that should be removed?

This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812694528

From dfuchs at openjdk.org  Wed Oct 23 13:10:37 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Oct 2024 13:10:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
Message-ID: <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>

On Wed, 23 Oct 2024 11:54:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:
> 
>> 340:         throws Exception
>> 341:     {
>> 342:         action.run();
> 
> testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

Good point. Similarly, the URLPermission[] parameter is now always unused, so maybe I should get rid of that too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812727202

From jlahoda at openjdk.org  Wed Oct 23 13:13:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Oct 2024 13:13:20 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <6t6044s7pqcy0dM-zUTzDTXjd1IVwMoge7ckm9WpvSs=.0f4027e4-f0c3-43cc-9f62-97d51fa446a6@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <6t6044s7pqcy0dM-zUTzDTXjd1IVwMoge7ckm9WpvSs=.0f4027e4-f0c3-43cc-9f62-97d51fa446a6@github.com>
Message-ID: <xFAXPbo_z4l7YbO6SgRt-dmbhN8etgyXf1LZJDoyB6c=.f5b7bba2-9daa-4b1c-bd51-e4da434bd143@github.com>

On Mon, 21 Oct 2024 11:03:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1141:
> 
>> 1139:             return true;
>> 1140:         } else if (sym.kind == TYP && toplevel != null) {
>> 1141:             for (Scope scope : new Scope[] {toplevel.namedImportScope,
> 
> I wonder if we could deal with this with a compound scope? (and avoid the loop)

In principle, we could, but the `CompoundScope` is a bit heavier, so it might be better to keep the loop here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1812730863

From nbenalla at openjdk.org  Wed Oct 23 13:41:43 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 23 Oct 2024 13:41:43 GMT
Subject: RFR: 8342697: Parameter arrays that are capped during annotation
 processing report incorrect length
Message-ID: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>

Can I please get a review for this change.
Passes tier1, currently running tier 2-3.

The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.

Here is the result of running `javap -c -p -v` on `ClassAnnotationWithLength_65536.class`  and `ClassAnnotationWithLength_65537.class` respectively. Results are the same before/after the change.


static int x;
    descriptor: I
    flags: (0x0008) ACC_STATIC
    RuntimeVisibleAnnotations:
      0: #14(#15=s#16,#17=I#18,#19=[J#20])
        CustomAnno(
          value="custom"
          count=42
          arr=[-1l]
        )



  static int x;
    descriptor: I
    flags: (0x0008) ACC_STATIC
    RuntimeVisibleAnnotations:
      0: #14(#15=s#16,#17=I#18,#19=[J#20,J#20])
        CustomAnno(
          value="custom"
          count=42
          arr=[-1l,-1l]
        )


TIA

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

Commit messages:
 - try to remove trailing whitespace
 - simplify BufferedWriter creation
 - JDK-8339190

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

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

From liach at openjdk.org  Wed Oct 23 13:41:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 13:41:44 GMT
Subject: RFR: 8342697: Parameter arrays that are capped during annotation
 processing report incorrect length
In-Reply-To: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
Message-ID: <0uYmysJNzL82dC9jnENe_kIeBM1h9Y6I7asHI1wTIYA=.b7da6d2c-e17b-46f7-a8ef-1969b083fefa@github.com>

On Wed, 23 Oct 2024 11:45:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I please get a review for this change.
> Passes tier1, currently running tier 2-3.
> 
> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
> 
> Here is the result of running `javap -c -p -v` on `ClassAnnotationWithLength_65536.class`  and `ClassAnnotationWithLength_65537.class` respectively. Results are the same before/after the change.
> 
> 
> static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l]
>         )
> 
> 
> 
>   static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20,J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l,-1l]
>         )
> 
> 
> TIA

test/langtools/tools/javac/annotations/ParameterArraySizeLimit.java line 121:

> 119: 
> 120:         FileWriter writer = new FileWriter(String.valueOf(out));
> 121:         BufferedWriter bufferedWriter = new BufferedWriter(writer);

This can be simplified to `Files.newBufferedWriter`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21663#discussion_r1812564387

From nbenalla at openjdk.org  Wed Oct 23 14:31:49 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 23 Oct 2024 14:31:49 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v2]
In-Reply-To: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
Message-ID: <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>

> Can I please get a review for this change.
> Passes tier1, currently running tier 2-3.
> 
> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
> 
> Here is the result of running `javap -c -p -v` on `ClassAnnotationWithLength_65536.class`  and `ClassAnnotationWithLength_65537.class` respectively. Results are the same before/after the change.
> 
> 
> static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l]
>         )
> 
> 
> 
>   static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20,J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l,-1l]
>         )
> 
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  - remove unused import
  - realized I need to change the condition in my for loop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21663/files
  - new: https://git.openjdk.org/jdk/pull/21663/files/e44f23e3..80d25a19

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

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

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

From jlahoda at openjdk.org  Wed Oct 23 14:31:49 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Oct 2024 14:31:49 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length
In-Reply-To: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
Message-ID: <SSrjowNXFqgQXBenxBOcKy9P9UIEJkdp_GFP-tnTp5g=.7b94e6b0-b837-4eaf-ad8d-642bd4e64049@github.com>

On Wed, 23 Oct 2024 11:45:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I please get a review for this change.
> Passes tier1, currently running tier 2-3.
> 
> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
> 
> Here is the result of running `javap -c -p -v` on `ClassAnnotationWithLength_65536.class`  and `ClassAnnotationWithLength_65537.class` respectively. Results are the same before/after the change.
> 
> 
> static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l]
>         )
> 
> 
> 
>   static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20,J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l,-1l]
>         )
> 
> 
> TIA

I am sorry, but producing warnings is IMO a wrong solution. While the Java language does not impose limits, the classfile format does, and if we cannot generate a classfile that corresponds to the input Java file, javac should not produce anything and should finish up with a compile-time error. That is what is done for other limits as well. Like, for example, here:
https://github.com/openjdk/jdk/blob/964d8d2234595afaf4dfe48ea5cacdbfd3792d03/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java#L940

(Although this check for annotations may need to be done in `ClassWriter`.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21663#issuecomment-2432411334

From vromero at openjdk.org  Wed Oct 23 15:30:49 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 23 Oct 2024 15:30:49 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v4]
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <GEUiK6aeKsmr-jf5JzM-7RcP-wrgcZibuoIIgp9aogA=.76802fd8-c82d-4713-adbc-31d5ac9f7669@github.com>

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21651/files
  - new: https://git.openjdk.org/jdk/pull/21651/files/0d2eecd3..d9b2962d

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

  Stats: 55 lines in 3 files changed: 8 ins; 39 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21651/head:pull/21651

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

From kizune at openjdk.org  Wed Oct 23 17:27:42 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 23 Oct 2024 17:27:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <cYDFZ0hXc_bXKTrCftDs1-Xd-Rr4iOpngFb3pB8zi2U=.6d408fe5-63bc-45a3-8ff4-264671975ed1@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Finished reviewing of accessibility (both in com.sun and jdk.javax), jdk.javax.sound and jdk.java.awt.Desktop. Looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2432939145

From honkar at openjdk.org  Wed Oct 23 18:06:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 18:06:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <-GbMPbwNI--hHPZyyPgdU-pOMZh0Z4tZ_tLdbv-LL2E=.1494bfd4-7941-4c2e-af9b-82a29a4b2427@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

@prsadhuk 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud

Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433031866

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <nTh2g7Sw6iv8lfDeUFsAru4vij3UTDzgCvhC8pwp3JU=.4546e9fb-99d9-48f9-8948-c6c1172355ea@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

> @prsadhuk
> 
> > looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud
> 
> Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

I also didn't realise you had "changed" it. I'm finding it very painful to navigate to the related files in this huge PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433046255

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ZLiF5TADkOkZ9p142_bjFkSO5cM4DKmqd7j3mnJxnhs=.2d8f316d-a604-4f17-be07-1a917491d5b3@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

I've reviewed all jdk/java/awt and jdk/javax/imageio tests.
I've either commented or proactively fixed in the jep sandbox branch. Or both.
Next sync from there should resolve those.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433048411

From nbenalla at openjdk.org  Wed Oct 23 18:20:06 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 23 Oct 2024 18:20:06 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v2]
In-Reply-To: <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
Message-ID: <UKSV2IuPfz5TM7zCDs83LTUwmZsxbrha5wfz-wsBBFc=.9dbea7c3-6005-4bd8-b16f-2e11c0e94e45@github.com>

On Wed, 23 Oct 2024 14:31:49 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this change.
>> Passes tier1, currently running tier 2-3.
>> 
>> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
>> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
>> 
>> Here is the result of running `javap -c -p -v` on `ClassAnnotationWithLength_65536.class`  and `ClassAnnotationWithLength_65537.class` respectively. Results are the same before/after the change.
>> 
>> 
>> static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>>         CustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[-1l]
>>         )
>> 
>> 
>> 
>>   static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[J#20,J#20])
>>         CustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[-1l,-1l]
>>         )
>> 
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - remove unused import
>   - realized I need to change the condition in my for loop

I will update this PR and the CSR to fail if we detect an overflow, rather than warn users. Thanks Jan

Though I am not sure why the check would need to be done when writing the classfile, why not do it earlier?

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

PR Comment: https://git.openjdk.org/jdk/pull/21663#issuecomment-2433059785

From vromero at openjdk.org  Wed Oct 23 18:32:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 23 Oct 2024 18:32:06 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v5]
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <Gnf900PfGmsDlySjF9ucim6UzjRZKVbY2LdXWtFtuW4=.1a6097d7-c35a-4627-899f-a286a3a3fed6@github.com>

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

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

  change in hash function changed a test output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21651/files
  - new: https://git.openjdk.org/jdk/pull/21651/files/d9b2962d..746fa427

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

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

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

From coleenp at openjdk.org  Wed Oct 23 19:18:33 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 19:18:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
Message-ID: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>

On Wed, 23 Oct 2024 12:53:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1272:
>> 
>>> 1270: 
>>> 1271: 
>>> 1272: // Returns the inherited_access_control_context field of the running thread.
>> 
>> There's some code in this file in 
>> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
>> 
>> That does this:
>> 
>> 
>>     while (!vfst.at_end()) {
>>       Method* m = vfst.method();
>>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>>         break;
>>       }
>>       last_caller = m;
>>       vfst.next();
>>     }
>> 
>> 
>> Is this dead code that should be removed?
>
> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813400810

From honkar at openjdk.org  Wed Oct 23 19:41:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 19:41:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
Message-ID: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>

On Mon, 21 Oct 2024 21:12:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
> 
>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>> 75: 
>> 76:         if (args.length > 1) {
> 
> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
> 
> Also the messing around with exceptions at the end of the test is pointless

@prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.

Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2

I'll be rename the test as suggested when I update this test next.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813429265

From honkar at openjdk.org  Wed Oct 23 20:20:35 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 20:20:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
 <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
Message-ID: <vmkpLn9nL1RxwBDfE6plkj6ja6Ks2R7_V355BH4mVGQ=.8b4c1433-acd9-4180-9169-5997f934125b@github.com>

On Wed, 23 Oct 2024 19:38:10 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
>> 
>>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>>> 75: 
>>> 76:         if (args.length > 1) {
>> 
>> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
>> 
>> Also the messing around with exceptions at the end of the test is pointless
>
> @prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.
> 
> Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2
> 
> I'll be rename the test as suggested when I update this test next.

No changes required for this test. The test was failing due to IDE config issue of tmp dir.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813474346

From mullan at openjdk.org  Wed Oct 23 21:57:34 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 21:57:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
Message-ID: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>

On Wed, 23 Oct 2024 12:14:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
> 
>> 239:         Properties props = System.getProperties();
>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>> 241:         System.setSecurityManager(new SecurityMan());
> 
> I assume SecurityMan should be removed too.

Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813724467

From mullan at openjdk.org  Wed Oct 23 22:21:35 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 22:21:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <-WUk0E4MRJ1CB84NKT6g7L3pmv-IFpgTnJsrjsjSavA=.53352f0c-6c82-4a45-86c8-b3468c842d9e@github.com>

On Tue, 22 Oct 2024 21:36:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

Thanks for the comprehensive review. I have incorporated all of your comments except for removing the enum from `java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java` which is a bit more involved. I plan on posting an updated PR with these and other changes tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433572062

From liach at openjdk.org  Thu Oct 24 04:26:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 04:26:06 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v2]
In-Reply-To: <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
Message-ID: <FXDxTMNgYoY1v3nfD2N-3pWMbC3Mffh_wbshIUXsmYs=.81fbbadf-1d64-482e-bc08-95f02b989e0b@github.com>

On Wed, 23 Oct 2024 14:31:49 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this change.
>> Passes tier1, currently running tier 2-3.
>> 
>> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
>> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
>> 
>> Here is the result of running `javap -c -p -v` on `ClassAnnotationWithLength_65536.class`  and `ClassAnnotationWithLength_65537.class` respectively. Results are the same before/after the change.
>> 
>> 
>> static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>>         CustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[-1l]
>>         )
>> 
>> 
>> 
>>   static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[J#20,J#20])
>>         CustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[-1l,-1l]
>>         )
>> 
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - remove unused import
>   - realized I need to change the condition in my for loop

src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java line 1430:

> 1428:         private void checkArraySize(List<JCExpression> tree) {
> 1429:             //check if attribute length exceeds maximum unsigned 16-bit value
> 1430:             if (!sigOnly && tree != null && (tree.size() >>> 16) > 0) {

Should we use `(tree.size & ~0xFFFF) != 0`? This is how classfile API checks the value compatibility, and I wonder how other places in javac does so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21663#discussion_r1814224310

From jlahoda at openjdk.org  Thu Oct 24 06:40:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 24 Oct 2024 06:40:42 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v4]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Updating PreviewFeature metadata
 - Cleanup.
 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - Adding a separate scope for module imports.
 - Cleanup.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/964d8d22...94b8bf6d

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

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=03
  Stats: 762 lines in 28 files changed: 580 ins; 46 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/21431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21431/head:pull/21431

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

From jlahoda at openjdk.org  Thu Oct 24 06:48:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 24 Oct 2024 06:48:16 GMT
Subject: Integrated: 8339296: Record deconstruction pattern in switch fails to
 compile
In-Reply-To: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
References: <hzjVlJ3yLBphpyxbCl3SCNLz-ZSa4XsxJ9km1Mx__iI=.0d818550-ea3c-4928-a313-6bf26ca9bcd2@github.com>
Message-ID: <ueuFDjQgdiaAC53ylsqXfkxm76kUQey-VspAU0rvO1s=.9cd65990-0940-4c32-af42-dabf026d3381@github.com>

On Fri, 13 Sep 2024 09:23:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
>     int nestedSwitchesInArgumentPosition(Object o1) {
>         return id(switch (o1) {
>             case R(var o2) -> switch (o2) {
>                 case R(String s) -> s;
>                 default -> "n";
>             };
>             default -> "";
>         });
>     }
> 
>     int id(String s) {
>         return s.length();
>     }
> 
>     int id(int i) {
>         return i;
>     }
> 
> 
> Compiling this fails with a `StackOverflowError`, because:
>  - there are speculative attribution happening for the switch expressions,
>  - "completes normally" is computed during these speculative attribution, which have parts of the AST unfilled - specifically the nested `case R(String s)`
>  - so, `Attr.PostAttrAnalyzer` fills in the missing types. In particular, the `String s` binding will get the `Symtab.unknownType`.
>  - `Flow.makePatternDescription` will eventually ask `Types.isSubtype(..., unknownType)`. This is guaranteed to fail with the `StackOverflowError`, as:
>  - `unknownType.isPartial()` returns `true`, so `Types.isSubtype(t, s)` (`s` is the `unknownType`) calls `Types.isSuperType(s, t)`, and `Types.isSuperType(s, t)` does not contain any special handling for the `unknownType`, so it will delegate to `Types.isSubtype(t, s)`, leading to an infinite recursion.
> 
> It may be possible to side-step the issue by not computing the completes normally property during speculative attribution, or move that computation outside of `Attr`. It may be good to do, for performance reasons.
> 
> But, that does not seem to solve the underlying issue with `unknownType`. Many methods in `Types` misbehave in weird ways when the `unknownType` is passed to them.
> 
> The proposal herein is to attempt to resolve that. In particular, the `UnknownType` is proposed to extend the `ErrorType`, dropping the (internal) `UNKNOWN` type tag. The uses of the `UNKNOWN` type tag appear to be equivalent to handling of the `ERROR` type tag anyway. And the special handling of the `unknownType` appear to usually use ` == syms.unknownType`:
> https://github.com/openjdk/jdk/blob/0c36177fead8b64a4cee9da3c895e3799f8ba231/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L904
> 
> After this change, the `unknownType` should behave as an erroneous type, unless specifically requested otherwise.
> 
> The intent is that the public API behavior for the `unknownType` should remain the same.

This pull request has now been integrated.

Changeset: f0b130e5
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0b130e54f33d3190640ce33c991e35f27e9f812
Stats:     188 lines in 6 files changed: 150 ins; 32 del; 6 mod

8339296: Record deconstruction pattern in switch fails to compile

Reviewed-by: vromero, mcimadamore

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

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

From alanb at openjdk.org  Thu Oct 24 07:18:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:18:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
Message-ID: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>

On Wed, 23 Oct 2024 19:15:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.
>
> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814402940

From azvegint at openjdk.org  Thu Oct 24 09:56:37 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 24 Oct 2024 09:56:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <HoUuHVqcGME8iweQAWbnP6igoSGpoRtK7oX32sXi7fk=.a7ec909b-aa58-477f-bf1a-a9244a49df12@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

java beans changes looks good

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2391943640

From coleenp at openjdk.org  Thu Oct 24 11:35:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 11:35:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
Message-ID: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>

On Thu, 24 Oct 2024 07:15:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.
>
> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814801818

From jpai at openjdk.org  Thu Oct 24 11:42:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 11:42:06 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

src/java.xml/share/classes/javax/xml/validation/SchemaFactoryConfigurationError.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Hello Hans, this looks like an oversight - the copyright year update should have retained the 2013 and additionally introduced 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21637#discussion_r1814810579

From hannesw at openjdk.org  Thu Oct 24 12:17:41 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 24 Oct 2024 12:17:41 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21637/files
  - new: https://git.openjdk.org/jdk/pull/21637/files/70c1d49f..65a3ddf8

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

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

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

From hannesw at openjdk.org  Thu Oct 24 12:17:42 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 24 Oct 2024 12:17:42 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>
Message-ID: <1SSi_dzz13sxXuDmlLMHn26DDwxozHVqmzIJkon1kFA=.6ce6f3c6-1e8e-4606-87ae-2ba61302c71e@github.com>

On Thu, 24 Oct 2024 11:39:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright header
>
> src/java.xml/share/classes/javax/xml/validation/SchemaFactoryConfigurationError.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Hello Hannes, this looks like an oversight - the copyright year update should have retained the 2013 and additionally introduced 2024.

Thanks for catching this, @jaikiran!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21637#discussion_r1814857072

From jpai at openjdk.org  Thu Oct 24 12:44:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 12:44:05 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <I2kDmWqE6Ca4VnWeVBXIT1oJTaBgT114GEuazR0do34=.3228f83c-9b8e-4af5-938d-08baed53bfe4@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

This doc-only change which merely reorders the `@param` tags looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2392367946

From nbenalla at openjdk.org  Thu Oct 24 12:50:07 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 24 Oct 2024 12:50:07 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v2]
In-Reply-To: <FXDxTMNgYoY1v3nfD2N-3pWMbC3Mffh_wbshIUXsmYs=.81fbbadf-1d64-482e-bc08-95f02b989e0b@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
 <FXDxTMNgYoY1v3nfD2N-3pWMbC3Mffh_wbshIUXsmYs=.81fbbadf-1d64-482e-bc08-95f02b989e0b@github.com>
Message-ID: <LA7caRRdAalJqgUWy2eG2p06CWA0r-p849d_qWXZAqI=.700422e1-c69d-45ec-9424-3b810077cd4c@github.com>

On Thu, 24 Oct 2024 04:22:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - remove unused import
>>   - realized I need to change the condition in my for loop
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java line 1430:
> 
>> 1428:         private void checkArraySize(List<JCExpression> tree) {
>> 1429:             //check if attribute length exceeds maximum unsigned 16-bit value
>> 1430:             if (!sigOnly && tree != null && (tree.size() >>> 16) > 0) {
> 
> Should we use `(tree.size & ~0xFFFF) != 0`? This is how classfile API checks the value compatibility, and I wonder how other places in javac does so.

I was trying to chose between this and `tree.size & ~0xFFFF`, I think `javac` will sometimes check if an int is larger than `0xFFFF`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21663#discussion_r1814913041

From vromero at openjdk.org  Thu Oct 24 12:53:45 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 12:53:45 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v6]
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <_0ugPCYKeJy_molffOL0ePEuGJ3DgNK3-PRQRz4SJcE=.348e55f9-af3c-4bc0-b30c-a3791d77e152@github.com>

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21651/files
  - new: https://git.openjdk.org/jdk/pull/21651/files/746fa427..9318455e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21651&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21651&range=04-05

  Stats: 20 lines in 2 files changed: 10 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21651/head:pull/21651

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

From liach at openjdk.org  Thu Oct 24 13:03:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 13:03:10 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v2]
In-Reply-To: <LA7caRRdAalJqgUWy2eG2p06CWA0r-p849d_qWXZAqI=.700422e1-c69d-45ec-9424-3b810077cd4c@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
 <FXDxTMNgYoY1v3nfD2N-3pWMbC3Mffh_wbshIUXsmYs=.81fbbadf-1d64-482e-bc08-95f02b989e0b@github.com>
 <LA7caRRdAalJqgUWy2eG2p06CWA0r-p849d_qWXZAqI=.700422e1-c69d-45ec-9424-3b810077cd4c@github.com>
Message-ID: <Z3U0APyGVCdhAxyQ2daKUcXkGBT97x9rT2eFKQyk95Y=.37091079-4a9b-4cf1-9a3f-fbecd4a10c2e@github.com>

On Thu, 24 Oct 2024 12:47:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java line 1430:
>> 
>>> 1428:         private void checkArraySize(List<JCExpression> tree) {
>>> 1429:             //check if attribute length exceeds maximum unsigned 16-bit value
>>> 1430:             if (!sigOnly && tree != null && (tree.size() >>> 16) > 0) {
>> 
>> Should we use `(tree.size & ~0xFFFF) != 0`? This is how classfile API checks the value compatibility, and I wonder how other places in javac does so.
>
> I was trying to chose between this and `tree.size & ~0xFFFF`, I think `javac` will sometimes check if an int is larger than `0xFFFF`

If you use `& ~0xFFFF` you must use `!= 0` as the mask includes the sign bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21663#discussion_r1814938704

From vromero at openjdk.org  Thu Oct 24 13:07:25 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 13:07:25 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v7]
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <QWdqz9speOjqDOAaXyvyj9k5_6OFVnpux57KW6nngS8=.c95a870e-172b-4409-bcc7-3efd7ba0c1ec@github.com>

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21651/files
  - new: https://git.openjdk.org/jdk/pull/21651/files/9318455e..a7cb54c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21651&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21651&range=05-06

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

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

From mullan at openjdk.org  Thu Oct 24 13:19:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 13:19:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge
 - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
 - Remove println about Security Manager.
 - Remove unused static variable NEW_PROXY_IN_PKG.
 - Remove static variable `DEFAULT_POLICY` and unused imports.
 - Remove hasSM() method and code that calls it, and remove comment about
   running test manually with SM.
 - clientlibs: import order
 - warning-string
 - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
 - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=02
  Stats: 65432 lines in 1867 files changed: 1137 ins; 60545 del; 3750 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From mcimadamore at openjdk.org  Thu Oct 24 13:20:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Oct 2024 13:20:11 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v7]
In-Reply-To: <QWdqz9speOjqDOAaXyvyj9k5_6OFVnpux57KW6nngS8=.c95a870e-172b-4409-bcc7-3efd7ba0c1ec@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
 <QWdqz9speOjqDOAaXyvyj9k5_6OFVnpux57KW6nngS8=.c95a870e-172b-4409-bcc7-3efd7ba0c1ec@github.com>
Message-ID: <Fq8of0MsvxMoBJyOlhE1MPpuVTzNqoe5jmkyzpmki9A=.3ed907c9-e253-4028-b57e-cf16015bb8c9@github.com>

On Thu, 24 Oct 2024 13:07:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks very good - thanks!

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3331:

> 3329:     }
> 3330: 
> 3331:     /* this class won't substitute all types for example UndetVars are never substituted, this is like this

Suggestion:

    /* this class won't substitute all types for example UndetVars are never substituted, this is

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 3332:

> 3330: 
> 3331:     /* this class won't substitute all types for example UndetVars are never substituted, this is like this
> 3332:      * by design as UndetVars are used locally during inference and shouldn't scape from inference rutines,

Suggestion:

     * by design as UndetVars are used locally during inference and shouldn't escape from inference routines,

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21651#pullrequestreview-2392487943
PR Review Comment: https://git.openjdk.org/jdk/pull/21651#discussion_r1814974259
PR Review Comment: https://git.openjdk.org/jdk/pull/21651#discussion_r1814974727

From prappo at openjdk.org  Thu Oct 24 13:52:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 24 Oct 2024 13:52:06 GMT
Subject: RFR: 8321500: javadoc rejects '@' in multi-line attribute value
In-Reply-To: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
References: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
Message-ID: <amUfJTXOU-pJSzHLzkbWBc08a0BWwHTleAKMqIriRgU=.3f7adc68-ab65-4987-a1b6-83984e06061c@github.com>

On Tue, 15 Oct 2024 10:41:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review the removal of code in `DocCommentParser` that created an error when encountering a spurious "@" character in an HTML attribute value after a line break. 
> 
> The removed code (which was added in its current form in 2012) seemed to assume that such a "@" character was part of a block tag and therefore an indication of an unclosed attribute value. However, both line breaks and "@" are valid characters in HTML attributes. Note that valid content for HTML attributes in `DocCommentParser` is [text and entities as per HTML5][html5-attributes] as well as JavaDoc inline tags, but not block tags.
> 
> [html5-attributes]: https://html.spec.whatwg.org/multipage/syntax.html#syntax-attribute-value
> 
> The change adds two doctree tests, one to make sure HTML attributes with mixed values (text, line breaks, entities, inline tags, "@") are parsed correctly, and a second one to make sure actual unclosed attribute values are still recognized as errors.

I'm surprised we've had no tests for that code you deleted. But deleting it solves the original reporter's issue.

Let's hope they don't start using constructs like `title="{@see`. On second thought, in that case, they can escape `@` with `@@`, provided their javadoc is reasonably modern. Consider adding a test for this.

Additionally, for sanity's sake, I checked that newlines are indeed fine if quoted:

  - https://html.spec.whatwg.org/#attribute-value-(double-quoted)-state
  - https://html.spec.whatwg.org/#attribute-value-(single-quoted)-state

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

PR Comment: https://git.openjdk.org/jdk/pull/21520#issuecomment-2435354076

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <TAjuG-LLpFQjYHfC-K2h0rAynZrqV0ckIViIVvwJB94=.cb21f1de-39bc-4fb6-96a1-861834ccb336@github.com>

On Mon, 21 Oct 2024 22:51:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:
> 
>> 29:  * @summary test that all fields returned by getDeclaredFields() can be
>> 30:  *          set accessible if the right permission is granted; this test
>> 31:  *          also verifies that Class.classLoader final private field is
> 
> "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d8564fa8dd003456b6e313c5e07809999c7d96e1

> test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:
> 
>> 43: 
>> 44:     public static void main(String... args) throws Throwable {
>> 45:         System.err.println("Test without security manager.");
> 
> Security manager is not relevant any more.  Suggest to drop this println.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/002276450e625b66b786fb7eae7256bbcafa7496

> test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";
> 
> This constant is no longer needed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/3dbf684263a75470b85a95b9446a44ceb99c4b3a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815057352
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058036
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815055982

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
 <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
Message-ID: <ZHPRQ0q6AkTrdGKCsX_9xghixEQm8e0qe7UTbqPSCFM=.b57001b8-376f-4e00-9953-64d8bdaeb160@github.com>

On Wed, 23 Oct 2024 11:58:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
>> 
>>> 31:  * @test
>>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
>> 
>> line 36 can also be removed.
>> 
>> 
>> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest
>
> hasSM and the code that only runs when true can be deleted too.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/559934662119b1372fd831de8be7c97f877e0947

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058738

From vromero at openjdk.org  Thu Oct 24 14:13:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 14:13:26 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v8]
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <GtkwYIWUmNG5gDr12ZR0a1OBLopFVjhH0zPfCoeJRUk=.5d667efa-e713-4a18-a1c1-046d39b2a8f1@github.com>

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21651/files
  - new: https://git.openjdk.org/jdk/pull/21651/files/a7cb54c5..fc210dd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21651&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21651&range=06-07

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

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

From alanb at openjdk.org  Thu Oct 24 14:29:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 14:29:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
 <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
Message-ID: <bLyF3XGfyhUtiuOuG0jqnqZtXM0UgzNtZAAZhDyNymM=.cdec18a4-ba4e-4e32-918a-93be3d95fadc@github.com>

On Thu, 24 Oct 2024 11:32:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?
>
> So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

I have the changes to Class/ClassLoader to propose as soon as this JEP integrates. If that can go in quickly then it would remove any concerns in advance of your cleanup to remove the filtering of these frames (although I don't think there is an issue as this code path is conditional based on whether a SM is set).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815107403

From mcimadamore at openjdk.org  Thu Oct 24 14:40:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Oct 2024 14:40:08 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v8]
In-Reply-To: <GtkwYIWUmNG5gDr12ZR0a1OBLopFVjhH0zPfCoeJRUk=.5d667efa-e713-4a18-a1c1-046d39b2a8f1@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
 <GtkwYIWUmNG5gDr12ZR0a1OBLopFVjhH0zPfCoeJRUk=.5d667efa-e713-4a18-a1c1-046d39b2a8f1@github.com>
Message-ID: <TJ64iokbylDBHSZAOXbTf6Y-qU2VihBu3Nw2gWf_h3g=.724b6c7c-35a0-4bdc-a41c-32e6a2219a3c@github.com>

On Thu, 24 Oct 2024 14:13:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21651#pullrequestreview-2392873491

From iris at openjdk.org  Thu Oct 24 14:48:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 24 Oct 2024 14:48:08 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <I0JNrzns6q4kroyAUrklR25TtDu-NaMGivmDom9qvPg=.5a85ad97-a410-4e92-b509-b959420cd0ba@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Confirmed changes only re-order @param declarations.
 
Recommend @JoeWang-Java to review changes to java.xml since portions of that module are maintained in an upstream repository.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2392918255

From vklang at openjdk.org  Thu Oct 24 15:13:40 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Oct 2024 15:13:40 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview
Message-ID: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>

Make final adjustments to drop PreviewFeature and updating the @ since markers.

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

Commit messages:
 - Removing PreviewFeature from Gatherers
 - Updating @since to 24 for Gatherers

Changes: https://git.openjdk.org/jdk/pull/21686/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21686&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342707
  Stats: 35 lines in 24 files changed: 0 ins; 17 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/21686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21686/head:pull/21686

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

From abimpoudis at openjdk.org  Thu Oct 24 15:31:32 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Oct 2024 15:31:32 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs and
 mismatched local variables names
Message-ID: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>

After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.

`TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.

The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).

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

Commit messages:
 - 8342967: Lambda deduplication fails with non-metafactory BSMs and mismatched local variables names

Changes: https://git.openjdk.org/jdk/pull/21687/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21687&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342967
  Stats: 89 lines in 6 files changed: 63 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21687/head:pull/21687

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

From jlahoda at openjdk.org  Thu Oct 24 16:18:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 24 Oct 2024 16:18:09 GMT
Subject: RFR: 8340145: Problem with generic pattern matching results in
 internal compiler error
In-Reply-To: <Vixxx9wLxcb4eILMDugrBqF7jSKpI1kkkAelQNNXecE=.bbafec8b-b5ac-4d5b-832e-981362304550@github.com>
References: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>
 <Vixxx9wLxcb4eILMDugrBqF7jSKpI1kkkAelQNNXecE=.bbafec8b-b5ac-4d5b-832e-981362304550@github.com>
Message-ID: <xP0SsFbhFaXA6qf7HMXJ1JwUYWPaN6NxN7imjq7PxaE=.3188b0c4-8252-4f63-9e5a-3e1bda556c07@github.com>

On Mon, 21 Oct 2024 21:12:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> In the following code, when calculating recursively the covered binding patterns, the nested case assumed that the direct supertype of `T2` will always be represented by a `ClassSymbol`. This PR intervenes the erasure calculation.
>> 
>> 
>> static <T, T2 extends T> T unwrapOrElse(Option<T2> option, T defaultValue) {
>>   return switch (option) {
>>      case Option.Some(T2 value) -> value;
>>      case Option.None<T2> _ -> defaultValue;
>>   };
>> }
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 913:
> 
>> 911: 
>> 912:                     for (Type sup : types.directSupertypes(bpOne.type)) {
>> 913:                         ClassSymbol clazz = (ClassSymbol) types.erasure(sup).tsym;
> 
> general comment: I think that erasure should happen in the desugaring phase, we are already doing some erasure in Flow and all of it is related to patterns. I think that we should consider moving all these erasure to either TransTypes or TransPatterns

While I agree that erased type attributes int the AST should happen after `Flow`, I don't think that's what is happening here. The erased types here are used by the exhaustiveness machinery, which is specified in terms of erased type. The erased type produce here, however, shouldn't be recorded in the AST.

But, and the same time, I am not sure if the erasure is correct here. It `sup` is a type variable with multiple bounds, we'll get only the first bound. I think we need to check if that make a difference at this place, I was trying to look, but didn't find any (yet).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21606#discussion_r1815328118

From joehw at openjdk.org  Thu Oct 24 16:40:06 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 24 Oct 2024 16:40:06 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <uMoFOQDA3ikNwrePol8zee2hd4FO8lGqoeMFhVh70B4=.4407fe29-37bd-4a2c-9d51-0bfdb6cfb55b@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Thanks Iris for the reminder. Changes to java.xml look good.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2393208720

From liach at openjdk.org  Thu Oct 24 16:45:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 16:45:06 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview
In-Reply-To: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
Message-ID: <ITbJz-c7M0Ow0nU-Bf6MjNw785FwOsDRKewU1Aa4c-4=.88a52b99-7b8c-41b8-ad35-9c79b799e95e@github.com>

On Thu, 24 Oct 2024 15:09:00 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 79:

> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
> 78:         CLASSFILE_API,
> 79:         STREAM_GATHERERS,

Does bootcycle fail if this enum constant is removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21686#discussion_r1815375043

From liach at openjdk.org  Thu Oct 24 16:49:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 16:49:08 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names
In-Reply-To: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
Message-ID: <atMXyfhjo4esHBSW35dpgU5L44a2iKIQOqIG2T3tCUo=.c060f0d8-91c3-472e-8955-2c0cd3d45fb3@github.com>

On Thu, 24 Oct 2024 15:19:16 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
> 
> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
> 
> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 224:

> 222:         Symbol otherSymbol = that.sym;
> 223: 
> 224:         result &= scan(symbol, otherSymbol);

I think we want to short circuit here, and `&=` will evaluate `scan` even if `result` is already `false`.
Suggestion:

        if (result)
            result = scan(symbol, otherSymbol);

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 693:

> 691: 
> 692:         if (!tree.sym.owner.type.hasTag(TypeTag.METHOD)) {
> 693:             result &= tree.name == that.name;

Same short-circuiting remark.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1815380394
PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1815380946

From aivanov at openjdk.org  Thu Oct 24 17:26:47 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:26:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/Desktop.java line 713:

> 711:      * {@code Info.plist}.
> 712:      *
> 713:      * @param printFileHandler handler

Suggestion:

     * @param printFileHandler handler
     *

Can we add a blank line here? It's present in the methods above.

Although there are other places below where it's missing; so not worth worrying.

src/java.desktop/share/classes/java/awt/Font.java line 1612:

> 1610:      * obtained.  The {@code String} value of this property is then
> 1611:      * interpreted as a {@code Font} object according to the
> 1612:      * specification of {@code Font.decode(String)}

Suggestion:

     * specification of {@code Font.decode(String)}.

Period is missing.

src/java.desktop/share/classes/java/awt/Font.java line 1613:

> 1611:      * interpreted as a {@code Font} object according to the
> 1612:      * specification of {@code Font.decode(String)}
> 1613:      * If the specified property is not found then null is returned instead.

Suggestion:

     * If the specified property is not found, null is returned instead.

The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.

src/java.desktop/share/classes/java/awt/Font.java line 1780:

> 1778:      * <p>
> 1779:      * The property value should be one of the forms accepted by
> 1780:      * {@code Font.decode(String)}

Suggestion:

     * {@code Font.decode(String)}.

Period is missing.

src/java.desktop/share/classes/java/awt/Font.java line 1781:

> 1779:      * The property value should be one of the forms accepted by
> 1780:      * {@code Font.decode(String)}
> 1781:      * If the specified property is not found then the {@code font}

Suggestion:

     * If the specified property is not found, the {@code font}

src/java.desktop/share/classes/java/awt/MouseInfo.java line 68:

> 66:      * @throws SecurityException if a security manager exists and its
> 67:      *            {@code checkPermission} method doesn't allow the operation
> 68:      * @see       GraphicsConfiguration

Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional?

src/java.desktop/share/classes/java/beans/Expression.java line 1:

> 1: /*

Needs copyright year update.

src/java.desktop/share/classes/java/beans/PropertyEditorManager.java line 71:

> 69:      *
> 70:      * @param targetType   the class object of the type to be edited
> 71:      * @param editorClass  the class object of the editor classs

Suggestion:

     * @param editorClass  the class object of the editor class

Typo with an extra ?s?. The line should remain unchanged.

src/java.desktop/share/classes/javax/swing/JTable.java line 6343:

> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
> 6342:      *                           returns <code>true</code>
> 6343:      *          method disallows this thread from creating a print job request

Suggestion:


One more line to remove here.

src/java.desktop/share/classes/javax/swing/WindowConstants.java line 1:

> 1: /*

Needs updating the copyright year.

test/jdk/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:

> 26:   @key headful
> 27:   @bug       6785058
> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.

Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java line 1:

> 1: /*

Copyright year needs updating.

test/jdk/java/beans/Introspector/7084904/Test7084904.java line 31:

> 29:  * @library ..
> 30:  * @run main Test7084904
> 31:  * @author Sergey Malenkov

The test below `Test4683761.java` removes the `@author` tag. Should it be removed here?

test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java line 1:

> 1: /*

Copyright years need updating.

test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java line 29:

> 27:  * @test
> 28:  * @bug 8060027
> 29:  * @run main/othervm ReferenceToNonStaticField

Other tests in the set removed `/othervm`. Is it left intentionally?

test/jdk/java/beans/XMLEncoder/Test4631471.java line 28:

> 26:  * @bug 4631471 6972468
> 27:  * @summary Tests DefaultTreeModel encoding
> 28:  * @run main/othervm Test4631471

Other tests in the set removed `/othervm`. Is it left intentionally?

Looks like this question applies to all tests in `XMLEncoder/` directory.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2392963469
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815168399
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815180719
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815184053
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815185648
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815187240
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815203856
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815290263
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815294333
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815320927
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815330072
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815362826
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815404801
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815414445
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815434082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815439684
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815440669

From vromero at openjdk.org  Thu Oct 24 17:28:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 17:28:17 GMT
Subject: Integrated: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects
In-Reply-To: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
Message-ID: <VMW7jdPTe534_ydhCazjoCnb0D1RGjeUTVNKf6fE07k=.3ff4e412-4aa8-441a-ba46-42f1aa3fd431@github.com>

On Tue, 22 Oct 2024 23:09:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
> 
> TIA

This pull request has now been integrated.

Changeset: d1540e2a
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1540e2a49c7a41eb771fc9896c367187d070dec
Stats:     127 lines in 4 files changed: 92 ins; 16 del; 19 mod

8342090: Infer::IncorporationBinaryOp::equals can produce side-effects
8288590: javac failure: incompatible types: cannot infer type arguments due to Object.hashCode collision

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore

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

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

From aivanov at openjdk.org  Thu Oct 24 17:30:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:30:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
Message-ID: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>

On Wed, 23 Oct 2024 02:56:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Agreed. This is not a "clean up / update tests" task.
>> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
>> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.
>
> I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
> In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

Did we agree on that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815457993

From honkar at openjdk.org  Thu Oct 24 18:01:47 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:01:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>

On Thu, 24 Oct 2024 17:16:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 8060027
>> 29:  * @run main/othervm ReferenceToNonStaticField
> 
> Other tests in the set removed `/othervm`. Is it left intentionally?

@aivanov-jdk 
It was missed when -Djava.security.manager=allow was removed. 
Out of curiosity: does it affect the performance of CI testing if tests are run in `/othervm` mode when it is not needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815499279

From honkar at openjdk.org  Thu Oct 24 18:12:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:12:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>

On Thu, 24 Oct 2024 14:55:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
> 
>> 711:      * {@code Info.plist}.
>> 712:      *
>> 713:      * @param printFileHandler handler
> 
> Suggestion:
> 
>      * @param printFileHandler handler
>      *
> 
> Can we add a blank line here? It's present in the methods above.
> 
> Although there are other places below where it's missing; so not worth worrying.

@seanjmullan Can you please advice on some of these src file javadoc related clean-up review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815510916

From gdub at openjdk.org  Thu Oct 24 18:17:14 2024
From: gdub at openjdk.org (Gilles Duboscq)
Date: Thu, 24 Oct 2024 18:17:14 GMT
Subject: RFR: 8342090: Infer::IncorporationBinaryOp::equals can produce
 side-effects [v8]
In-Reply-To: <GtkwYIWUmNG5gDr12ZR0a1OBLopFVjhH0zPfCoeJRUk=.5d667efa-e713-4a18-a1c1-046d39b2a8f1@github.com>
References: <minlcQFxAus5H0n4qseKKB67tWhdIoh8XnQm82XL0ag=.54615c13-352c-48b0-965d-50f2f4e6caba@github.com>
 <GtkwYIWUmNG5gDr12ZR0a1OBLopFVjhH0zPfCoeJRUk=.5d667efa-e713-4a18-a1c1-046d39b2a8f1@github.com>
Message-ID: <kRERM12YrUvTdA_ed5oF-YyLHJg5rS1cLpNxrjHZJ4I=.b86e0481-a5ff-48b4-bf58-f22db0d2b572@github.com>

On Thu, 24 Oct 2024 14:13:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Type inference uses a cache to store incorporation operations already done. This way we can avoid redoing operations that once done won't produce any change. This can reduce the compilation time when the number of inference variables involved is not trivial. The elements in the cache are implemented with class `com.sun.tools.javac.comp.Infer::IncorporationBinaryOp` the problem here is that the equals method of this class can produce side effects, implying that after a comparison the compared objects can mutate. This patch is fixing this issue,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Thank you for looking into this!

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

PR Comment: https://git.openjdk.org/jdk/pull/21651#issuecomment-2436049529

From rriggs at openjdk.org  Thu Oct 24 18:30:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:30:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/java.base/share/classes/java/io/FilePermission.java line 71:

> 69:  *
> 70:  * @apiNote
> 71:  * This permission cannot be used for controlling access to resources anymore

The word "anymore" is unnecessary.

src/java.base/share/classes/java/io/SerializablePermission.java line 40:

> 38:  *
> 39:  * @apiNote
> 40:  * This permission cannot be used for controlling access to resources anymore

Unnecessary "anymore"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811333130
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811338244

From rriggs at openjdk.org  Thu Oct 24 18:37:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:37:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
 <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
Message-ID: <WP5Y8HfjmKGYOHZjnGID9Uj3_RcqBwlETVZqhbyLuoY=.b97320ba-8fa4-4ee6-bbeb-4fd9178bc3e8@github.com>

On Wed, 23 Oct 2024 21:54:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
>> 
>>> 239:         Properties props = System.getProperties();
>>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>>> 241:         System.setSecurityManager(new SecurityMan());
>> 
>> I assume SecurityMan should be removed too.
>
> Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

Fix to ExecCommand pushed to the sandbox.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815540092

From vromero at openjdk.org  Thu Oct 24 18:47:07 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 18:47:07 GMT
Subject: RFR: 8340145: Problem with generic pattern matching results in
 internal compiler error
In-Reply-To: <xP0SsFbhFaXA6qf7HMXJ1JwUYWPaN6NxN7imjq7PxaE=.3188b0c4-8252-4f63-9e5a-3e1bda556c07@github.com>
References: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>
 <Vixxx9wLxcb4eILMDugrBqF7jSKpI1kkkAelQNNXecE=.bbafec8b-b5ac-4d5b-832e-981362304550@github.com>
 <xP0SsFbhFaXA6qf7HMXJ1JwUYWPaN6NxN7imjq7PxaE=.3188b0c4-8252-4f63-9e5a-3e1bda556c07@github.com>
Message-ID: <7y7UGDiQ_ULYYtjPQNlorgsLbisyfbYiTKA5FdXt0DI=.6406adf0-8d41-4ac0-9b75-323668207a38@github.com>

On Thu, 24 Oct 2024 16:15:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 913:
>> 
>>> 911: 
>>> 912:                     for (Type sup : types.directSupertypes(bpOne.type)) {
>>> 913:                         ClassSymbol clazz = (ClassSymbol) types.erasure(sup).tsym;
>> 
>> general comment: I think that erasure should happen in the desugaring phase, we are already doing some erasure in Flow and all of it is related to patterns. I think that we should consider moving all these erasure to either TransTypes or TransPatterns
>
> While I agree that erased type attributes int the AST should happen after `Flow`, I don't think that's what is happening here. The erased types here are used by the exhaustiveness machinery, which is specified in terms of erased type. The erased type produce here, however, shouldn't be recorded in the AST.
> 
> But, and the same time, I am not sure if the erasure is correct here. It `sup` is a type variable with multiple bounds, we'll get only the first bound. I think we need to check if that make a difference at this place, I was trying to look, but didn't find any (yet).

sure I agree my comment about erasure is a meta-comment, it would be desirable to do all the erasure after flow, unless it is not possible of course

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21606#discussion_r1815550590

From duke at openjdk.org  Thu Oct 24 19:16:41 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Thu, 24 Oct 2024 19:16:41 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
Message-ID: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>

This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.

Current behaviour of `javap` differs with and without `-verbose` in the following way:
**Command**: `javap -c -XDdetails:stackMaps A.class`

Without `-verbose`


...
  public void a();
    Code:
       0: iconst_0
       1: istore_1
    StackMap locals:  this int
    StackMap stack:
...


With `-verbose`


...
  public void a();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=1
         0: iconst_0
         1: istore_1
      StackMap locals:  this int
      StackMap stack:
...


With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.

In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.

---

Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.


void writeSimple(CodeAttribute attr) {
        println("Code:");
        indent(+1);
        writeInstrs(attr);
        writeExceptionTable(attr);
        indent(-1);
    }


---

Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

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

Commit messages:
 - 8034066: fix indentation in javap Code section details

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

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

From jvernee at openjdk.org  Thu Oct 24 19:16:41 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 24 Oct 2024 19:16:41 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
Message-ID: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>

On Thu, 24 Oct 2024 14:57:19 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
> 
> Current behaviour of `javap` differs with and without `-verbose` in the following way:
> **Command**: `javap -c -XDdetails:stackMaps A.class`
> 
> Without `-verbose`
> 
> 
> ...
>   public void a();
>     Code:
>        0: iconst_0
>        1: istore_1
>     StackMap locals:  this int
>     StackMap stack:
> ...
> 
> 
> With `-verbose`
> 
> 
> ...
>   public void a();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          1: istore_1
>       StackMap locals:  this int
>       StackMap stack:
> ...
> 
> 
> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
> 
> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
> 
> ---
> 
> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
> 
> 
> void writeSimple(CodeAttribute attr) {
>         println("Code:");
>         indent(+1);
>         writeInstrs(attr);
>         writeExceptionTable(attr);
>         indent(-1);
>     }
> 
> 
> ---
> 
> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

I think I prefer your idea of keeping the code inside `CodeWriter`.

Maybe have a `write` and a `writeVerbose`, and have a private method with a `boolean` param that controls printing of extra info?

test/langtools/tools/javap/8034066/T8034066.java line 37:

> 35: import java.util.regex.Pattern;
> 36: 
> 37: public class T8034066 {

Please don't continue the old practice of naming tests after their bug ID. It obfuscates which test class does what (both in the source code and in the test logs). Suggestion for name: `TestStackMapDetailsIndent`

test/langtools/tools/javap/8034066/T8034066.java line 44:

> 42:     public void run() throws IOException {
> 43:         String output = javap();
> 44: 

Could you put a comment here that roughly shows what the expected output looks like? I think it would help readers understand what the following three lines are looking for.

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

PR Review: https://git.openjdk.org/jdk/pull/21685#pullrequestreview-2393197370
PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815355517
PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815380775

From rriggs at openjdk.org  Thu Oct 24 19:23:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:23:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <u1-uOqM_jiV8EcaC7dsfCwCQiUjiQVcgHL2XfvTbXBg=.33981b17-c4df-435d-87fe-b552e2fabbb8@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java.io... changes in classes and tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2436170029

From darcy at openjdk.org  Thu Oct 24 19:36:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 24 Oct 2024 19:36:05 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <C7bEaXoK5m7U1dx10KUM-56dwGBKOh0-x_vtV3T2dpg=.d6c51bc6-0a33-4568-8188-78de35125012@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Changes in java.compiler look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2393555695

From rriggs at openjdk.org  Thu Oct 24 19:43:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:43:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed rmi classes and tests
Reviewed ProcessBuilder, ProcessHandler, and Runtime.exec classes and tests

src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java line 342:

> 340:         /*
> 341:          * There is no security manager, so disable access to RMI class
> 342:          * loaders and use the would-de parent instead.

Fix typo "would-de" -> "would-be".

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2393555484
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815601635

From vklang at openjdk.org  Thu Oct 24 19:47:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Oct 2024 19:47:05 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview
In-Reply-To: <ITbJz-c7M0Ow0nU-Bf6MjNw785FwOsDRKewU1Aa4c-4=.88a52b99-7b8c-41b8-ad35-9c79b799e95e@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <ITbJz-c7M0Ow0nU-Bf6MjNw785FwOsDRKewU1Aa4c-4=.88a52b99-7b8c-41b8-ad35-9c79b799e95e@github.com>
Message-ID: <kbhGBwR9Ne-Hab7YLaQH1lhpK5JQGo-dWU71qBBwPM8=.b2f9ed82-3a61-445f-a37e-1315f50b9eb3@github.com>

On Thu, 24 Oct 2024 16:42:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 79:
> 
>> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
>> 78:         CLASSFILE_API,
>> 79:         STREAM_GATHERERS,
> 
> Does bootcycle fail if this enum constant is removed?

Yep :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21686#discussion_r1815612773

From vromero at openjdk.org  Thu Oct 24 19:52:11 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 19:52:11 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v17]
In-Reply-To: <783S4wS6h1j_ejoU_dOx9WmjDgYW8hWEltgn6nLH9wo=.c3deb952-207a-4212-8dff-2c859e41076f@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <783S4wS6h1j_ejoU_dOx9WmjDgYW8hWEltgn6nLH9wo=.c3deb952-207a-4212-8dff-2c859e41076f@github.com>
Message-ID: <AOGnffEMgRvP2q9Jo5b6MNIiT0njag6ozrp1_eAhJUM=.b4b1f991-be55-41de-9156-e330e9ccaec3@github.com>

On Sat, 19 Oct 2024 11:57:08 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose 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 20 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into selaed-permits-allow-private-members
>  - remove logging error
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - Revert bugid change
>  - Change bugid
>  - report feature error
>  - add feature
>  - make method names shorter
>  - fix test failures 3
>  - fix test failures 2
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/e8b21c9c...38dd1b5a

minor suggestion, other than that, looks good, thanks for fixing this

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20718#pullrequestreview-2393577301

From vromero at openjdk.org  Thu Oct 24 19:52:13 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 19:52:13 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v15]
In-Reply-To: <2KBOqH9kYsEKgcaLY27zPHM5m-qgUCv31Zgb6ND0dNk=.4102eb3e-3d54-456c-b815-6d7c70a20f45@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <yPBvDN_ySzNpKbHcRI1_ltcSxYzAIIZPLDbuIohhtQI=.90bd7c70-8b2c-4a3d-b92b-d20d848ae3a6@github.com>
 <sDVHN0akoLGLARDbKdhuWJdigVV-TLPr5qx6m5wiMJ8=.ac9b6997-633c-4d29-9cbb-ea7c095e276e@github.com>
 <2KBOqH9kYsEKgcaLY27zPHM5m-qgUCv31Zgb6ND0dNk=.4102eb3e-3d54-456c-b815-6d7c70a20f45@github.com>
Message-ID: <OoQo81LyQheN3kZdHNbeS4Aip1s_8RLmE2s2Qre8o60=.71eb53f2-f078-47bb-a76c-15a8877bba71@github.com>

On Fri, 18 Oct 2024 21:48:09 GMT, Evemose <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 475:
>> 
>>> 473:             }
>>> 474:         }
>>> 475:         return false;
>> 
>> shouldn't we return true here?
>
> No, method name is privateMemberInPermitsClause if allowed, and return is:
> 1. If condition in if is met, then return whether feature is enabled or not (value of field allowPrivateMembersInPermitsClause)
> 2. If condition is not met, then this is NOT privateMemberInPermitsClause, so return false

what about:

private boolean privateMemberInPermitsClauseIfAllowed(Env<AttrContext> env, Symbol sym) {
    return allowPrivateMembersInPermitsClause &&
           env.info.isPermitsClause &&
           ((JCClassDecl) env.tree).sym.outermostClass() == sym.owner.outermostClass();
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1815614701

From vromero at openjdk.org  Thu Oct 24 19:58:11 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 19:58:11 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v17]
In-Reply-To: <783S4wS6h1j_ejoU_dOx9WmjDgYW8hWEltgn6nLH9wo=.c3deb952-207a-4212-8dff-2c859e41076f@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <783S4wS6h1j_ejoU_dOx9WmjDgYW8hWEltgn6nLH9wo=.c3deb952-207a-4212-8dff-2c859e41076f@github.com>
Message-ID: <S_nAyYElWcJqgdiixDGkelfgsz0K9dPk4nZZOv6M9Gc=.28a3f7dc-3fed-4e87-a899-83b733a79b75@github.com>

On Sat, 19 Oct 2024 11:57:08 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose 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 20 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into selaed-permits-allow-private-members
>  - remove logging error
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - Revert bugid change
>  - Change bugid
>  - report feature error
>  - add feature
>  - make method names shorter
>  - fix test failures 3
>  - fix test failures 2
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/a673a08c...38dd1b5a

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3250:

> 3248:     module imports
> 3249: 
> 3250: compiler.misc.feature.private.members.in.permits.clause=\

this one is not used now, can be removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1815623686

From aivanov at openjdk.org  Thu Oct 24 20:26:44 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:26:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
Message-ID: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>

On Thu, 24 Oct 2024 17:58:55 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> It was missed when `-Djava.security.manager=allow` was removed.

It wasn't intentional then, was it?

> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?

I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.

Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.

https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49

It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815652996

From aivanov at openjdk.org  Thu Oct 24 20:30:39 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:30:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
Message-ID: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>

On Thu, 24 Oct 2024 18:09:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
>> 
>>> 711:      * {@code Info.plist}.
>>> 712:      *
>>> 713:      * @param printFileHandler handler
>> 
>> Suggestion:
>> 
>>      * @param printFileHandler handler
>>      *
>> 
>> ~~Can we add a blank line here? It's present in the methods above.~~
>> 
>> Although there are other places below where it's missing; _so not worth worrying_.
>
> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

@honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.

If it's worth taking care of, we may submit another bug to address it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815657461

From mullan at openjdk.org  Thu Oct 24 21:00:39 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 21:00:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
 <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>
Message-ID: <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>

On Thu, 24 Oct 2024 20:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.
>
> @honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.
> 
> If it's worth taking care of, we may submit another bug to address it later.

This does not need to be handled in this PR. In the majority of changes, we have really tried hard to avoid making unrelated changes, but sometimes a few snuck in, like moving package imports or perhaps fixing a typo here and there that was not specific to JEP 486. My opinion is that unless it is something that _really_ should be done as part of a more general technical debt or code cleanup exercise, then it is ok to let a few of these in and they don't have to be reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815686941

From honkar at openjdk.org  Thu Oct 24 21:10:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 21:10:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
Message-ID: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>

On Thu, 24 Oct 2024 20:23:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk 
>> It was missed when -Djava.security.manager=allow was removed. 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in `/othervm` mode when it is not needed?
>
>> It was missed when `-Djava.security.manager=allow` was removed.
> 
> It wasn't intentional then, was it?
> 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
> 
> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
> 
> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
> 
> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
> 
> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

@aivanov-jdk 
Right, it wasn't intentionally but missed when removing `-Djava.security.manager=allow`.

> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.

Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good to remove, I can probably do a replace-all on beans/XMLEncoder/ folder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815694898

From vromero at openjdk.org  Thu Oct 24 21:11:14 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Oct 2024 21:11:14 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v17]
In-Reply-To: <783S4wS6h1j_ejoU_dOx9WmjDgYW8hWEltgn6nLH9wo=.c3deb952-207a-4212-8dff-2c859e41076f@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <783S4wS6h1j_ejoU_dOx9WmjDgYW8hWEltgn6nLH9wo=.c3deb952-207a-4212-8dff-2c859e41076f@github.com>
Message-ID: <2j1RDv2stbo9GnfaDmDeJnCxmyYUuwfuEoT8oxYSk70=.33282a76-aff5-4280-9c93-e37069556c60@github.com>

On Sat, 19 Oct 2024 11:57:08 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose 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 20 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into selaed-permits-allow-private-members
>  - remove logging error
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - Revert bugid change
>  - Change bugid
>  - report feature error
>  - add feature
>  - make method names shorter
>  - fix test failures 3
>  - fix test failures 2
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/f514b97c...38dd1b5a

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 90:

> 88:             """
> 89:             public sealed class T permits S.A {
> 90:                 private static final class A {}

I don't see the need for class T.A in this test case. I think that you can get the same effect with:


class S {
    private static final class A {}
}

sealed class T permits S.A {
} 

having both classes in the same file, at least the error message is the same

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 159:

> 157:      */
> 158:     @Test
> 159:     public void referencePrivateClassFails() throws Exception {

this one is very similar to: `otherTopLevelPrivateClassFails` I think you should keep only one of them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1815692389
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1815695878

From abimpoudis at openjdk.org  Thu Oct 24 22:14:40 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Oct 2024 22:14:40 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
Message-ID: <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>

> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
> 
> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
> 
> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21687/files
  - new: https://git.openjdk.org/jdk/pull/21687/files/e7a6c041..4b0d560b

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

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

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

From abimpoudis at openjdk.org  Thu Oct 24 22:14:40 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 24 Oct 2024 22:14:40 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <atMXyfhjo4esHBSW35dpgU5L44a2iKIQOqIG2T3tCUo=.c060f0d8-91c3-472e-8955-2c0cd3d45fb3@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <atMXyfhjo4esHBSW35dpgU5L44a2iKIQOqIG2T3tCUo=.c060f0d8-91c3-472e-8955-2c0cd3d45fb3@github.com>
Message-ID: <uDrnG4r6WplZFk6NmtiTIz23tQ3Jr181a9jaUcVRkjM=.4019ca1f-4400-4884-9259-b1fdc20f4680@github.com>

On Thu, 24 Oct 2024 16:46:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 224:
> 
>> 222:         Symbol otherSymbol = that.sym;
>> 223: 
>> 224:         result &= scan(symbol, otherSymbol);
> 
> I think we want to short circuit here, and `&=` will evaluate `scan` even if `result` is already `false`.
> Suggestion:
> 
>         if (result)
>             result = scan(symbol, otherSymbol);

Thanks! Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1815760533

From honkar at openjdk.org  Thu Oct 24 22:27:40 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:27:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <gIwlmNzUQN7CM7jX7Tq5CQkS1Ay_fWsPrZABjIRdHeo=.ba7f210c-8a6a-4e47-9c00-830476aa158b@github.com>

On Thu, 24 Oct 2024 16:35:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:
> 
>> 26:   @key headful
>> 27:   @bug       6785058
>> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.
> 
> Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

Looks like the test was created for SM specific issue - [JDK-6785058](https://bugs.openjdk.org/browse/JDK-6785058). I have deleted the test here https://github.com/openjdk/jdk-sandbox/commit/de0a0f67ef207e1d217c42c312a4378f9f7fa833

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815770344

From honkar at openjdk.org  Thu Oct 24 22:31:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:31:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <C6AQiFYXzD9ov3ZvyWThfp_FUec5f-cLLOyPkqLBeeE=.f3c888ca-d459-44ad-9c18-2329869ffa18@github.com>

On Thu, 24 Oct 2024 16:11:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 6343:
> 
>> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
>> 6342:      *                           returns <code>true</code>
>> 6343:      *          method disallows this thread from creating a print job request
> 
> Suggestion:
> 
> 
> One more line to remove here.

Relevant (w.r.t jep486) javadocs changes have been updated here: https://github.com/openjdk/jdk-sandbox/commit/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815773023

From henryjen at openjdk.org  Fri Oct 25 01:43:52 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 25 Oct 2024 01:43:52 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
Message-ID: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>

Check output for including values rather than exact match.
Also include the manpage change  and revert the problem list.

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

Commit messages:
 - 8342930: New tests from JDK-8335912 are failing

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

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

From liach at openjdk.org  Fri Oct 25 02:58:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 02:58:04 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
Message-ID: <hx4_aWAXVQRoL6rzjVRVPCT_IN6EgKQ10a8TSsLNojw=.f92a2dfd-8bab-4bb9-8d99-bdb7d27ae25c@github.com>

On Thu, 24 Oct 2024 16:31:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> test/langtools/tools/javap/8034066/T8034066.java line 37:
> 
>> 35: import java.util.regex.Pattern;
>> 36: 
>> 37: public class T8034066 {
> 
> Please don't continue the old practice of naming tests after their bug ID. It obfuscates which test class does what (both in the source code and in the test logs). Suggestion for name: `TestStackMapDetailsIndent`

How about `CodeWriterIndentTest`? We prefer to use prefix modifiers, and this tests the indent for general code writer output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815928810

From liach at openjdk.org  Fri Oct 25 03:04:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 03:04:06 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
Message-ID: <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>

On Thu, 24 Oct 2024 14:57:19 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
> 
> Current behaviour of `javap` differs with and without `-verbose` in the following way:
> **Command**: `javap -c -XDdetails:stackMaps A.class`
> 
> Without `-verbose`
> 
> 
> ...
>   public void a();
>     Code:
>        0: iconst_0
>        1: istore_1
>     StackMap locals:  this int
>     StackMap stack:
> ...
> 
> 
> With `-verbose`
> 
> 
> ...
>   public void a();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          1: istore_1
>       StackMap locals:  this int
>       StackMap stack:
> ...
> 
> 
> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
> 
> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
> 
> ---
> 
> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
> 
> 
> void writeSimple(CodeAttribute attr) {
>         println("Code:");
>         indent(+1);
>         writeInstrs(attr);
>         writeExceptionTable(attr);
>         indent(-1);
>     }
> 
> 
> ---
> 
> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

test/langtools/tools/javap/8034066/EmptyLoop.jcod line 26:

> 24:  /*
> 25:  * Original source:
> 26:  * public class EmptyLoop {

To reduce test file noise, I recommend adding this as a package-private class to the end of your test file (so not a nested class) after it is renamed, like:


class EmptyLoop {
    public void emptyLoop() {
        for (int i = 0; i < 10; i++) {
        }
    }
}


After that, once your test class is compiled, the `EmptyLoop.class` is available in `test.classes` property directory, so you can remove this jcod and all code that converts the jcod to class.

You can see UndefinedAccessFlagTest for how we use such tricks.

Note: since you will only have one test class, you no longer need a dedicated directory; you can just place our `CodeIndentTest.java` in the root javap directory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815931722

From liach at openjdk.org  Fri Oct 25 03:09:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 03:09:12 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
Message-ID: <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>

On Fri, 25 Oct 2024 03:01:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> test/langtools/tools/javap/8034066/EmptyLoop.jcod line 26:
> 
>> 24:  /*
>> 25:  * Original source:
>> 26:  * public class EmptyLoop {
> 
> To reduce test file noise, I recommend adding this as a package-private class to the end of your test file (so not a nested class) after it is renamed, like:
> 
> 
> class EmptyLoop {
>     public void emptyLoop() {
>         for (int i = 0; i < 10; i++) {
>         }
>     }
> }
> 
> 
> After that, once your test class is compiled, the `EmptyLoop.class` is available in `test.classes` property directory, so you can remove this jcod and all code that converts the jcod to class.
> 
> You can see UndefinedAccessFlagTest for how we use such tricks.
> 
> Note: since you will only have one test class, you no longer need a dedicated directory; you can just place our `CodeIndentTest.java` in the root javap directory.

Another example of such a trick is available at [test/jdk/jdk/classfile/ClassBuildingTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/classfile/ClassBuildingTest.java)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815933828

From jpai at openjdk.org  Fri Oct 25 04:38:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 04:38:06 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
Message-ID: <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>

On Fri, 25 Oct 2024 01:38:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Check output for including values rather than exact match.
> Also include the manpage change  and revert the problem list.

Marked as reviewed by jpai (Reviewer).

test/jdk/tools/jar/MultipleManifestTest.java line 203:

> 201: 
> 202:     private void assertOutputContains(String expected) {
> 203:         Assertions.assertTrue(baos.toString().contains(expected));

The linked JBS issue notes that the test was failing because of the additional (new) log messages from the jar tool itself. So I think the logs will be deterministic (since they aren't being generated by something else other than the jart tool). Using `contains()` thus looks fine to me.

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

PR Review: https://git.openjdk.org/jdk/pull/21697#pullrequestreview-2394147934
PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1815980769

From jpai at openjdk.org  Fri Oct 25 04:38:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 04:38:07 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
Message-ID: <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>

On Fri, 25 Oct 2024 04:34:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Check output for including values rather than exact match.
>> Also include the manpage change  and revert the problem list.
>
> test/jdk/tools/jar/MultipleManifestTest.java line 203:
> 
>> 201: 
>> 202:     private void assertOutputContains(String expected) {
>> 203:         Assertions.assertTrue(baos.toString().contains(expected));
> 
> The linked JBS issue notes that the test was failing because of the additional (new) log messages from the jar tool itself. So I think the logs will be deterministic (since they aren't being generated by something else other than the jart tool). Using `contains()` thus looks fine to me.

Do you think we should print out the actual and expected, when they don't match? It might make it easier to debug any unexpected failures in future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1815981958

From psadhukhan at openjdk.org  Fri Oct 25 04:57:39 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 04:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
 <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
Message-ID: <3cbgckSg8DmaAkUalu54f2S9UMmrVrgo7SNQ1Eb1PvM=.a2830527-7ffc-48d2-8191-85c861f30b6f@github.com>

On Thu, 24 Oct 2024 17:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
> 
> Did we agree on that?

Atleast client-dev team did..
See this initial note https://github.com/openjdk/jdk/pull/18414/files#r1534605049
And also in our internal meeting, Phil mentioned if IDE is having issue with this tag order (like collapsing) it's IDE's problem and they should be rectified and we should not change our product code for that..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815994453

From darcy at openjdk.org  Fri Oct 25 06:12:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 25 Oct 2024 06:12:38 GMT
Subject: RFR: 8342934: TYPE_USE annotations printed with error causing ", " in
 toString output
Message-ID: <PQ9zRKIH7UmIhzkXJSC9oXIAtmxhcO3dvyDOwvGAXHw=.b424d6d6-fa4e-4c8a-9f42-870b83a842c8@github.com>

Use space instead of comma as a delimiter when building the string of type annotations.

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

Commit messages:
 - JDK-8342934: TYPE_USE annotations printed with error causing "," in toString output

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

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

From psadhukhan at openjdk.org  Fri Oct 25 06:43:42 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 06:43:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <8Oq38NBheXvpvw7sKy_5vSHd7o5r2rJmM8lQToaXmDc=.d8488397-1c79-446b-95c9-9b7a43d4b308@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed jdk javax/print and javax/swing..Looks good..

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437002459

From hannesw at openjdk.org  Fri Oct 25 07:11:18 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 25 Oct 2024 07:11:18 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <PgAAUiIwM4y3ghPK2qfvZ8PECbU_Py3VGRyOLX4YUsM=.ede5c00f-1c52-44fe-9de4-cc1650ebb506@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2437054155

From hannesw at openjdk.org  Fri Oct 25 07:11:19 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 25 Oct 2024 07:11:19 GMT
Subject: Integrated: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <r2DQm4YM057gNfMLILLJZJswLeOxQagxBqyFAGNMU7g=.de394ac2-5105-4aea-b153-59f519148dd3@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

This pull request has now been integrated.

Changeset: fd5ff054
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd5ff0547ced6733ae05f1428664062615408dc9
Stats:     144 lines in 28 files changed: 58 ins; 58 del; 28 mod

8342827: Fix order of @param tags in other modules

Reviewed-by: jpai, iris, joehw, darcy, dfuchs

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

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

From duke at openjdk.org  Fri Oct 25 08:02:06 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 08:02:06 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
 <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>
Message-ID: <BoqI7hVgo3HwsqOdMv5UBwuqFUzh1tecjSWLAELg_Sk=.78ec1b80-55c1-4ce3-884e-45f5ed90e445@github.com>

On Fri, 25 Oct 2024 03:06:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javap/8034066/EmptyLoop.jcod line 26:
>> 
>>> 24:  /*
>>> 25:  * Original source:
>>> 26:  * public class EmptyLoop {
>> 
>> To reduce test file noise, I recommend adding this as a package-private class to the end of your test file (so not a nested class) after it is renamed, like:
>> 
>> 
>> class EmptyLoop {
>>     public void emptyLoop() {
>>         for (int i = 0; i < 10; i++) {
>>         }
>>     }
>> }
>> 
>> 
>> After that, once your test class is compiled, the `EmptyLoop.class` is available in `test.classes` property directory, so you can remove this jcod and all code that converts the jcod to class.
>> 
>> You can see UndefinedAccessFlagTest for how we use such tricks.
>> 
>> Note: since you will only have one test class, you no longer need a dedicated directory; you can just place our `CodeIndentTest.java` in the root javap directory.
>
> Another example of such a trick is available at [test/jdk/jdk/classfile/ClassBuildingTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/classfile/ClassBuildingTest.java)

I initially had something like this, but was not sure if the generated classfile could differ between jdk versions/implementations. I assume this is not a valid concern for such a simple example?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816186616

From duke at openjdk.org  Fri Oct 25 08:06:11 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 08:06:11 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <hx4_aWAXVQRoL6rzjVRVPCT_IN6EgKQ10a8TSsLNojw=.f92a2dfd-8bab-4bb9-8d99-bdb7d27ae25c@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
 <hx4_aWAXVQRoL6rzjVRVPCT_IN6EgKQ10a8TSsLNojw=.f92a2dfd-8bab-4bb9-8d99-bdb7d27ae25c@github.com>
Message-ID: <N2ASB-26v4AcQBHcXV8s3-SZ1x3tTqcxbyokA5C5usA=.e0f27ba1-58a4-4949-9e97-df1f0f185b88@github.com>

On Fri, 25 Oct 2024 02:55:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javap/8034066/T8034066.java line 37:
>> 
>>> 35: import java.util.regex.Pattern;
>>> 36: 
>>> 37: public class T8034066 {
>> 
>> Please don't continue the old practice of naming tests after their bug ID. It obfuscates which test class does what (both in the source code and in the test logs). Suggestion for name: `TestStackMapDetailsIndent`
>
> How about `CodeIndentTest`? We prefer to use prefix modifiers, and this tests the indent for general code writer output.

I would propose `ClassWriterCodeIndentTest`. Although a little longer, it makes clear we are testing the Path `ClassWriter->CoderWriter` and not the similar `AttributeWriter->CodeWriter` control flow. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816192328

From duke at openjdk.org  Fri Oct 25 09:28:53 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 09:28:53 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
Message-ID: <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>

> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
> 
> Current behaviour of `javap` differs with and without `-verbose` in the following way:
> **Command**: `javap -c -XDdetails:stackMaps A.class`
> 
> Without `-verbose`
> 
> 
> ...
>   public void a();
>     Code:
>        0: iconst_0
>        1: istore_1
>     StackMap locals:  this int
>     StackMap stack:
> ...
> 
> 
> With `-verbose`
> 
> 
> ...
>   public void a();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          1: istore_1
>       StackMap locals:  this int
>       StackMap stack:
> ...
> 
> 
> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
> 
> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
> 
> ---
> 
> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
> 
> 
> void writeSimple(CodeAttribute attr) {
>         println("Code:");
>         indent(+1);
>         writeInstrs(attr);
>         writeExceptionTable(attr);
>         indent(-1);
>     }
> 
> 
> ---
> 
> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:

 - adress feedback in implementation
 - address feedback in tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21685/files
  - new: https://git.openjdk.org/jdk/pull/21685/files/ac915325..bd6372ce

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

  Stats: 382 lines in 5 files changed: 127 ins; 249 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21685/head:pull/21685

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

From duke at openjdk.org  Fri Oct 25 09:28:53 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 09:28:53 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <BoqI7hVgo3HwsqOdMv5UBwuqFUzh1tecjSWLAELg_Sk=.78ec1b80-55c1-4ce3-884e-45f5ed90e445@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
 <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>
 <BoqI7hVgo3HwsqOdMv5UBwuqFUzh1tecjSWLAELg_Sk=.78ec1b80-55c1-4ce3-884e-45f5ed90e445@github.com>
Message-ID: <zCVR1T7JQzL7IPgqMhUTk-5EnIovJBA9_0uxN9G6CW4=.041dbfc9-b9d2-48b7-a2d1-7df867d6504b@github.com>

On Fri, 25 Oct 2024 07:59:29 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Another example of such a trick is available at [test/jdk/jdk/classfile/ClassBuildingTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/classfile/ClassBuildingTest.java)
>
> I initially had something like this, but was not sure if the generated classfile could differ between jdk versions/implementations. I assume this is not a valid concern for such a simple example?

Have adjusted the implementation and moved to single source file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816334918

From duke at openjdk.org  Fri Oct 25 09:28:53 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 09:28:53 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
Message-ID: <pHXMQYbAvZ0mHXpa_gWqQ7fYUqEXlEi_TgUfMt0DXGo=.e8d9273a-66cc-4d45-9d9d-a3c7bfa8452d@github.com>

On Thu, 24 Oct 2024 16:46:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - adress feedback in implementation
>>  - address feedback in tests
>
> test/langtools/tools/javap/8034066/T8034066.java line 44:
> 
>> 42:     public void run() throws IOException {
>> 43:         String output = javap();
>> 44: 
> 
> Could you put a comment here that roughly shows what the expected output looks like? I think it would help readers understand what the following three lines are looking for.

Have added a partial snippet of the relevant part of the output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816333032

From henryjen at openjdk.org  Fri Oct 25 09:39:07 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 25 Oct 2024 09:39:07 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
 <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>
Message-ID: <qbKlykRjPeruxOdzUot6jvVPcgG2WjML9zxc8B_ntG0=.dd23020c-1101-46d0-abbe-392e232a8204@github.com>

On Fri, 25 Oct 2024 04:35:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/tools/jar/MultipleManifestTest.java line 203:
>> 
>>> 201: 
>>> 202:     private void assertOutputContains(String expected) {
>>> 203:         Assertions.assertTrue(baos.toString().contains(expected));
>> 
>> The linked JBS issue notes that the test was failing because of the additional (new) log messages from the jar tool itself. So I think the logs will be deterministic (since they aren't being generated by something else other than the jar tool). Using `contains()` thus looks fine to me.
>
> Do you think we should print out the actual and expected, when they don't match? It might make it easier to debug any unexpected failures in future.

The output is always printed in the log, so we know the actual value. If a test failed, the source code tell us the expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1816360973

From mistria at redhat.com  Fri Oct 25 09:54:51 2024
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 25 Oct 2024 11:54:51 +0200
Subject: -proceedOnError option (like ECJ) ?
In-Reply-To: <4756ee9e-572d-4a94-8dd3-f88de3366421@oracle.com>
References: <CAFr6BZSk7a22FWrZy6QakmJ0OA5-sOKaga6DYpEJRqSZL4rnSg@mail.gmail.com>
 <3344b2bd-4190-41ac-ae36-ec1afb272c8d@oracle.com>
 <4756ee9e-572d-4a94-8dd3-f88de3366421@oracle.com>
Message-ID: <CAFr6BZQ5JLjvAaMZeXfEvpcSrytRkBSpHbstt+voWGer-ggaEw@mail.gmail.com>

Thanks for your feedback. I interpret optimistically that such a feature
seems compliant with the spec and would be a welcome addition in Javac is
anyone gets to contribute a good patch for it.
We will try it on the JDT-LS side, and if successful, we'll try to
contribute it back directly in OpenJDK. For those interested, we'll be
using this ticket to track progress on our end:
https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/issues/907 . Of
course, anyone willing to work on this before we get started would be very
warmly welcome and thanked ;)

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241025/63fdd368/attachment.htm>

From jpai at openjdk.org  Fri Oct 25 10:21:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 10:21:03 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <qbKlykRjPeruxOdzUot6jvVPcgG2WjML9zxc8B_ntG0=.dd23020c-1101-46d0-abbe-392e232a8204@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
 <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>
 <qbKlykRjPeruxOdzUot6jvVPcgG2WjML9zxc8B_ntG0=.dd23020c-1101-46d0-abbe-392e232a8204@github.com>
Message-ID: <5drpdSBWJMArKNainC5RnaM-DWaV0aXNz5uaYwfqdL0=.ed96ca33-7d27-49ba-9958-0a35ff7efeac@github.com>

On Fri, 25 Oct 2024 09:36:41 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Do you think we should print out the actual and expected, when they don't match? It might make it easier to debug any unexpected failures in future.
>
> The output is always printed in the log, so we know the actual value. If a test failed, the source code tell us the expected.

Thank you Henry, I believe that's good enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1816419731

From duke at openjdk.org  Fri Oct 25 10:26:05 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 10:26:05 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
Message-ID: <3WzotMeV2mA4HkUTDORqYoSLAWwfyzPy6uYsm2gwzdo=.92a6362a-437b-4c2d-8280-2be2211a92cd@github.com>

On Thu, 24 Oct 2024 16:48:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - adress feedback in implementation
>>  - address feedback in tests
>
> I think I prefer your idea of keeping the code inside `CodeWriter`.
> 
> Maybe have a `write` and a `writeVerbose`, and have a private method with a `boolean` param that controls printing of extra info?

@JornVernee 

> I think I prefer your idea of keeping the code inside `CodeWriter`.
> 
> Maybe have a `write` and a `writeVerbose`, and have a private method with a `boolean` param that controls printing of extra info?

Not sure about the wording of using `writeVerbose`. It just happens that in the case when the `-verbose` flag is set, that `task.options.showAllAttrs = true;` is set, which leads to writing out the "complete" output of the `CodeWriter`. I think the non-verbose case is the exception, where we override the default `write` functionality. Thus I have opted for keeping the functionality and naming of `write` and adding a new function `writeMinimal` as the "non-standard" case. What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/21685#issuecomment-2437425971

From psadhukhan at openjdk.org  Fri Oct 25 11:19:41 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <N9SCzjHG3Q-GHIk6nNj7s8_vQBkx_dirVhnTjhWpWw0=.d298d7d7-4fab-46e7-9f07-f4f39f308478@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2394343323

From dfuchs at openjdk.org  Fri Oct 25 11:19:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <XK2j-0yrasFNv7xEkGgkrwWX09OJD29pcQPMmVd88kU=.13059532-b236-45bf-b788-626491003998@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

For the record I had a look at the changes in JMX and JNDI tests and these look good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437522137

From mcimadamore at openjdk.org  Fri Oct 25 11:30:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 11:30:05 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
Message-ID: <izdTQ3xS0TyWgtl3O3ed5kZJqJ00yczVuXVEl04OklE=.f811458a-7c9b-4217-9e53-8e0202638961@github.com>

On Thu, 24 Oct 2024 22:14:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 207:

> 205:     }
> 206: 
> 207:     private boolean scan(Symbol symbol, Symbol otherSymbol) {

Consider renaming this to `scanSymbol`, to make it clear it doesn't apply to trees.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 224:

> 222:         Symbol otherSymbol = that.sym;
> 223: 
> 224:         if (result)

This could also be:


result = scan(tree.selected, that.selected) &&
                   scan(tree.sym, that.sym);


Right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816513551
PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816513042

From mcimadamore at openjdk.org  Fri Oct 25 11:36:07 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 11:36:07 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
Message-ID: <aPmnfTo77OdlQCT12HT3qJMEYkHDeMCgbZQvoYu9WAA=.6a3e2452-674d-4a96-8ff6-8bfb47560b52@github.com>

On Thu, 24 Oct 2024 22:14:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 693:

> 691:                         && scan(tree.init, that.init);
> 692: 
> 693:         if (!tree.sym.owner.type.hasTag(TypeTag.METHOD) && result) {

I would rewrite this (for improved readability) as:


JCVariableDecl that = (JCVariableDecl) parameter;
 result =
                scan(tree.mods, that.mods)
                        && scan(tree.nameexpr, that.nameexpr)
                        && scan(tree.vartype, that.vartype)
                        && scan(tree.init, that.init);

if (tree.sym.owner.type.hasTag(TypeTag.CLASS)) {
    // field names are important!
    result &= tree.name == that.name;
}

if (result) {
     equiv.put(tree.sym, that.sym);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816519489

From aivanov at openjdk.org  Fri Oct 25 11:38:37 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 11:38:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
 <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>
Message-ID: <xmvA-xWfN2PbFLJsskbi8HNSDlJ6ANEKeWuzLgqlzrk=.b2eb7e3f-4f25-4c3e-b5c0-e29705ab9ce4@github.com>

On Thu, 24 Oct 2024 21:06:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> It was missed when `-Djava.security.manager=allow` was removed.
>> 
>> It wasn't intentional then, was it?
>> 
>>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
>> 
>> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
>> 
>> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
>> 
>> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
>> 
>> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.
>
> @aivanov-jdk 
> Right, it wasn't intentional but missed when removing `-Djava.security.manager=allow`.
> 
>> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.
> 
> Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good idea to remove it, I could do a find and replace-all on beans/XMLEncoder/ test folder.

@honkar-jdk I've submitted [JDK-8343062](https://bugs.openjdk.org/browse/JDK-8343062) for additional cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816521679

From mcimadamore at openjdk.org  Fri Oct 25 11:42:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 11:42:04 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <aPmnfTo77OdlQCT12HT3qJMEYkHDeMCgbZQvoYu9WAA=.6a3e2452-674d-4a96-8ff6-8bfb47560b52@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
 <aPmnfTo77OdlQCT12HT3qJMEYkHDeMCgbZQvoYu9WAA=.6a3e2452-674d-4a96-8ff6-8bfb47560b52@github.com>
Message-ID: <QqeGJIW64Y4M__j2DiAIDel-LTpCI6NmmwbaY2Fx75o=.56eb3e8e-15ad-4877-a96d-6850b9ffb03f@github.com>

On Fri, 25 Oct 2024 11:33:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 693:
> 
>> 691:                         && scan(tree.init, that.init);
>> 692: 
>> 693:         if (!tree.sym.owner.type.hasTag(TypeTag.METHOD) && result) {
> 
> I would rewrite this (for improved readability) as:
> 
> 
> JCVariableDecl that = (JCVariableDecl) parameter;
>  result =
>                 scan(tree.mods, that.mods)
>                         && scan(tree.nameexpr, that.nameexpr)
>                         && scan(tree.vartype, that.vartype)
>                         && scan(tree.init, that.init);
> 
> if (tree.sym.owner.type.hasTag(TypeTag.CLASS)) {
>     // field names are important!
>     result &= tree.name == that.name;
> }
> 
> if (result) {
>      equiv.put(tree.sym, that.sym);
> }

And, now that I wrote that I realize there's another issue in the code (from before your changes). I don't think `equiv` is really meant to be for non-local variables. IMHO the logic should be:
1. if we're comparing two local variables, do a structural comparison (and ignore the names)
2. if we're comparing fields, just check the symbols are the same.
And... I'm not sure there's ever a case where (2) applies? E.g. do we really want to deduplicate lambdas containing similar local class definitions? @cushon what do you think? What was the original intention for this code?

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeHasher.java line 104:
> 
>> 102:             }
>> 103:         }
>> 104:         if (sym instanceof PoolConstant.Dynamic dynamic) {
> 
> You could in principle add an `hashSymbol` method which does this dance - then you reuse it from both `visitIdent` and `visitSelect`

I'm not sure if `visitVarDef` is ok here. Again, we seem to assume that all variables encountered here are locals - and we use a number to hash them. This is fine for locals, but I think a field should just hash to the field symbol's hash? @cushon what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816523345
PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816527035

From mcimadamore at openjdk.org  Fri Oct 25 11:42:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 11:42:05 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
Message-ID: <dyOiWQ_jUccvKdzoCpJP6Gj33KUGZqLnjPcQgJZ9Z9c=.26f24999-23b0-470d-bd82-b0dcd5ca788a@github.com>

On Thu, 24 Oct 2024 22:14:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeHasher.java line 104:

> 102:             }
> 103:         }
> 104:         if (sym instanceof PoolConstant.Dynamic dynamic) {

You could in principle add an `hashSymbol` method which does this dance - then you reuse it from both `visitIdent` and `visitSelect`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816524905

From jlahoda at openjdk.org  Fri Oct 25 12:05:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Oct 2024 12:05:07 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <QqeGJIW64Y4M__j2DiAIDel-LTpCI6NmmwbaY2Fx75o=.56eb3e8e-15ad-4877-a96d-6850b9ffb03f@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
 <aPmnfTo77OdlQCT12HT3qJMEYkHDeMCgbZQvoYu9WAA=.6a3e2452-674d-4a96-8ff6-8bfb47560b52@github.com>
 <QqeGJIW64Y4M__j2DiAIDel-LTpCI6NmmwbaY2Fx75o=.56eb3e8e-15ad-4877-a96d-6850b9ffb03f@github.com>
Message-ID: <cHEKsOAwstB7A6NTG7HwpkaexixrrOKLDPQp7TCr6-Q=.57124da9-7197-4867-9d2d-2dd7fc21e20e@github.com>

On Fri, 25 Oct 2024 11:36:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeDiffer.java line 693:
>> 
>>> 691:                         && scan(tree.init, that.init);
>>> 692: 
>>> 693:         if (!tree.sym.owner.type.hasTag(TypeTag.METHOD) && result) {
>> 
>> I would rewrite this (for improved readability) as:
>> 
>> 
>> JCVariableDecl that = (JCVariableDecl) parameter;
>>  result =
>>                 scan(tree.mods, that.mods)
>>                         && scan(tree.nameexpr, that.nameexpr)
>>                         && scan(tree.vartype, that.vartype)
>>                         && scan(tree.init, that.init);
>> 
>> if (tree.sym.owner.type.hasTag(TypeTag.CLASS)) {
>>     // field names are important!
>>     result &= tree.name == that.name;
>> }
>> 
>> if (result) {
>>      equiv.put(tree.sym, that.sym);
>> }
>
> And, now that I wrote that I realize there's another issue in the code (from before your changes). I don't think `equiv` is really meant to be for non-local variables. IMHO the logic should be:
> 1. if we're comparing two local variables, do a structural comparison (and ignore the names)
> 2. if we're comparing fields, just check the symbols are the same.
> And... I'm not sure there's ever a case where (2) applies? E.g. do we really want to deduplicate lambdas containing similar local class definitions? @cushon what do you think? What was the original intention for this code?

FWIW, I doubt we meaningfully deduplicate lambdas with local class definitions. I suspect we deduplicate them only if the declarations are not used, like:

         Runnable r1 = () -> {class C {}};
         Runnable r2 = () -> {class C {}};


But not when they are used, like:

         Runnable r1 = () -> {class C {} new C();};
         Runnable r2 = () -> {class C {} new C();};


because the use site (`new C();`) uses different `Symbol`s, and these `Symbol`s are not `equiv`-ed.

So, possibly, simply using `false` once we see a `JCClassDecl` might be a more direct, open, answer.

(Besides aliasing local variables, there are probably other cases where we don't detect semantically equivalent duplicates. Like `Object` and `java.lang.Object`. It is not clear to me if those are important in practice, though.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816554212

From vromero at openjdk.org  Fri Oct 25 13:30:07 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Oct 2024 13:30:07 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
Message-ID: <RoZjaobLuGglsOzFGe1--zDvQ0_kaQJzxvdRom4Pr1U=.8d9bb108-df00-4507-b5fa-769e68b7eef2@github.com>

On Thu, 24 Oct 2024 22:14:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

side: not sure if the dedup effort is worthy at the end in terms of performance / class file reduction / maintenance

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2437777772

From jvernee at openjdk.org  Fri Oct 25 13:46:05 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 25 Oct 2024 13:46:05 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
Message-ID: <S_TgHacDPxuvj3ncEN9_9SWzQMXbp6GEPBR-WakZmB4=.ff817e4b-191b-4f24-befd-b0250a79f6e1@github.com>

On Fri, 25 Oct 2024 09:28:53 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - adress feedback in implementation
>  - address feedback in tests

Looks great, thanks!

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21685#pullrequestreview-2395341712

From mullan at openjdk.org  Fri Oct 25 13:47:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 13:47:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
Message-ID: <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>

On Tue, 22 Oct 2024 20:23:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
> 
>> 38:  *
>> 39:  * @apiNote
>> 40:  * This permission cannot be used for controlling access to resources anymore
> 
> Unnecessary "anymore"

Removed this word from all `Permission` subclasses; fix will be in next update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816717534

From liach at openjdk.org  Fri Oct 25 15:07:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 15:07:11 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
Message-ID: <Pzvr8gvg3Zx2fDxc01bvtZvKqyJFbuPbXQW3lbKhPUk=.dd1d9dba-04d0-44e0-9aee-dedbed6d075a@github.com>

On Fri, 25 Oct 2024 09:28:53 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - adress feedback in implementation
>  - address feedback in tests

Looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21685#pullrequestreview-2395574746

From mcimadamore at openjdk.org  Fri Oct 25 15:14:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 15:14:10 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <RoZjaobLuGglsOzFGe1--zDvQ0_kaQJzxvdRom4Pr1U=.8d9bb108-df00-4507-b5fa-769e68b7eef2@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
 <RoZjaobLuGglsOzFGe1--zDvQ0_kaQJzxvdRom4Pr1U=.8d9bb108-df00-4507-b5fa-769e68b7eef2@github.com>
Message-ID: <rE8X2c6980Qnuol3d9g3Y02X9KkpwAfHZ2dUzXiWgRE=.3e0644d3-0fe2-4e67-985b-7fa35f968b79@github.com>

On Fri, 25 Oct 2024 13:26:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> side: not sure if the dedup effort is worthy at the end in terms of performance / class file reduction / maintenance

Good point - these deduplication tests are rather painful to maintain every time the compiler is changed (I had to fight with them as well when writing the revamped backend support for flexible constructor bodies). I share the general feeling of a slightly negative cost vs. benefit ratio -- but I don't have any backing evidence (maybe we should gather that up).

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2438087221

From mcimadamore at openjdk.org  Fri Oct 25 15:14:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 15:14:11 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <cHEKsOAwstB7A6NTG7HwpkaexixrrOKLDPQp7TCr6-Q=.57124da9-7197-4867-9d2d-2dd7fc21e20e@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
 <aPmnfTo77OdlQCT12HT3qJMEYkHDeMCgbZQvoYu9WAA=.6a3e2452-674d-4a96-8ff6-8bfb47560b52@github.com>
 <QqeGJIW64Y4M__j2DiAIDel-LTpCI6NmmwbaY2Fx75o=.56eb3e8e-15ad-4877-a96d-6850b9ffb03f@github.com>
 <cHEKsOAwstB7A6NTG7HwpkaexixrrOKLDPQp7TCr6-Q=.57124da9-7197-4867-9d2d-2dd7fc21e20e@github.com>
Message-ID: <myGW_Upja2kI_wl_w-0CbZV4H2A-2OSuKc-vNay2tzE=.a3f83d5e-0d51-4cb5-bf8d-6f63e6e3776a@github.com>

On Fri, 25 Oct 2024 12:02:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> And, now that I wrote that I realize there's another issue in the code (from before your changes). I don't think `equiv` is really meant to be for non-local variables. IMHO the logic should be:
>> 1. if we're comparing two local variables, do a structural comparison (and ignore the names)
>> 2. if we're comparing fields, just check the symbols are the same.
>> And... I'm not sure there's ever a case where (2) applies? E.g. do we really want to deduplicate lambdas containing similar local class definitions? @cushon what do you think? What was the original intention for this code?
>
> FWIW, I doubt we meaningfully deduplicate lambdas with local class definitions. I suspect we deduplicate them only if the declarations are not used, like:
> 
>          Runnable r1 = () -> {class C {}};
>          Runnable r2 = () -> {class C {}};
> 
> 
> But not when they are used, like:
> 
>          Runnable r1 = () -> {class C {} new C();};
>          Runnable r2 = () -> {class C {} new C();};
> 
> 
> because the use site (`new C();`) uses different `Symbol`s, and these `Symbol`s are not `equiv`-ed.
> 
> So, possibly, simply using `false` once we see a `JCClassDecl` might be a more direct, open, answer.
> 
> (Besides aliasing local variables, there are probably other cases where we don't detect semantically equivalent duplicates. Like `Object` and `java.lang.Object`. It is not clear to me if those are important in practice, though.)

@lahodaj  that's my feeling too - but if that's the case, I think all our dedup visitors should be more transparent that that's the case (which you seem to agree with).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1816884215

From iris at openjdk.org  Fri Oct 25 15:27:05 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 25 Oct 2024 15:27:05 GMT
Subject: RFR: 8342934: TYPE_USE annotations printed with error causing ", "
 in toString output
In-Reply-To: <PQ9zRKIH7UmIhzkXJSC9oXIAtmxhcO3dvyDOwvGAXHw=.b424d6d6-fa4e-4c8a-9f42-870b83a842c8@github.com>
References: <PQ9zRKIH7UmIhzkXJSC9oXIAtmxhcO3dvyDOwvGAXHw=.b424d6d6-fa4e-4c8a-9f42-870b83a842c8@github.com>
Message-ID: <LElTV1LbvJ5hlClMQGhDdzNhgWo0dEfvUZf0u1zJlJQ=.b27f7a76-cd41-4bd3-9506-eea19d285460@github.com>

On Fri, 25 Oct 2024 06:07:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use space instead of comma as a delimiter when building the string of type annotations.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21702#pullrequestreview-2395649462

From vromero at openjdk.org  Fri Oct 25 15:39:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Oct 2024 15:39:09 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <g7bmNd7Z053J_mOJOTANb-pWZzfxu2st5QRXrbbyfA8=.350e02f3-b7c1-4465-8c6b-d994ebff6546@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
 <RoZjaobLuGglsOzFGe1--zDvQ0_kaQJzxvdRom4Pr1U=.8d9bb108-df00-4507-b5fa-769e68b7eef2@github.com>
 <rE8X2c6980Qnuol3d9g3Y02X9KkpwAfHZ2dUzXiWgRE=.3e0644d3-0fe2-4e67-985b-7fa35f968b79@github.com>
 <g7bmNd7Z053J_mOJOTANb-pWZzfxu2st5QRXrbbyfA8=.350e02f3-b7c1-4465-8c6b-d994ebff6546@github.com>
Message-ID: <e6Lac5bnmQPJnjP_SOoqQojMslis9Yxz8bwU-O-SL6c=.8a8516b4-91c8-4077-ade0-7267aa7ccf67@github.com>

On Fri, 25 Oct 2024 15:34:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> > side: not sure if the dedup effort is worthy at the end in terms of performance / class file reduction / maintenance
> 
> Good point - these deduplication tests are rather painful to maintain every time the compiler is changed (I had to fight with them as well when writing the revamped backend support for flexible constructor bodies). I share the general feeling of a slightly negative cost vs. benefit ratio -- but I don't have any backing evidence (maybe we should gather that up).

it seems like for some code bases it makes sense, which is I think why Liam proposed this change, but this type of optimization seems to belong more to the VM than to javac

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2438146305

From cushon at openjdk.org  Fri Oct 25 15:39:08 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 25 Oct 2024 15:39:08 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <rE8X2c6980Qnuol3d9g3Y02X9KkpwAfHZ2dUzXiWgRE=.3e0644d3-0fe2-4e67-985b-7fa35f968b79@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
 <RoZjaobLuGglsOzFGe1--zDvQ0_kaQJzxvdRom4Pr1U=.8d9bb108-df00-4507-b5fa-769e68b7eef2@github.com>
 <rE8X2c6980Qnuol3d9g3Y02X9KkpwAfHZ2dUzXiWgRE=.3e0644d3-0fe2-4e67-985b-7fa35f968b79@github.com>
Message-ID: <g7bmNd7Z053J_mOJOTANb-pWZzfxu2st5QRXrbbyfA8=.350e02f3-b7c1-4465-8c6b-d994ebff6546@github.com>

On Fri, 25 Oct 2024 15:11:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > side: not sure if the dedup effort is worthy at the end in terms of performance / class file reduction / maintenance
> 
> Good point - these deduplication tests are rather painful to maintain every time the compiler is changed (I had to fight with them as well when writing the revamped backend support for flexible constructor bodies). I share the general feeling of a slightly negative cost vs. benefit ratio -- but I don't have any backing evidence (maybe we should gather that up).

I don't have good data on what the remaining benefit is either, but for what it's worth I share the feeling that this feature may not be worth keeping around. The deduplication isn't performed if debug info is enabled to avoid incorrect line numbers in stack traces, so there's a large fraction of code that enables debug info and isn't benefiting from it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2438144066

From vromero at openjdk.org  Fri Oct 25 16:08:04 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Oct 2024 16:08:04 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
Message-ID: <jf3pitE2lEWjqg_NdrEoZUYuMbOSnSBBP8Bk0nQUcVA=.d16a348e-682c-4217-a71a-4767857f656b@github.com>

On Thu, 24 Oct 2024 22:14:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

I was reading the discussion back then and it seems like the number of lambdas that could be deduplicated per file were < 1 on average, this is for their code base. We are not de-duplicating serializable lambdas and if we are generating debug info, then we are not deduplicating either

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2438215969

From michaelm at openjdk.org  Fri Oct 25 16:11:46 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Oct 2024 16:11:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <TJNWAEiPXYUxNLNQSveRSSTbV6KUK2aDTjUBN-V-Q9M=.97954e4d-05d7-480a-94a6-ca283458596d@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

I've reviewed the networking tests and they look fine. There are tests that possibly don't need the `othervm` keyword any more, and some tests that still do permission implies tests (without a security manager) but these can be updated independently in future PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438222428

From vromero at openjdk.org  Fri Oct 25 16:47:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Oct 2024 16:47:06 GMT
Subject: RFR: 8342934: TYPE_USE annotations printed with error causing ", "
 in toString output
In-Reply-To: <PQ9zRKIH7UmIhzkXJSC9oXIAtmxhcO3dvyDOwvGAXHw=.b424d6d6-fa4e-4c8a-9f42-870b83a842c8@github.com>
References: <PQ9zRKIH7UmIhzkXJSC9oXIAtmxhcO3dvyDOwvGAXHw=.b424d6d6-fa4e-4c8a-9f42-870b83a842c8@github.com>
Message-ID: <wqzD33Qyi59e8c8pn84UoIyNxzEOufb6UGe4TwuAKOw=.2111ac48-46b4-4a6e-8eb0-ed24a6fa6603@github.com>

On Fri, 25 Oct 2024 06:07:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use space instead of comma as a delimiter when building the string of type annotations.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21702#pullrequestreview-2395852313

From darcy at openjdk.org  Fri Oct 25 16:52:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 25 Oct 2024 16:52:08 GMT
Subject: Integrated: 8342934: TYPE_USE annotations printed with error causing
 "," in toString output
In-Reply-To: <PQ9zRKIH7UmIhzkXJSC9oXIAtmxhcO3dvyDOwvGAXHw=.b424d6d6-fa4e-4c8a-9f42-870b83a842c8@github.com>
References: <PQ9zRKIH7UmIhzkXJSC9oXIAtmxhcO3dvyDOwvGAXHw=.b424d6d6-fa4e-4c8a-9f42-870b83a842c8@github.com>
Message-ID: <MC4YNYeJaDQzj1yHkWTN641WMZKZYC7AYqwbWl5L7fE=.408de20f-e5b9-420a-8d6d-7d164e4a3c72@github.com>

On Fri, 25 Oct 2024 06:07:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use space instead of comma as a delimiter when building the string of type annotations.

This pull request has now been integrated.

Changeset: ff165f9f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff165f9f0cf519144d7361b766bcce53d04c518e
Stats:     8 lines in 3 files changed: 4 ins; 0 del; 4 mod

8342934: TYPE_USE annotations printed with error causing "," in toString output

Reviewed-by: iris, vromero

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

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

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Changes requested by aivanov (Reviewer).

test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:

> 1: /*

I believe this test becomes irrelevant without `SecurityManager`.

The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:

> 1: /*

I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.

If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.

The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 44:

> 42:     private static JFrame frame;
> 43:     private static JPopupMenu popupMenu;
> 44:     private static volatile boolean isAlwaysOnTop1 = false;

Suggestion:

    private static volatile boolean isAlwaysOnTop = false;

There's only one flag now, it needs no modifier.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 54:

> 52: 
> 53:             SwingUtilities.invokeAndWait(bug6691503::testApplication);
> 54:             robot.delay(200);

The additional delay is redundant.

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:

> 39:  * @bug 6694823
> 40:  * @summary Checks that popup menu cannot be partially hidden
> 41:  *          by the task bar.

I believe this test is irrelevant without the security manager.

The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.

Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.

We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:

> 1: /*

Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.

Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2395179909
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816616064
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816806950
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816827134
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816826424
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816840082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816896526

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>

On Fri, 25 Oct 2024 15:12:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
> 
>> 1: /*
> 
> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
> 
> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.

Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.

However, a more thorough analysis is required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816923550

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
Message-ID: <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>

On Fri, 25 Oct 2024 15:29:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
>> 
>>> 1: /*
>> 
>> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
>> 
>> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.
>
> This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.
> 
> Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.
> 
> However, a more thorough analysis is required.

The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817034884

From honkar at openjdk.org  Fri Oct 25 17:33:44 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 17:33:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>

On Fri, 25 Oct 2024 14:57:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:
> 
>> 39:  * @bug 6694823
>> 40:  * @summary Checks that popup menu cannot be partially hidden
>> 41:  *          by the task bar.
> 
> I believe this test is irrelevant without the security manager.
> 
> The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.
> 
> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
> 
> We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.

This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817093001

From aivanov at openjdk.org  Fri Oct 25 17:56:43 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 17:56:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
Message-ID: <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>

On Fri, 25 Oct 2024 17:30:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:
>> 
>>> 39:  * @bug 6694823
>>> 40:  * @summary Checks that popup menu cannot be partially hidden
>>> 41:  *          by the task bar.
>> 
>> I believe this test is irrelevant without the security manager.
>> 
>> The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.
>> 
>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
>> 
>> We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.
>
> This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.

The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.

> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.

The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817116860

From aivanov at openjdk.org  Fri Oct 25 18:12:44 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 18:12:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

I've looked through the changes to `java.desktop` module and to tests under `java/awt`, `java/beans`, `javax/accessibility`, `javax/sound`, `javax/swing`, `com/sun/java/accessibility` (removed).

test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:

> 40:         } catch (ServiceConfigurationError sce) {
> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
> 42:             System.out.println("Test Passed");

Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438514238
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817159883

From honkar at openjdk.org  Fri Oct 25 18:36:39 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 18:36:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
Message-ID: <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>

On Fri, 25 Oct 2024 17:52:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
>
> The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
> 
> The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.
> 
>> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
> 
> There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.
> 
> The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.

@aivanov-jdk 
On macOS, popup is shifted up and does not cover the taskbar even without SM. 

> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.

On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817183611

From aivanov at openjdk.org  Fri Oct 25 18:55:38 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 18:55:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
 <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
Message-ID: <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>

On Fri, 25 Oct 2024 18:30:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>> 
>> The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.
>> 
>>> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
>> 
>> There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.
>> 
>> The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.
>
> @aivanov-jdk 
> On macOS, popup is shifted up and does not cover the taskbar even without SM. 
> 
>> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
> 
> On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?

The pop is shifted up on macOS because `LWCToolkit` returns `false` in `canPopupOverlapTaskBar`:

https://github.com/openjdk/jdk/blob/36d71735e3554264e8d17f7e0e72999ac639e398/src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java#L900-L902

On Windows, apps can control the area where they want a popmenu display or exclude an area of the screen. At the same time, Firefox displays its right-click menu over the taskbar if the menu fits when dropped down. A native Win32 app with a menu bar displays popup menus over the taskbar if it fits on the screen; some menus could open upwards if their items don't fit on the screen to display downwards (I attached a screenshot to JBS). Popup menus in Win32 Notepad (the version in Windows 10) displays it's right-click menu over the taskbar if it fits.

At the same time, right-click menu of a window title never displays over the taskbar, the menu opens upward if it doesn't fit without covering part of the taskbar.

I'm pretty sure the default return value of `true` from `SunToolkit.canPopupOverlapTaskBar` isn't something that was chosen accidentally.

Windows applications may avoid showing popup over the taskbar (confining the popups inside the work area, see [`SystemParametersInfoW`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow) and `SPI_GETWORKAREA`). We can change the behaviour of the JDK.

Yet the failure of `bug6694823.java` without the security manager isn't a product bug in my opinion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817205444

From weijun at openjdk.org  Fri Oct 25 19:49:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Oct 2024 19:49:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Comments on `java.security` classes.

Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

I also reviewed files in `conf/security`. Everything looks fine except for the `networkaddress.cache.ttl` security property which still references the Security Manager.

src/java.base/share/classes/java/security/AccessControlContext.java line 32:

> 30: 
> 31: /**
> 32:  * AccessControlContext was used with a SecurityManager for access control decisions

I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.

src/java.base/share/classes/java/security/AccessControlContext.java line 141:

> 139:         throws AccessControlException
> 140:     {
> 141:         throw new AccessControlException("");

No message for this exception?

src/java.base/share/classes/java/security/AccessControlException.java line 29:

> 27: 
> 28: /**
> 29:  *

Add a sentence like "This was..."?

src/java.base/share/classes/java/security/Policy.java line 90:

> 88:  *       and subject to removal in a future release. Consequently, this class
> 89:  *       is also deprecated and subject to removal. There is no replacement for
> 90:  *       the Security Manager or this class.

Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.

src/java.base/share/classes/java/security/Policy.java line 374:

> 372:      *
> 373:      * @param codesource the CodeSource to which the returned
> 374:      *          PermissionCollection has been granted

Can we say this parameter is ignored? I see some other methods said so.

Same with the other `getPermissions` and `implies`.

src/java.base/share/classes/java/security/SecureClassLoader.java line 1:

> 1: /*

The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? Also, `getPermissions` always returns an empty `Permissions` object, do we need to add an `@apiNote` for it?

src/java.base/share/classes/java/security/Security.java line 489:

> 487: 
> 488:     /**
> 489:      * Adds a provider to the next position available..

Two periods at the end.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2395870667
PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438672204
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817189896
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817193883
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817194616
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817163586
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817173742
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817050537
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817042605

From honkar at openjdk.org  Fri Oct 25 20:34:40 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 20:34:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>

On Fri, 25 Oct 2024 14:36:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
> 
>> 1: /*
> 
> I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.
> 
> If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.
> 
> The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.

This test was initially deleted but then restored based on the following comment - https://github.com/openjdk/jdk/pull/21498#discussion_r1810297085

Since this test falls under similar category as test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java and based on your suggestion, I think we can delete it if it doesn't hold value after SM removal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817311600

From rriggs at openjdk.org  Fri Oct 25 21:04:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Oct 2024 21:04:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java/util/* and corresponding tests.
Logging tests should refactor to eliminate use of doPrivileged(fn);

test/jdk/java/util/PluggableLocale/PermissionTest.java line 52:

> 50: import com.foo.NumberFormatProviderImpl;
> 51: 
> 52: public class PermissionTest{

This test can be deleted entirely. What remains is just constructing each provider impl.
The summary mentions a RuntimePermission and would need to be revised to a new description.

test/jdk/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java line 48:

> 46:             throw new RuntimeException("unexpected resource bundle");
> 47:         }
> 48: 

This main and TestPermission.java duplicate the basic resource location mechanisms.
This test/Main.java an test/TestPermission can be removed entirely.

test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java line 28:

> 26:  * @bug 6552961 6558429
> 27:  * @summary Test privilegedCallable, privilegedCallableUsingCurrentClassLoader
> 28:  * @run main PrivilegedCallables

There's nothing privileged here; the test should be renamed or deleted if it duplicates other non-privileged call tests.

test/jdk/java/util/logging/FileHandlerLongLimit.java line 157:

> 155:     static class Configure {
> 156:         static void setUp(Properties propertyFile) {
> 157:             doPrivileged(() -> {

The doPrivileged() could be factored out.
And callPrivileged().

test/jdk/java/util/logging/FileHandlerPath.java line 149:

> 147:     static class Configure {
> 148:         static void setUp(Properties propertyFile) {
> 149:             doPrivileged(() -> {

doPrivileged() could be refactored; it is no longer necessary.

test/jdk/java/util/logging/FileHandlerPatternExceptions.java line 106:

> 104:     static class Configure {
> 105:         static void setUp(Properties propertyFile) {
> 106:             doPrivileged(() -> {

doPrivileged() is no longer necessary.

test/jdk/java/util/logging/TestAppletLoggerContext.java line 40:

> 38:  * @modules java.base/jdk.internal.access
> 39:  *          java.logging
> 40:  * @run main/othervm TestAppletLoggerContext LoadingApplet

Rename these?  What's really being tested, there are no more Applets.

test/jdk/java/util/logging/TestLogConfigurationDeadLockWithConf.java line 83:

> 81:      * then the test is considered a success and passes.
> 82:      *
> 83:      * Note that 4sec may not be enough to detect issues if there are some.

Where is this timeout enforced or measured; this is just a comment, not a parameter.

test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 125:

> 123:     }
> 124: 
> 125:     @Benchmark

Is this benchmark still useful if it is not comparing the SM vs the Non-SM case?

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2396279786
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817269899
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817285899
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817291039
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817304993
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817307433
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817310090
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817323513
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817327555
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817352471

From honkar at openjdk.org  Fri Oct 25 21:12:39 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 21:12:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
Message-ID: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>

On Fri, 25 Oct 2024 18:08:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:
> 
>> 40:         } catch (ServiceConfigurationError sce) {
>> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
>> 42:             System.out.println("Test Passed");
> 
> Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?

When SM is removed, test fails with java.util.ServiceConfigurationError: javax.imageio.spi.ImageReaderSpi:Provider BadReaderPluginSpi not found. This is the expected behavior without SM. 

When SM is present this error is swallowed because otherwise a erroneous plugin could cause a VM-wide problem. Now that SM is removed, the test (IIOPluginTest.java)
has been updated to expect ServiceConfigurationError.

AFAIK, there isn't another test which checks this code path hence it has been repurposed and retained.

> test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:
> 
>> 1: /*
> 
> I believe this test becomes irrelevant without `SecurityManager`.
> 
> The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).

Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
I can update the test summary accordingly  -
 **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**

@azuev-java Your thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817371084
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817373529

From mullan at openjdk.org  Fri Oct 25 21:21:41 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 21:21:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
Message-ID: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>

On Fri, 25 Oct 2024 19:44:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Comments on `java.security` classes.
> 
> Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

Yes, good point, let me review the class again and see if we can remove some more text or make some adjustments.

> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
> 
>> 30: 
>> 31: /**
>> 32:  * AccessControlContext was used with a SecurityManager for access control decisions
> 
> I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.

Right, it should be "the Security Manager", but we can also link to the `SecurityManager` class as plain text.  I'll make some wording changes to this class and `AccessController`.

> src/java.base/share/classes/java/security/AccessControlContext.java line 141:
> 
>> 139:         throws AccessControlException
>> 140:     {
>> 141:         throw new AccessControlException("");
> 
> No message for this exception?

I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.

> src/java.base/share/classes/java/security/AccessControlException.java line 29:
> 
>> 27: 
>> 28: /**
>> 29:  *
> 
> Add a sentence like "This was..."?

You mean move the first sentence of the deprecated text to here?

> src/java.base/share/classes/java/security/Policy.java line 90:
> 
>> 88:  *       and subject to removal in a future release. Consequently, this class
>> 89:  *       is also deprecated and subject to removal. There is no replacement for
>> 90:  *       the Security Manager or this class.
> 
> Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.

Yes, we should be consistent. The deprecated text always comes first, and sometimes we want to say immediately why this class is not useful anymore in that text instead of later, further down. I don't know which is better. I guess I'll go with your suggestion just so it looks more like a normal class.

> src/java.base/share/classes/java/security/Policy.java line 374:
> 
>> 372:      *
>> 373:      * @param codesource the CodeSource to which the returned
>> 374:      *          PermissionCollection has been granted
> 
> Can we say this parameter is ignored? I see some other methods said so.
> 
> Same with the other `getPermissions` and `implies`.

Yes, good suggestion.

> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 

Yes I think we can remove that text.

> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?

You mean a warning like we have in the `Permission` subclasses?

`URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.

> src/java.base/share/classes/java/security/Security.java line 489:
> 
>> 487: 
>> 488:     /**
>> 489:      * Adds a provider to the next position available..
> 
> Two periods at the end.

Will fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438893608
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817327704
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817335403
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817344307
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817362628
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817348142
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817377926
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817314475

From honkar at openjdk.org  Fri Oct 25 21:27:51 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 21:27:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
Message-ID: <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>

On Fri, 25 Oct 2024 16:47:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.
>> 
>> Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.
>> 
>> However, a more thorough analysis is required.
>
> The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.

@prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817385564

From rriggs at openjdk.org  Fri Oct 25 21:27:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Oct 2024 21:27:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <MjiRdWwmMhjnUXIIeDkclBTTnKBLsbxdZzHk-r69OaA=.c8ddefea-bd18-4ed7-8e2a-700860c2f99e@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java.compiler and corresponding langtools/tools/ tests. lgtm

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438900946

From prr at openjdk.org  Fri Oct 25 22:44:40 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Oct 2024 22:44:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
Message-ID: <tSwEN61gdo0zlJ-Wsw2DRIx1yD_dTIp596vpnWdm0nY=.24b18dd6-e549-4ae1-8638-da8993c22962@github.com>

On Fri, 25 Oct 2024 21:06:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:
>> 
>>> 40:         } catch (ServiceConfigurationError sce) {
>>> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
>>> 42:             System.out.println("Test Passed");
>> 
>> Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?
>
> When SM is removed, test fails with java.util.ServiceConfigurationError: javax.imageio.spi.ImageReaderSpi:Provider BadReaderPluginSpi not found. This is the expected behavior without SM. 
> 
> When SM is present this error is swallowed because otherwise a erroneous plugin could cause a VM-wide problem. Now that SM is removed, the test (IIOPluginTest.java)
> has been updated to expect ServiceConfigurationError.
> 
> AFAIK, there isn't another test which checks this code path hence it has been repurposed and retained.

Yes, perhaps there's some more general test for this in java.base, but there's nothing wrong with verifying it here, even though it is sort of backward from what the test previously verified.
Probably the test could always have tested both cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817428928

From prr at openjdk.org  Fri Oct 25 22:55:38 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Oct 2024 22:55:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
Message-ID: <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>

On Fri, 25 Oct 2024 21:23:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.
>
> @prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).

I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used.
But I don't see a problem with keeping the rest of the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817433603

From kizune at openjdk.org  Fri Oct 25 23:23:37 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 25 Oct 2024 23:23:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
Message-ID: <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>

On Fri, 25 Oct 2024 21:09:19 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:
>> 
>>> 1: /*
>> 
>> I believe this test becomes irrelevant without `SecurityManager`.
>> 
>> The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).
>
> Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
> I can update the test summary accordingly  -
>  **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**
> 
> @azuev-java Your thoughts?

That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817444639

From weijun at openjdk.org  Fri Oct 25 23:47:43 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Oct 2024 23:47:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>

On Fri, 25 Oct 2024 20:53:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessControlContext.java line 141:
>> 
>>> 139:         throws AccessControlException
>>> 140:     {
>>> 141:         throw new AccessControlException("");
>> 
>> No message for this exception?
>
> I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.

I see. Maybe this is enough.

>> src/java.base/share/classes/java/security/AccessControlException.java line 29:
>> 
>>> 27: 
>>> 28: /**
>>> 29:  *
>> 
>> Add a sentence like "This was..."?
>
> You mean move the first sentence of the deprecated text to here?

Oh, I just meant the class spec should have a body text. This is similar to my previous comment on the `Policy` class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817452801
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817452658

From weijun at openjdk.org  Sat Oct 26 00:01:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 26 Oct 2024 00:01:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>

On Fri, 25 Oct 2024 21:14:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/SecureClassLoader.java line 1:
>> 
>>> 1: /*
>> 
>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? Also, `getPermissions` always returns an empty `Permissions` object, do we need to add an `@apiNote` for it?
>
>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 
> 
> Yes I think we can remove that text.
> 
>> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?
> 
> You mean a warning like we have in the `Permission` subclasses?
> 
> `URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.

Sorry, I got it wrong. I thought this `return new Permissions()` is something new. In fact, it was there before this change.

On the other hand, I looked at its subclasses and their `getPermissions(CodeSource cs)` could return quite complicated permission collections. I assume it does not really matter since they are all useless now, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817457008

From duke at openjdk.org  Sat Oct 26 14:04:55 2024
From: duke at openjdk.org (Evemose)
Date: Sat, 26 Oct 2024 14:04:55 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v18]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

Evemose has updated the pull request incrementally with three additional commits since the last revision:

 - remove trailing whitespaces
 - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
 - address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/38dd1b5a..5fdfdf32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=16-17

  Stats: 49 lines in 4 files changed: 0 ins; 41 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20718/head:pull/20718

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

From duke at openjdk.org  Mon Oct 28 08:13:35 2024
From: duke at openjdk.org (duke)
Date: Mon, 28 Oct 2024 08:13:35 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
Message-ID: <unkeEQRSt33YNn00jF2WsMKQitMbLsZXHGqpovm50sQ=.d43fb840-4675-4f45-8d5c-e80c0ca7aa46@github.com>

On Fri, 25 Oct 2024 09:28:53 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - adress feedback in implementation
>  - address feedback in tests

@jonath4ndev 
Your change (at version bd6372ce02098c89abbf54e198faf2180fba0520) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21685#issuecomment-2440819902

From duke at openjdk.org  Mon Oct 28 09:45:58 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Mon, 28 Oct 2024 09:45:58 GMT
Subject: Integrated: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
Message-ID: <t22k35hO6sWkns59CtMViaFKAaMoTEVewSw55cuFAaw=.2371bb68-b70e-4b1f-89a1-b9a85e3eb6c3@github.com>

On Thu, 24 Oct 2024 14:57:19 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
> 
> Current behaviour of `javap` differs with and without `-verbose` in the following way:
> **Command**: `javap -c -XDdetails:stackMaps A.class`
> 
> Without `-verbose`
> 
> 
> ...
>   public void a();
>     Code:
>        0: iconst_0
>        1: istore_1
>     StackMap locals:  this int
>     StackMap stack:
> ...
> 
> 
> With `-verbose`
> 
> 
> ...
>   public void a();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          1: istore_1
>       StackMap locals:  this int
>       StackMap stack:
> ...
> 
> 
> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
> 
> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
> 
> ---
> 
> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
> 
> 
> void writeSimple(CodeAttribute attr) {
>         println("Code:");
>         indent(+1);
>         writeInstrs(attr);
>         writeExceptionTable(attr);
>         indent(-1);
>     }
> 
> 
> ---
> 
> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

This pull request has now been integrated.

Changeset: ec061874
Author:    Jonathan Lamp?rth <jonathan.lamperth at oracle.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec0618742ff6cfd6d83f1278e8d245673fb9ef2c
Stats:     137 lines in 3 files changed: 127 ins; 4 del; 6 mod

8034066: Incorrect alignment in the "Code" section for "-c -XDdetails" options

Reviewed-by: jvernee, liach

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

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

From duke at openjdk.org  Mon Oct 28 11:23:37 2024
From: duke at openjdk.org (Evemose)
Date: Mon, 28 Oct 2024 11:23:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v18]
In-Reply-To: <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
Message-ID: <gC1yNl8SaHt-VaEoWzZX6xZuQk6JA6F8zjFgQFfw63I=.39431a8f-abed-4677-b35d-0be2fa688c8c@github.com>

On Sat, 26 Oct 2024 14:04:55 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove trailing whitespaces
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - address review comments

By the way, does anyone know why ci fails? It fails on generate report, not on tests. I tried to sync branch with master but it seems like it has not had any affect

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2441307496

From mullan at openjdk.org  Mon Oct 28 12:29:07 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 12:29:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Specify that params passed to getPermissions and implies are ignored and
   implies always returns false.
 - Change deprecated annotations to api notes on getPolicy and setPolicy.
 - clientlibs: Updated Problemlist
   Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
 - clientlibs: Deleted JPopupMenu tests
   The following tests are deleted as they don't hold value without SM
   test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
   always-on-top for apps which doesn't hold value after SM removal.
   
   test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
   Works differently on macOS and windows & linux but this is the expected behavior.
   Details in JDK-8342012. Not a functional issue.
 - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
 - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
   test renamed, test summary updated
 - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
 - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
 - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
 - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=03
  Stats: 65873 lines in 1867 files changed: 1158 ins; 61009 del; 3706 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From mullan at openjdk.org  Mon Oct 28 13:47:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 13:47:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>
Message-ID: <t3eNL3sIsaBSuCKWvllA_vjpUyR7fH2u7cy2j_lCESE=.7a06982d-f836-4a2a-a711-418df3b180ae@github.com>

On Tue, 15 Oct 2024 22:09:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
>> 
>>> 665:      * @param codesource the codesource
>>> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
>>> 667:      * @return the permissions for the codesource
>> 
>> Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?
>
> Yes, I think that is a good suggestion. Let me think about whether it should be done as part of this JEP or if we can do it later.

I filed a follow-on issue to consider this: https://bugs.openjdk.org/browse/JDK-8343150

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819084510

From mullan at openjdk.org  Mon Oct 28 14:03:02 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:02 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
Message-ID: <vVe4o9wGohQAxFryEEG-ATg99g8s9Lud9YlM68S4BZc=.bcaa09df-a01d-4751-af7d-245fb008881c@github.com>

On Tue, 22 Oct 2024 20:20:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.base/share/classes/java/io/FilePermission.java line 71:
> 
>> 69:  *
>> 70:  * @apiNote
>> 71:  * This permission cannot be used for controlling access to resources anymore
> 
> The word "anymore" is unnecessary.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/44b552adb68d9aae1e72ed7bf20feb81552014c8

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819108633

From mullan at openjdk.org  Mon Oct 28 14:03:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
 <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>
Message-ID: <0zzRwrMnjzNfCdMIUBA1pBgjiUjutknxWCyGtlODbto=.ad858095-07aa-41f9-a3f3-9f1059ac5b5c@github.com>

On Fri, 25 Oct 2024 13:44:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
>> 
>>> 38:  *
>>> 39:  * @apiNote
>>> 40:  * This permission cannot be used for controlling access to resources anymore
>> 
>> Unnecessary "anymore"
>
> Removed this word from all `Permission` subclasses; fix will be in next update.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/44b552adb68d9aae1e72ed7bf20feb81552014c8

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819109553

From mullan at openjdk.org  Mon Oct 28 14:03:05 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:05 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <MCGUYtIT23K7W16rxcBd1daw9mpMeqYpQ8Hki50NKaQ=.0f8f8488-24be-441e-9195-a9ddb63b3b69@github.com>

On Mon, 21 Oct 2024 22:57:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 338:
> 
>> 336: 
>> 337:     public static enum TestCase {
>> 338:         UNSECURE;
> 
> Better to drop this enum entirely.   Simply call `FieldSetAccessibleTest::run` as it's the only test case.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/e50cf64d771ed12de20e0a0500dc92f2e8a0abe4

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819096279

From mullan at openjdk.org  Mon Oct 28 14:03:06 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:06 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
 <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>
Message-ID: <fTgvcpw5HqiI30y5Z2jb5QjrdO2A7ZB-xKxi-elxDoo=.f9a20ad6-15ca-45ba-8d0d-09eef26f2df8@github.com>

On Tue, 22 Oct 2024 20:55:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
>> 
>>> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>>> 48:     }
>>> 49: 
>> 
>> Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...
>
> Updated

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

>> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:
>> 
>>> 115:             }
>>> 116:             popup.setVisible(false);
>>> 117:             frame.dispose();
>> 
>> The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..
>
> Updated

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819100037
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819104451

From mullan at openjdk.org  Mon Oct 28 14:03:08 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:08 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
 <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>
Message-ID: <0WKxUeUG7NcPFjIQDAKyMj2Q-zqjGzuDbgojtkuu-LA=.fbf49390-45aa-4238-84c7-ff8e18bdf74c@github.com>

On Tue, 22 Oct 2024 21:01:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> I guess we can test this without SM since it tests SwingLazyValue?
>
> I believe I had removed this test because it wasn't testing anything significant. But I have re-added it please re-review and let me know if it holds value to be retained.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819105638

From mullan at openjdk.org  Mon Oct 28 14:08:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:08:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
 <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>
Message-ID: <Fq8YAL6u5aQpBWsTKacnyqmH2to-keqqUMZlRfCMUU4=.4267c4b9-3527-463b-a5d4-8e582ccf0dd5@github.com>

On Wed, 23 Oct 2024 13:07:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:
>> 
>>> 340:         throws Exception
>>> 341:     {
>>> 342:         action.run();
>> 
>> testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?
>
> Good point. Similarly, the URLPermission[] parameter is now always unused, so maybe I should get rid of that too.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/82bb0d8207334d6072277e596fb16228f397fb77 and https://github.com/openjdk/jdk/pull/21498/commits/34439751f1b26e6ff1705e35f269e260401233af

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819119422

From duke at openjdk.org  Mon Oct 28 14:11:16 2024
From: duke at openjdk.org (duke)
Date: Mon, 28 Oct 2024 14:11:16 GMT
Subject: Withdrawn: 8334761: Source launcher fails with
 "Module reads more than one module named" error
In-Reply-To: <Z4pUQl32mdsgohdS6c9QWvq1XBz1PBMaIYtfAFMMi_w=.20c39189-1faf-457f-b063-136b11909bee@github.com>
References: <Z4pUQl32mdsgohdS6c9QWvq1XBz1PBMaIYtfAFMMi_w=.20c39189-1faf-457f-b063-136b11909bee@github.com>
Message-ID: <8G-94886TyBqx7wxqunZtUbV59woYjdktgsKzn7qu98=.2c9aad18-caf4-48ea-9f21-c377fb1c59fd@github.com>

On Sat, 22 Jun 2024 10:19:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to fix the setup of the optional module layer for user-supplied modules.
> 
> This fix is composed of two parts:
> - modules already resolved in the boot layer are no longer part of the parent layer
> - the parent layer configuration does no longer bind services

This pull request has been closed without being integrated.

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

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

From abimpoudis at openjdk.org  Mon Oct 28 14:11:53 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 28 Oct 2024 14:11:53 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v3]
In-Reply-To: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
Message-ID: <Hm5J1fGXwVi8a0xZa9NHbZjio32k8DKiYgUkX_0ikBA=.f0286442-8ab9-4eaa-b79a-5bd5888caa72@github.com>

> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
> 
> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
> 
> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21687/files
  - new: https://git.openjdk.org/jdk/pull/21687/files/4b0d560b..c51e7385

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

  Stats: 24 lines in 2 files changed: 5 ins; 10 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21687/head:pull/21687

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

From abimpoudis at openjdk.org  Mon Oct 28 14:11:53 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 28 Oct 2024 14:11:53 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v2]
In-Reply-To: <rE8X2c6980Qnuol3d9g3Y02X9KkpwAfHZ2dUzXiWgRE=.3e0644d3-0fe2-4e67-985b-7fa35f968b79@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <zwYOHSPtflMwo3EjdK4V5xcUpYAix1V5l1Loo6eqbiU=.8d3062c6-b09b-4093-9b21-e0c1741b6f15@github.com>
 <RoZjaobLuGglsOzFGe1--zDvQ0_kaQJzxvdRom4Pr1U=.8d9bb108-df00-4507-b5fa-769e68b7eef2@github.com>
 <rE8X2c6980Qnuol3d9g3Y02X9KkpwAfHZ2dUzXiWgRE=.3e0644d3-0fe2-4e67-985b-7fa35f968b79@github.com>
Message-ID: <8FC4eaiL4wGLpsQy7G3O66c5VwlCk7PiOMsK237XpIo=.f9f67a4d-3875-4f7b-861e-1a1d5013b250@github.com>

On Fri, 25 Oct 2024 15:11:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> side: not sure if the dedup effort is worthy at the end in terms of performance / class file reduction / maintenance
>
>> side: not sure if the dedup effort is worthy at the end in terms of performance / class file reduction / maintenance
> 
> Good point - these deduplication tests are rather painful to maintain every time the compiler is changed (I had to fight with them as well when writing the revamped backend support for flexible constructor bodies). I share the general feeling of a slightly negative cost vs. benefit ratio -- but I don't have any backing evidence (maybe we should gather that up).

I addressed the review. One thing that I didn't yet change is `visitVarDef` after @mcimadamore's https://github.com/openjdk/jdk/pull/21687#discussion_r1816527035

@cushon what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2441699015

From mullan at openjdk.org  Mon Oct 28 14:16:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <ggccis0uu3BN3Kmofv1RlWFK8QykntW4i06p84FMTy8=.58430444-17a6-4a6e-b983-92588d6e21d5@github.com>

On Fri, 25 Oct 2024 20:34:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 489:
>> 
>>> 487: 
>>> 488:     /**
>>> 489:      * Adds a provider to the next position available..
>> 
>> Two periods at the end.
>
> Will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ed0f5c07f2bf3f3d7636533a77e8455d66bbf8b8

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819146725

From mullan at openjdk.org  Mon Oct 28 14:16:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com>

On Thu, 24 Oct 2024 15:01:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1612:
> 
>> 1610:      * obtained.  The {@code String} value of this property is then
>> 1611:      * interpreted as a {@code Font} object according to the
>> 1612:      * specification of {@code Font.decode(String)}
> 
> Suggestion:
> 
>      * specification of {@code Font.decode(String)}.
> 
> Period is missing.

Not part of this change, can be fixed later as a follow-on cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819134820

From mullan at openjdk.org  Mon Oct 28 14:16:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>
Message-ID: <_-G-fWk2aAwcuoiLUlzkkNJ5ShuRx8dAOtOGfL1c9IE=.777bfd82-b0a6-43f3-a761-c9bcfe962553@github.com>

On Thu, 24 Oct 2024 19:33:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java line 342:
> 
>> 340:         /*
>> 341:          * There is no security manager, so disable access to RMI class
>> 342:          * loaders and use the would-de parent instead.
> 
> Fix typo "would-de" -> "would-be".

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/0f448e5fabac7941cd1b551aa1cc9ade773814ff

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819144885

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <GjxEiU7FQ9j_4EDb6nAwuApuvgHg6nlgwF-nGm0N5-w=.bf1d5c89-f5df-4a6c-aeed-50c382b5dd3c@github.com>

On Fri, 25 Oct 2024 20:48:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
>> 
>>> 30: 
>>> 31: /**
>>> 32:  * AccessControlContext was used with a SecurityManager for access control decisions
>> 
>> I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.
>
> Right, it should be "the Security Manager", but we can also link to the `SecurityManager` class as plain text.  I'll make some wording changes to this class and `AccessController`.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/275dabd4dbc8f443901dc5d82b281111dcbf15e6

>> src/java.base/share/classes/java/security/Policy.java line 374:
>> 
>>> 372:      *
>>> 373:      * @param codesource the CodeSource to which the returned
>>> 374:      *          PermissionCollection has been granted
>> 
>> Can we say this parameter is ignored? I see some other methods said so.
>> 
>> Same with the other `getPermissions` and `implies`.
>
> Yes, good suggestion.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/4981da0fe50919e60cc036371f8bc8d7ee153849

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819165566
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819166630

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
 <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>
Message-ID: <XMB2uyJSxzLDYmcYCxZ4_cGg3oS5gtRnksKaPr3GsBA=.8773b0cf-910b-4d29-b049-8ffea2cc4846@github.com>

On Fri, 25 Oct 2024 23:45:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.
>
> I see. Maybe this is enough.

Actually, I changed the message to "checking permissions is not supported" which is the same as the exception message of`Permission.checkGuard` and `AccessController.checkPermission`.

https://github.com/openjdk/jdk/pull/21498/commits/b6fe405dbbe8ec19a18174bc48dd649feca3d6aa

>> You mean move the first sentence of the deprecated text to here?
>
> Oh, I just meant the class spec should have a body text. This is similar to my previous comment on the `Policy` class.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/09b6cd602c1f2c7998ed824878c5f5f43be69075

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819161320
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819162666

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <5cNNcS3nKl9Xq1oRJl6UR0Hsa7TScT14a1vA0YsNcO4=.515dbc77-19b3-425d-88d3-5752f3916eca@github.com>

On Fri, 25 Oct 2024 21:02:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Policy.java line 90:
>> 
>>> 88:  *       and subject to removal in a future release. Consequently, this class
>>> 89:  *       is also deprecated and subject to removal. There is no replacement for
>>> 90:  *       the Security Manager or this class.
>> 
>> Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.
>
> Yes, we should be consistent. The deprecated text always comes first, and sometimes we want to say immediately why this class is not useful anymore in that text instead of later, further down. I don't know which is better. I guess I'll go with your suggestion just so it looks more like a normal class.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/09b6cd602c1f2c7998ed824878c5f5f43be69075

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819163498

From mullan at openjdk.org  Mon Oct 28 14:26:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <s11CKR8J4p4OO6MhnvG9htT8gCepixeepGrWXpTkb6o=.56e88ee6-6436-4d6e-8056-a9e23d2d66de@github.com>

On Thu, 24 Oct 2024 15:04:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1780:
> 
>> 1778:      * <p>
>> 1779:      * The property value should be one of the forms accepted by
>> 1780:      * {@code Font.decode(String)}
> 
> Suggestion:
> 
>      * {@code Font.decode(String)}.
> 
> Period is missing.

Not part of this change, can be fixed later as a follow-on cleanup.

> src/java.desktop/share/classes/java/beans/Expression.java line 1:
> 
>> 1: /*
> 
> Needs copyright year update.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

> test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java line 1:
> 
>> 1: /*
> 
> Copyright year needs updating.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

> test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java line 1:
> 
>> 1: /*
> 
> Copyright years need updating.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819152998
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819155061
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819156309
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819156796

From vromero at openjdk.org  Mon Oct 28 14:50:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Oct 2024 14:50:37 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview)
In-Reply-To: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
References: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
Message-ID: <qHbiyABQE41D7ZgXUrQ71OH0G5Q6g2-YCj_DbTY6VOk=.e6066d90-6078-432f-b0bc-8b2eaa0a4c50@github.com>

On Wed, 16 Oct 2024 14:18:44 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR prepares the improvement for JEP 488.
> 
> The proposed approach is described in the CSR.
> 
> In terms of compiler implementation, we add the related translation in `TransPatterns`. Interestingly, this issue would be ideally addressed in `TransTypes`. However, there are some conveniences in `TransPatterns` that would need to be pulled into `TransTypes` to make this work: 1) the dependency to `makeBinary` and transitively to `operators` and 2) a lot of ceremony around `currentMethodSym` is already setup nicely in `TransPatterns`.

test/langtools/tools/javac/patterns/PrimitiveTypesInTestingContextErasure.java line 1:

> 1: import java.util.List;

nit: this import seems to be out of place

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21539#discussion_r1819204784

From mullan at openjdk.org  Mon Oct 28 14:51:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
 <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>
Message-ID: <2jF7R61_yDPlFJ9Mh9c9RW-TDvtp4UPDj2OrU1--r4M=.9359f0c1-76e1-4287-8d53-05903baa6f25@github.com>

On Fri, 25 Oct 2024 23:58:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 
>> 
>> Yes I think we can remove that text.
>> 
>>> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?
>> 
>> You mean a warning like we have in the `Permission` subclasses?
>> 
>> `URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.
>
> Sorry, I got it wrong. I thought this `return new Permissions()` is something new. In fact, it was there before this change.
> 
> On the other hand, I looked at its subclasses and their `getPermissions(CodeSource cs)` could return quite complicated permission collections. I assume it does not really matter since they are all useless now, right?

I removed the text "permissions which are retrieved by the system policy by default" from the class description and added an API note that permissions cannot be used to control access to resources. See https://github.com/openjdk/jdk/pull/21498/commits/8b527c90e434e63fd00a719aedda50d8d27e93b5

> On the other hand, I looked at its subclasses and their getPermissions(CodeSource cs) could return quite 
> complicated permission collections. I assume it does not really matter since they are all useless now, right?

Yes, although I would prefer to handle those as follow-on issues, I filed one for `URLClassLoader`: https://bugs.openjdk.org/browse/JDK-8343150

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819210679

From mullan at openjdk.org  Mon Oct 28 14:51:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <ecXA9z7pXC8iHPzwyo5ZNBiptYS950MNZdm3yjHFd-Y=.f95ed696-c762-40f2-9079-e218b36f164b@github.com>

On Thu, 24 Oct 2024 15:57:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/beans/PropertyEditorManager.java line 71:
> 
>> 69:      *
>> 70:      * @param targetType   the class object of the type to be edited
>> 71:      * @param editorClass  the class object of the editor classs
> 
> Suggestion:
> 
>      * @param editorClass  the class object of the editor class
> 
> Typo with an extra ?s?. The line should remain unchanged.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

> src/java.desktop/share/classes/javax/swing/WindowConstants.java line 1:
> 
>> 1: /*
> 
> Needs updating the copyright year.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819200392
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819172129

From mullan at openjdk.org  Mon Oct 28 14:51:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
 <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>
Message-ID: <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@github.com>

On Fri, 25 Oct 2024 23:20:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
>> I can update the test summary accordingly  -
>>  **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**
>> 
>> @azuev-java Your thoughts?
>
> That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/934e1c28f783b32c43e6977f0e1ba6e1c68f810f

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819186623

From mullan at openjdk.org  Mon Oct 28 14:51:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>
Message-ID: <IaFWniwJ0ayT2cKcMKQ3OSQfgSbE6Cdm_vACx8gYhNQ=.6ac87108-0c02-4e7f-a85c-b1c140e78512@github.com>

On Fri, 25 Oct 2024 20:31:40 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
>> 
>>> 1: /*
>> 
>> I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.
>> 
>> If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.
>> 
>> The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.
>
> This test was initially deleted but then restored based on the following comment - https://github.com/openjdk/jdk/pull/21498#discussion_r1810297085
> 
> Since this test falls under similar category as test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java and based on your suggestion, I think we can delete it if it doesn't hold value after SM removal.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/aca9555a0b697bd9829224396a5448c88057009d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819190841

From mullan at openjdk.org  Mon Oct 28 14:51:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
 <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
 <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>
Message-ID: <3UWYFypKVUDbFKF8O3Q1XuygK6WoWNs50jtx7yQooR4=.c7f4127d-2927-4750-8983-be5b7d163883@github.com>

On Fri, 25 Oct 2024 18:52:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk 
>> On macOS, popup is shifted up and does not cover the taskbar even without SM. 
>> 
>>> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
>> 
>> On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?
>
> The pop is shifted up on macOS because `LWCToolkit` returns `false` in `canPopupOverlapTaskBar`:
> 
> https://github.com/openjdk/jdk/blob/36d71735e3554264e8d17f7e0e72999ac639e398/src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java#L900-L902
> 
> On Windows, apps can control the area where they want a popmenu display or exclude an area of the screen. At the same time, Firefox displays its right-click menu over the taskbar if the menu fits when dropped down. A native Win32 app with a menu bar displays popup menus over the taskbar if it fits on the screen; some menus could open upwards if their items don't fit on the screen to display downwards (I attached a screenshot to JBS). Popup menus in Win32 Notepad (the version in Windows 10) displays it's right-click menu over the taskbar if it fits.
> 
> At the same time, right-click menu of a window title never displays over the taskbar, the menu opens upward if it doesn't fit without covering part of the taskbar.
> 
> I'm pretty sure the default return value of `true` from `SunToolkit.canPopupOverlapTaskBar` isn't something that was chosen accidentally.
> 
> Windows applications may avoid showing popup over the taskbar (confining the popups inside the work area, see [`SystemParametersInfoW`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow) and `SPI_GETWORKAREA`). We can change the behaviour of the JDK.
> 
> Yet the failure of `bug6694823.java` without the security manager isn't a product bug in my opinion.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/aca9555a0b697bd9829224396a5448c88057009d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819180850

From mullan at openjdk.org  Mon Oct 28 15:09:54 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 15:09:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <di3QwjPshatki7F1k9zaiWfs8C5lgRBvLiYnMGXdmYE=.b95d7132-856f-4fbf-a7b1-818ed02d144d@github.com>

On Fri, 25 Oct 2024 20:59:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 125:
> 
>> 123:     }
>> 124: 
>> 125:     @Benchmark
> 
> Is this benchmark still useful if it is not comparing the SM vs the Non-SM case?

`ProtectionDomain` has not been deprecated and classes are still populated with PDs w/o an SM, so it may still have some value for measuring performance and detecting regressions/improvements.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819242889

From vromero at openjdk.org  Mon Oct 28 15:17:55 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Oct 2024 15:17:55 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview)
In-Reply-To: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
References: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
Message-ID: <glF8XyAQnPSRfZEzJ3_AP0VvcWmCIlvSYyqLEFu_tBE=.911d9f35-ebae-47ad-a910-e1717fa4bb66@github.com>

On Wed, 16 Oct 2024 14:18:44 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR prepares the improvement for JEP 488.
> 
> The proposed approach is described in the CSR.
> 
> In terms of compiler implementation, we add the related translation in `TransPatterns`. Interestingly, this issue would be ideally addressed in `TransTypes`. However, there are some conveniences in `TransPatterns` that would need to be pulled into `TransTypes` to make this work: 1) the dependency to `makeBinary` and transitively to `operators` and 2) a lot of ceremony around `currentMethodSym` is already setup nicely in `TransPatterns`.

test/langtools/tools/javac/patterns/PrimitiveTypesInTestingContextErasure.java line 30:

> 28:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Second Preview)
> 29:  * @enablePreview
> 30:  * @compile PrimitiveTypesInTestingContextErasure.java

I don't think you need the `@compile` and the `@run` commands `@enablePreview` should be enough

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21539#discussion_r1819239416

From abimpoudis at openjdk.org  Mon Oct 28 15:24:23 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 28 Oct 2024 15:24:23 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview) [v2]
In-Reply-To: <qHbiyABQE41D7ZgXUrQ71OH0G5Q6g2-YCj_DbTY6VOk=.e6066d90-6078-432f-b0bc-8b2eaa0a4c50@github.com>
References: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
 <qHbiyABQE41D7ZgXUrQ71OH0G5Q6g2-YCj_DbTY6VOk=.e6066d90-6078-432f-b0bc-8b2eaa0a4c50@github.com>
Message-ID: <0VWPg7ba_KgS9dsu3EoGfpA5erMZVexJa49EezhLDD4=.4c423288-135a-4940-acd1-09684289aa4b@github.com>

On Mon, 28 Oct 2024 14:46:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> test/langtools/tools/javac/patterns/PrimitiveTypesInTestingContextErasure.java line 1:
> 
>> 1: import java.util.List;
> 
> nit: this import seems to be out of place

Also moved it. Thx!

> test/langtools/tools/javac/patterns/PrimitiveTypesInTestingContextErasure.java line 30:
> 
>> 28:  * @summary Compiler Implementation for Primitive types in patterns, instanceof, and switch (Second Preview)
>> 29:  * @enablePreview
>> 30:  * @compile PrimitiveTypesInTestingContextErasure.java
> 
> I don't think you need the `@compile` and the `@run` commands `@enablePreview` should be enough

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21539#discussion_r1819263030
PR Review Comment: https://git.openjdk.org/jdk/pull/21539#discussion_r1819262714

From vromero at openjdk.org  Mon Oct 28 15:24:22 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Oct 2024 15:24:22 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview) [v2]
In-Reply-To: <QmLzC5yRtKwMH56AQ7zMbmXTVBacD0a_UCZyzZxkYhM=.156e7bf7-102c-48f1-be0f-41efd646006c@github.com>
References: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
 <QmLzC5yRtKwMH56AQ7zMbmXTVBacD0a_UCZyzZxkYhM=.156e7bf7-102c-48f1-be0f-41efd646006c@github.com>
Message-ID: <1KwfLZYpw8hPrxq93xWqRb9Kax6lBZAdRjkEeWMNd5k=.e0c6ae73-1f15-460a-8dee-f4958b6fcbdd@github.com>

On Mon, 28 Oct 2024 15:21:42 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR prepares the improvement for JEP 488.
>> 
>> The proposed approach is described in the CSR.
>> 
>> In terms of compiler implementation, we add the related translation in `TransPatterns`. Interestingly, this issue would be ideally addressed in `TransTypes`. However, there are some conveniences in `TransPatterns` that would need to be pulled into `TransTypes` to make this work: 1) the dependency to `makeBinary` and transitively to `operators` and 2) a lot of ceremony around `currentMethodSym` is already setup nicely in `TransPatterns`.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21539#pullrequestreview-2399420856

From abimpoudis at openjdk.org  Mon Oct 28 15:24:22 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 28 Oct 2024 15:24:22 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview) [v2]
In-Reply-To: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
References: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
Message-ID: <QmLzC5yRtKwMH56AQ7zMbmXTVBacD0a_UCZyzZxkYhM=.156e7bf7-102c-48f1-be0f-41efd646006c@github.com>

> This PR prepares the improvement for JEP 488.
> 
> The proposed approach is described in the CSR.
> 
> In terms of compiler implementation, we add the related translation in `TransPatterns`. Interestingly, this issue would be ideally addressed in `TransTypes`. However, there are some conveniences in `TransPatterns` that would need to be pulled into `TransTypes` to make this work: 1) the dependency to `makeBinary` and transitively to `operators` and 2) a lot of ceremony around `currentMethodSym` is already setup nicely in `TransPatterns`.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21539/files
  - new: https://git.openjdk.org/jdk/pull/21539/files/cd4f288e..c056b439

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

  Stats: 8 lines in 1 file changed: 3 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21539/head:pull/21539

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

From javalists at cbfiddle.com  Mon Oct 28 15:49:48 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 28 Oct 2024 08:49:48 -0700
Subject: testing the -target option
Message-ID: <4B0CE760-AEE0-46E6-A479-961A7AD22D59@cbfiddle.com>

I?m curious to know how the javac -target option is tested. I can think of several possibilities, but am wondering what actually is done.

(I did not find any discussion of this issue in the online project docs.)

A few questions:

* Is javac -target required to generate the same byte code as the target javac?

* Is javac -target required to generate the same error messages as the target javac?

* Are there negative tests to verify that language features introduced in later releases are rejected?

* How frequently are the tests typically run?

Thank you.

  Alan


From javalists at cbfiddle.com  Mon Oct 28 15:49:48 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 28 Oct 2024 08:49:48 -0700
Subject: testing the -target option
Message-ID: <4B0CE760-AEE0-46E6-A479-961A7AD22D59@cbfiddle.com>

I?m curious to know how the javac -target option is tested. I can think of several possibilities, but am wondering what actually is done.

(I did not find any discussion of this issue in the online project docs.)

A few questions:

* Is javac -target required to generate the same byte code as the target javac?

* Is javac -target required to generate the same error messages as the target javac?

* Are there negative tests to verify that language features introduced in later releases are rejected?

* How frequently are the tests typically run?

Thank you.

  Alan


From honkar at openjdk.org  Mon Oct 28 18:14:53 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 28 Oct 2024 18:14:53 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
Message-ID: <UibYchrEh4IMGTL2M1YjvpMysipL1Clnov5XIuBs9zg=.d2006057-0749-4a3e-b194-3a3d512d0e5e@github.com>

On Fri, 25 Oct 2024 18:09:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> I've looked through the changes to `java.desktop` module and to tests under `java/awt`, `java/beans`, `javax/accessibility`, `javax/sound`, `javax/swing`, `com/sun/java/accessibility` (removed).

@aivanov-jdk Clientlibs review comments have been addressed and updated. Please re-review when you get a chance.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2442286841

From honkar at openjdk.org  Mon Oct 28 18:14:54 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 28 Oct 2024 18:14:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
 <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
Message-ID: <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>

On Fri, 25 Oct 2024 22:52:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).
>
> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used.
> But I don't see a problem with keeping the rest of the test.

Test updated in sandbox - https://github.com/openjdk/jdk-sandbox/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819521798

From vromero at openjdk.org  Mon Oct 28 18:18:15 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Oct 2024 18:18:15 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v18]
In-Reply-To: <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
Message-ID: <Wo4XoxExBvd2BiVx-kRpCBMONLTVl78aoacoHbsROS4=.33ae43d3-fbbb-4afa-b85b-26af45e1e073@github.com>

On Sat, 26 Oct 2024 14:04:55 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove trailing whitespaces
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - address review comments

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 80:

> 78:      */
> 79:     @Test
> 80:     public void otherTopLevelPrivateClassFails() throws Exception {

this test is failing for me (Linux):


Expected errors: [S.java:5:25: compiler.err.report.access: S.A, private, S, 1 error], 
but got: [S.java:4:25: compiler.err.report.access: S.A, private, S, 1 error]

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1819529873

From bchristi at openjdk.org  Mon Oct 28 18:28:01 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 18:28:01 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <yPy9DNlPYRyWTHBE5WWerf-MwhvFPW0tXLeaEQ-ZB8s=.bf67126c-a0fd-436e-ac50-60ba35dd8923@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

java.prefs changes look good. (No prefs tests were changed.)

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2397377427

From bchristi at openjdk.org  Mon Oct 28 18:28:04 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 18:28:04 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java line 93:

> 91:  * static {@link ThreadLocal} instance.  Authors of such implementations are
> 92:  * <i>strongly</i> encouraged to determine the user at the time preferences
> 93:  * are accessed (for example by the {@link #get(String,String)} or {@link

Most of this seems like it will remain applicable. Of course we won't suggest throwing `SecurityException`. But users not having sufficient OS-level privileges will still need to be addressed, yes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817954250

From prr at openjdk.org  Mon Oct 28 18:44:19 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Oct 2024 18:44:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <22AJ3u3UiSxFqANDpVqeJV3-H54pfkjt4YfbhbQ_T2Q=.8228b822-dd85-436d-a208-ff15995098eb@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

The client/desktop related src and test changes have all now been reviewed by at least one client/desktop engineer.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2399915245

From joe.darcy at oracle.com  Mon Oct 28 19:00:09 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 28 Oct 2024 12:00:09 -0700
Subject: testing the -target option
In-Reply-To: <4B0CE760-AEE0-46E6-A479-961A7AD22D59@cbfiddle.com>
References: <4B0CE760-AEE0-46E6-A479-961A7AD22D59@cbfiddle.com>
Message-ID: <464e9598-4c67-4833-842f-7b454888dc01@oracle.com>

On 10/28/2024 8:49 AM, Alan Snyder wrote:
> I?m curious to know how the javac -target option is tested. I can think of several possibilities, but am wondering what actually is done.


You can satisfy your curiosity by looking the the javac regressions 
tests in the OpenJDK repo. Under

https://github.com/openjdk/jdk

see the test/langtools/tools/javac directory hierarchy.


>
> (I did not find any discussion of this issue in the online project docs.)
>
> A few questions:
>
> * Is javac -target required to generate the same byte code as the target javac?

No.

>
> * Is javac -target required to generate the same error messages as the target javac?

No.

>
> * Are there negative tests to verify that language features introduced in later releases are rejected?

Yes.

> * How frequently are the tests typically run?

All the time. The javac tests are part of the "tier 1" tests of OpenJDK 
and are run by the CI systems for (effectively) every push.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241028/51606052/attachment.htm>

From bchristi at openjdk.org  Mon Oct 28 19:05:46 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 19:05:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <MVzDG3v00pr-BbVREYbr2PXIfV-ChDESYKHwRqlWVTQ=.9fc15703-9e3a-439d-aa88-f8b06f71fac2@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

src/java.base/share/classes/java/util/concurrent/Executors.java line 400:

> 398:      * AccessControlContext and contextClassLoader of new threads to
> 399:      * be the same as the thread invoking this
> 400:      * {@code privilegedThreadFactory} method.  A new

We no longer state that the contextClassLoader is set, though `PrivilegedThreadFactory` _does_ still set the ccl. Is this OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819601556

From bchristi at openjdk.org  Mon Oct 28 19:19:52 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 19:19:52 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

src/java.base/share/classes/java/util/concurrent/Executors.java line 529:

> 527:      * execute the given {@code callable} under the current access
> 528:      * control context, with the current context class loader as the
> 529:      * context class loader. This method should normally be invoked

We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819618471

From rriggs at openjdk.org  Mon Oct 28 20:14:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Oct 2024 20:14:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

Reviewed all tests under test/jaxp/javax/xml/jaxp.
A few imports moved around unnecessarily but otherwise looks fine.

test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeTest.java line 53:

> 51: import org.w3c.dom.Node;
> 52: import org.w3c.dom.NodeList;
> 53: import static jaxp.library.JAXPTestUtilities.USER_DIR;

The import change was unnecessary.

test/jaxp/javax/xml/jaxp/unittest/sax/Bug7057778Test.java line 48:

> 46: import org.xml.sax.XMLReader;
> 47: import org.xml.sax.ext.DefaultHandler2;
> 48: import static jaxp.library.JAXPTestUtilities.USER_DIR;

Keep imports JAXPTestUtilities imports together.

test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/EventReaderTest.java line 32:

> 30: import javax.xml.stream.XMLStreamException;
> 31: import javax.xml.stream.events.StartDocument;
> 32: import static org.testng.Assert.assertEquals;

Import change is unnecessary.

test/jaxp/javax/xml/jaxp/unittest/validation/Bug6925531Test.java line 52:

> 50:             + "        targetNamespace='jaxp13_test'\n"
> 51:             + "        elementFormDefault='qualified'>\n"
> 52:             + "    <element name='test' type='string'/>\n"

Would be a good use for multi-line strings.   """ """
But not worth changing.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathPrecedingTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.

no change necessary

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2399985101
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819611468
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819667734
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819672433
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819646448
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819624631

From darcy at openjdk.org  Mon Oct 28 20:59:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Oct 2024 20:59:51 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
Message-ID: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>

Get JDK 24 underway.

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

Commit messages:
 - Update copyright.
 - Updated problem list after bug fix.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Temporarily problem list java.lang.instrument tests until jar generation is fixed.
 - Merge branch 'master' into JDK-8330188
 - Update symbol files for JDK 23 build 25.
 - Correct release year.
 - Merge branch 'master' into JDK-8330188
 - Add symbol files current with JDK 23 build 24.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/4369856c...f4a5026b

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330182
  Stats: 2083 lines in 50 files changed: 2019 ins; 7 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

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

From iris at openjdk.org  Mon Oct 28 20:59:54 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 28 Oct 2024 20:59:54 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
Message-ID: <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.17ca9593-555c-40cb-8db7-2370b87afd1f@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

The copyright year was  not updated in all files *14.java.  I assume that's intentional. 

I've also Reviewed the associated CSRs.

Marked as reviewed by iris (Reviewer).

Marked as reviewed by iris (Reviewer).

Still looks good.

Marked as reviewed by iris (Reviewer).

Marked as reviewed by iris (Reviewer).

make/conf/version-numbers.conf line 36:

> 34: DEFAULT_VERSION_EXTRA2=0
> 35: DEFAULT_VERSION_EXTRA3=0
> 36: DEFAULT_VERSION_DATE=2024-03-17

"2024-03-17"?  I thought that the expected date was "2025-03-18"?

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2002002355
PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2006604933
PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2030298396
PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2067401131
PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2089018766
PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2099585754
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1566336599

From vromero at openjdk.org  Mon Oct 28 20:59:56 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Oct 2024 20:59:56 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
Message-ID: <8gjzk6jIhtLXgFgNO4udYRJaCCZkto2IE9ETZYZeSig=.9af49a59-3943-4516-a0a5-3d657286833b@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2004323374

From asotona at openjdk.org  Mon Oct 28 20:59:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Oct 2024 20:59:56 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
Message-ID: <nOjs6B6AtCkTvGxO2FN_89dFz4vA9d5Od9_gzq0X7p4=.40c9e062-4041-45cf-89fb-9720e29dc8b6@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

ClassFile changes are OK.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2005504192

From dholmes at openjdk.org  Mon Oct 28 20:59:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 20:59:56 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
Message-ID: <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.aadbda6e-2651-4f49-a8b9-cce99d7ff9d6@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

LGTM

Thanks

test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 1:

> 1: /*

There are further updates to this test in the pipeline (new deprecated flags in 23) so you will need to keep updating to reflect that.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2016422206
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1575750313

From darcy at openjdk.org  Mon Oct 28 20:59:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Oct 2024 20:59:56 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
Message-ID: <qZnKYgjUvvMiD9WCCV0lbTTyFKAymG1KEVKRZWkhIW4=.5aac15cf-45cc-4f34-8db4-211f7d9d3b11@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

This initial version of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see.

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

PR Comment: https://git.openjdk.org/jdk/pull/18787#issuecomment-2057615983

From darcy at openjdk.org  Mon Oct 28 20:59:57 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Oct 2024 20:59:57 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.17ca9593-555c-40cb-8db7-2370b87afd1f@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
 <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.17ca9593-555c-40cb-8db7-2370b87afd1f@github.com>
Message-ID: <TfadiV_C_pOGf2x7nI1pH2xU5UlQUF05uhZoD0bnCLg=.faf9ddb5-d96b-46ca-bc3c-1e81578a591e@github.com>

On Mon, 15 Apr 2024 19:57:49 GMT, Iris Clark <iris at openjdk.org> wrote:

> The copyright year was not updated in all files *14.java. I assume that's intentional.

I'll run my copyright update script before pushing.

> I've also Reviewed the associated CSRs.

Thanks.

> make/conf/version-numbers.conf line 36:
> 
>> 34: DEFAULT_VERSION_EXTRA2=0
>> 35: DEFAULT_VERSION_EXTRA3=0
>> 36: DEFAULT_VERSION_DATE=2024-03-17
> 
> "2024-03-17"?  I thought that the expected date was "2025-03-18"?

Thanks for catching that; yes, I'll correct and double-check the expected GA date in the next push.

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

PR Comment: https://git.openjdk.org/jdk/pull/18787#issuecomment-2057735741
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1566383373

From liach at openjdk.org  Mon Oct 28 20:59:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Oct 2024 20:59:58 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
Message-ID: <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.86f3739d-d9b3-4cf7-813e-0c4bc55b2ccc@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:

> 1479:     int JAVA_23_VERSION = 67;
> 1480: 
> 1481:     /** 68 */

We need `@since 24` here.

src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:

> 1: #

Just curious, does CreateSymbols not track module migrations, now that jdk.incubator.foreign is completely merged into java.base?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1567955182
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1621274290

From darcy at openjdk.org  Mon Oct 28 20:59:58 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Oct 2024 20:59:58 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.86f3739d-d9b3-4cf7-813e-0c4bc55b2ccc@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
 <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.86f3739d-d9b3-4cf7-813e-0c4bc55b2ccc@github.com>
Message-ID: <fWBlbS1URCHC3BnuvEYl2Z3OXrbnkEFeGtQgUEW5MuQ=.8ae60b98-07fe-4a40-82b6-96056c8b8f54@github.com>

On Tue, 16 Apr 2024 21:21:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:
> 
>> 1479:     int JAVA_23_VERSION = 67;
>> 1480: 
>> 1481:     /** 68 */
> 
> We need `@since 24` here.

Ah, good catch; looks like I was treating that as an internal API element when it is indeed a public API element. I've filed JDK-8330458 to fix-up the Java 23 constant as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1568231344

From jlahoda at openjdk.org  Mon Oct 28 20:59:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 28 Oct 2024 20:59:59 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.86f3739d-d9b3-4cf7-813e-0c4bc55b2ccc@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
 <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.86f3739d-d9b3-4cf7-813e-0c4bc55b2ccc@github.com>
Message-ID: <Nk3avVtqWTHpYmwBk8wXj5zyBThclSzR9kSgCvaDEuM=.1ec48f6b-dea2-42c3-9165-98c6d5b61f7d@github.com>

On Thu, 30 May 2024 18:39:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:
> 
>> 1: #
> 
> Just curious, does CreateSymbols not track module migrations, now that jdk.incubator.foreign is completely merged into java.base?

When writing these symbol files, CreateSymbols does not keep track where a given package was in a given version, and puts packages to files based on the first version where the package was first introduced. Technically, it should not matter, as the assignment of classes/packages to modules is not based on the file from which the description of the class was read. So, so far, it didn't seem necessary to keep track of package movement for writing of these files. But it is feasible to do so, if the need arises. (When writing ct.sym, it keeps track of the exact package module for every version, of course.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1621320340

From darcy at openjdk.org  Mon Oct 28 21:00:00 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Oct 2024 21:00:00 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.aadbda6e-2651-4f49-a8b9-cce99d7ff9d6@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
 <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.aadbda6e-2651-4f49-a8b9-cce99d7ff9d6@github.com>
Message-ID: <i6esXfmg7Qx3-KZZgjmszE9ZFHd5-qmZeCZW-YAlef8=.f820ae2b-1beb-473c-9ddc-d59468adaff0@github.com>

On Tue, 23 Apr 2024 07:03:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are further updates to this test in the pipeline (new deprecated flags in 23) so you will need to keep updating to reflect that.

Thanks @dholmes-ora ; acknowledged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1583479535

From darcy at openjdk.org  Mon Oct 28 21:00:03 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 28 Oct 2024 21:00:03 GMT
Subject: Integrated: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.adda241b-ccea-44c2-add3-547b39ede759@github.com>
Message-ID: <zvPepcUjjlzXf4oeagWHU5bC9dQaGuJlLvItYoII88U=.02130108-0a09-4836-a250-a306a01372af@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

This pull request has now been integrated.

Changeset: 75dc2f85
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75dc2f8518d0adea30f7065d6732b807c0220756
Stats:     2083 lines in 50 files changed: 2019 ins; 7 del; 57 mod

8330182: Start of release updates for JDK 24
8330183: Add SourceVersion.RELEASE_24
8330184: Add source 24 and target 24 to javac

Reviewed-by: iris, vromero, asotona, dholmes

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

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

From mullan at openjdk.org  Mon Oct 28 21:07:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 21:07:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:

> 1: /*

@wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?

test/jdk/javax/xml/crypto/dsig/TransformService/NullParent.java line 1:

> 1: /*

Missed a copyright update; will fix.

test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30:

> 28:  * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom
> 29:  * @compile -XDignore.symbol.file Marshal.java
> 30:  * @run main/othervm/java.security.policy==test.policy Marshal

With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main <test>" when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.

Also, missing a copyright update, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819757618
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819758300
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819756247

From bpb at openjdk.org  Mon Oct 28 21:33:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Oct 2024 21:33:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <3zWmdX5pdYRfq9hBJGyY-lDdhgs9xuZ2xPLLKgpPYzU=.81747961-8d9b-4488-b31e-37d6a5bf4003@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

The `java/nio/file` src and test changes look all right.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2442669945

From bchristi at openjdk.org  Mon Oct 28 22:10:15 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 22:10:15 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <HOiCwZKc-UJsz_0__Bzto-LuAGch7-AOdKyEs0xT_3Q=.248b7897-841e-4ad5-8f89-10a3e7cf8177@github.com>

On Fri, 25 Oct 2024 20:13:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java line 28:
> 
>> 26:  * @bug 6552961 6558429
>> 27:  * @summary Test privilegedCallable, privilegedCallableUsingCurrentClassLoader
>> 28:  * @run main PrivilegedCallables
> 
> There's nothing privileged here; the test should be renamed or deleted if it duplicates other non-privileged call tests.

`Executors.privilegedCallable()` and `Executors.privilegedCallableUsingCurrentClassLoader()` are still present in the `Executors` class (though deprecated for removal). This test should be removed when those methods are removed. In the meantime, the name of the test seems reasonable to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819824791

From alanb at openjdk.org  Tue Oct 29 06:36:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 06:36:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
Message-ID: <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>

On Mon, 28 Oct 2024 19:16:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
> 
>> 527:      * execute the given {@code callable} under the current access
>> 528:      * control context, with the current context class loader as the
>> 529:      * context class loader. This method should normally be invoked
> 
> We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?

That's a good observation. Although deprecated for removal, the wording should at least specify what it does for the period before it is removed. I'll come up with some spec wording for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820163200

From abimpoudis at openjdk.org  Tue Oct 29 09:52:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 29 Oct 2024 09:52:14 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v4]
In-Reply-To: <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>
Message-ID: <jDvCQrQ1j_WjC4Ku7-OU_870TVzb5faEkVukVyxlQmc=.093a4024-e311-4949-ac19-34c1af8a0758@github.com>

On Thu, 24 Oct 2024 06:40:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Updating PreviewFeature metadata
>  - Cleanup.
>  - Merge branch 'master' into JDK-8335989
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/964d8d22...94b8bf6d

Changes look good!

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2401321203

From stephan.herrmann at berlin.de  Tue Oct 29 11:39:33 2024
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 29 Oct 2024 12:39:33 +0100
Subject: disjoint or not disjoint?
Message-ID: <ba498f5d-0726-4c04-8362-bd26ccc8e83c@berlin.de>

Please consider this source:

public class X1 {
     sealed interface I permits C1 {}
     non-sealed class C1 implements I {}
     class C2 extends C1 {}
     class C3 {}
     I m2(int s, C3 c3) {
         return switch (s) {
             case 0 -> (I) c3;
             case 1 -> (C1) c3;
             case 2 -> (C2) c3;
             default -> null;
         };
     }
}

javac raises errors at case 1 and case 2 but not at case 0.

If we're reading the spec correctly, then also case 0 would be illegal:

* A class named C is disjoint from an interface named I if ...
   * C is freely extensible (?8.1.1.2), and I is sealed, and C is disjoint
     from all of the permitted direct subclasses and subinterfaces of I.

with C=C3, I=I we are asking if C3 is disjoint from C1.

* A class named C is disjoint from another class named D if (i) it is not the
   case that C <: D, and (ii) it is not the case that D <: C.

with C=C3 and D=C1 we asking C3 <: C1 and C1 <: C3, both being false.

Actually, in case 1 javac agrees with this last line of reasoning.


Do you agree that this is a bug in javac, or am I missing some subtlety?

thanks
Stephan

From jlahoda at openjdk.org  Tue Oct 29 12:34:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 29 Oct 2024 12:34:06 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v2]
In-Reply-To: <UKSV2IuPfz5TM7zCDs83LTUwmZsxbrha5wfz-wsBBFc=.9dbea7c3-6005-4bd8-b16f-2e11c0e94e45@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
 <UKSV2IuPfz5TM7zCDs83LTUwmZsxbrha5wfz-wsBBFc=.9dbea7c3-6005-4bd8-b16f-2e11c0e94e45@github.com>
Message-ID: <uah20vDZ4qWZ5WoYUL2MxXbkNO5ry2CX4n3XabYYeTk=.7d17fd91-61ee-48d9-b5d6-b46cb003d2cf@github.com>

On Wed, 23 Oct 2024 18:16:57 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I will update this PR and the CSR to fail if we detect an overflow, rather than warn users. Thanks Jan
> 
> Though I am not sure why the check would need to be done when writing the classfile, why not do it earlier?

Some of the existing similar "limit" errors are basically only detectable when writing the classfile. So, for consistency, I think it would be good to do it at some place close to where the other errors are detected.

In principle, the javac "frontend" should mostly care about JLS, and JLS is not imposing any limits. The backend, when writing, needs to care about JVMS, which imposes limits, and hence that's probably the correct place to report the error.

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

PR Comment: https://git.openjdk.org/jdk/pull/21663#issuecomment-2444080318

From jlahoda at openjdk.org  Tue Oct 29 12:34:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 29 Oct 2024 12:34:07 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v2]
In-Reply-To: <Z3U0APyGVCdhAxyQ2daKUcXkGBT97x9rT2eFKQyk95Y=.37091079-4a9b-4cf1-9a3f-fbecd4a10c2e@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <F9VzNw7pAQw-370-wkUe00CdBeA5ip2lOba-SCsB33c=.15959694-aaef-4a4b-a769-f731821817a9@github.com>
 <FXDxTMNgYoY1v3nfD2N-3pWMbC3Mffh_wbshIUXsmYs=.81fbbadf-1d64-482e-bc08-95f02b989e0b@github.com>
 <LA7caRRdAalJqgUWy2eG2p06CWA0r-p849d_qWXZAqI=.700422e1-c69d-45ec-9424-3b810077cd4c@github.com>
 <Z3U0APyGVCdhAxyQ2daKUcXkGBT97x9rT2eFKQyk95Y=.37091079-4a9b-4cf1-9a3f-fbecd4a10c2e@github.com>
Message-ID: <HDCsp_UslEi1qFbLcOs14vubKaT-SN1MlHZguuBP0n0=.7320d935-5157-4514-9bdc-58aae3db443e@github.com>

On Thu, 24 Oct 2024 13:00:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I was trying to chose between this and `tree.size & ~0xFFFF`, I think `javac` will sometimes check if an int is larger than `0xFFFF`
>
> If you use `& ~0xFFFF` you must use `!= 0` as the mask includes the sign bit.

I think the other checks are implemented as simple `value > limit => error` checks:
https://github.com/openjdk/jdk/blob/d8430efb5e159b8e08d2cac66b46cb4ff1112927/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java#L114
https://github.com/openjdk/jdk/blob/d8430efb5e159b8e08d2cac66b46cb4ff1112927/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java#L938

True, it may overflow, but if it would overflow once, it might overflow twice (back to positive numbers), so if/when that becomes a problem, we'd probably need something more complex. And it will be easier to find if the pattern is as close to the existing patterns as possible. So, I guess I would suggest to use a simple ` > ClassFile.MAX_ANNOTATIONS`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21663#discussion_r1820699731

From mullan at openjdk.org  Tue Oct 29 12:40:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:40:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Update copyrights. Remove @compile line form Marshal.java test.
 - Update copyright headers
 - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
 - Merge branch 'master' into jep486
 - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
 - remove privileged calls in logging/File* tests
 - delete PermissionTest.java as it simply constructs provider impls
 - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
 - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
   Removed createPrivateValue(), no longer used.
 - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=04
  Stats: 66378 lines in 1872 files changed: 1145 ins; 61413 del; 3820 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From mullan at openjdk.org  Tue Oct 29 12:51:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:51:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>
Message-ID: <InHcapZDPzV248KM-JZkB0e6iBp-skpVNJXkDdYazH0=.dd390d4d-e66f-4139-900a-a10410385483@github.com>

On Sun, 27 Oct 2024 00:15:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java line 93:
> 
>> 91:  * static {@link ThreadLocal} instance.  Authors of such implementations are
>> 92:  * <i>strongly</i> encouraged to determine the user at the time preferences
>> 93:  * are accessed (for example by the {@link #get(String,String)} or {@link
> 
> Most of this seems like it will remain applicable. Of course we won't suggest throwing `SecurityException`. But users not having sufficient OS-level privileges will still need to be addressed, yes?

This text was restored. See https://github.com/openjdk/jdk/pull/21498/commits/66145173cce201b655845144daa209a75ad5964a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820732961

From mullan at openjdk.org  Tue Oct 29 12:52:02 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:52:02 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <WtTk6-HHt037cI-2dFzi2Xsah_0A7ceHMYjo_UI8t10=.7b75bce3-ff04-4cf5-a854-7cc54f4f94d1@github.com>

On Fri, 25 Oct 2024 19:55:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/PluggableLocale/PermissionTest.java line 52:
> 
>> 50: import com.foo.NumberFormatProviderImpl;
>> 51: 
>> 52: public class PermissionTest{
> 
> This test can be deleted entirely. What remains is just constructing each provider impl.
> The summary mentions a RuntimePermission and would need to be revised to a new description.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/8054d108fea3ce9e7f1618c3d90ef5af6cfa22d7

> test/jdk/java/util/logging/FileHandlerLongLimit.java line 157:
> 
>> 155:     static class Configure {
>> 156:         static void setUp(Properties propertyFile) {
>> 157:             doPrivileged(() -> {
> 
> The doPrivileged() could be factored out.
> And callPrivileged().

These are all fixed in https://github.com/openjdk/jdk/pull/21498/commits/bc5b3d70741505a684a39474630372a9b2fd8bc0

> test/jdk/java/util/logging/TestLogConfigurationDeadLockWithConf.java line 83:
> 
>> 81:      * then the test is considered a success and passes.
>> 82:      *
>> 83:      * Note that 4sec may not be enough to detect issues if there are some.
> 
> Where is this timeout enforced or measured; this is just a comment, not a parameter.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/2a9b98e244362dbbb98487098865cfd46a46dc1e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820722883
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820727624
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820725397

From mullan at openjdk.org  Tue Oct 29 12:52:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:52:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <kvSkNGGzpjSCrqcFcn_IfCM4LgffbPzAtH1WX1jHnmY=.da6d0dea-5296-4604-964c-f87b81486392@github.com>

On Fri, 25 Oct 2024 20:07:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> test/jdk/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java line 48:
> 
>> 46:             throw new RuntimeException("unexpected resource bundle");
>> 47:         }
>> 48: 
> 
> This main and TestPermission.java duplicate the basic resource location mechanisms.
> This test/Main.java an test/TestPermission can be removed entirely.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/cb5f6e43b891df8c2a977e665016079469290669

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820730316

From mullan at openjdk.org  Tue Oct 29 12:59:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
 <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>
Message-ID: <-KKpAuNUa1hNQE1tPbw9tlG5LKTTS-L9r5_YSJNhAFw=.10315724-126e-42bc-a933-8cd854efc163@github.com>

On Tue, 29 Oct 2024 06:32:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
>> 
>>> 527:      * execute the given {@code callable} under the current access
>>> 528:      * control context, with the current context class loader as the
>>> 529:      * context class loader. This method should normally be invoked
>> 
>> We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?
>
> That's a good observation. Although deprecated for removal, the wording should at least specify what it does for the period before it is removed. I'll come up with some spec wording for this.
> 
> Update: now fixed in sandbox

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/0feceaae472710aa13e4c569f4d72d6149b7de07

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820738332

From mullan at openjdk.org  Tue Oct 29 12:59:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <9nyF6shPmWaMMGsOnjrzYKlZApNJV1uhY-tsTQhi_-M=.021bd5d0-f978-4651-97d6-0ab3f7cb2eaf@github.com>

On Mon, 28 Oct 2024 21:02:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> test/jdk/javax/xml/crypto/dsig/TransformService/NullParent.java line 1:
> 
>> 1: /*
> 
> Missed a copyright update; will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820743852

From mullan at openjdk.org  Tue Oct 29 12:59:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@github.com>

On Mon, 28 Oct 2024 21:00:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30:
> 
>> 28:  * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom
>> 29:  * @compile -XDignore.symbol.file Marshal.java
>> 30:  * @run main/othervm/java.security.policy==test.policy Marshal
> 
> With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main <test>" when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.
> 
> Also, missing a copyright update, will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820743569

From stephan.herrmann at berlin.de  Tue Oct 29 13:02:30 2024
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 29 Oct 2024 14:02:30 +0100
Subject: Flexible constructors: dubious error
Message-ID: <e96fd47a-ad5e-4fc2-9ab2-6559bbe50f49@berlin.de>

Given:

public class X {
	public static void main(String[] argv) {
		class Inner {
			String s;
			Inner() {
				class Local {}
				new Local() {};
				super();
			}
			Inner(int i) {
				class Local {}
				new Local() {
					void m() {
						System.out.println(s);
					}
				};
				super();
			}
		}
		new Inner();
	}
}

javac 23 reports exactly one error against the illegal use of 's' in Inner(int). 
Good.

javac 24 ea+21 additionally flags both instantiations "new Local() ...":

X.java:7: error: cannot reference this before supertype constructor has been called
                                 new Local() {};
                                             ^

I don't see any reason for that error as I don't see any access to 'this'. What 
is the reason for this change in behavior?

thanks,
Stephan

From rotanolexandr842 at gmail.com  Tue Oct 29 13:11:08 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Tue, 29 Oct 2024 15:11:08 +0200
Subject: Flexible constructors: dubious error
In-Reply-To: <e96fd47a-ad5e-4fc2-9ab2-6559bbe50f49@berlin.de>
References: <e96fd47a-ad5e-4fc2-9ab2-6559bbe50f49@berlin.de>
Message-ID: <CAL5bRt9VQF7xrjnGqOwuQANAix-2D=fatTHDpEqBrFW5kOg34w@mail.gmail.com>

Local classes, as well as inner ones (don't confuse with nested) implicitly
take parents "this" as a constructor argument (if I'm not mistaken, untill
some point of time or even now inner classes were elevated to top level
classes with reference to parent as their constructor argument).

In fact, if I remember correctly, the behaviour in version 23 is a known
bug that was fixed a while ago

On Tue, Oct 29, 2024, 15:02 Stephan Herrmann <stephan.herrmann at berlin.de>
wrote:

> Given:
>
> public class X {
>         public static void main(String[] argv) {
>                 class Inner {
>                         String s;
>                         Inner() {
>                                 class Local {}
>                                 new Local() {};
>                                 super();
>                         }
>                         Inner(int i) {
>                                 class Local {}
>                                 new Local() {
>                                         void m() {
>                                                 System.out.println(s);
>                                         }
>                                 };
>                                 super();
>                         }
>                 }
>                 new Inner();
>         }
> }
>
> javac 23 reports exactly one error against the illegal use of 's' in
> Inner(int).
> Good.
>
> javac 24 ea+21 additionally flags both instantiations "new Local() ...":
>
> X.java:7: error: cannot reference this before supertype constructor has
> been called
>                                  new Local() {};
>                                              ^
>
> I don't see any reason for that error as I don't see any access to 'this'.
> What
> is the reason for this change in behavior?
>
> thanks,
> Stephan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241029/fffdb3ef/attachment.htm>

From prappo at openjdk.org  Tue Oct 29 13:32:51 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 29 Oct 2024 13:32:51 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25
Message-ID: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>

Prepare for JDK 25.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/21763/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342979
  Stats: 96 lines in 36 files changed: 49 ins; 3 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/21763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21763/head:pull/21763

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

From stephan.herrmann at berlin.de  Tue Oct 29 14:10:47 2024
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 29 Oct 2024 15:10:47 +0100
Subject: Flexible constructors: dubious error
In-Reply-To: <CAL5bRt9VQF7xrjnGqOwuQANAix-2D=fatTHDpEqBrFW5kOg34w@mail.gmail.com>
References: <e96fd47a-ad5e-4fc2-9ab2-6559bbe50f49@berlin.de>
 <CAL5bRt9VQF7xrjnGqOwuQANAix-2D=fatTHDpEqBrFW5kOg34w@mail.gmail.com>
Message-ID: <0f36624f-b105-4b1c-9fff-b600b078c689@berlin.de>

Am 29.10.24 um 14:11 schrieb Olexandr Rotan:
> Local classes, as well as inner ones (don't confuse with nested) implicitly take 
> parents "this" as a constructor argument

They *may* take this argument *if needed*.

But this is more an implementation detail and not the level at which the 
specification defines this, is it?

Stephan

> (if I'm not mistaken, untill some point 
> of time or even now inner classes were elevated to top level classes with 
> reference to parent as their constructor argument).
> 
> In fact, if I remember correctly, the behaviour in version 23 is a known bug 
> that was fixed a while ago
> 
> 
> On Tue, Oct 29, 2024, 15:02 Stephan Herrmann <stephan.herrmann at berlin.de 
> <mailto:stephan.herrmann at berlin.de>> wrote:
> 
>     Given:
> 
>     public class X {
>      ? ? ? ? public static void main(String[] argv) {
>      ? ? ? ? ? ? ? ? class Inner {
>      ? ? ? ? ? ? ? ? ? ? ? ? String s;
>      ? ? ? ? ? ? ? ? ? ? ? ? Inner() {
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? class Local {}
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new Local() {};
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? super();
>      ? ? ? ? ? ? ? ? ? ? ? ? }
>      ? ? ? ? ? ? ? ? ? ? ? ? Inner(int i) {
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? class Local {}
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new Local() {
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? void m() {
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? System.out.println(s);
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? }
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? };
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? super();
>      ? ? ? ? ? ? ? ? ? ? ? ? }
>      ? ? ? ? ? ? ? ? }
>      ? ? ? ? ? ? ? ? new Inner();
>      ? ? ? ? }
>     }
> 
>     javac 23 reports exactly one error against the illegal use of 's' in
>     Inner(int).
>     Good.
> 
>     javac 24 ea+21 additionally flags both instantiations "new Local() ...":
> 
>     X.java:7: error: cannot reference this before supertype constructor has been
>     called
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?new Local() {};
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> 
>     I don't see any reason for that error as I don't see any access to 'this'. What
>     is the reason for this change in behavior?
> 
>     thanks,
>     Stephan
> 


From weijun at openjdk.org  Tue Oct 29 14:22:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Oct 2024 14:22:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>

On Mon, 28 Oct 2024 21:02:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
> 
>> 1: /*
> 
> @wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?

It can removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820899380

From archie.cobbs at gmail.com  Tue Oct 29 14:24:03 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 29 Oct 2024 09:24:03 -0500
Subject: Flexible constructors: dubious error
In-Reply-To: <0f36624f-b105-4b1c-9fff-b600b078c689@berlin.de>
References: <e96fd47a-ad5e-4fc2-9ab2-6559bbe50f49@berlin.de>
 <CAL5bRt9VQF7xrjnGqOwuQANAix-2D=fatTHDpEqBrFW5kOg34w@mail.gmail.com>
 <0f36624f-b105-4b1c-9fff-b600b078c689@berlin.de>
Message-ID: <CANSoFxt0c27hRCwBh2Ud+4H2MeCQDD+vm2DZPgqYTfXj2dwG=A@mail.gmail.com>

Hi Stephan,

On Tue, Oct 29, 2024 at 9:11?AM Stephan Herrmann <stephan.herrmann at berlin.de>
wrote:

> Am 29.10.24 um 14:11 schrieb Olexandr Rotan:
> > Local classes, as well as inner ones (don't confuse with nested)
> implicitly take
> > parents "this" as a constructor argument
>
> They *may* take this argument *if needed*.
>
> But this is more an implementation detail and not the level at which the
> specification defines this, is it?
>

This is a specification thing.

Here is what is "supposed" to happen: Both "Local" classes in the example
are declared prior to super(). These classes are therefore within an early
construction context of "Inner" and therefore do not have access to the
current instance of "Inner" - but this access would be required for the
expression "s" which is short-hand for "Inner.this.s".

So the reference to "s" should generate an error, which happens with the
current 24 build:

    X.java:14: error: cannot reference s before supertype constructor has
been called
                                                System.out.println(s);
                                                                   ^

FYI there is still an outstanding bug and associated PR
<https://github.com/openjdk/jdk/pull/21410> related to this situation, so
with the current 24 build you also get these (bogus) errors:

    X.java:7: error: cannot reference this before supertype constructor has
been called
                                new Local() {};
                                            ^
    X.java:12: error: cannot reference this before supertype constructor
has been called
                                new Local() {
                                            ^

Those errors are bogus, because under the latest "flexible constructors"
spec, local classes declared in an early construction context of class C
are treated the same as anonymous classes in that situation - they do not
have any outer instance of type C - so you can declare and instantiate them
freely.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241029/439b02f6/attachment-0001.htm>

From dfuchs at openjdk.org  Tue Oct 29 14:47:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 14:47:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <5kPidtpO9u4Uq1Cjk3-caYGOFua3Q09ea4tO_2eVdKs=.90e9833e-9445-4545-93fc-f179230d6597@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

Changes to System.LoggerFinder / System.getXxxLogger methods look good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402138949

From duke at openjdk.org  Tue Oct 29 14:50:51 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 29 Oct 2024 14:50:51 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v19]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <CLtQGe9FdkFu25BZJspRbmugWpU4Kl-E2K0cVU4V_VA=.ed6a382b-b436-489f-ad5d-6affeaacd036@github.com>

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

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

  fix test failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/5fdfdf32..0889133b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20718&range=17-18

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

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

From duke at openjdk.org  Tue Oct 29 14:50:51 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 29 Oct 2024 14:50:51 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v18]
In-Reply-To: <Wo4XoxExBvd2BiVx-kRpCBMONLTVl78aoacoHbsROS4=.33ae43d3-fbbb-4afa-b85b-26af45e1e073@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
 <Wo4XoxExBvd2BiVx-kRpCBMONLTVl78aoacoHbsROS4=.33ae43d3-fbbb-4afa-b85b-26af45e1e073@github.com>
Message-ID: <KcG1Su6eMsKhfAgwZJTF1qRzgk0tI7fbj96oRlQ8Ask=.4ce67dec-4016-4c9a-84a3-6217f967c5c2@github.com>

On Mon, 28 Oct 2024 18:13:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove trailing whitespaces
>>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>>  - address review comments
>
> test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 80:
> 
>> 78:      */
>> 79:     @Test
>> 80:     public void otherTopLevelPrivateClassFails() throws Exception {
> 
> this test is failing for me (Linux):
> 
> 
> Expected errors: [S.java:5:25: compiler.err.report.access: S.A, private, S, 1 error], 
> but got: [S.java:4:25: compiler.err.report.access: S.A, private, S, 1 error]

Thanks, I forgot to change the line number when removed empty line for jcheck

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1820953597

From dfuchs at openjdk.org  Tue Oct 29 14:52:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 14:52:13 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <cyX0-593hoAmv_MAHCQnjHRZFJywvIxuL4PTUWO7hLU=.82d77ccc-2e4f-4d7f-b2f9-08f07e3c9252@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I had a look at public classes in java/io; I am not a regular reviewer there but what I saw made sense to me. Changes to ObjectInputStream/ObjectOutputStream will need a more qualified Reviewer but I believe you have that already.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402160395

From stephan.herrmann at berlin.de  Tue Oct 29 15:03:07 2024
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 29 Oct 2024 16:03:07 +0100
Subject: Flexible constructors: dubious error
In-Reply-To: <CANSoFxt0c27hRCwBh2Ud+4H2MeCQDD+vm2DZPgqYTfXj2dwG=A@mail.gmail.com>
References: <e96fd47a-ad5e-4fc2-9ab2-6559bbe50f49@berlin.de>
 <CAL5bRt9VQF7xrjnGqOwuQANAix-2D=fatTHDpEqBrFW5kOg34w@mail.gmail.com>
 <0f36624f-b105-4b1c-9fff-b600b078c689@berlin.de>
 <CANSoFxt0c27hRCwBh2Ud+4H2MeCQDD+vm2DZPgqYTfXj2dwG=A@mail.gmail.com>
Message-ID: <9bfd5b5b-ee31-4f6a-99c1-c94f082b4e32@berlin.de>

Thanks, Archie,

What you say effectively confirms my understanding that the error against access 
of 's' is good, the others are wrong.

What I said about not being an specification thing is that the spec does not 
mandate where exactly which synthetic argument / field is to be generated.

thanks,
Stephan

Am 29.10.24 um 15:24 schrieb Archie Cobbs:
> Hi Stephan,
> 
> On Tue, Oct 29, 2024 at 9:11?AM Stephan Herrmann <stephan.herrmann at berlin.de 
> <mailto:stephan.herrmann at berlin.de>> wrote:
> 
>     Am 29.10.24 um 14:11 schrieb Olexandr Rotan:
>      > Local classes, as well as inner ones (don't confuse with nested)
>     implicitly take
>      > parents "this" as a constructor argument
> 
>     They *may* take this argument *if needed*.
> 
>     But this is more an implementation detail and not the level at which the
>     specification defines this, is it?
> 
> 
> This is a specification thing.
> 
> Here is what is "supposed" to happen: Both "Local" classes in the example are 
> declared prior to super(). These classes are therefore within an early 
> construction context of "Inner" and therefore do not have access to the current 
> instance of "Inner" - but this access would be required for the expression "s" 
> which is short-hand for "Inner.this.s".
> 
> So the reference to "s" should generate an error, which happens with the current 
> 24 build:
> 
>  ??? X.java:14: error: cannot reference s before supertype constructor has been 
> called
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? System.out.println(s);
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> 
> FYI there is still an outstanding bug and associated PR 
> <https://github.com/openjdk/jdk/pull/21410> related to this situation, so with 
> the current 24 build you also get these (bogus) errors:
> 
>  ??? X.java:7: error: cannot reference this before supertype constructor has 
> been called
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new Local() {};
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
>  ??? X.java:12: error: cannot reference this before supertype constructor has 
> been called
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new Local() {
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
> 
> Those errors are bogus, because under the latest "flexible constructors" spec, 
> local classes declared in an early construction context of class C are treated 
> the same as anonymous classes in that situation - they do not have any outer 
> instance of type C - so you can declare and instantiate them freely.
> 
> -Archie
> 
> -- 
> Archie L. Cobbs


From dfuchs at openjdk.org  Tue Oct 29 15:03:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 15:03:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <MlrAktPp9rmUHEnK3fWUbAH3j7eY0jZ0AzLMzRbSo_0=.34e5e56f-ef85-46e5-a92d-717a95e7a38e@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I have reviewed changes in the public classes in java/nio/channels and java/nio/channels/spi. They LGTM.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402192169

From maurizio.cimadamore at oracle.com  Tue Oct 29 15:22:38 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 29 Oct 2024 15:22:38 +0000
Subject: Flexible constructors: dubious error
In-Reply-To: <CANSoFxt0c27hRCwBh2Ud+4H2MeCQDD+vm2DZPgqYTfXj2dwG=A@mail.gmail.com>
References: <e96fd47a-ad5e-4fc2-9ab2-6559bbe50f49@berlin.de>
 <CAL5bRt9VQF7xrjnGqOwuQANAix-2D=fatTHDpEqBrFW5kOg34w@mail.gmail.com>
 <0f36624f-b105-4b1c-9fff-b600b078c689@berlin.de>
 <CANSoFxt0c27hRCwBh2Ud+4H2MeCQDD+vm2DZPgqYTfXj2dwG=A@mail.gmail.com>
Message-ID: <b3ab3920-7b02-4d1a-bcd9-789bf5c0ecee@oracle.com>

What Archie says - there is going to be a spec clarification and 
associated compiler enhancement to deal with the situation you describe.

Maurizio

On 29/10/2024 14:24, Archie Cobbs wrote:
> Hi Stephan,
>
> On Tue, Oct 29, 2024 at 9:11?AM Stephan Herrmann 
> <stephan.herrmann at berlin.de> wrote:
>
>     Am 29.10.24 um 14:11 schrieb Olexandr Rotan:
>     > Local classes, as well as inner ones (don't confuse with nested)
>     implicitly take
>     > parents "this" as a constructor argument
>
>     They *may* take this argument *if needed*.
>
>     But this is more an implementation detail and not the level at
>     which the
>     specification defines this, is it?
>
>
> This is a specification thing.
>
> Here is what is "supposed" to happen: Both "Local" classes in the 
> example are declared prior to super(). These classes are therefore 
> within an early construction context of "Inner" and therefore do not 
> have access to the current instance of "Inner" - but this access would 
> be required for the expression "s" which is short-hand for "Inner.this.s".
>
> So the reference to "s" should generate an error, which happens with 
> the current 24 build:
>
> X.java:14: error: cannot reference s before supertype constructor has 
> been called
> System.out.println(s);
> ? ? ? ?^
>
> FYI there is still an outstanding bug and associated PR 
> <https://github.com/openjdk/jdk/pull/21410> related to this situation, 
> so with the current 24 build you also get these (bogus) errors:
>
> ??? X.java:7: error: cannot reference this before supertype 
> constructor has been called
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new Local() {};
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
> ??? X.java:12: error: cannot reference this before supertype 
> constructor has been called
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new Local() {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
>
> Those errors are bogus, because under the latest "flexible 
> constructors" spec, local classes declared in an early construction 
> context of class C are treated the same as anonymous classes in that 
> situation - they do not have any outer instance of type C - so you can 
> declare and instantiate them freely.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241029/ce14921d/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Tue Oct 29 15:26:12 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 29 Oct 2024 15:26:12 +0000
Subject: disjoint or not disjoint?
In-Reply-To: <ba498f5d-0726-4c04-8362-bd26ccc8e83c@berlin.de>
References: <ba498f5d-0726-4c04-8362-bd26ccc8e83c@berlin.de>
Message-ID: <b29679c5-bffd-4b80-8a4e-19734c3035ef@oracle.com>

I agree with your analysis - this seems a javac bug - C3 and I (or C1) 
have nothing to do with each other.

Maurizio

On 29/10/2024 11:39, Stephan Herrmann wrote:
> Please consider this source:
>
> public class X1 {
> ??? sealed interface I permits C1 {}
> ??? non-sealed class C1 implements I {}
> ??? class C2 extends C1 {}
> ??? class C3 {}
> ??? I m2(int s, C3 c3) {
> ??????? return switch (s) {
> ??????????? case 0 -> (I) c3;
> ??????????? case 1 -> (C1) c3;
> ??????????? case 2 -> (C2) c3;
> ??????????? default -> null;
> ??????? };
> ??? }
> }
>
> javac raises errors at case 1 and case 2 but not at case 0.
>
> If we're reading the spec correctly, then also case 0 would be illegal:
>
> * A class named C is disjoint from an interface named I if ...
> ? * C is freely extensible (?8.1.1.2), and I is sealed, and C is disjoint
> ??? from all of the permitted direct subclasses and subinterfaces of I.
>
> with C=C3, I=I we are asking if C3 is disjoint from C1.
>
> * A class named C is disjoint from another class named D if (i) it is 
> not the
> ? case that C <: D, and (ii) it is not the case that D <: C.
>
> with C=C3 and D=C1 we asking C3 <: C1 and C1 <: C3, both being false.
>
> Actually, in case 1 javac agrees with this last line of reasoning.
>
>
> Do you agree that this is a bug in javac, or am I missing some subtlety?
>
> thanks
> Stephan

From dfuchs at openjdk.org  Tue Oct 29 15:39:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 15:39:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <ytVM17GPcnPoj29Blt9_kjjl-DLdbG_ixtEsUzamNx8=.55080c4c-0e5b-4f23-8052-889754c55b2e@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

For the record I have also reviewed the changes in JNDI (sources + test) and HTTP server (sources, I did the test changes) and they look good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2444638665

From abimpoudis at openjdk.org  Tue Oct 29 16:08:56 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 29 Oct 2024 16:08:56 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v4]
In-Reply-To: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
Message-ID: <K-GUFEgPo-WdH9VqcLpB6M2FQfWczkRPRA10Z2mNtP8=.f698ea23-5852-4076-bef1-9c5ddefc3b72@github.com>

> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
> 
> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
> 
> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Assume that two lambdas that contain a class definition (any) are always different

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21687/files
  - new: https://git.openjdk.org/jdk/pull/21687/files/c51e7385..afed3649

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

  Stats: 35 lines in 4 files changed: 14 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21687/head:pull/21687

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

From abimpoudis at openjdk.org  Tue Oct 29 16:13:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 29 Oct 2024 16:13:14 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v4]
In-Reply-To: <K-GUFEgPo-WdH9VqcLpB6M2FQfWczkRPRA10Z2mNtP8=.f698ea23-5852-4076-bef1-9c5ddefc3b72@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <K-GUFEgPo-WdH9VqcLpB6M2FQfWczkRPRA10Z2mNtP8=.f698ea23-5852-4076-bef1-9c5ddefc3b72@github.com>
Message-ID: <5ePcBCvrgMXhAzu3ssXE9TmzS6-N-56jUhhopk5rMi0=.1717f2b3-8f89-439a-aad1-e06fda8d6292@github.com>

On Tue, 29 Oct 2024 16:08:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Assume that two lambdas that contain a class definition (any) are always different

In this [commit](https://github.com/openjdk/jdk/pull/21687/commits/afed36490a76d858b4909efb9fd5dc1487699cd2) I have added two groups of the same lambda (syntactically). There are
two checks in `DeduplicationTest.TreeDiffHashTaskListener.finished` as described in
the comments:

- // Scan the compilation for calls to a varargs method named 'group', whose arguments
   // are a group of lambdas that are equivalent to each other, but distinct from all
   // lambdas in the compilation unit outside of that group.
- // 1. Assert that all pairwise combinations of lambdas in the group are equal, and
   // hash to the same value.
- // 2. Assert that no lambdas in a group are equal to any lambdas outside that group,
   // or hash to the same value as lambda outside the group.

As a result, I added two groups (since there is no functionality to assert that
two lambdas in a group are different.) IIUC any lambda inside the group is
checked for non equality with each lambda outside the group.

        group((Function<Object, Integer>) x -> {class C {} new C(); return 42; });
        group((Function<Object, Integer>) x -> {class C {} new C(); return 42; });

I believe that now (since the same lambda is not equal to itself if it contains a class decl)
a reasonable if-test within the group, could be to test `if (rhs != lhs)`. Applying TreeDiff 
between the same lambda can yield an assertion error now. 

Let me know if I you believe that I misinterpreted the test in anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2444732437

From jlahoda at openjdk.org  Tue Oct 29 16:14:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 29 Oct 2024 16:14:15 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview) [v2]
In-Reply-To: <QmLzC5yRtKwMH56AQ7zMbmXTVBacD0a_UCZyzZxkYhM=.156e7bf7-102c-48f1-be0f-41efd646006c@github.com>
References: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
 <QmLzC5yRtKwMH56AQ7zMbmXTVBacD0a_UCZyzZxkYhM=.156e7bf7-102c-48f1-be0f-41efd646006c@github.com>
Message-ID: <WAMAAWzbd_kuIEPu16n0opctayt-0ODBBYJpergACng=.c4a286c2-8dc8-4ee9-a90f-d0434475a153@github.com>

On Mon, 28 Oct 2024 15:24:22 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR prepares the improvement for JEP 488.
>> 
>> The proposed approach is described in the CSR.
>> 
>> In terms of compiler implementation, we add the related translation in `TransPatterns`. Interestingly, this issue would be ideally addressed in `TransTypes`. However, there are some conveniences in `TransPatterns` that would need to be pulled into `TransTypes` to make this work: 1) the dependency to `makeBinary` and transitively to `operators` and 2) a lot of ceremony around `currentMethodSym` is already setup nicely in `TransPatterns`.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21539#pullrequestreview-2402446341

From prappo at openjdk.org  Tue Oct 29 16:15:30 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 29 Oct 2024 16:15:30 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v2]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <xVEI7zgStz5E0otdw0Z12XwFZLArWYugQe3UDUxRbm0=.0c415f00-ee89-4ac3-ac36-54853364ae76@github.com>

> Prepare for JDK 25.

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

  Add forgotten .jcheck/conf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/fc851b94..64e9326b

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

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

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

From rriggs at openjdk.org  Tue Oct 29 16:54:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Oct 2024 16:54:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <Pg9N43cJQ4mPhIHzrotEbgDy4oCc1OcfEDWoP9U8aVI=.11981767-6704-4655-beb0-7b6c7d7b8bc9@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

Reviewed java.sql and java.sql.rowset src and test; lgtm

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402558624

From honkar at openjdk.org  Tue Oct 29 17:10:54 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 29 Oct 2024 17:10:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>

On Thu, 24 Oct 2024 15:03:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1613:
> 
>> 1611:      * interpreted as a {@code Font} object according to the
>> 1612:      * specification of {@code Font.decode(String)}
>> 1613:      * If the specified property is not found then null is returned instead.
> 
> Suggestion:
> 
>      * If the specified property is not found, null is returned instead.
> 
> The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.

Updated on jep486 branch

> src/java.desktop/share/classes/java/awt/Font.java line 1781:
> 
>> 1779:      * The property value should be one of the forms accepted by
>> 1780:      * {@code Font.decode(String)}
>> 1781:      * If the specified property is not found then the {@code font}
> 
> Suggestion:
> 
>      * If the specified property is not found, the {@code font}

Updated on jep486 branch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821237100
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821236441

From honkar at openjdk.org  Tue Oct 29 17:10:55 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 29 Oct 2024 17:10:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>

On Thu, 24 Oct 2024 15:12:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> src/java.desktop/share/classes/java/awt/MouseInfo.java line 68:
> 
>> 66:      * @throws SecurityException if a security manager exists and its
>> 67:      *            {@code checkPermission} method doesn't allow the operation
>> 68:      * @see       GraphicsConfiguration
> 
> Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional?

You are right, I see it mentioned already in the doc. I don't think we need to mention it again?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821232103

From alanb at openjdk.org  Tue Oct 29 17:28:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 17:28:11 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v4]
In-Reply-To: <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>
Message-ID: <fkr6ezU1ggYyreCGoQK_rgpbnyrpA95XzKhhdBiy16k=.e0e4a629-6997-483d-9360-84820171d625@github.com>

On Thu, 24 Oct 2024 06:40:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Updating PreviewFeature metadata
>  - Cleanup.
>  - Merge branch 'master' into JDK-8335989
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/964d8d22...94b8bf6d

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 193:

> 191:         int minor_version = in.readUnsignedShort();
> 192:         int major_version = in.readUnsignedShort();
> 193:         boolean isPreview = minor_version == ClassFile.PREVIEW_MINOR_VERSION;

I think this will need to throw invalidModuleDescriptor if isPreview && major version != ClassFile.latestMajorVersion, otherwise the check in readModuleAttribute will be defeated by hand craft class files (the VM doesn't read module-info class files so it won't reject it, and this code is called from exposed APIs such as ModuleDescriptor.read).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1821270533

From iris at openjdk.org  Tue Oct 29 18:06:12 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 29 Oct 2024 18:06:12 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v2]
In-Reply-To: <xVEI7zgStz5E0otdw0Z12XwFZLArWYugQe3UDUxRbm0=.0c415f00-ee89-4ac3-ac36-54853364ae76@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <xVEI7zgStz5E0otdw0Z12XwFZLArWYugQe3UDUxRbm0=.0c415f00-ee89-4ac3-ac36-54853364ae76@github.com>
Message-ID: <VqPOAJggbzqqfDBrKbrIqbIoBcf76DRp2GyJVJ-hG7Y=.beb8e97f-d539-441b-9629-c20ea95b2c3c@github.com>

On Tue, 29 Oct 2024 16:15:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add forgotten .jcheck/conf

Congratulations on accepting the baton from Joe!

Confirmed everything as expected.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2402735973

From bchristi at openjdk.org  Tue Oct 29 18:38:54 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 29 Oct 2024 18:38:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

`java.util` and `java.util.concurrent` src and test changes look good.

src/java.base/share/classes/java/util/concurrent/Executors.java line 392:

> 390:     /**
> 391:      * Returns a thread factory used to create new threads that
> 392:      * have current context class loader as the context class loader.

One nit for your consideration: "...to create new threads that have **_the_** current context class loader..."

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

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402793417
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821358523

From rriggs at openjdk.org  Tue Oct 29 18:49:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Oct 2024 18:49:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <gYQw-g86W7MLIsSAkOIYq5Y3HjssUtl3_xxeYVHGV74=.3a600d88-7674-4014-bae5-65691f06af21@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

Reviewed java/util/jar,zip src and test.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402819301

From erikj at openjdk.org  Tue Oct 29 20:58:20 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 29 Oct 2024 20:58:20 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v2]
In-Reply-To: <xVEI7zgStz5E0otdw0Z12XwFZLArWYugQe3UDUxRbm0=.0c415f00-ee89-4ac3-ac36-54853364ae76@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <xVEI7zgStz5E0otdw0Z12XwFZLArWYugQe3UDUxRbm0=.0c415f00-ee89-4ac3-ac36-54853364ae76@github.com>
Message-ID: <L4Ip59gwgO1ajWI78Y-rJGr0bR8NmyCVjgC8TQuFR5s=.2ee96153-5311-49b7-afcd-20319d45e9ab@github.com>

On Tue, 29 Oct 2024 16:15:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add forgotten .jcheck/conf

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2403063356

From archie.cobbs at gmail.com  Tue Oct 29 21:30:24 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 29 Oct 2024 16:30:24 -0500
Subject: Unchecked cast unchecked?
Message-ID: <CANSoFxtzU1Y9GSnC_mhcZ6gb5X1LCgfz9YXtTrfMcc1eJVqw1w@mail.gmail.com>

Question: Should this program generate an unchecked cast warning?

import java.lang.invoke.VarHandle;
class VarHandleCast<V> {
    VarHandle vh;
    V method(Object obj) {
        return (V)vh.getAndSet(this, obj);  // unchecked cast?
    }
}

Currently, it does not.

Presumably that has something to do with this code in Types.java but I'm
not sure why this would mean there should be no warning:

    /**
     * A polymorphic signature method (JLS 15.12.3) is a method that
     *   (i) is declared in the java.lang.invoke.MethodHandle/VarHandle
classes;
     *  (ii) takes a single variable arity parameter;
     * (iii) whose declared type is Object[];
     *  (iv) has any return type, Object signifying a polymorphic return
type; and
     *   (v) is native.
    */
   public boolean isSignaturePolymorphic(MethodSymbol msym) {
       List<Type> argtypes = msym.type.getParameterTypes();
       return (msym.flags_field & NATIVE) != 0 &&
              (msym.owner == syms.methodHandleType.tsym || msym.owner ==
syms.varHandleType.tsym) &&
               argtypes.length() == 1 &&
               argtypes.head.hasTag(TypeTag.ARRAY) &&
               ((ArrayType)argtypes.head).elemtype.tsym ==
syms.objectType.tsym;
   }

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241029/d73cd512/attachment.htm>

From alex.buckley at oracle.com  Tue Oct 29 22:52:16 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 29 Oct 2024 15:52:16 -0700
Subject: Unchecked cast unchecked?
In-Reply-To: <CANSoFxtzU1Y9GSnC_mhcZ6gb5X1LCgfz9YXtTrfMcc1eJVqw1w@mail.gmail.com>
References: <CANSoFxtzU1Y9GSnC_mhcZ6gb5X1LCgfz9YXtTrfMcc1eJVqw1w@mail.gmail.com>
Message-ID: <7ad3fb18-0335-4e05-b584-4c15ca979252@oracle.com>

VarHandle::getAndSet(Object[]) is a signature polymorphic method, which 
means that the type of a method call is sensitive to an ensuing cast:

"... if the method invocation expression is the operand of a cast 
expression (?15.16), the compile-time result is the erasure of the type 
of the cast expression (?4.6)."  (JLS 15.12.3)

This has implications for how the method call is compiled, but it's moot 
for your program because the type of the method call is Object no matter 
how you slice it.

Casting from Object to type variable V is achieved by a narrowing 
reference conversion that is unchecked. So, I'd expect an "unchecked 
cast" warning, like for a non-signature polymorphic method.

Alex

On 10/29/2024 2:30 PM, Archie Cobbs wrote:
> Question: Should this program generate an unchecked cast warning?
> 
> import java.lang.invoke.VarHandle;
> class VarHandleCast<V> {
>  ? ? VarHandle vh;
>  ? ? V method(Object obj) {
>  ? ? ? ? return (V)vh.getAndSet(this, obj); ?// unchecked cast?
>  ? ? }
> }
> 
> Currently, it does not.
> 
> Presumably that has something to do with this code in Types.java but I'm 
> not sure why this would mean there should be no warning:
> 
>  ? ? /**
>  ? ? ?* A polymorphic signature method (JLS 15.12.3) is a method that
>  ? ? ?* ? (i) is declared in the java.lang.invoke.MethodHandle/VarHandle 
> classes;
>  ? ? ?* ?(ii) takes a single variable arity parameter;
>  ? ? ?* (iii) whose declared type is Object[];
>  ? ? ?* ?(iv) has any return type, Object signifying a polymorphic 
> return type; and
>  ? ? ?* ? (v) is native.
>  ? ? */
>  ? ?public boolean isSignaturePolymorphic(MethodSymbol msym) {
>  ? ? ? ?List<Type> argtypes = msym.type.getParameterTypes();
>  ? ? ? ?return (msym.flags_field & NATIVE) != 0 &&
>  ? ? ? ? ? ? ? (msym.owner == syms.methodHandleType.tsym || msym.owner 
> == syms.varHandleType.tsym) &&
>  ? ? ? ? ? ? ? ?argtypes.length() == 1 &&
>  ? ? ? ? ? ? ? ?argtypes.head.hasTag(TypeTag.ARRAY) &&
>  ? ? ? ? ? ? ? ?((ArrayType)argtypes.head).elemtype.tsym == 
> syms.objectType.tsym;
>  ? ?}
> 
> Thanks,
> -Archie
> 
> -- 
> Archie L. Cobbs


From dholmes at openjdk.org  Wed Oct 30 05:05:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 05:05:06 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v2]
In-Reply-To: <xVEI7zgStz5E0otdw0Z12XwFZLArWYugQe3UDUxRbm0=.0c415f00-ee89-4ac3-ac36-54853364ae76@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <xVEI7zgStz5E0otdw0Z12XwFZLArWYugQe3UDUxRbm0=.0c415f00-ee89-4ac3-ac36-54853364ae76@github.com>
Message-ID: <u767_H2gXj-MjEixEUkjZGwvrnJgh8ujp4uAnNlptrE=.33f30e31-ae3a-4f28-8096-f4d6a769b2e0@github.com>

On Tue, 29 Oct 2024 16:15:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add forgotten .jcheck/conf

Hotspot changes are fine.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2403614465

From sundar at openjdk.org  Wed Oct 30 07:38:48 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 30 Oct 2024 07:38:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <KpTjC3N9OKmhZehKUPHo3hDuxCaNLC2rP9VYkWvCDIo=.d2ad268f-39af-4b60-9fc1-f6546a85f7ed@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I reviewed jdk.dynalink changes. LGTM

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

Marked as reviewed by sundar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2403864492

From mcimadamore at openjdk.org  Wed Oct 30 09:55:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 30 Oct 2024 09:55:10 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v4]
In-Reply-To: <K-GUFEgPo-WdH9VqcLpB6M2FQfWczkRPRA10Z2mNtP8=.f698ea23-5852-4076-bef1-9c5ddefc3b72@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <K-GUFEgPo-WdH9VqcLpB6M2FQfWczkRPRA10Z2mNtP8=.f698ea23-5852-4076-bef1-9c5ddefc3b72@github.com>
Message-ID: <C6UGFmunx_bU-_UQtwvdEGY1HT7J1fBqJpuOLBf0OUA=.2bc5d4a1-a579-4c7f-a225-3882fa4d2bf9@github.com>

On Tue, 29 Oct 2024 16:08:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Assume that two lambdas that contain a class definition (any) are always different

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TreeHasher.java line 98:

> 96:     public void visitClassDef(JCClassDecl tree) {
> 97:         hash(tree.sym);
> 98:         super.visitClassDef(tree);

I would remove the recursive call here - the hash of a class is just that of its symbol - no need to scan its members recursively.

test/langtools/tools/javac/lambda/deduplication/Deduplication.java line 191:

> 189:                });
> 190: 
> 191:         group((Function<Object, Integer>) x -> {class C {} new C(); return 42; });

It feels like the test logic could be maybe cleaner if `group` had two variants `groupEquals` and `groupNotEquals` - e.g. in this case you want to make sure the lambdas in the group do NOT dedup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1822243435
PR Review Comment: https://git.openjdk.org/jdk/pull/21687#discussion_r1822248806

From maurizio.cimadamore at oracle.com  Wed Oct 30 10:17:18 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 30 Oct 2024 10:17:18 +0000
Subject: Unchecked cast unchecked?
In-Reply-To: <7ad3fb18-0335-4e05-b584-4c15ca979252@oracle.com>
References: <CANSoFxtzU1Y9GSnC_mhcZ6gb5X1LCgfz9YXtTrfMcc1eJVqw1w@mail.gmail.com>
 <7ad3fb18-0335-4e05-b584-4c15ca979252@oracle.com>
Message-ID: <30f33b81-bd19-41c2-8bc1-6dd27a6e60ce@oracle.com>

Good catch - I believe the compiler does what it does because it uses 
the type of the cast (as well as the types of the aruments) to determine 
the final compile-time type of the method being called. This is the type 
that will (under erasure) be reified in the constant pool. So, here 
javac sees a call to a method that returns V and then a cast to V...

Ideally javac should erase things earlier, or just use Object as the 
type of the method call, as Alex suggests. The latter might be slightly 
complicated because, after we added VarHandle support in Java 9, we also 
have some polymorphic methods whose return type is not Object (see 
VarHandle::compareAndSet). But, basically, javac should implement this 
more closely, w/o getting too distracted by the type inferred for the 
synthetic symbol attached to the method call AST node:

> The compile-time result is determined as follows:
>
>  *
>
>     If the signature polymorphic method is either |void| or has a
>     return type other than |Object|, the compile-time result is the
>     result of the invocation type of the compile-time declaration
>     (?15.12.2.6
>     <https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.html#jls-15.12.2.6>).
>
>
>  *
>
>     Otherwise, if the method invocation expression is an expression
>     statement, the compile-time result is |void|.
>
>  *
>
>     Otherwise, if the method invocation expression is the operand of a
>     cast expression (?15.16
>     <https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.html#jls-15.16>),
>     the compile-time result is the erasure of the type of the cast
>     expression (?4.6
>     <https://docs.oracle.com/javase/specs/jls/se15/html/jls-4.html#jls-4.6>).
>
>  *
>
>     Otherwise, the compile-time result is the signature polymorphic
>     method's return type, |Object|.
>
Filed:
https://bugs.openjdk.org/browse/JDK-8343286

Cheers
Maurizio


On 29/10/2024 22:52, Alex Buckley wrote:
> VarHandle::getAndSet(Object[]) is a signature polymorphic method, 
> which means that the type of a method call is sensitive to an ensuing 
> cast:
>
> "... if the method invocation expression is the operand of a cast 
> expression (?15.16), the compile-time result is the erasure of the 
> type of the cast expression (?4.6)."? (JLS 15.12.3)
>
> This has implications for how the method call is compiled, but it's 
> moot for your program because the type of the method call is Object no 
> matter how you slice it.
>
> Casting from Object to type variable V is achieved by a narrowing 
> reference conversion that is unchecked. So, I'd expect an "unchecked 
> cast" warning, like for a non-signature polymorphic method.
>
> Alex
>
> On 10/29/2024 2:30 PM, Archie Cobbs wrote:
>> Question: Should this program generate an unchecked cast warning?
>>
>> import java.lang.invoke.VarHandle;
>> class VarHandleCast<V> {
>> ?? ? VarHandle vh;
>> ?? ? V method(Object obj) {
>> ?? ? ? ? return (V)vh.getAndSet(this, obj); ?// unchecked cast?
>> ?? ? }
>> }
>>
>> Currently, it does not.
>>
>> Presumably that has something to do with this code in Types.java but 
>> I'm not sure why this would mean there should be no warning:
>>
>> ?? ? /**
>> ?? ? ?* A polymorphic signature method (JLS 15.12.3) is a method that
>> ?? ? ?* ? (i) is declared in the 
>> java.lang.invoke.MethodHandle/VarHandle classes;
>> ?? ? ?* ?(ii) takes a single variable arity parameter;
>> ?? ? ?* (iii) whose declared type is Object[];
>> ?? ? ?* ?(iv) has any return type, Object signifying a polymorphic 
>> return type; and
>> ?? ? ?* ? (v) is native.
>> ?? ? */
>> ?? ?public boolean isSignaturePolymorphic(MethodSymbol msym) {
>> ?? ? ? ?List<Type> argtypes = msym.type.getParameterTypes();
>> ?? ? ? ?return (msym.flags_field & NATIVE) != 0 &&
>> ?? ? ? ? ? ? ? (msym.owner == syms.methodHandleType.tsym || 
>> msym.owner == syms.varHandleType.tsym) &&
>> ?? ? ? ? ? ? ? ?argtypes.length() == 1 &&
>> ?? ? ? ? ? ? ? ?argtypes.head.hasTag(TypeTag.ARRAY) &&
>> ?? ? ? ? ? ? ? ?((ArrayType)argtypes.head).elemtype.tsym == 
>> syms.objectType.tsym;
>> ?? ?}
>>
>> Thanks,
>> -Archie
>>
>> -- 
>> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241030/9e1229ac/attachment-0001.htm>

From jlahoda at openjdk.org  Wed Oct 30 12:52:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Oct 2024 12:52:13 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v4]
In-Reply-To: <fkr6ezU1ggYyreCGoQK_rgpbnyrpA95XzKhhdBiy16k=.e0e4a629-6997-483d-9360-84820171d625@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>
 <fkr6ezU1ggYyreCGoQK_rgpbnyrpA95XzKhhdBiy16k=.e0e4a629-6997-483d-9360-84820171d625@github.com>
Message-ID: <A5nfKDzs5suWzcPytv8691_S65jlpCnTadPO8uatCvQ=.7aeee0f0-168a-4af5-b50c-bca7a4d60044@github.com>

On Tue, 29 Oct 2024 17:25:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Updating PreviewFeature metadata
>>  - Cleanup.
>>  - Merge branch 'master' into JDK-8335989
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/964d8d22...94b8bf6d
>
> src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 193:
> 
>> 191:         int minor_version = in.readUnsignedShort();
>> 192:         int major_version = in.readUnsignedShort();
>> 193:         boolean isPreview = minor_version == ClassFile.PREVIEW_MINOR_VERSION;
> 
> I think this will need to throw invalidModuleDescriptor if isPreview && major version != ClassFile.latestMajorVersion, otherwise the check in readModuleAttribute will be defeated by hand craft class files (the VM doesn't read module-info class files so it won't reject it, and this code is called from exposed APIs such as ModuleDescriptor.read).

I believe the check is already being done, right on the next line:
https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java#L192
which leads to:
https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/misc/VM.java#L188
which then leads to:
https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/misc/VM.java#L174
which has this check:
https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/misc/VM.java#L179

I tried with a `module-info.class` with major version 65, and minor version 0xFFFF, and it correctly threw the exception for me.

Do I miss something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1822553137

From jlahoda at openjdk.org  Wed Oct 30 13:07:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Oct 2024 13:07:42 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main Methods
 (Fourth Preview)
Message-ID: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>

This is a partial implementation of JEP 495 - adjustments of the JEP metadata in `PreviewFeature`. There are no language changes associated with this JEP. Changes to the `java.io.IO` class are covered by https://github.com/openjdk/jdk/pull/21693.

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

Commit messages:
 - 8335991: Implement Simple Source Files and Instance Main Methods (Fourth Preview)

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

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

From alanb at openjdk.org  Wed Oct 30 13:25:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Oct 2024 13:25:07 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v4]
In-Reply-To: <A5nfKDzs5suWzcPytv8691_S65jlpCnTadPO8uatCvQ=.7aeee0f0-168a-4af5-b50c-bca7a4d60044@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>
 <fkr6ezU1ggYyreCGoQK_rgpbnyrpA95XzKhhdBiy16k=.e0e4a629-6997-483d-9360-84820171d625@github.com>
 <A5nfKDzs5suWzcPytv8691_S65jlpCnTadPO8uatCvQ=.7aeee0f0-168a-4af5-b50c-bca7a4d60044@github.com>
Message-ID: <w8YTaSGQRSGw3PKexmkPKBiLg3n9YbkWUpBqJCFnPDA=.f16f8de3-f816-42b7-a241-8e31c1d61ec9@github.com>

On Wed, 30 Oct 2024 12:49:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Do I miss something?

Okay, so this must have been modified at some point to add/use isSupportedModuleDescriptorVersion, in which case readModuleAttribute won't be called. In that case, what you have is okay.

Minor nit, can you fix up the code style in the modified expression as it has ended up with && at the start and end of lines which looks a bit messy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1822617486

From archie.cobbs at gmail.com  Wed Oct 30 13:26:42 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 30 Oct 2024 08:26:42 -0500
Subject: Unchecked cast unchecked?
In-Reply-To: <30f33b81-bd19-41c2-8bc1-6dd27a6e60ce@oracle.com>
References: <CANSoFxtzU1Y9GSnC_mhcZ6gb5X1LCgfz9YXtTrfMcc1eJVqw1w@mail.gmail.com>
 <7ad3fb18-0335-4e05-b584-4c15ca979252@oracle.com>
 <30f33b81-bd19-41c2-8bc1-6dd27a6e60ce@oracle.com>
Message-ID: <CANSoFxsgWB6A0NLLqn136Q4E2WR79qJVkk3BEmP4cR147+njDg@mail.gmail.com>

Alex & Maurizio,

Thanks for the explanations & for creating the Jira issue.

FWIW here? is where I ran across this in real life.

-Archie

[1]
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java#L163-L166

On Wed, Oct 30, 2024 at 5:18?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Good catch - I believe the compiler does what it does because it uses the
> type of the cast (as well as the types of the aruments) to determine the
> final compile-time type of the method being called. This is the type that
> will (under erasure) be reified in the constant pool. So, here javac sees a
> call to a method that returns V and then a cast to V...
>
> Ideally javac should erase things earlier, or just use Object as the type
> of the method call, as Alex suggests. The latter might be slightly
> complicated because, after we added VarHandle support in Java 9, we also
> have some polymorphic methods whose return type is not Object (see
> VarHandle::compareAndSet). But, basically, javac should implement this more
> closely, w/o getting too distracted by the type inferred for the synthetic
> symbol attached to the method call AST node:
>
> The compile-time result is determined as follows:
>
>    -
>
>    If the signature polymorphic method is either void or has a return
>    type other than Object, the compile-time result is the result of the
>    invocation type of the compile-time declaration (?15.12.2.6
>    <https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.html#jls-15.12.2.6>).
>
>    -
>
>    Otherwise, if the method invocation expression is an expression
>    statement, the compile-time result is void.
>    -
>
>    Otherwise, if the method invocation expression is the operand of a
>    cast expression (?15.16
>    <https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.html#jls-15.16>),
>    the compile-time result is the erasure of the type of the cast expression (
>    ?4.6
>    <https://docs.oracle.com/javase/specs/jls/se15/html/jls-4.html#jls-4.6>
>    ).
>
>
>    -
>
>    Otherwise, the compile-time result is the signature polymorphic
>    method's return type, Object.
>
> Filed:
> https://bugs.openjdk.org/browse/JDK-8343286
>
> Cheers
> Maurizio
>
>
> On 29/10/2024 22:52, Alex Buckley wrote:
>
> VarHandle::getAndSet(Object[]) is a signature polymorphic method, which
> means that the type of a method call is sensitive to an ensuing cast:
>
> "... if the method invocation expression is the operand of a cast
> expression (?15.16), the compile-time result is the erasure of the type of
> the cast expression (?4.6)."  (JLS 15.12.3)
>
> This has implications for how the method call is compiled, but it's moot
> for your program because the type of the method call is Object no matter
> how you slice it.
>
> Casting from Object to type variable V is achieved by a narrowing
> reference conversion that is unchecked. So, I'd expect an "unchecked cast"
> warning, like for a non-signature polymorphic method.
>
> Alex
>
> On 10/29/2024 2:30 PM, Archie Cobbs wrote:
>
> Question: Should this program generate an unchecked cast warning?
>
> import java.lang.invoke.VarHandle;
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);  // unchecked cast?
>      }
> }
>
> Currently, it does not.
>
> Presumably that has something to do with this code in Types.java but I'm
> not sure why this would mean there should be no warning:
>
>      /**
>       * A polymorphic signature method (JLS 15.12.3) is a method that
>       *   (i) is declared in the java.lang.invoke.MethodHandle/VarHandle
> classes;
>       *  (ii) takes a single variable arity parameter;
>       * (iii) whose declared type is Object[];
>       *  (iv) has any return type, Object signifying a polymorphic return
> type; and
>       *   (v) is native.
>      */
>     public boolean isSignaturePolymorphic(MethodSymbol msym) {
>         List<Type> argtypes = msym.type.getParameterTypes();
>         return (msym.flags_field & NATIVE) != 0 &&
>                (msym.owner == syms.methodHandleType.tsym || msym.owner ==
> syms.varHandleType.tsym) &&
>                 argtypes.length() == 1 &&
>                 argtypes.head.hasTag(TypeTag.ARRAY) &&
>                 ((ArrayType)argtypes.head).elemtype.tsym ==
> syms.objectType.tsym;
>     }
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241030/616323f1/attachment-0001.htm>

From abimpoudis at openjdk.org  Wed Oct 30 13:52:52 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 30 Oct 2024 13:52:52 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v5]
In-Reply-To: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
Message-ID: <a1QWNoF9wXW4OOHU6p81wX0eIQFu0EZ0NgtwdjaxynA=.de5f8fa8-8d9f-4dbb-a211-64aba8dca73f@github.com>

> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
> 
> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
> 
> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Refactor deduplication test
  
  - introduce two kinds of groups
  - extract assertNotEqualsWithinGroup
  - extract isMethodWithName
  - extract addToGroup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21687/files
  - new: https://git.openjdk.org/jdk/pull/21687/files/afed3649..1c80a7c4

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

  Stats: 111 lines in 3 files changed: 35 ins; 10 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/21687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21687/head:pull/21687

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

From abimpoudis at openjdk.org  Wed Oct 30 14:29:31 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 30 Oct 2024 14:29:31 GMT
Subject: RFR: 8341408: Implement JEP 488: Primitive Types in Patterns,
 instanceof, and switch (Second Preview) [v3]
In-Reply-To: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
References: <2LL_yvKRw2gygxVtWb_6cZ0QZHNvJGPXBrkAZCLYn6k=.8c5f7d34-a91d-40ea-8b78-d958c1ec6924@github.com>
Message-ID: <TgHgim2q0g0aaJSlDAUEnBs66wliKuo1yfB3dbbLTiU=.aaf33244-5e3f-4694-943f-c6b8d842aadc@github.com>

> This PR prepares the improvement for JEP 488.
> 
> The proposed approach is described in the CSR.
> 
> In terms of compiler implementation, we add the related translation in `TransPatterns`. Interestingly, this issue would be ideally addressed in `TransTypes`. However, there are some conveniences in `TransPatterns` that would need to be pulled into `TransTypes` to make this work: 1) the dependency to `makeBinary` and transitively to `operators` and 2) a lot of ceremony around `currentMethodSym` is already setup nicely in `TransPatterns`.

Aggelos Biboudis 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 three additional commits since the last revision:

 - Merge branch 'master' into fix-#8341408
 - Address review
 - 8341408: Implement JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21539/files
  - new: https://git.openjdk.org/jdk/pull/21539/files/c056b439..ab587198

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

  Stats: 106140 lines in 1693 files changed: 39061 ins; 62093 del; 4986 mod
  Patch: https://git.openjdk.org/jdk/pull/21539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21539/head:pull/21539

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

From jlahoda at openjdk.org  Wed Oct 30 15:25:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Oct 2024 15:25:24 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v5]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <MQLi3Thx3P6aqJzcg0sLSNtcJiPlzT-B7Hc7bk9vhNM=.a0c44e93-5b1c-43e5-8a62-06c19f8d1ad9@github.com>

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Moving operators to the beginning of line, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21431/files
  - new: https://git.openjdk.org/jdk/pull/21431/files/94b8bf6d..9ae10e2c

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

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

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

From jlahoda at openjdk.org  Wed Oct 30 15:25:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 30 Oct 2024 15:25:25 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v4]
In-Reply-To: <w8YTaSGQRSGw3PKexmkPKBiLg3n9YbkWUpBqJCFnPDA=.f16f8de3-f816-42b7-a241-8e31c1d61ec9@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@github.com>
 <fkr6ezU1ggYyreCGoQK_rgpbnyrpA95XzKhhdBiy16k=.e0e4a629-6997-483d-9360-84820171d625@github.com>
 <A5nfKDzs5suWzcPytv8691_S65jlpCnTadPO8uatCvQ=.7aeee0f0-168a-4af5-b50c-bca7a4d60044@github.com>
 <w8YTaSGQRSGw3PKexmkPKBiLg3n9YbkWUpBqJCFnPDA=.f16f8de3-f816-42b7-a241-8e31c1d61ec9@github.com>
Message-ID: <QRgbP1UrJ4ENCrrSFudcElcvNS-cIH1mPiXuOsdynDo=.2591f286-1586-4506-8c7f-b65cddfef610@github.com>

On Wed, 30 Oct 2024 13:22:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I believe the check is already being done, right on the next line:
>> https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java#L192
>> which leads to:
>> https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/misc/VM.java#L188
>> which then leads to:
>> https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/misc/VM.java#L174
>> which has this check:
>> https://github.com/openjdk/jdk/blob/821c514a132e809a14648ddbb56f2ffee85fd35a/src/java.base/share/classes/jdk/internal/misc/VM.java#L179
>> 
>> I tried with a `module-info.class` with major version 65, and minor version 0xFFFF, and it correctly threw the exception for me.
>> 
>> Do I miss something?
>
>> Do I miss something?
> 
> Okay, so this must have been modified at some point to add/use isSupportedModuleDescriptorVersion, in which case readModuleAttribute won't be called. In that case, what you have is okay.
> 
> Minor nit, can you fix up the code style in the modified expression as it has ended up with && at the start and end of lines which looks a bit messy.

Thanks, done:
https://github.com/openjdk/jdk/pull/21431/commits/9ae10e2c43d240ba3647531c4d041589cf02875d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1822863309

From prappo at openjdk.org  Wed Oct 30 18:11:54 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 30 Oct 2024 18:11:54 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v3]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <LSERzhelV98qe6_4fxLl0hC44sRMLzUs0ZRQEIm_Sdo=.251c47c8-9da7-4841-bd78-c6cfa1c56265@github.com>

> Prepare for JDK 25.

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

  Update --release 24 symbol information for JDK 24 build 21
  
  The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/64e9326b..1286fcca

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

  Stats: 4074 lines in 61 files changed: 4073 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21763/head:pull/21763

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

From iris at openjdk.org  Wed Oct 30 18:37:07 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 30 Oct 2024 18:37:07 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v3]
In-Reply-To: <LSERzhelV98qe6_4fxLl0hC44sRMLzUs0ZRQEIm_Sdo=.251c47c8-9da7-4841-bd78-c6cfa1c56265@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <LSERzhelV98qe6_4fxLl0hC44sRMLzUs0ZRQEIm_Sdo=.251c47c8-9da7-4841-bd78-c6cfa1c56265@github.com>
Message-ID: <0qswlthN8tpTRWnIgOojOwBa_hb55wul3A8HMQscKP8=.a4a45b58-e583-4495-a078-e9eb4661e671@github.com>

On Wed, 30 Oct 2024 18:11:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update --release 24 symbol information for JDK 24 build 21
>   
>   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/

Additional changes (all autogenerated) look good.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2405939122

From darcy at openjdk.org  Wed Oct 30 18:46:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 30 Oct 2024 18:46:06 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v3]
In-Reply-To: <LSERzhelV98qe6_4fxLl0hC44sRMLzUs0ZRQEIm_Sdo=.251c47c8-9da7-4841-bd78-c6cfa1c56265@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <LSERzhelV98qe6_4fxLl0hC44sRMLzUs0ZRQEIm_Sdo=.251c47c8-9da7-4841-bd78-c6cfa1c56265@github.com>
Message-ID: <BkXwsNMYy_X3wiL89eQftGQG4TCvpr4AdokMJ_GegSs=.3a3d6079-1082-454d-a149-ddfe0b2cadbe@github.com>

On Wed, 30 Oct 2024 18:11:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update --release 24 symbol information for JDK 24 build 21
>   
>   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/

I skimmed over the new symbol information and the results look plausible.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2405964916

From liach at openjdk.org  Wed Oct 30 18:51:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Oct 2024 18:51:11 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v2]
In-Reply-To: <8qxwoSwCBqifwbsIEL5dOY2Q9qriF6UtE9eAUH9m1_M=.efaed9b4-655b-4c30-b807-2c73bfe28461@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <8qxwoSwCBqifwbsIEL5dOY2Q9qriF6UtE9eAUH9m1_M=.efaed9b4-655b-4c30-b807-2c73bfe28461@github.com>
Message-ID: <Rg2ojjG0F0fI-ZNiwahDeH0oK4gymc6tJBjDJGg9ZN0=.31d5fc26-09d2-4767-b81e-4c4b536d61ee@github.com>

On Wed, 30 Oct 2024 08:49:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
>> 
>> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
>> 
>> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
>> 
>> Here are some actions:
>> 1. Add section for hierarchy overview for both Type and AnnotatedType
>> 2. Specify the underlying type for different AnnotatedType subinterfaces
>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>> 5. Minor improvements to `ParameterizedType::getRawType`
>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>> 
>> API docs: https://cr.openjdk.org/~liach/8343251-api/java.base/java/lang/reflect/package-summary.html#class-summary
>> 
>> Please review the associated CSR as well.
>
> Chen Liang 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 five additional commits since the last revision:
> 
>  - Mass improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result

cc'ing this to the javac list: this brings in a few definitions from the JLS to core reflection, for which the compiler developers know better.

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

PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2448079672

From mullan at openjdk.org  Wed Oct 30 19:28:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:28:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Modify three RMI tests to work without the security manager:
    - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
    - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
    - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
   Also remove them from the problem list.
 - Remove two obsolete RMI tests:
    - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
    - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
   Adjust two tests to run without the Security Manager:
    - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
    - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
   Remove all of these tests from the problem list.
 - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
 - Added API Notes to ProtectionDomain clarifying that the current policy always
   grants no permissions. A few other small changes to Policy and PD.
 - Merge branch 'master' into jep486
 - JAXP tests: organize imports of a few tests
 - Improve description of Executors.privilegedThreadFactory
 - rename TestAppletLoggerContext.java as suggested in util test review
 - clientlibs: Javadoc cleanup
 - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=05
  Stats: 68829 lines in 1886 files changed: 2485 ins; 62501 del; 3843 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From alex.buckley at oracle.com  Wed Oct 30 19:46:51 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 30 Oct 2024 12:46:51 -0700
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v2]
In-Reply-To: <Rg2ojjG0F0fI-ZNiwahDeH0oK4gymc6tJBjDJGg9ZN0=.31d5fc26-09d2-4767-b81e-4c4b536d61ee@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <8qxwoSwCBqifwbsIEL5dOY2Q9qriF6UtE9eAUH9m1_M=.efaed9b4-655b-4c30-b807-2c73bfe28461@github.com>
 <Rg2ojjG0F0fI-ZNiwahDeH0oK4gymc6tJBjDJGg9ZN0=.31d5fc26-09d2-4767-b81e-4c4b536d61ee@github.com>
Message-ID: <b4bee885-f2ed-498c-9869-d37c91be7947@oracle.com>

Hi Chen,

On 10/30/2024 11:51 AM, Chen Liang wrote:
>>> 2. Specify the underlying type for different AnnotatedType subinterfaces

The new "Interface Hierarchy" starts with: "Annotated use of types in 
the Java programming language is modeled with these subinterfaces".

Only _annotated_ uses? Even though AnnotatedType generally speaks about 
the *potentially* annotated use of a type" ?

I think your best bet when introducing the interface hierarchy is to 
explain that some types are rich in structure, and each part of the 
structure is itself a type that can potentially be annotated. For 
example, the parameterized type `Collection<? extends Number>` actually 
denotes three uses of types that can potentially be annotated 
individually: (1) the parameterized type as a whole (`@Foo Collection<? 
extends Number>`); (2) the wildcard type argument (`Collection<@Bar ? 
extends Number>`); and (3) the wildcard type bound (`Collection<? 
extends @Quux Number>`). The AnnotatedType interface grants access to 
the potentially annotated use of a type as a whole (`@Foo 
Collection<..>`). If that type is rich in structure, subinterfaces of 
AnnotatedType grant additional access to the potentially annotated uses 
of types in parts of that structure.  [Note I have not said "structural 
type" at any point.]

With this in mind, you can see that e.g. AnnotatedParameterizedType 
doesn't model [the potentially annotated use of] parameterized types as 
such. AnnotatedType already models that: I can call getAnnotations() to 
get the @Foo in `@Foo Collection<..>`. What AnnotatedParameterizedType 
models is the potentially annotated use of types _serving as type 
arguments of a parameterized type_.

Similarly, AnnotatedWildcardType doesn't model wildcard type arguments 
as such -- you get the @Bar in `Collection<@Bar ? extends Number>` from 
the aforementioned AnnotatedParameterizedType, regardless of whether the 
type argument is a wildcard or not. What AnnotatedWildcardType models is 
the potentially annotated use of types _serving as upper or lower bounds 
of a wildcard type argument_. The @Quux in `<@Bar ? extends @Quux Number>`.

I recommend clarifying the interface hierarchy along those lines. Make 
liberal use of the same example type throughout, to demonstrate which 
part is which, and which use-of-a-type is which.

As for getType: before any interface hierarchy, you should explain what 
the underlying type of the annotated-type-as-a-whole is. An 
AnnotatedType that represents `@Foo int` yields the Class object for int 
as the underlying type. An AnnotatedType that represents `@Foo 
Collection<@Bar ? extends @Quux Number>` yields `Collection<? extends 
Number>` as the underlying type. By saying all this first, you can 
streamline the interface hierarchy to avoid mentioning 
getType/underlying types.

>>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.

This definition and use are very nice to see.

Alex

>>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>>> 5. Minor improvements to `ParameterizedType::getRawType`
>>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>>>
>>> API docs: https://cr.openjdk.org/~liach/8343251-api/java.base/java/lang/reflect/package-summary.html#class-summary
>>>
>>> Please review the associated CSR as well.
>>
>> Chen Liang 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 five additional commits since the last revision:
>>
>>   - Mass improvements
>>   - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>>   - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>>   - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>>   - 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result
> 
> cc'ing this to the javac list: this brings in a few definitions from the JLS to core reflection, for which the compiler developers know better.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2448079672


From mullan at openjdk.org  Wed Oct 30 19:46:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:46:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <lZcOTgw-GDnWydfumYS8_S_FKYztRvpJUdExxx0_pu4=.ef9178a6-ae67-40df-875d-d69968e75324@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Main changes in latest update include:

- Resolution of 6 remaining RMI related tests on the ProblemList by removing or replacing SM dependencies
- Added several API Notes to the `ProtectionDomain` to note that the "current policy" always grants no permissions.
- Updated definition of `networkaddress.cache.ttl` security property and removed specified behavior when Security Manager is enabled.
- Adjusted wording of `Executors.privilegedThreadFactory` and `privilegedCallable` to clarify use of current classloader
- A few miscellaneous fixes to tests, see other comments for pointer to fixes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448208886

From mullan at openjdk.org  Wed Oct 30 19:52:47 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:52:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>
Message-ID: <WxVLgqtMTy2s4lu6__o0VRy59hAVkG7THNCACepN8Lk=.93d6e4e8-ad7a-451c-ac19-7593a3a95ec2@github.com>

On Tue, 29 Oct 2024 17:07:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Font.java line 1613:
>> 
>>> 1611:      * interpreted as a {@code Font} object according to the
>>> 1612:      * specification of {@code Font.decode(String)}
>>> 1613:      * If the specified property is not found then null is returned instead.
>> 
>> Suggestion:
>> 
>>      * If the specified property is not found, null is returned instead.
>> 
>> The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.
>
> Updated on jep486 branch

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/90469c2e42d0259d032a7bdf3be20d81e9fb8fac

>> src/java.desktop/share/classes/java/awt/Font.java line 1781:
>> 
>>> 1779:      * The property value should be one of the forms accepted by
>>> 1780:      * {@code Font.decode(String)}
>>> 1781:      * If the specified property is not found then the {@code font}
>> 
>> Suggestion:
>> 
>>      * If the specified property is not found, the {@code font}
>
> Updated on jep486 branch

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/90469c2e42d0259d032a7bdf3be20d81e9fb8fac

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823297079
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823297577

From mullan at openjdk.org  Wed Oct 30 20:16:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <24vtAM0Ez1gNMgD69tDo3tvSJttBAB27n6S3du1YCI0=.3f968953-0bd9-4e8c-b77d-ef351f232116@github.com>

On Fri, 25 Oct 2024 21:18:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Comments on `java.security` classes.
> 
> Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/376d1b58bd442143ed9dc48c7d38cb5535af1569

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448236942

From mullan at openjdk.org  Wed Oct 30 20:16:43 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>
Message-ID: <GPn_TYX-s1iHAu2QRhyA6fZq0IY8QEj3151WQP3O44c=.5224e14c-d59c-4c01-a3cf-cf0a64bc998a@github.com>

On Mon, 28 Oct 2024 20:12:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Reviewed all tests under test/jaxp/javax/xml/jaxp. A few imports moved around unnecessarily but otherwise looks fine.

JAXP test comments fixed in https://github.com/openjdk/jdk/pull/21498/commits/5577e4884710eba498ee5f40fa85d47eaa07364d

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448243564

From mullan at openjdk.org  Wed Oct 30 20:16:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <QDRmqh8JFZp8wqckrMDjRg-xZqTsqh2gMS35zax4RF4=.6f15599e-85ff-40aa-b736-b8f64074faa1@github.com>

On Fri, 25 Oct 2024 20:44:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/logging/TestAppletLoggerContext.java line 40:
> 
>> 38:  * @modules java.base/jdk.internal.access
>> 39:  *          java.logging
>> 40:  * @run main/othervm TestAppletLoggerContext LoadingApplet
> 
> Rename these?  What's really being tested, there are no more Applets.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/444fabe80a7b53ba208db99d69b9778a6113454d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823302577

From mullan at openjdk.org  Wed Oct 30 20:16:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
 <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>
Message-ID: <eWQL7DYj1uuJ1CPxnHlGcggMuMiMzOOXFPDGrAbLQKM=.eb6e1333-eb8c-4d23-bca8-200a22e34ccd@github.com>

On Tue, 29 Oct 2024 18:35:05 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 392:
> 
>> 390:     /**
>> 391:      * Returns a thread factory used to create new threads that
>> 392:      * have current context class loader as the context class loader.
> 
> One nit for your consideration: "...to create new threads that have **_the_** current context class loader..."

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/06c4c3c1ab1fe121b625bd30a0c424be06d5022a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823307856

From mullan at openjdk.org  Wed Oct 30 20:16:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
 <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>
Message-ID: <GJqcqELAGDX0uDd55OOoblexMod-v5ByE02XvOpUx6M=.fb5f6f0b-66e8-4c47-b045-c99b5989df3e@github.com>

On Tue, 29 Oct 2024 14:19:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
>> 
>>> 1: /*
>> 
>> @wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?
>
> It can be removed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b2d59a432d6472263c1706d9dbb83c99cbf79793

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823306809

From vromero at openjdk.org  Wed Oct 30 22:00:39 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Oct 2024 22:00:39 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v5]
In-Reply-To: <a1QWNoF9wXW4OOHU6p81wX0eIQFu0EZ0NgtwdjaxynA=.de5f8fa8-8d9f-4dbb-a211-64aba8dca73f@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <a1QWNoF9wXW4OOHU6p81wX0eIQFu0EZ0NgtwdjaxynA=.de5f8fa8-8d9f-4dbb-a211-64aba8dca73f@github.com>
Message-ID: <hAsW0F2bzmUN7qgTB8h23I5Jr9Wl6mHChgaQNVuoRN4=.6dcd14a8-b20c-4e1c-94d5-252224bc16bd@github.com>

On Wed, 30 Oct 2024 13:52:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor deduplication test
>   
>   - introduce two kinds of groups
>   - extract assertNotEqualsWithinGroup
>   - extract isMethodWithName
>   - extract addToGroup

corpus jobs finished, mostly same results for both jobs one with and one without this patch. Of a total of ~23940 lambdas, none of them were deduplicated. This is a bit surprising tbh. It could be that most artifacts (all?) are generated with debug information. But still it seems like the benefit of this feature is marginal

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2448505231

From vromero at openjdk.org  Wed Oct 30 22:01:05 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 30 Oct 2024 22:01:05 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between a
 class and a sealed interface
Message-ID: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>

For code like:


class Test {
    sealed interface I permits C1 {}
    non-sealed class C1 implements I {}
    class C2 extends C1 {}
    class C3 {}
    I m(int s, C3 c3) {
        I i = (I)c3;
    }
}

javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:

5.1.6.1 Allowed Narrowing Reference Conversion:

? A class named C is disjoint from an interface named I if (i) it is not the case that
  C <: I , and (ii) one of the following cases applies:
  ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
  the permitted direct subclasses and subinterfaces of I .

and just below it continues:
? A class named C is disjoint from another class named D if (i) it is not the case
that C <: D , and (ii) it is not the case that D <: C .

so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`

This PR should sync javac with the spec

TIA

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

Commit messages:
 - 8343306: javac is failing to determine disjoint-ness between a class and a sealed interface

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

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

From josiahnoel at gmail.com  Thu Oct 31 00:45:43 2024
From: josiahnoel at gmail.com (Josiah Noel)
Date: Wed, 30 Oct 2024 20:45:43 -0400
Subject: ModuleElement#getEnclosedElements only has exported packages in some
 cases?
Message-ID: <CAJ_t5UYtWN6KEqR6o0UdA_giTOoNK9FBQ5q7aL4mTgp_aqk4Jw@mail.gmail.com>

Hey team,

I got an annotation processor that uses Elements#getAllModuleElements and
goes through all the packages to find classes matching a certain condition,
but it seems packages that are not explicitly exported are not present when
I call ModuleElement#getEnclosedElements.

Another thing that makes this odd is that when I know the package ahead of
time and call Elements#getPackageElement to get the non-exported package,
suddenly using getEnclosedElements() on the module element works as
expected.

I want to confirm if this behavior is intentional, as the Javadocs for
getEnclosedElements do not suggest this should be happening.

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241030/71a453cf/attachment.htm>

From alanb at openjdk.org  Thu Oct 31 11:10:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 11:10:35 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v5]
In-Reply-To: <MQLi3Thx3P6aqJzcg0sLSNtcJiPlzT-B7Hc7bk9vhNM=.a0c44e93-5b1c-43e5-8a62-06c19f8d1ad9@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <MQLi3Thx3P6aqJzcg0sLSNtcJiPlzT-B7Hc7bk9vhNM=.a0c44e93-5b1c-43e5-8a62-06c19f8d1ad9@github.com>
Message-ID: <I6z906uZoRigqUXeQmqkxWPImzV99MgiwXljHsY_gao=.b6041f08-d142-48c9-8a7a-28800cb2eb04@github.com>

On Wed, 30 Oct 2024 15:25:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moving operators to the beginning of line, as suggested.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2407660920

From mcimadamore at openjdk.org  Thu Oct 31 13:49:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Oct 2024 13:49:28 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <IIHnf_TPv3e_1UP_-I71qd0_t2yzP6mlx6sQiKANjn8=.94f9280b-6f6e-4dd2-b73e-4e4d175bf786@github.com>

On Wed, 30 Oct 2024 20:48:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> For code like:
> 
> 
> class Test {
>     sealed interface I permits C1 {}
>     non-sealed class C1 implements I {}
>     class C2 extends C1 {}
>     class C3 {}
>     I m(int s, C3 c3) {
>         I i = (I)c3;
>     }
> }
> 
> javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:
> 
> 5.1.6.1 Allowed Narrowing Reference Conversion:
> 
> ? A class named C is disjoint from an interface named I if (i) it is not the case that
>   C <: I , and (ii) one of the following cases applies:
>   ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
>   the permitted direct subclasses and subinterfaces of I .
> 
> and just below it continues:
> ? A class named C is disjoint from another class named D if (i) it is not the case
> that C <: D , and (ii) it is not the case that D <: C .
> 
> so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`
> 
> This PR should sync javac with the spec
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1685:

> 1683:                 if (!ts.isInterface() && !ss.isInterface()) {
> 1684:                     return !isSubtype(erasure(ss.type), erasure(ts.type)) && !isSubtype(erasure(ts.type), erasure(ss.type));
> 1685:                 } else if (ts.isInterface() && !ss.isInterface() || !ts.isInterface() && ss.isInterface()) {

can be simplified to `ts.isInterface() != ss.isInterface()`

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1694:

> 1692:                     } else {
> 1693:                         if (csym.isFinal()) {
> 1694:                             return true;

Maybe add a comment e.g. `not freely extensible`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1824494592
PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1824496092

From mcimadamore at openjdk.org  Thu Oct 31 13:52:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Oct 2024 13:52:31 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface
In-Reply-To: <IIHnf_TPv3e_1UP_-I71qd0_t2yzP6mlx6sQiKANjn8=.94f9280b-6f6e-4dd2-b73e-4e4d175bf786@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <IIHnf_TPv3e_1UP_-I71qd0_t2yzP6mlx6sQiKANjn8=.94f9280b-6f6e-4dd2-b73e-4e4d175bf786@github.com>
Message-ID: <DmaRh64QX5mXakV2je573lJKlh8q9l_F8r7kh51R4e0=.15fbd1a7-ed76-4ef7-a523-13abc7be44d7@github.com>

On Thu, 31 Oct 2024 13:46:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> For code like:
>> 
>> 
>> class Test {
>>     sealed interface I permits C1 {}
>>     non-sealed class C1 implements I {}
>>     class C2 extends C1 {}
>>     class C3 {}
>>     I m(int s, C3 c3) {
>>         I i = (I)c3;
>>     }
>> }
>> 
>> javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:
>> 
>> 5.1.6.1 Allowed Narrowing Reference Conversion:
>> 
>> ? A class named C is disjoint from an interface named I if (i) it is not the case that
>>   C <: I , and (ii) one of the following cases applies:
>>   ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
>>   the permitted direct subclasses and subinterfaces of I .
>> 
>> and just below it continues:
>> ? A class named C is disjoint from another class named D if (i) it is not the case
>> that C <: D , and (ii) it is not the case that D <: C .
>> 
>> so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`
>> 
>> This PR should sync javac with the spec
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1694:
> 
>> 1692:                     } else {
>> 1693:                         if (csym.isFinal()) {
>> 1694:                             return true;
> 
> Maybe add a comment e.g. `not freely extensible`

Strike that - freely extensible is checked later. Seems to me that this `csym.isFinal()` check is subsumed by the new `isClassFreelyExtensible` predicate (and so, can be removed) ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1824502440

From mcimadamore at openjdk.org  Thu Oct 31 14:01:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Oct 2024 14:01:35 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface
In-Reply-To: <DmaRh64QX5mXakV2je573lJKlh8q9l_F8r7kh51R4e0=.15fbd1a7-ed76-4ef7-a523-13abc7be44d7@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <IIHnf_TPv3e_1UP_-I71qd0_t2yzP6mlx6sQiKANjn8=.94f9280b-6f6e-4dd2-b73e-4e4d175bf786@github.com>
 <DmaRh64QX5mXakV2je573lJKlh8q9l_F8r7kh51R4e0=.15fbd1a7-ed76-4ef7-a523-13abc7be44d7@github.com>
Message-ID: <vN9owgmRG9cXyHvhAsr_DF9OGa1CGPYE46_1j8VeYjs=.72f9898a-e93b-4cc6-8409-70d3afd5c64c@github.com>

On Thu, 31 Oct 2024 13:49:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1694:
>> 
>>> 1692:                     } else {
>>> 1693:                         if (csym.isFinal()) {
>>> 1694:                             return true;
>> 
>> Maybe add a comment e.g. `not freely extensible`
>
> Strike that - freely extensible is checked later. Seems to me that this `csym.isFinal()` check is subsumed by the new `isClassFreelyExtensible` predicate (and so, can be removed) ?

Question: I find it hard to verify that this logic matches the spec exactly. That's because the spec says when under which conditions two types are disjoint, while this code seems to work the other way around -- e.g. find ways to say when two types are NOT disjoint. Also, the code tries to share some logic across different paths - which also makes thing harder to check.

Would it be possible to write the code the other way around and align it fully with the spec?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1824520801

From mcimadamore at openjdk.org  Thu Oct 31 14:01:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Oct 2024 14:01:36 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface
In-Reply-To: <vN9owgmRG9cXyHvhAsr_DF9OGa1CGPYE46_1j8VeYjs=.72f9898a-e93b-4cc6-8409-70d3afd5c64c@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <IIHnf_TPv3e_1UP_-I71qd0_t2yzP6mlx6sQiKANjn8=.94f9280b-6f6e-4dd2-b73e-4e4d175bf786@github.com>
 <DmaRh64QX5mXakV2je573lJKlh8q9l_F8r7kh51R4e0=.15fbd1a7-ed76-4ef7-a523-13abc7be44d7@github.com>
 <vN9owgmRG9cXyHvhAsr_DF9OGa1CGPYE46_1j8VeYjs=.72f9898a-e93b-4cc6-8409-70d3afd5c64c@github.com>
Message-ID: <W4aepClAQAUPzC-WP1Tg7VSFL7RGx6HhnC9Yvcle5Uo=.f44bb1e5-40b8-429f-947f-89f5799f2a3d@github.com>

On Thu, 31 Oct 2024 13:57:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Strike that - freely extensible is checked later. Seems to me that this `csym.isFinal()` check is subsumed by the new `isClassFreelyExtensible` predicate (and so, can be removed) ?
>
> Question: I find it hard to verify that this logic matches the spec exactly. That's because the spec says when under which conditions two types are disjoint, while this code seems to work the other way around -- e.g. find ways to say when two types are NOT disjoint. Also, the code tries to share some logic across different paths - which also makes thing harder to check.
> 
> Would it be possible to write the code the other way around and align it fully with the spec?

(Note - the problems above are pre-existing, but since we're here we might as well clean up for good?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1824524377

From hannesw at openjdk.org  Thu Oct 31 15:07:30 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 31 Oct 2024 15:07:30 GMT
Subject: RFR: 8321500: javadoc rejects '@' in multi-line attribute value
In-Reply-To: <amUfJTXOU-pJSzHLzkbWBc08a0BWwHTleAKMqIriRgU=.3f7adc68-ab65-4987-a1b6-83984e06061c@github.com>
References: <iGNlKeyVvefYhVtec6ES01D4DuBGKY8A4ktfjWO8Nfk=.f3992295-7a3f-42d0-bfd7-27ee0cdda676@github.com>
 <amUfJTXOU-pJSzHLzkbWBc08a0BWwHTleAKMqIriRgU=.3f7adc68-ab65-4987-a1b6-83984e06061c@github.com>
Message-ID: <5-1MXtmYPbwC9p4PIDvGWgC_y7K16IDwMGrQGLjWUQY=.b32683af-4b99-49c9-9a6c-58046aa38829@github.com>

On Thu, 24 Oct 2024 13:49:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Let's hope they don't start using constructs like `title="{@see`. On second thought, in that case, they can escape `@` with `@@`, provided their javadoc is reasonably modern. Consider adding a test for this.

As it turns out there are several problems with both unescaped and escaped inline tags in HTML attribute values. I filed [a JBS issue][jbs] for them. While part of the inline tag issue (reading escaped inline tags) will require fixes in `DocCommentParser.java`, it is not related to the issue addressed in this PR, so I propose to handle them separately.

[jbs]: https://bugs.openjdk.org/browse/JDK-8343393

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

PR Comment: https://git.openjdk.org/jdk/pull/21520#issuecomment-2450117119

From vromero at openjdk.org  Thu Oct 31 15:16:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 15:16:32 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v19]
In-Reply-To: <CLtQGe9FdkFu25BZJspRbmugWpU4Kl-E2K0cVU4V_VA=.ed6a382b-b436-489f-ad5d-6affeaacd036@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CLtQGe9FdkFu25BZJspRbmugWpU4Kl-E2K0cVU4V_VA=.ed6a382b-b436-489f-ad5d-6affeaacd036@github.com>
Message-ID: <k9d35-jnh7wV_SW8d0zYHyW2Yu-l23Yg5wn0fYNaZNM=.1e177442-8ec4-4276-969b-5847483a2fb2@github.com>

On Tue, 29 Oct 2024 14:50:51 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test failures

thanks!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20718#pullrequestreview-2408261939

From vromero at openjdk.org  Thu Oct 31 15:16:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 15:16:33 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v18]
In-Reply-To: <gC1yNl8SaHt-VaEoWzZX6xZuQk6JA6F8zjFgQFfw63I=.39431a8f-abed-4677-b35d-0be2fa688c8c@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
 <gC1yNl8SaHt-VaEoWzZX6xZuQk6JA6F8zjFgQFfw63I=.39431a8f-abed-4677-b35d-0be2fa688c8c@github.com>
Message-ID: <AbsOlUCUP29dXZKuLgnpdfdG0vJIFJ--msGf0KA_8Fg=.f56e9eca-c6ab-4cbe-a5a0-3fc96e1deb17@github.com>

On Mon, 28 Oct 2024 11:20:54 GMT, Evemose <duke at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove trailing whitespaces
>>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>>  - address review comments
>
> By the way, does anyone know why ci fails? It fails on generate report, not on tests. I tried to sync branch with master but it seems like it has not had any affect

@Evemose I was waiting for the results of the tests after your last change, all green, we are good to go

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2450136378

From duke at openjdk.org  Thu Oct 31 15:23:36 2024
From: duke at openjdk.org (duke)
Date: Thu, 31 Oct 2024 15:23:36 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v19]
In-Reply-To: <CLtQGe9FdkFu25BZJspRbmugWpU4Kl-E2K0cVU4V_VA=.ed6a382b-b436-489f-ad5d-6affeaacd036@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CLtQGe9FdkFu25BZJspRbmugWpU4Kl-E2K0cVU4V_VA=.ed6a382b-b436-489f-ad5d-6affeaacd036@github.com>
Message-ID: <BMAdJrqfRV63eyrzmnBjj7zfJGRE-i8uD5dxt8QLME8=.f817fd0c-1da6-42e6-8aa6-c9426ead8310@github.com>

On Tue, 29 Oct 2024 14:50:51 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test failures

@Evemose 
Your change (at version 0889133b3ca9380d8d4ad836b82bd4236edc5c2c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2450147959

From duke at openjdk.org  Thu Oct 31 15:23:37 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 31 Oct 2024 15:23:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v18]
In-Reply-To: <gC1yNl8SaHt-VaEoWzZX6xZuQk6JA6F8zjFgQFfw63I=.39431a8f-abed-4677-b35d-0be2fa688c8c@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
 <gC1yNl8SaHt-VaEoWzZX6xZuQk6JA6F8zjFgQFfw63I=.39431a8f-abed-4677-b35d-0be2fa688c8c@github.com>
Message-ID: <cTxVzThUB8iBW-uSOgie2ltBXvY3h9L0CaEAlzJhSk0=.ff32987e-9280-4e1b-b7dc-016abf2976a6@github.com>

On Mon, 28 Oct 2024 11:20:54 GMT, Evemose <duke at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove trailing whitespaces
>>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>>  - address review comments
>
> By the way, does anyone know why ci fails? It fails on generate report, not on tests. I tried to sync branch with master but it seems like it has not had any affect

> @Evemose I was waiting for the results of the tests after your last change, all green, we are good to go

Glad we are finally done with this one. Got a bit busy lately, pr could`ve taken much less time, thanks for your patience. Would you mind sponsoring?

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2450151873

From vromero at openjdk.org  Thu Oct 31 15:28:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 15:28:37 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v18]
In-Reply-To: <cTxVzThUB8iBW-uSOgie2ltBXvY3h9L0CaEAlzJhSk0=.ff32987e-9280-4e1b-b7dc-016abf2976a6@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <CUy4mxHcxeCXRksSDWFvstDTzCEI-7e-G1GorEA7lgw=.ed8b0af7-55dc-4d92-97ee-c58db5e1b7fb@github.com>
 <gC1yNl8SaHt-VaEoWzZX6xZuQk6JA6F8zjFgQFfw63I=.39431a8f-abed-4677-b35d-0be2fa688c8c@github.com>
 <cTxVzThUB8iBW-uSOgie2ltBXvY3h9L0CaEAlzJhSk0=.ff32987e-9280-4e1b-b7dc-016abf2976a6@github.com>
Message-ID: <LZgKJvrXNOkAhkUtTsmttjdTIhkwqOcsPqU9vtTHnqo=.6c405fb8-1d9d-4678-97db-ae1278bcf6ac@github.com>

On Thu, 31 Oct 2024 15:20:08 GMT, Evemose <duke at openjdk.org> wrote:

> > @Evemose I was waiting for the results of the tests after your last change, all green, we are good to go
> 
> Glad we are finally done with this one. Got a bit busy lately, pr could`ve taken much less time, thanks for your patience. Would you mind sponsoring?

thanks to you!

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2450163581

From duke at openjdk.org  Thu Oct 31 15:28:38 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 31 Oct 2024 15:28:38 GMT
Subject: Integrated: 8338981: Access to private classes should be permitted
 inside the permits clause of the enclosing top-level class
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <pUvcQ7F0B-2ZueJjLYrudUFUHvQVfq6i7ix5cNxWAno=.d75a2d75-5ff4-4e62-8835-f056791d375e@github.com>

On Mon, 26 Aug 2024 21:46:04 GMT, Evemose <duke at openjdk.org> wrote:

> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause

This pull request has now been integrated.

Changeset: b2694934
Author:    Olexandr Rotan <rotan.olexandr at gmail.com>
URL:       https://git.openjdk.org/jdk/commit/b2694934b567c896b715c420584ce0989d2decc9
Stats:     211 lines in 5 files changed: 206 ins; 1 del; 4 mod

8338981: Access to private classes should be permitted inside the permits clause of the enclosing top-level class

Reviewed-by: vromero, mcimadamore

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

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

From vromero at openjdk.org  Thu Oct 31 15:47:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 15:47:17 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface [v2]
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <aK6to2fYPXF8y5qqHhIhAGn6YfigF5tEMrE9XD-ZEOw=.25a37166-7cb6-45fa-a3a7-251ffeb182ae@github.com>

> For code like:
> 
> 
> class Test {
>     sealed interface I permits C1 {}
>     non-sealed class C1 implements I {}
>     class C2 extends C1 {}
>     class C3 {}
>     I m(int s, C3 c3) {
>         I i = (I)c3;
>     }
> }
> 
> javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:
> 
> 5.1.6.1 Allowed Narrowing Reference Conversion:
> 
> ? A class named C is disjoint from an interface named I if (i) it is not the case that
>   C <: I , and (ii) one of the following cases applies:
>   ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
>   the permitted direct subclasses and subinterfaces of I .
> 
> and just below it continues:
> ? A class named C is disjoint from another class named D if (i) it is not the case
> that C <: D , and (ii) it is not the case that D <: C .
> 
> so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`
> 
> This PR should sync javac with the spec
> 
> TIA

Vicente Romero 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8343306
 - 8343306: javac is failing to determine disjoint-ness between a class and a sealed interface

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21794/files
  - new: https://git.openjdk.org/jdk/pull/21794/files/38f0de17..9dd1430f

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

  Stats: 2279 lines in 296 files changed: 932 ins; 369 del; 978 mod
  Patch: https://git.openjdk.org/jdk/pull/21794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21794/head:pull/21794

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

From rriggs at openjdk.org  Thu Oct 31 15:58:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Oct 2024 15:58:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <y-jccaVTuCdisVPbN2qCr2rVn8tCHNLThqd75t2crl0=.7c7a4790-5327-4925-9153-e591cfee552d@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2408378244

From mchung at openjdk.org  Thu Oct 31 16:11:04 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 31 Oct 2024 16:11:04 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <T5ERS9U-Z-8BFoRNUpGqJnmRkP6FQc8DEX7qbXqODVU=.6f3e8f2f-de82-48c0-a8ee-c935093e825a@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2408431117

From abimpoudis at openjdk.org  Thu Oct 31 16:54:34 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 31 Oct 2024 16:54:34 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v5]
In-Reply-To: <a1QWNoF9wXW4OOHU6p81wX0eIQFu0EZ0NgtwdjaxynA=.de5f8fa8-8d9f-4dbb-a211-64aba8dca73f@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <a1QWNoF9wXW4OOHU6p81wX0eIQFu0EZ0NgtwdjaxynA=.de5f8fa8-8d9f-4dbb-a211-64aba8dca73f@github.com>
Message-ID: <y8UDdUESmvWPK6qa4HU7hqr0EW197T7lD3IYFOLkGe8=.f834487e-8999-4edf-accc-5e5b8f90dfd6@github.com>

On Wed, 30 Oct 2024 13:52:52 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After experimentation and under certain conditions, a few equivalent lambdas (up to variable renaming) fail to deduplicate.
>> 
>> `TreeHasher` and `TreeDiffer` are now aware that other bootstraps may appear in lambda bodies (e.g. `SwitchBootstraps.typeSwitch`) and that variable names do not matter (when they appear in method/lambda definitions). In the first case equivalence is checked based on `bsmKey` and not the `Dynamic{Var, Method}Symbol` itself.
>> 
>> The test was also adjusted since it was assuming BSM with certain structure only (that `.get(1)` was unprotected).
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor deduplication test
>   
>   - introduce two kinds of groups
>   - extract assertNotEqualsWithinGroup
>   - extract isMethodWithName
>   - extract addToGroup

Addressed the reviews with https://github.com/openjdk/jdk/pull/21687/commits/1c80a7c45e950cd49f98f22f1ec055be10e5f22e 
(which would be great if someone could have a final quick look).

I guess the only thing now is to decide (based on the experiments' results) whether we merge this and remove later, or close this and remove dedup now or remove later ?

Sooner or later, this test will start to fail when lambda bodies start containing other kinds of bootstrap invocations.

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2450362290

From jlahoda at openjdk.org  Thu Oct 31 17:51:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 31 Oct 2024 17:51:30 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v5]
In-Reply-To: <hAsW0F2bzmUN7qgTB8h23I5Jr9Wl6mHChgaQNVuoRN4=.6dcd14a8-b20c-4e1c-94d5-252224bc16bd@github.com>
References: <DjNHzR-moTe25Yddx9kLz_vthe6js73g46nFACA9H-o=.201ed945-8639-4983-9f05-dfd1fbac5415@github.com>
 <a1QWNoF9wXW4OOHU6p81wX0eIQFu0EZ0NgtwdjaxynA=.de5f8fa8-8d9f-4dbb-a211-64aba8dca73f@github.com>
 <hAsW0F2bzmUN7qgTB8h23I5Jr9Wl6mHChgaQNVuoRN4=.6dcd14a8-b20c-4e1c-94d5-252224bc16bd@github.com>
Message-ID: <p55sgBiBNQQNS34ADpaq_jgEQhuc5pTBfv5J6aOs8ao=.0468144f-6903-4b8b-8876-6bb74b31fd48@github.com>

On Wed, 30 Oct 2024 21:57:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> corpus jobs finished, mostly same results for both jobs one with and one without this patch. Of a total of ~23940 lambdas, none of them were deduplicated. This is a bit surprising tbh. It could be that most artifacts (all?) are generated with debug information. But still it seems like the benefit of this feature is marginal

Maybe not so surprising. I believe the default for javac is `-g:lines`, which disables the de-duplication. So, it would actually require the builds to explicitly use `-g:none`, which is probably not very common.

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2450477797

From vromero at openjdk.org  Thu Oct 31 17:57:45 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 17:57:45 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface [v3]
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <KVuqJBfpgVg9Rq9OvMyo2edSxkNKRErbiXW-vaVf9ic=.0f08e758-3b01-46f4-ad27-a9ca7a3dcd3c@github.com>

> For code like:
> 
> 
> class Test {
>     sealed interface I permits C1 {}
>     non-sealed class C1 implements I {}
>     class C2 extends C1 {}
>     class C3 {}
>     I m(int s, C3 c3) {
>         I i = (I)c3;
>     }
> }
> 
> javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:
> 
> 5.1.6.1 Allowed Narrowing Reference Conversion:
> 
> ? A class named C is disjoint from an interface named I if (i) it is not the case that
>   C <: I , and (ii) one of the following cases applies:
>   ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
>   the permitted direct subclasses and subinterfaces of I .
> 
> and just below it continues:
> ? A class named C is disjoint from another class named D if (i) it is not the case
> that C <: D , and (ii) it is not the case that D <: C .
> 
> so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`
> 
> This PR should sync javac with the spec
> 
> TIA

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

  implementation closer to the spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21794/files
  - new: https://git.openjdk.org/jdk/pull/21794/files/9dd1430f..e8501a97

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

  Stats: 41 lines in 1 file changed: 17 ins; 11 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21794/head:pull/21794

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

From nbenalla at openjdk.org  Thu Oct 31 18:02:56 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 31 Oct 2024 18:02:56 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v3]
In-Reply-To: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
Message-ID: <BKi9kA7RCGuiVYKxWFyur3ULv2nKY67buLnZof0swu8=.bb08239e-5bf1-43b7-bdd0-f6a3e090630b@github.com>

> Can I please get a review for this change.
> Passes tier1, currently running tier 2-3.
> 
> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
> 
> Here is the result of running `javap -c -p -v` on `ClassAnnotationWithLength_65536.class`  and `ClassAnnotationWithLength_65537.class` respectively. Results are the same before/after the change.
> 
> 
> static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l]
>         )
> 
> 
> 
>   static int x;
>     descriptor: I
>     flags: (0x0008) ACC_STATIC
>     RuntimeVisibleAnnotations:
>       0: #14(#15=s#16,#17=I#18,#19=[J#20,J#20])
>         CustomAnno(
>           value="custom"
>           count=42
>           arr=[-1l,-1l]
>         )
> 
> 
> TIA

Nizar Benalla 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 seven additional commits since the last revision:

 - Update test
 - revert changes to TypeAnnotations
   generate error when param array is too large
   generate error closer to other limits, during code gen
 - Merge remote-tracking branch 'upstream/master' into 8339190-Parameter-arrays
 - - remove unused import
   - realized I need to change the condition in my for loop
 - try to remove trailing whitespace
 - simplify BufferedWriter creation
 - JDK-8339190

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21663/files
  - new: https://git.openjdk.org/jdk/pull/21663/files/80d25a19..35b89ece

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

  Stats: 23960 lines in 191 files changed: 4180 ins; 18863 del; 917 mod
  Patch: https://git.openjdk.org/jdk/pull/21663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21663/head:pull/21663

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

From jlahoda at openjdk.org  Thu Oct 31 18:06:34 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 31 Oct 2024 18:06:34 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface [v3]
In-Reply-To: <KVuqJBfpgVg9Rq9OvMyo2edSxkNKRErbiXW-vaVf9ic=.0f08e758-3b01-46f4-ad27-a9ca7a3dcd3c@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <KVuqJBfpgVg9Rq9OvMyo2edSxkNKRErbiXW-vaVf9ic=.0f08e758-3b01-46f4-ad27-a9ca7a3dcd3c@github.com>
Message-ID: <d1yD2vaWB_VAp3i4mg-k2b_JroCXavuiuF8_aulKABw=.42157304-dd72-4080-b094-eee3bcac6f87@github.com>

On Thu, 31 Oct 2024 17:57:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> For code like:
>> 
>> 
>> class Test {
>>     sealed interface I permits C1 {}
>>     non-sealed class C1 implements I {}
>>     class C2 extends C1 {}
>>     class C3 {}
>>     I m(int s, C3 c3) {
>>         I i = (I)c3;
>>     }
>> }
>> 
>> javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:
>> 
>> 5.1.6.1 Allowed Narrowing Reference Conversion:
>> 
>> ? A class named C is disjoint from an interface named I if (i) it is not the case that
>>   C <: I , and (ii) one of the following cases applies:
>>   ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
>>   the permitted direct subclasses and subinterfaces of I .
>> 
>> and just below it continues:
>> ? A class named C is disjoint from another class named D if (i) it is not the case
>> that C <: D , and (ii) it is not the case that D <: C .
>> 
>> so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`
>> 
>> This PR should sync javac with the spec
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implementation closer to the spec

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1719:

> 1717: 
> 1718:             private boolean isClassFreelyExtensible(ClassSymbol csym) {
> 1719:                 boolean anySuperIsSealed = (csym.getSuperclass().tsym != null && csym.getSuperclass().tsym.isSealed()) || csym.getInterfaces().stream().anyMatch(i -> i.tsym.isSealed());

I am not sure about these checks. Should it be simply `isClassFreelyExtensible == !csym.isSealed() && !csym.isFinal()`? Or is the a particular case this is solving.

(Besides this code being more complex, I suspect "non-sealed" is not restored when reading from classfiles - is that correct? Will this code do something sensible when `csym` is read from a classfile, and has a sealed supertype?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1824942423

From nbenalla at openjdk.org  Thu Oct 31 18:16:29 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 31 Oct 2024 18:16:29 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v3]
In-Reply-To: <BKi9kA7RCGuiVYKxWFyur3ULv2nKY67buLnZof0swu8=.bb08239e-5bf1-43b7-bdd0-f6a3e090630b@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <BKi9kA7RCGuiVYKxWFyur3ULv2nKY67buLnZof0swu8=.bb08239e-5bf1-43b7-bdd0-f6a3e090630b@github.com>
Message-ID: <ev3971ShkSx8eTOQ-nUEbBN6htSgUrKEhOEt3642TVo=.2ac19870-c089-435f-9613-eff5b744f4d2@github.com>

On Thu, 31 Oct 2024 18:02:56 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get reviews for this change.
>> 
>> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
>> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
>> 
>> Here is the truncated result of running `javap -c -p -v` (before the change) on `ClassAnnotationWithLength_65536_RUNTIME.class`  and `ClassAnnotationWithLength_65537_RUNTIME..class` respectively.
>> 
>> 
>>   static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[])
>>         MyCustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[]
>>         )
>> 
>> 
>>   static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>>         MyCustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[-1l]
>>         )
>> 
>> 
>> After the change a compile-time error is thrown
>> 
>> 
>> javac ClassAnnotationWithLength_65536_RUNTIME.java 
>> error: Annotation array element too large in "MyCustomAnno"
>> 
>> 
>> TIA
>
> Nizar Benalla 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 seven additional commits since the last revision:
> 
>  - Update test
>  - revert changes to TypeAnnotations
>    generate error when param array is too large
>    generate error closer to other limits, during code gen
>  - Merge remote-tracking branch 'upstream/master' into 8339190-Parameter-arrays
>  - - remove unused import
>    - realized I need to change the condition in my for loop
>  - try to remove trailing whitespace
>  - simplify BufferedWriter creation
>  - JDK-8339190

I've updated the PR to now generate a compile-time error when the annotation array length exceeds the limit.
Also expanded the test to check type annotations and annotations with class/runtime retention. The test runs in ~4 seconds on my machine.

I can make the test smaller if necessary. Or maybe expand it to include a negative test to check the code runs as intended.

Will update the CSR next.

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

PR Comment: https://git.openjdk.org/jdk/pull/21663#issuecomment-2450531409

From vromero at openjdk.org  Thu Oct 31 18:43:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 18:43:30 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface [v3]
In-Reply-To: <d1yD2vaWB_VAp3i4mg-k2b_JroCXavuiuF8_aulKABw=.42157304-dd72-4080-b094-eee3bcac6f87@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <KVuqJBfpgVg9Rq9OvMyo2edSxkNKRErbiXW-vaVf9ic=.0f08e758-3b01-46f4-ad27-a9ca7a3dcd3c@github.com>
 <d1yD2vaWB_VAp3i4mg-k2b_JroCXavuiuF8_aulKABw=.42157304-dd72-4080-b094-eee3bcac6f87@github.com>
Message-ID: <BsJZucveWM-YrDilr1v-CwLY3YKMAJiAL--ZsTrk4Yw=.eb20104c-0f41-418c-bd63-1a51b242736a@github.com>

On Thu, 31 Oct 2024 18:03:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implementation closer to the spec
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1719:
> 
>> 1717: 
>> 1718:             private boolean isClassFreelyExtensible(ClassSymbol csym) {
>> 1719:                 boolean anySuperIsSealed = (csym.getSuperclass().tsym != null && csym.getSuperclass().tsym.isSealed()) || csym.getInterfaces().stream().anyMatch(i -> i.tsym.isSealed());
> 
> I am not sure about these checks. Should it be simply `isClassFreelyExtensible == !csym.isSealed() && !csym.isFinal()`? Or is the a particular case this is solving.
> 
> (Besides this code being more complex, I suspect "non-sealed" is not restored when reading from classfiles - is that correct? Will this code do something sensible when `csym` is read from a classfile, and has a sealed supertype?)

yes I think you are right, will do

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825016102

From mcimadamore at openjdk.org  Thu Oct 31 18:52:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Oct 2024 18:52:30 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface [v3]
In-Reply-To: <KVuqJBfpgVg9Rq9OvMyo2edSxkNKRErbiXW-vaVf9ic=.0f08e758-3b01-46f4-ad27-a9ca7a3dcd3c@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <KVuqJBfpgVg9Rq9OvMyo2edSxkNKRErbiXW-vaVf9ic=.0f08e758-3b01-46f4-ad27-a9ca7a3dcd3c@github.com>
Message-ID: <NcNzvzr5WeeW3DYWSAJK6hclIuVt03M_kO3TSqSpBVk=.eaabbd02-e76e-4b32-89f2-045c6417db39@github.com>

On Thu, 31 Oct 2024 17:57:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> For code like:
>> 
>> 
>> class Test {
>>     sealed interface I permits C1 {}
>>     non-sealed class C1 implements I {}
>>     class C2 extends C1 {}
>>     class C3 {}
>>     I m(int s, C3 c3) {
>>         I i = (I)c3;
>>     }
>> }
>> 
>> javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:
>> 
>> 5.1.6.1 Allowed Narrowing Reference Conversion:
>> 
>> ? A class named C is disjoint from an interface named I if (i) it is not the case that
>>   C <: I , and (ii) one of the following cases applies:
>>   ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
>>   the permitted direct subclasses and subinterfaces of I .
>> 
>> and just below it continues:
>> ? A class named C is disjoint from another class named D if (i) it is not the case
>> that C <: D , and (ii) it is not the case that D <: C .
>> 
>> so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`
>> 
>> This PR should sync javac with the spec
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implementation closer to the spec

The new code looks great. I pulled up the new file and read the code side by side with the spec and was very pleased with the easy-to-spot symmetry. Thanks!

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1689:

> 1687:                     return false;
> 1688: 
> 1689:                 if (ts.isInterface() && !ss.isInterface() || // case I: one is a class and the other one is an interface

Nit: you can still simplify this to `ts.isInterface() != ss.isInterface()`

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21794#pullrequestreview-2408852261
PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825025286

From vromero at openjdk.org  Thu Oct 31 18:59:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 18:59:28 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface [v3]
In-Reply-To: <NcNzvzr5WeeW3DYWSAJK6hclIuVt03M_kO3TSqSpBVk=.eaabbd02-e76e-4b32-89f2-045c6417db39@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <KVuqJBfpgVg9Rq9OvMyo2edSxkNKRErbiXW-vaVf9ic=.0f08e758-3b01-46f4-ad27-a9ca7a3dcd3c@github.com>
 <NcNzvzr5WeeW3DYWSAJK6hclIuVt03M_kO3TSqSpBVk=.eaabbd02-e76e-4b32-89f2-045c6417db39@github.com>
Message-ID: <idvCOYDBr1Bq2ksvJkmIV-4dsnqdgUE7FMm3LrL4R_Y=.1001151f-d6c1-43e9-8df0-bf9ad9a0c3fd@github.com>

On Thu, 31 Oct 2024 18:50:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new code looks great. I pulled up the new file and read the code side by side with the spec and was very pleased with the easy-to-spot symmetry. Thanks!

yes I agree that the code looks much better now, thanks for the suggestion

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

PR Comment: https://git.openjdk.org/jdk/pull/21794#issuecomment-2450611743

From vromero at openjdk.org  Thu Oct 31 19:21:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 19:21:34 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v3]
In-Reply-To: <BKi9kA7RCGuiVYKxWFyur3ULv2nKY67buLnZof0swu8=.bb08239e-5bf1-43b7-bdd0-f6a3e090630b@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <BKi9kA7RCGuiVYKxWFyur3ULv2nKY67buLnZof0swu8=.bb08239e-5bf1-43b7-bdd0-f6a3e090630b@github.com>
Message-ID: <zvXH5hjcJ51FJnkTGuf-v5h2vb0SVHlEUdzsWpKtC2o=.73485b2d-94bc-42ea-b9e5-17c60df27829@github.com>

On Thu, 31 Oct 2024 18:02:56 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get reviews for this change.
>> 
>> The regression test creates temporary files in `tmpdir` to check that the warning is emitted correctly.
>> I've also added the new warning to `example.not-yet.txt` as the example would require a very large file.
>> 
>> Here is the truncated result of running `javap -c -p -v` (before the change) on `ClassAnnotationWithLength_65536_RUNTIME.class`  and `ClassAnnotationWithLength_65537_RUNTIME..class` respectively.
>> 
>> 
>>   static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[])
>>         MyCustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[]
>>         )
>> 
>> 
>>   static int x;
>>     descriptor: I
>>     flags: (0x0008) ACC_STATIC
>>     RuntimeVisibleAnnotations:
>>       0: #14(#15=s#16,#17=I#18,#19=[J#20])
>>         MyCustomAnno(
>>           value="custom"
>>           count=42
>>           arr=[-1l]
>>         )
>> 
>> 
>> After the change a compile-time error is thrown
>> 
>> 
>> javac ClassAnnotationWithLength_65536_RUNTIME.java 
>> error: Annotation array element too large in "MyCustomAnno"
>> 
>> 
>> TIA
>
> Nizar Benalla 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 seven additional commits since the last revision:
> 
>  - Update test
>  - revert changes to TypeAnnotations
>    generate error when param array is too large
>    generate error closer to other limits, during code gen
>  - Merge remote-tracking branch 'upstream/master' into 8339190-Parameter-arrays
>  - - remove unused import
>    - realized I need to change the condition in my for loop
>  - try to remove trailing whitespace
>  - simplify BufferedWriter creation
>  - JDK-8339190

general comment. I wonder if we should add a predicate to com.sun.tools.javac.jvm.Target ala: `Target::runtimeUseNestAccess()` so that we don't generate this error for targets `< 24`, the rest looks good to me

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

PR Review: https://git.openjdk.org/jdk/pull/21663#pullrequestreview-2408903415

From vromero at openjdk.org  Thu Oct 31 19:31:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Oct 2024 19:31:09 GMT
Subject: RFR: 8343306: javac is failing to determine disjoint-ness between
 a class and a sealed interface [v4]
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <0IWNauPGzF0NKnsqCbY-o04iLU71JcQ8DHoZKjM6jb0=.cd5adfa4-86c4-45a3-a896-dff38c79f8f3@github.com>

> For code like:
> 
> 
> class Test {
>     sealed interface I permits C1 {}
>     non-sealed class C1 implements I {}
>     class C2 extends C1 {}
>     class C3 {}
>     I m(int s, C3 c3) {
>         I i = (I)c3;
>     }
> }
> 
> javac is failing to issue an error and accepts this code. The spec is clear stating that code like this should be rejected. See:
> 
> 5.1.6.1 Allowed Narrowing Reference Conversion:
> 
> ? A class named C is disjoint from an interface named I if (i) it is not the case that
>   C <: I , and (ii) one of the following cases applies:
>   ? C is freely extensible (?8.1.1.2), and I is sealed , and C is disjoint from all of
>   the permitted direct subclasses and subinterfaces of I .
> 
> and just below it continues:
> ? A class named C is disjoint from another class named D if (i) it is not the case
> that C <: D , and (ii) it is not the case that D <: C .
> 
> so here we have the `C3` is a freely extensible class and interface `I` is sealed and `C3` is disjoint from `C1` which is is the permitted subclass of interface `I`
> 
> This PR should sync javac with the spec
> 
> TIA

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21794/files
  - new: https://git.openjdk.org/jdk/pull/21794/files/e8501a97..e2f60639

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

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

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

From liach at openjdk.org  Thu Oct 31 19:35:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Oct 2024 19:35:48 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v3]
In-Reply-To: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
Message-ID: <aP_-nJhVRMxQ4uZwWSQOtSENhiQLuO6B41bYEbbgGDQ=.0762c434-4908-43ff-85b8-8b0fe423886c@github.com>

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> API diffs: https://cr.openjdk.org/~liach/8343251-apidiff/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang 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 nine additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Mass improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/2d14b047..090eee17

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

  Stats: 46218 lines in 758 files changed: 3099 ins; 40210 del; 2909 mod
  Patch: https://git.openjdk.org/jdk/pull/19977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977

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

From liach at openjdk.org  Thu Oct 31 19:40:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Oct 2024 19:40:39 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v3]
In-Reply-To: <aP_-nJhVRMxQ4uZwWSQOtSENhiQLuO6B41bYEbbgGDQ=.0762c434-4908-43ff-85b8-8b0fe423886c@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <aP_-nJhVRMxQ4uZwWSQOtSENhiQLuO6B41bYEbbgGDQ=.0762c434-4908-43ff-85b8-8b0fe423886c@github.com>
Message-ID: <Jy-5hLE-LxI58im0QorgjUNqrV0vgpMOyKeSFeCKqRc=.8c9523ee-9fbe-492b-8653-a2f527c744c9@github.com>

On Thu, 31 Oct 2024 19:35:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
>> 
>> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
>> 
>> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
>> 
>> Here are some actions:
>> 1. Add section for hierarchy overview for both Type and AnnotatedType
>> 2. Specify the underlying type for different AnnotatedType subinterfaces
>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>> 5. Minor improvements to `ParameterizedType::getRawType`
>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>> 
>> API diffs: https://cr.openjdk.org/~liach/8343251-apidiff/java.base/java/lang/reflect/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang 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 nine additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Cleanup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Mass improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result

Alex, thanks for your review!

Please review the APIdiff for the updated version at https://cr.openjdk.org/~liach/8343251-apidiff/java.base/java/lang/reflect/package-summary.html which includes the HTML rendering as well.

Notably, I gave up the interface hierarchy section and replaced it with a Java type or type argument to modeling interface mapping.  This is more natural from the Java programmer point of view, and makes the documentation more concise.  I have also included relevant examples, as you have recommended.  The terms for AnnotatedXxType are all updated to be "use" instead of "type", and I distinguished type versus type argument as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2450679110

From alex.buckley at oracle.com  Thu Oct 31 19:53:37 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 31 Oct 2024 12:53:37 -0700
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v3]
In-Reply-To: <Jy-5hLE-LxI58im0QorgjUNqrV0vgpMOyKeSFeCKqRc=.8c9523ee-9fbe-492b-8653-a2f527c744c9@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <aP_-nJhVRMxQ4uZwWSQOtSENhiQLuO6B41bYEbbgGDQ=.0762c434-4908-43ff-85b8-8b0fe423886c@github.com>
 <Jy-5hLE-LxI58im0QorgjUNqrV0vgpMOyKeSFeCKqRc=.8c9523ee-9fbe-492b-8653-a2f527c744c9@github.com>
Message-ID: <9e85b8fb-64a5-4d76-bc06-880a6f49dad2@oracle.com>

On 10/31/2024 12:40 PM, Chen Liang wrote:
> Please review the APIdiff for the updated version at https://cr.openjdk.org/~liach/8343251-apidiff/java.base/java/lang/reflect/package-summary.html which includes the HTML rendering as well.
> 
> Notably, I gave up the interface hierarchy section and replaced it with a Java type or type argument to modeling interface mapping.  This is more natural from the Java programmer point of view, and makes the documentation more concise.  I have also included relevant examples, as you have recommended.  The terms for AnnotatedXxType are all updated to be "use" instead of "type", and I distinguished type versus type argument as well.

Type has become difficult to read. Please lighten up the introductory 
paragraph. To do that, I recommend unifying the kinds of types/type 
arguments (primitive types, reference types, raw types, wildcard type 
arguments ...) with the mapping from types/type arguments to the 
interface hierarchy. One list, giving the kind of type + an example + 
the appropriate interface or subinterface.

Do the same in AnnotatedType. Also, drop the introduction of "current 
runtime" -- this is about the use of types/type arguments in programs.

Alex



From javalists at cbfiddle.com  Thu Oct 31 20:29:11 2024
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 31 Oct 2024 13:29:11 -0700
Subject: testing the -target option
In-Reply-To: <464e9598-4c67-4833-842f-7b454888dc01@oracle.com>
References: <4B0CE760-AEE0-46E6-A479-961A7AD22D59@cbfiddle.com>
 <464e9598-4c67-4833-842f-7b454888dc01@oracle.com>
Message-ID: <49EA70BC-6ABC-4B5F-ABA1-1005E2AEF814@cbfiddle.com>

> You can satisfy your curiosity by looking the the javac regressions tests in the OpenJDK repo. Under
> 
> https://github.com/openjdk/jdk
> 
> see the test/langtools/tools/javac directory hierarchy.
> 

Thank you.

I took a quick look at the files in that directory. I found many examples of using -target (or --release). The negative tests are easy to understand. The feature tests less so, as apparently each individual test developer decides what releases to test.

The thoroughness of the tests varies considerably. A few tests use all of the supported releases (from 8 onward), but many just test one or two releases and the current release. I don't see any way to estimate the coverage of these tests.

Given that the byte code produced by javac is not examined, the best way to positively test the -target feature for a given target is to run tests that are compatible with that target, and I would think that the best source of such tests is the actual target release. It looks like jtreg could do this, using the -compilejdk and -javacoption options. Has anyone tried this?

The most comprehensive test would be to use the latest javac to build the target release and then run all of the normal pre-release tests. I'm guessing that could be done by making the latest JDK the boot JDK (although the documentation only mentions using older JDKs), setting COMPILER=bootjdk and JDK_SOURCE_TARGET_VERSION to the target release (if necessary). Not something to be done nightly, but perhaps a good idea shortly before blessing a new release.

  Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241031/51544fd5/attachment-0001.htm>

From acobbs at openjdk.org  Thu Oct 31 21:58:38 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 31 Oct 2024 21:58:38 GMT
Subject: RFR: 8343412: Missing escapes for single quote marks in
 javac.properties
Message-ID: <DO2aqREeLAeqvFQwX78FU6RJ5pxiJ6bmgclI7n9nRKk=.766048b3-fb9b-466d-8e9a-20c6106553fc@github.com>

Please review these simple syntax fixes for `javac.properties`.

The source file `javac.properties` contains the English message bundle for the javac tool. Since the strings in this file are `MessageFormat` format strings, any single quotes must be escaped by doubling them.

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

Commit messages:
 - Include javac.properties in the MessageFormat validation check.
 - Fix unescaped single quotes in javac.properties.

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

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

From liach at openjdk.org  Thu Oct 31 22:36:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Oct 2024 22:36:45 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v4]
In-Reply-To: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
Message-ID: <alhxNdZBoGZY89UJzxq95LEtgkMnZY_MGr5OdI1fPwo=.46aa932b-2713-4a02-be54-e5767aae3555@github.com>

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> API diffs: https://cr.openjdk.org/~liach/8343251-apidiff/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Intro and other various improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/090eee17..83feba99

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

  Stats: 150 lines in 7 files changed: 54 ins; 12 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/19977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977

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

From liach at openjdk.org  Thu Oct 31 22:36:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Oct 2024 22:36:46 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v3]
In-Reply-To: <aP_-nJhVRMxQ4uZwWSQOtSENhiQLuO6B41bYEbbgGDQ=.0762c434-4908-43ff-85b8-8b0fe423886c@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <aP_-nJhVRMxQ4uZwWSQOtSENhiQLuO6B41bYEbbgGDQ=.0762c434-4908-43ff-85b8-8b0fe423886c@github.com>
Message-ID: <IZ6E_wHVsBCV2Y9w-b2TvRLEqEdciJesLM_QRKdtgI4=.5d1d6f1a-858d-49d6-8ab9-e7fb8244502b@github.com>

On Thu, 31 Oct 2024 19:35:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
>> 
>> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
>> 
>> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
>> 
>> Here are some actions:
>> 1. Add section for hierarchy overview for both Type and AnnotatedType
>> 2. Specify the underlying type for different AnnotatedType subinterfaces
>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>> 5. Minor improvements to `ParameterizedType::getRawType`
>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>> 
>> API diffs: https://cr.openjdk.org/~liach/8343251-apidiff/java.base/java/lang/reflect/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang 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 nine additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Cleanup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Mass improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
>  - 8306039: ParameterizedType.getOwnerType() documentation is incomplete about null result

Thanks for the recommendations. I have moved the trees into a table; it should be much more straightforward from the HTML documentation.

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

PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2450965360

From nbenalla at openjdk.org  Thu Oct 31 22:40:28 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 31 Oct 2024 22:40:28 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v3]
In-Reply-To: <zvXH5hjcJ51FJnkTGuf-v5h2vb0SVHlEUdzsWpKtC2o=.73485b2d-94bc-42ea-b9e5-17c60df27829@github.com>
References: <RrA7lr5KEGymm4BRJcOrWjSxHjPYeHC42TlIXcL5FQc=.b2f5e0aa-3bf8-48e5-9aee-4469a9002cae@github.com>
 <BKi9kA7RCGuiVYKxWFyur3ULv2nKY67buLnZof0swu8=.bb08239e-5bf1-43b7-bdd0-f6a3e090630b@github.com>
 <zvXH5hjcJ51FJnkTGuf-v5h2vb0SVHlEUdzsWpKtC2o=.73485b2d-94bc-42ea-b9e5-17c60df27829@github.com>
Message-ID: <gjT0xhr98fIklEfy9CX0zJkDbmOtWfdEyn5Gq7kOGeU=.8cbeb25b-b06a-4f06-abe6-3a3cce388da1@github.com>

On Thu, 31 Oct 2024 19:19:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> general comment. I wonder if we should add a predicate to com.sun.tools.javac.jvm.Target ala: Target::runtimeUseNestAccess() so that we don't generate this error for targets < 24, the rest looks good to me

I can easily add it if you or other Reviewers think it's a good idea. But it might not be worth it? The purpose of this change was to prevent generating classfiles that don't match the input files.

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

PR Comment: https://git.openjdk.org/jdk/pull/21663#issuecomment-2450969354