From attila at openjdk.org  Fri Nov  1 09:19:12 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Fri, 1 Nov 2024 09:19:12 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: <yCCKheohe-gTYgtLgXobFgKSQOYjymWCWQ_0zzF9O0w=.84ce1a1f-f8ca-435b-8a98-63073ac9ea5a@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

`jdk.dynalink` changes look good.

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

Marked as reviewed by attila (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2409755977

From vromero at openjdk.org  Fri Nov  1 13:30:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Nov 2024 13:30:28 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v4]
In-Reply-To: <0IWNauPGzF0NKnsqCbY-o04iLU71JcQ8DHoZKjM6jb0=.cd5adfa4-86c4-45a3-a896-dff38c79f8f3@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <0IWNauPGzF0NKnsqCbY-o04iLU71JcQ8DHoZKjM6jb0=.cd5adfa4-86c4-45a3-a896-dff38c79f8f3@github.com>
Message-ID: <UeQ9jPCbTSbn8eL7xGhkkkyc4T8Xyn4oh0w4dQGuozg=.d1dd78dc-f388-42a4-aba3-3fec899ff3ee@github.com>

On Thu, 31 Oct 2024 19:31:09 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:
> 
>   addressing review comments

please review the CSR too, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21794#issuecomment-2451873460

From prappo at openjdk.org  Fri Nov  1 13:53:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Nov 2024 13:53:35 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: <DrhjKkkQ3Hibu8U6w7aSfQnHlUk_gfHz-LlPagAZcN4=.fbe631e9-f6ee-4e9b-b010-c00db8c70cb8@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.

Looks good to me.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21520#pullrequestreview-2410110533

From jlahoda at openjdk.org  Fri Nov  1 13:53:39 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 1 Nov 2024 13:53:39 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v4]
In-Reply-To: <0IWNauPGzF0NKnsqCbY-o04iLU71JcQ8DHoZKjM6jb0=.cd5adfa4-86c4-45a3-a896-dff38c79f8f3@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <0IWNauPGzF0NKnsqCbY-o04iLU71JcQ8DHoZKjM6jb0=.cd5adfa4-86c4-45a3-a896-dff38c79f8f3@github.com>
Message-ID: <Iz07qOuF40k0blPYJeh7J7X_r5TpgBwpoMuNQ8GLIkI=.b298f9d0-3588-4480-9dc0-519cdc5ece82@github.com>

On Thu, 31 Oct 2024 19:31:09 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:
> 
>   addressing review comments

Looks good to me. A few comments for consideration inline - these are up to you.

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

Only for consideration: the specification does not have 3 cases, but 4, when the second asks the "areDisjoint" question with swapped arguments. The code here is equivalent to that, but might be easier to just re-do what the spec is doing, having handle the case where `ts` is a class, `ss` is an interface, and then have something along the lines:

} else if (ts.isInterface() && !ss.isInterface()) {
     return areDisjoint(ss, ts);
}

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1697:

> 1695:                         } else if (csym.isSealed()) {
> 1696:                             return areDisjoint(isym, csym.getPermittedSubclasses());
> 1697:                         } else if (!csym.isSealed() && isym.isSealed()) {

Nit: the `!csym.isSealed()` seems superfluous here. We know `csym.isSealed()` returns `false` (otherwise we would not get here). Hence `!csym.isSealed()` is always `true`.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1701:

> 1699:                         }
> 1700:                     }
> 1701:                 } else if (!ts.isInterface() &&              // case II: both are classes

Nit: it is not necessary to check both `ts` and `ss` (although it is not wrong). If one of them is a class, both are. For your consideration.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1713:

> 1711:                     }
> 1712:                 }
> 1713:                 // at this point we haven't been able to prove that the classes or interfaces are disjoint so we bail out

Nit: I would drop the "so we bail out". javac is not giving up - it just checked what JLS says should be checked, and can't prove the types are disjoint.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21794#pullrequestreview-2410098024
PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825835099
PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825836054
PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825837557
PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825841400

From prappo at openjdk.org  Fri Nov  1 14:14:51 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Nov 2024 14:14:51 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v4]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <mK7TQp3GfHcv73DKoOhXaUFeTEAyY9LxpY8e7srvJ18=.6a1c08fd-018d-4884-b184-42583ac41849@github.com>

> Prepare for JDK 25.

Pavel Rappo 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:

 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 21
   
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
 - Add forgotten .jcheck/conf
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/1286fcca..9a0553bb

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

  Stats: 49274 lines in 836 files changed: 5371 ins; 40901 del; 3002 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 vromero at openjdk.org  Fri Nov  1 14:55:29 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Nov 2024 14:55:29 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v4]
In-Reply-To: <Iz07qOuF40k0blPYJeh7J7X_r5TpgBwpoMuNQ8GLIkI=.b298f9d0-3588-4480-9dc0-519cdc5ece82@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <0IWNauPGzF0NKnsqCbY-o04iLU71JcQ8DHoZKjM6jb0=.cd5adfa4-86c4-45a3-a896-dff38c79f8f3@github.com>
 <Iz07qOuF40k0blPYJeh7J7X_r5TpgBwpoMuNQ8GLIkI=.b298f9d0-3588-4480-9dc0-519cdc5ece82@github.com>
Message-ID: <_NX2aEMeZaHkz7Bep3mRSb3lWOYTecxZSGtpV6pftnc=.429bc1db-e87e-4c9e-88e8-44916432c2b0@github.com>

On Fri, 1 Nov 2024 13:44:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> 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
> 
> Only for consideration: the specification does not have 3 cases, but 4, when the second asks the "areDisjoint" question with swapped arguments. The code here is equivalent to that, but might be easier to just re-do what the spec is doing, having handle the case where `ts` is a class, `ss` is an interface, and then have something along the lines:
> 
> } else if (ts.isInterface() && !ss.isInterface()) {
>      return areDisjoint(ss, ts);
> }

you are right but given that these two cases can be folded into one, I mean when one is an interface an the other is a class, I think I prefer the current code. Both cases are symmetrical so I think they could naturally be folded into one

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825914971

From vromero at openjdk.org  Fri Nov  1 14:59:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Nov 2024 14:59:28 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v4]
In-Reply-To: <Iz07qOuF40k0blPYJeh7J7X_r5TpgBwpoMuNQ8GLIkI=.b298f9d0-3588-4480-9dc0-519cdc5ece82@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <0IWNauPGzF0NKnsqCbY-o04iLU71JcQ8DHoZKjM6jb0=.cd5adfa4-86c4-45a3-a896-dff38c79f8f3@github.com>
 <Iz07qOuF40k0blPYJeh7J7X_r5TpgBwpoMuNQ8GLIkI=.b298f9d0-3588-4480-9dc0-519cdc5ece82@github.com>
Message-ID: <BKT2m9lLqAUuJAjrjDSoYxgWhHZSwl09EL7BX2TylDs=.b366f083-9edd-4d92-ac76-755525588159@github.com>

On Fri, 1 Nov 2024 13:46:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1701:
> 
>> 1699:                         }
>> 1700:                     }
>> 1701:                 } else if (!ts.isInterface() &&              // case II: both are classes
> 
> Nit: it is not necessary to check both `ts` and `ss` (although it is not wrong). If one of them is a class, both are. For your consideration.

not sure, what if both are interfaces at this point in the code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1825919524

From vromero at openjdk.org  Fri Nov  1 15:02:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Nov 2024 15:02:42 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v5]
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <Kfe-LCLhufBxKGgbX412be5pkON2iRKKguBDjhRDv5g=.14f7cd70-f5ad-46ef-a465-083835533561@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/e2f60639..4838a140

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 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 jjg at openjdk.org  Fri Nov  1 16:01:29 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 1 Nov 2024 16:01:29 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: <Zw7dsXHPutMkq_qS5d0oz5LOO_JVll9_CqdDW9eGQgc=.978abe10-f8f0-4e7d-8bcb-b05e6efcf8cd@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.

As a (very) general comment, it is not a requirement that the standard doclet (or `DocCommentParser`) should support a maximal applicable subset of HTML. It is reasonable for there to be restrictions, preferably as long as they are (better) documented. The goal is to be able to support all "reasonable" doc comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/21520#issuecomment-2452122384

From joe.darcy at oracle.com  Fri Nov  1 16:09:30 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 1 Nov 2024 09:09:30 -0700
Subject: testing the -target option
In-Reply-To: <49EA70BC-6ABC-4B5F-ABA1-1005E2AEF814@cbfiddle.com>
References: <4B0CE760-AEE0-46E6-A479-961A7AD22D59@cbfiddle.com>
 <464e9598-4c67-4833-842f-7b454888dc01@oracle.com>
 <49EA70BC-6ABC-4B5F-ABA1-1005E2AEF814@cbfiddle.com>
Message-ID: <f94262c0-58b9-49dd-a199-56144be63656@oracle.com>


On 10/31/2024 1:29 PM, Alan Snyder wrote:
>>
>> 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.


When I write tests for a new language feature, I'll use multiple test 
harness directives in a single test file:

1) Run the test on the last version of the language _without_ the 
feature and verify the right compiler error is reported at the expected 
location
2) Run the test on the current language version, which is assumed to 
support the feature going into the future, and in some cases verify the 
operation of compiled code

Correct functional operation of the feature, i.e. does the generated 
code run properly, may also be done under separate test files.

While not implemented this way directly, the "is feature X supported in 
the language level being used for this compilation" usually boils down 
to a check of "language level used for the compilation >= first language 
level where this feature is supported."

>
> 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.

For a given feature, generally it is either support or not supported 
and, if it is supported, it is most commonly compiled a single way 
across releases (although as noted elsewhere, that is not a 
requirement). So as white box regression tests, this technique is 
sufficient for code coverage.


>
> 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?

A considerable amount of effort is already spent on testing the JDK, 
especially "tier 1" areas like the core libraries and javac. Spinning up 
large new testing methodologies that have little expectation of finding 
issues is not attractive.

-Joe



From asotona at openjdk.org  Fri Nov  1 16:23:34 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 16:23:34 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
Message-ID: <MyDELcrkBSGRLWaSH1SiBLCbRUQ1j-4RjRYxht3Wlq8=.b29108c1-a430-4c90-945c-9107977bddd9@github.com>

On Wed, 30 Oct 2024 13:01:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 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.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21787#pullrequestreview-2410400307

From vromero at openjdk.org  Fri Nov  1 17:47:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Nov 2024 17:47:31 GMT
Subject: RFR: 8339190: Parameter arrays that are capped during annotation
 processing report incorrect length [v3]
In-Reply-To: <gjT0xhr98fIklEfy9CX0zJkDbmOtWfdEyn5Gq7kOGeU=.8cbeb25b-b06a-4f06-abe6-3a3cce388da1@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>
 <gjT0xhr98fIklEfy9CX0zJkDbmOtWfdEyn5Gq7kOGeU=.8cbeb25b-b06a-4f06-abe6-3a3cce388da1@github.com>
Message-ID: <Zysq5Vh2HBixkEEXa7SnQy-SzeR9proeHu02BQbqHUQ=.1d980e73-e753-4d1a-be1d-ef47dfb33068@github.com>

On Thu, 31 Oct 2024 22:37:25 GMT, Nizar Benalla <nbenalla 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.
> 
> I will bring it up in the CSR comment section.

not sure tbh, probably not necessary

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

PR Comment: https://git.openjdk.org/jdk/pull/21663#issuecomment-2452310564

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 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: <5_m66jOr6E-qHq5r9AHGX-Yb5IKCT_VbHGmq_Yh8v34=.172e81bb-9281-4364-a8cb-3696c5ef4b36@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

I looked through the updates to `java.desktop` module and to tests under `java/awt`, `javax/sound`, `javax/swing`.

Looks good.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2410517684

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@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>
 <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>
Message-ID: <mvT1t92RTxP5hIzw4FI8nhFlY_Vv9Md6ZhT5I6jr4rc=.16f5be4b-3885-4e52-920f-7cf399e99a70@github.com>

On Thu, 24 Oct 2024 20:57:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @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.

> > 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_.
>
> ? 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.

I've submitted [JDK-8343448](https://bugs.openjdk.org/browse/JDK-8343448): _Improve formatting of docs in java.awt.Desktop_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826079117

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@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>
 <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com>
Message-ID: <BKKnlgdcwUbIGvmukmS0xfXL3JqXL6TVXwckzzdXKRk=.c68053bd-cb29-4dcc-a34b-c0a49397ff6c@github.com>

On Mon, 28 Oct 2024 14:08:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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.

I've submitted [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446): _Add missing periods in docs for java.awt.Font_.

>> 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.

Deferred to [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826080609
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826081342

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@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>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
Message-ID: <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>

On Mon, 28 Oct 2024 18:07:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> 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

> 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.

@prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?

The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:

https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826141057

From aivanov at openjdk.org  Fri Nov  1 19:43:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:43:18 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: <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@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

test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1:

> 1: /*

I wonder if we should add an Oracle copyright to the update test file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826228675

From aivanov at openjdk.org  Fri Nov  1 19:43:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:43:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@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>
 <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@github.com>
Message-ID: <f5IcQJqOak2nDS4qB6f3s_Dl-zHGs4g45Grph8KCe_s=.9978557c-258f-4b7f-b49a-c0595cfd2a29@github.com>

On Mon, 28 Oct 2024 14:35:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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

Thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826225216

From aivanov at openjdk.org  Fri Nov  1 20:31:37 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 20:31:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@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>
 <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@github.com>
Message-ID: <sA2jKaSsQXz3NGMICFq-okZkJV_NNcIPZgEyd-vEMio=.bcb93df4-b266-4951-87d4-a91d610ec051@github.com>

On Tue, 29 Oct 2024 12:56:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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

> 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 " 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.

I guess it's the intended behaviour, jtreg implies `@run` if there are no other commands; you have to provide `@run` explicitly if there are `@compile` or `@build` tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826256418

From stephan.herrmann at berlin.de  Fri Nov  1 21:31:59 2024
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Fri, 1 Nov 2024 22:31:59 +0100
Subject: syntax of type pattern vs. local variable declaration
Message-ID: <eb8b9f24-688d-45df-a835-d63e8b4d423c@berlin.de>

We have this test case:

-------------------
abstract sealed class J<T1, T2> permits X.S, A {}

final class A extends J<Integer, String> {}

public class X<T> {

	final class S<U> extends J<T, U> {}

	int testExhaustive(J<Integer, String> ji) {
		return switch (ji) {
			case A a -> 42;
			case X<Integer>.S<String> e -> 4200;
		};
	}
	public static void main(String[] args) {
		X<Integer>.S<String> xs = null;
		System.out.println(new X<Integer>().testExhaustive(new X<Integer>().new 
S<String>()));
	}
}
-------------------

In comparing with javac we noticed that javac reports this error:

X.java:12: error: illegal start of type
      case X<Integer>.S<String> e -> 4200;
                                ^

The grammar states that the syntax for TypePattern is the same as 
LocalVariableDeclaration. Now see that in main() a local variable with the same 
shape is accepted by javac, so it should also accept the type pattern, right?

regards,
Stephan

From acobbs at openjdk.org  Fri Nov  1 21:51:41 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 1 Nov 2024 21:51:41 GMT
Subject: RFR: 8343412: Missing escapes for single quote marks in
 javac.properties [v2]
In-Reply-To: <DO2aqREeLAeqvFQwX78FU6RJ5pxiJ6bmgclI7n9nRKk=.766048b3-fb9b-466d-8e9a-20c6106553fc@github.com>
References: <DO2aqREeLAeqvFQwX78FU6RJ5pxiJ6bmgclI7n9nRKk=.766048b3-fb9b-466d-8e9a-20c6106553fc@github.com>
Message-ID: <hhAw03AreUnleboIoZz5HnH-_4iebMwrxDT2VEQwgEQ=.99a94747-2e1d-46c7-8bed-0d665d2f3164@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.

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

  Reword to keep width under 80 columns.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21816/files
  - new: https://git.openjdk.org/jdk/pull/21816/files/31e74035..ac32b52c

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 vromero at openjdk.org  Sat Nov  2 02:06:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 2 Nov 2024 02:06:28 GMT
Subject: RFR: 8343412: Missing escapes for single quote marks in
 javac.properties [v2]
In-Reply-To: <hhAw03AreUnleboIoZz5HnH-_4iebMwrxDT2VEQwgEQ=.99a94747-2e1d-46c7-8bed-0d665d2f3164@github.com>
References: <DO2aqREeLAeqvFQwX78FU6RJ5pxiJ6bmgclI7n9nRKk=.766048b3-fb9b-466d-8e9a-20c6106553fc@github.com>
 <hhAw03AreUnleboIoZz5HnH-_4iebMwrxDT2VEQwgEQ=.99a94747-2e1d-46c7-8bed-0d665d2f3164@github.com>
Message-ID: <VEaY7Tfaf6dEU7vtzOWXB2GkX87WYO-rryqf5eAoigg=.5b4b939b-d8fa-4d68-b457-f7482a88e786@github.com>

On Fri, 1 Nov 2024 21:51:41 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword to keep width under 80 columns.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21816#pullrequestreview-2411118350

From acobbs at openjdk.org  Sat Nov  2 02:34:30 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 2 Nov 2024 02:34:30 GMT
Subject: RFR: 8343412: Missing escapes for single quote marks in
 javac.properties [v2]
In-Reply-To: <VEaY7Tfaf6dEU7vtzOWXB2GkX87WYO-rryqf5eAoigg=.5b4b939b-d8fa-4d68-b457-f7482a88e786@github.com>
References: <DO2aqREeLAeqvFQwX78FU6RJ5pxiJ6bmgclI7n9nRKk=.766048b3-fb9b-466d-8e9a-20c6106553fc@github.com>
 <hhAw03AreUnleboIoZz5HnH-_4iebMwrxDT2VEQwgEQ=.99a94747-2e1d-46c7-8bed-0d665d2f3164@github.com>
 <VEaY7Tfaf6dEU7vtzOWXB2GkX87WYO-rryqf5eAoigg=.5b4b939b-d8fa-4d68-b457-f7482a88e786@github.com>
Message-ID: <1SxMLVSr7vW_pXwhM_Ox3JoFwcS3npO9IttCX398PLk=.9a89821c-209f-42d2-a4a0-8d8e3ea54ff1@github.com>

On Sat, 2 Nov 2024 02:04:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reword to keep width under 80 columns.
>
> looks good

@vicente-romero-oracle thanks for the quick review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21816#issuecomment-2452808343

From acobbs at openjdk.org  Sat Nov  2 02:34:31 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 2 Nov 2024 02:34:31 GMT
Subject: Integrated: 8343412: Missing escapes for single quote marks in
 javac.properties
In-Reply-To: <DO2aqREeLAeqvFQwX78FU6RJ5pxiJ6bmgclI7n9nRKk=.766048b3-fb9b-466d-8e9a-20c6106553fc@github.com>
References: <DO2aqREeLAeqvFQwX78FU6RJ5pxiJ6bmgclI7n9nRKk=.766048b3-fb9b-466d-8e9a-20c6106553fc@github.com>
Message-ID: <wXcJ5nyiGtYQfmfpS-sGIz9O04-0k9XR4bSi528GOm0=.0bff1770-4f69-460c-aea4-f95afaf655d9@github.com>

On Thu, 31 Oct 2024 21:54:34 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: 00ec1057
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00ec10574dd66ba300f02929ec9406a6b9fdfb07
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8343412: Missing escapes for single quote marks in javac.properties

Reviewed-by: vromero

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

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

From jpai at openjdk.org  Sat Nov  2 10:45:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Nov 2024 10:45:28 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
Message-ID: <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>

On Wed, 30 Oct 2024 13:01:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 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.

This looks OK to me and matches what is stated in the CSR.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:

> 70:         //---
> 71:         @JEP(number=495, title="Simple Source Files and Instance Main Methods", status="Fourth Preview")
> 72:         IMPLICIT_CLASSES,

Hello Jan, although it's just an internal enum name, do you think we should rename it to be closer to the JEP's title or is it not worth it?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21787#pullrequestreview-2411231079
PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826544471

From alanb at openjdk.org  Sat Nov  2 15:13:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Nov 2024 15:13:29 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
 <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
Message-ID: <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>

On Sat, 2 Nov 2024 10:41:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 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.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:
> 
>> 70:         //---
>> 71:         @JEP(number=495, title="Simple Source Files and Instance Main Methods", status="Fourth Preview")
>> 72:         IMPLICIT_CLASSES,
> 
> Hello Jan, although it's just an internal enum name, do you think we should rename it to be closer to the JEP's title or is it not worth it?

The title also shows up in list of preview APIs in the javadoc so changing seems correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826585785

From acobbs at openjdk.org  Sat Nov  2 15:32:00 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 2 Nov 2024 15:32:00 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler)
Message-ID: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>

Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

Commit messages:
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Apply change that was missed somehow.
 - Undo change that will be moved to the core-libs branch.
 - Remove unnecessary @SuppressWarnings annotations.

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

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

From acobbs at openjdk.org  Sat Nov  2 15:45:00 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 2 Nov 2024 15:45:00 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs)
Message-ID: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>

Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

Commit messages:
 - Remove unnecessary @SuppressWarnings annotations.

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343478
  Stats: 113 lines in 89 files changed: 0 ins; 82 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From jlahoda at openjdk.org  Sat Nov  2 17:11:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Sat, 2 Nov 2024 17:11:28 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
 <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
 <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>
Message-ID: <QJUoyokVZYfwOpJ7my1USn-6N9GH2l7ppWXO630yaM0=.3f7f0e7a-5b9d-4bc2-ae81-af0b6e32c6cb@github.com>

On Sat, 2 Nov 2024 15:11:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:
>> 
>>> 70:         //---
>>> 71:         @JEP(number=495, title="Simple Source Files and Instance Main Methods", status="Fourth Preview")
>>> 72:         IMPLICIT_CLASSES,
>> 
>> Hello Jan, although it's just an internal enum name, do you think we should rename it to be closer to the JEP's title or is it not worth it?
>
> The title also shows up in list of preview APIs in the javadoc so changing seems correct.

Please note the title is adjusted to match the current name of the JEP. So the built javadoc should not be an issue. What Jaikiran is speaking about is the enum constant name, which hopefully(!) does not have a meaning outside of the JDK.

We could change the constant to `SIMPLE_SOURCE_FILES_AND_INSTANCE_MAIN_METHODS` (to precisely reflect the JEP's name), but it seems like an unnecessary git churn to me. We might also need to keep the existing constant due to bootstrap issues, then remove it when JDK 25 is switched to bootstrap on JDK 24.

I can do that, if really needed, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826603335

From duke at openjdk.org  Sat Nov  2 22:42:07 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 2 Nov 2024 22:42:07 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: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@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

src/java.base/share/classes/java/lang/System.java line 1364:

> 1362:      * <br>
> 1363:      * It is the responsibility of the provider of
> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that

This is?still a?part of?the?paragraph related to?the?security?manager.

src/java.base/share/classes/java/lang/System.java line 2338:

> 2336:      * Invoked by VM.  Phase 3 is the final system initialization:
> 2337:      * 1. eagerly initialize bootstrap method factories that might interact
> 2338:      *    negatively with custom security managers and custom class loaders

They?might?still interact?negatively with?custom class?loaders?though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826864120
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826863295

From jpai at openjdk.org  Sun Nov  3 01:32:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 3 Nov 2024 01:32:39 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <QJUoyokVZYfwOpJ7my1USn-6N9GH2l7ppWXO630yaM0=.3f7f0e7a-5b9d-4bc2-ae81-af0b6e32c6cb@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
 <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
 <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>
 <QJUoyokVZYfwOpJ7my1USn-6N9GH2l7ppWXO630yaM0=.3f7f0e7a-5b9d-4bc2-ae81-af0b6e32c6cb@github.com>
Message-ID: <DHzvNMLyGUfqQdJtNhx7Cs3SQF5gUQoG8IleCOVh5Jo=.17e30b89-35ea-4f90-9b63-ebe32d95842f@github.com>

On Sat, 2 Nov 2024 17:08:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> What Jaikiran is speaking about is the enum constant name, which hopefully(!) does not have a meaning outside of the JDK.

I had looked around the rendered javadoc and a few other places and I didn't notice the enum name showing up anywhere publically. It merely appears to be an internal reference within the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826884467

From acobbs at openjdk.org  Sun Nov  3 03:09:27 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 3 Nov 2024 03:09:27 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v2]
In-Reply-To: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
Message-ID: <1WDY45GXN0Sz6zOF_sivG6AcURKYqED_Gl--h3-2IjY=.4bc92fe5-4a48-4a0d-a606-14e5eb7eeed2@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Apply change that was missed somehow.
 - Undo change that will be moved to the core-libs branch.
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21851/files
  - new: https://git.openjdk.org/jdk/pull/21851/files/84561e2f..033f7631

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

  Stats: 601 lines in 27 files changed: 420 ins; 93 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/21851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21851/head:pull/21851

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

From acobbs at openjdk.org  Sun Nov  3 03:13:25 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 3 Nov 2024 03:13:25 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v2]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <zvOlVozGs_y3wT3BPPdVPSG-pMZSon_S9jkoDYObhN4=.0b54a387-3926-460a-90a2-3a98cbc41ff1@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/9cef2ae6..7842dfea

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

  Stats: 3279 lines in 177 files changed: 2078 ins; 749 del; 452 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From alanb at openjdk.org  Sun Nov  3 07:01:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Nov 2024 07:01:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
Message-ID: <ZlkjUPtWJiKV28QHg5wypFJPAkqECKNofd8X0Tr6TqA=.8ffd4d6f-3d9b-4978-a45c-804050b038ba@github.com>

On Sat, 2 Nov 2024 22:18:09 GMT, ExE Boss <duke 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 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
>
> src/java.base/share/classes/java/lang/System.java line 2338:
> 
>> 2336:      * Invoked by VM.  Phase 3 is the final system initialization:
>> 2337:      * 1. eagerly initialize bootstrap method factories that might interact
>> 2338:      *    negatively with custom security managers and custom class loaders
> 
> They?might?still interact?negatively with?custom class?loaders?though.

The context here is custom a security manager doing string concatenation, this has required StringConcatFactory be eagerly initialized or security managers set on the command line to have been compiled with -XDstringConcat=inline. I think your question is about overriding the system class loader and whether its initialisation can use string concatenation reliably. That's a good thing to add a test for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826916876

From dfuchs at openjdk.org  Sun Nov  3 11:28:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Sun, 3 Nov 2024 11:28:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
Message-ID: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>

On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss <duke 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 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
>
> src/java.base/share/classes/java/lang/System.java line 1364:
> 
>> 1362:      * <br>
>> 1363:      * It is the responsibility of the provider of
>> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that
> 
> This is?still a?part of?the?paragraph related to?the?security?manager.

Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826959976

From alanb at openjdk.org  Sun Nov  3 12:36:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Nov 2024 12:36:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
 <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
Message-ID: <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>

On Sun, 3 Nov 2024 11:25:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 1364:
>> 
>>> 1362:      * <br>
>>> 1363:      * It is the responsibility of the provider of
>>> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that
>> 
>> This is?still a?part of?the?paragraph related to?the?security?manager.
>
> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.

Removed in jep486 branch in sandbox so will get picked up when PR is refreshed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826972198

From vromero at openjdk.org  Sun Nov  3 23:20:12 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 3 Nov 2024 23:20:12 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@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/4838a140..d88da991

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21794&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21794&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 1 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 mcimadamore at openjdk.org  Mon Nov  4 10:21:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 4 Nov 2024 10:21:31 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: <9UHOS_Gv-mW5nMFYUK9mLOX37B2HU9pSx2b94E7pMSg=.6952ac0b-9a01-4b45-b1df-389c5045c85d@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

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21687#pullrequestreview-2412670687

From hannesw at openjdk.org  Mon Nov  4 12:07:32 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 4 Nov 2024 12:07:32 GMT
Subject: Integrated: 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: <B3B1K_kj_EXPQ00_6t45rU_iscjhd28MZykq-a96Q-g=.a5fe902a-4b7b-4097-b29d-cf9b9253bbc5@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.

This pull request has now been integrated.

Changeset: 809030bf
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/809030bfb2066805118dcd4326588bc224b78d3f
Stats:     77 lines in 2 files changed: 66 ins; 9 del; 2 mod

8321500: javadoc rejects '@' in multi-line attribute value

Reviewed-by: prappo

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

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

From abimpoudis at openjdk.org  Mon Nov  4 12:29:34 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 4 Nov 2024 12:29:34 GMT
Subject: Integrated: 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: <-O5N5FgTUOcZrnoSYUGyxTtXTGz3z3VD_4Qpnzw2R_A=.d8da9393-ca71-4dc7-990a-d665684f368c@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).

This pull request has now been integrated.

Changeset: 895a7b64
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/895a7b64f01dec7248549b127875edcf006457cf
Stats:     245 lines in 6 files changed: 132 ins; 43 del; 70 mod

8342967: Lambda deduplication fails with non-metafactory BSMs and mismatched local variables names

Reviewed-by: mcimadamore

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

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

From vklang at openjdk.org  Mon Nov  4 16:10:47 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Nov 2024 16:10:47 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v2]
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: <3J4BybOBLEvHajoowPmaESUb0lfmWvB51buu68o9mSQ=.78df4cd7-edc2-4ec4-9782-7f2bbf18cd53@github.com>

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

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

  Updating copyright years and removing an unneccessary import for Gatherers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21686/files
  - new: https://git.openjdk.org/jdk/pull/21686/files/194c7695..189f2f85

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

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 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 vromero at openjdk.org  Mon Nov  4 15:38:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 4 Nov 2024 15:38:33 GMT
Subject: RFR: 8342967: Lambda deduplication fails with non-metafactory BSMs
 and mismatched local variables names [v5]
In-Reply-To: <p55sgBiBNQQNS34ADpaq_jgEQhuc5pTBfv5J6aOs8ao=.0468144f-6903-4b8b-8876-6bb74b31fd48@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>
 <p55sgBiBNQQNS34ADpaq_jgEQhuc5pTBfv5J6aOs8ao=.0468144f-6903-4b8b-8876-6bb74b31fd48@github.com>
Message-ID: <5Jvpd_CanPtQMEPJ96mDP9ggg5Yw5-9iEzjRbjAWutA=.9f8b1b8d-0ed2-42b0-bc2f-4365a22ace5b@github.com>

On Thu, 31 Oct 2024 17:49:03 GMT, Jan Lahoda <jlahoda 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, to see de-duplication, it would actually require the builds to explicitly use `-g:none`, which is probably not very common.

correct. I reran the corpus job. All lambdas (23948) are failing because of the use of debug options. Can we conclude after this that deduplication can be removed?

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

PR Comment: https://git.openjdk.org/jdk/pull/21687#issuecomment-2455033203

From nbenalla at openjdk.org  Mon Nov  4 18:23:09 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 4 Nov 2024 18:23:09 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v5]
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <4-lQd203dPu_BrGHaQurU5SI7TC0BK2h0ACqRNNbH_4=.2582d879-b8c6-40b9-88af-123d476de853@github.com>

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

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

  Rename tests and directories under modules dir

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21542/files
  - new: https://git.openjdk.org/jdk/pull/21542/files/e973302b..dda5f1b6

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

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

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

From liach at openjdk.org  Mon Nov  4 18:29:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Nov 2024 18:29:31 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v2]
In-Reply-To: <zvOlVozGs_y3wT3BPPdVPSG-pMZSon_S9jkoDYObhN4=.0b54a387-3926-460a-90a2-3a98cbc41ff1@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <zvOlVozGs_y3wT3BPPdVPSG-pMZSon_S9jkoDYObhN4=.0b54a387-3926-460a-90a2-3a98cbc41ff1@github.com>
Message-ID: <cN9PxkA-TmCSKrHxXRSaZvGeZv5s0nafAQEDZaB0Wzs=.0cb21a43-1493-4f49-8922-2b42eb918f70@github.com>

On Sun, 3 Nov 2024 03:13:25 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> 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 four additional commits since the last revision:
> 
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove unnecessary @SuppressWarnings annotations.

java.lang.invoke/reflect and jdk.internal.classfile changes look good.

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

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2413824024

From nbenalla at openjdk.org  Mon Nov  4 18:30:50 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 4 Nov 2024 18:30:50 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v6]
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <fBPuS7YR_HLfktERI27HgDiEpp1SiV42VXSCfBcP450=.10284966-be20-4c6f-a35c-ae2f3e961677@github.com>

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

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

  tiny change in test summary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21542/files
  - new: https://git.openjdk.org/jdk/pull/21542/files/dda5f1b6..07530dec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21542&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21542&range=04-05

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

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

From vromero at openjdk.org  Mon Nov  4 19:07:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 4 Nov 2024 19:07: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: <bmT-SeqaANhrWE5DoICBiFS5WICsfxzCiW8lCtWkVc0=.ac093bfb-e5a4-4bc5-b2ca-fd7d5ccb8a28@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

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21663#pullrequestreview-2413892804

From cushon at openjdk.org  Mon Nov  4 22:23:50 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 4 Nov 2024 22:23:50 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v4]
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <qM415oS2t5vN-3HIkzHd_sQBzqPdDUL3SLeUcOYkzYg=.970db2cc-ce93-4dba-ab32-9ed77b818d6a@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 seven additional commits since the last revision:

 - Update another reference to sun.misc.Unsafe
 - Merge remote-tracking branch 'origin/master' into JDK-8332744
 - Migrate another use of sun.misc.Unsafewq
 - 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/aa688777..a56bc3a5

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

  Stats: 259097 lines in 2770 files changed: 159963 ins; 73418 del; 25716 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  Tue Nov  5 01:05:31 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 5 Nov 2024 01:05:31 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
 <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>
Message-ID: <tu2S8UiFlVsX6tbU8cbrY-v98l9yJa_7Urp9A4cn0WE=.92d3c239-00e3-4dde-9849-347783ee5239@github.com>

On Mon, 21 Oct 2024 17:56:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> 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

@vicente-romero-oracle could you please take another look?

I was preparing to integrate this, and the latest merge includes one new benchmark that requires another update: https://github.com/openjdk/jdk/pull/19397/commits/a56bc3a5d461f2f27ee77e169d7bc6b9e80247cb

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

PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2456009483

From vromero at openjdk.org  Tue Nov  5 15:14:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Nov 2024 15:14:34 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v4]
In-Reply-To: <qM415oS2t5vN-3HIkzHd_sQBzqPdDUL3SLeUcOYkzYg=.970db2cc-ce93-4dba-ab32-9ed77b818d6a@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <qM415oS2t5vN-3HIkzHd_sQBzqPdDUL3SLeUcOYkzYg=.970db2cc-ce93-4dba-ab32-9ed77b818d6a@github.com>
Message-ID: <aAtkQqPQIlBWL8UpKK7fVCR9vrjd1B5b7puY6u1L8mU=.0246a81e-9a18-41e1-80be-95f6ad925147@github.com>

On Mon, 4 Nov 2024 22:23:50 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 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 another reference to sun.misc.Unsafe
>  - Merge remote-tracking branch 'origin/master' into JDK-8332744
>  - Migrate another use of sun.misc.Unsafewq
>  - 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

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19397#pullrequestreview-2415924757

From vromero at openjdk.org  Tue Nov  5 15:14:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Nov 2024 15:14:35 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <tu2S8UiFlVsX6tbU8cbrY-v98l9yJa_7Urp9A4cn0WE=.92d3c239-00e3-4dde-9849-347783ee5239@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
 <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>
 <tu2S8UiFlVsX6tbU8cbrY-v98l9yJa_7Urp9A4cn0WE=.92d3c239-00e3-4dde-9849-347783ee5239@github.com>
Message-ID: <98ego0ITZcPdFJrPOtSXGeRVdYSheBuMre9SiCYRFpg=.784d6375-752b-4c35-b17f-f41daa365a09@github.com>

On Tue, 5 Nov 2024 01:03:14 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> lgtm
>
> @vicente-romero-oracle could you please take another look?
> 
> I was preparing to integrate this, and the latest merge includes one new benchmark that requires another update: https://github.com/openjdk/jdk/pull/19397/commits/a56bc3a5d461f2f27ee77e169d7bc6b9e80247cb

@cushon done, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2457434466

From cushon at openjdk.org  Tue Nov  5 17:08:43 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 5 Nov 2024 17:08:43 GMT
Subject: Integrated: 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: <zmHdknVXpTiOKGhcEmDmbGNwePKbRt6labO2YqjDvNE=.31016eec-86c9-4615-9510-a71638175754@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 now been integrated.

Changeset: 839de82c
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/839de82c314697d7461b77caa9d85407e3578de3
Stats:     161 lines in 22 files changed: 132 ins; 0 del; 29 mod

8332744: [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version

Reviewed-by: vromero

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

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

From mullan at openjdk.org  Tue Nov  5 18:30:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 18:30:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v7]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <djVIdf6f-DCXWXIZXcS0tr5pnTYNYUi_qzbrtKGbUB0=.ce9aafa1-bf99-4f36-a520-a4b6ff670686@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 213 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove "access" and "policy" options from debug help.
 - Merge branch 'master' into jep486
 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
 - remove MainClassCantBeLoadedTest from problemlisting
 - remove LauncherErrors test from problemlisting
 - Merge branch 'master' into jep486
 - Remove left-over paragraph about SM use from LoggerFinder
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 203 more: https://git.openjdk.org/jdk/compare/f69b6016...51d2a2a3

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=06
  Stats: 68938 lines in 1889 files changed: 2490 ins; 62600 del; 3848 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 Nov  5 18:58:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 18:58:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v8]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@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 217 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove "access" and "policy" options from debug help.
 - Merge branch 'master' into jep486
 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
 - remove MainClassCantBeLoadedTest from problemlisting
 - remove LauncherErrors test from problemlisting
 - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=07
  Stats: 68934 lines in 1889 files changed: 2490 ins; 62600 del; 3844 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 Nov  5 19:24:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 19:24:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
 <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
 <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>
Message-ID: <oObdOTPzC4tiiWiwoqy9kJo6t60O7P7kqlnArXu9wbc=.925ca6c4-fa1d-4433-bff2-70b3e66bbce8@github.com>

On Sun, 3 Nov 2024 12:33:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.
>
> Removed in jep486 branch in sandbox so will get picked up when PR is refreshed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ab586f6619ca5f7e213876219abf61a36155735c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1829886748

From vromero at openjdk.org  Tue Nov  5 19:55:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Nov 2024 19:55:58 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call
Message-ID: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>

Javac is not issuing a mandated unchecked cast warning for code like:


import java.lang.invoke.VarHandle;

class VarHandleCast<V> {
     VarHandle vh;
     V method(Object obj) {
         return (V)vh.getAndSet(this, obj);
     }
}


according to the spec the return type inferred for this method polymorphic method should be Object see:

-  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
...
    ? The compile-time result is determined as follows:
        Otherwise, 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).

javac is not doing the type erasure mandated by the spec which is what this PR is fixing

TIA

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

Commit messages:
 - 8343286: Redundant cast in polymorphic method call

Changes: https://git.openjdk.org/jdk/pull/21914/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343286
  Stats: 29 lines in 7 files changed: 28 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

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

From mullan at openjdk.org  Tue Nov  5 20:10:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 20:10:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v8]
In-Reply-To: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com>
Message-ID: <nKDNw4mah9BaszGzCs83ttYt9TzQdfhGCiO_8quB0vQ=.4234a809-ebc3-4aa5-8265-08f8cebb1bf5@github.com>

On Tue, 5 Nov 2024 18:58:22 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 217 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Remove "access" and "policy" options from debug help.
>  - Merge branch 'master' into jep486
>  - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
>  - remove MainClassCantBeLoadedTest from problemlisting
>  - remove LauncherErrors test from problemlisting
>  - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9

The latest update includes:
- merging with the mainline sources
- a couple of test removals from the ProblemList for tests that no longer apply
- removal of the "policy" and "access" options from the `-Djava.security.debug` help option.
- a small update to remove some SM specific text from the `System.LoggerFinder` class description.
- copyright header updates for several tests that were previously modified
- addition of a few client manual tests to the ProblemList that have dependencies on the Security Manager and will be resolved later

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2458058335

From duke at openjdk.org  Wed Nov  6 00:42:37 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 6 Nov 2024 00:42: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: <n6KfCxrn5acB8-pa4bvc4qMhiYNrXRjW6OQ7gh8_rLY=.ce5be271-c716-4446-861b-808e1dca8839@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'm still awaiting review.

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

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

From jjg at openjdk.org  Wed Nov  6 00:51:28 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 6 Nov 2024 00:51:28 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: <d8-97UPc7LeEG8MNQ6vDRBzrTaiqJIldLzy9QnxBsU0=.9672555d-178d-4203-acb9-6a4589a404a3@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.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19519#pullrequestreview-2417049901

From duke at openjdk.org  Wed Nov  6 01:23:31 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 6 Nov 2024 01:23:31 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows [v2]
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: <9H3u8DP6f-08S-_V-J2mcJXybl0I6idLV6ICZVuCCu0=.1bc0ccd0-2859-4ae4-a9f4-7c298ef12027@github.com>

> 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.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19519/files
  - new: https://git.openjdk.org/jdk/pull/19519/files/3f2a5e2f..c6ee9e0e

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

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

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

From duke at openjdk.org  Wed Nov  6 04:05:37 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 6 Nov 2024 04:05:37 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows [v2]
In-Reply-To: <d8-97UPc7LeEG8MNQ6vDRBzrTaiqJIldLzy9QnxBsU0=.9672555d-178d-4203-acb9-6a4589a404a3@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
 <d8-97UPc7LeEG8MNQ6vDRBzrTaiqJIldLzy9QnxBsU0=.9672555d-178d-4203-acb9-6a4589a404a3@github.com>
Message-ID: <M51bPelEiwwMXuA0_pY34EXj4IaEM8valoz8z9wnFn8=.1dd7d1be-649d-4fdf-822e-2a24395b7f0a@github.com>

On Wed, 6 Nov 2024 00:48:54 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update full name
>
> Marked as reviewed by jjg (Reviewer).

Thanks @jonathan-gibbons for the review.

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

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

From duke at openjdk.org  Wed Nov  6 04:05:38 2024
From: duke at openjdk.org (duke)
Date: Wed, 6 Nov 2024 04:05:38 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows [v2]
In-Reply-To: <9H3u8DP6f-08S-_V-J2mcJXybl0I6idLV6ICZVuCCu0=.1bc0ccd0-2859-4ae4-a9f4-7c298ef12027@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
 <9H3u8DP6f-08S-_V-J2mcJXybl0I6idLV6ICZVuCCu0=.1bc0ccd0-2859-4ae4-a9f4-7c298ef12027@github.com>
Message-ID: <9NoyKrYrZfiRrQbl9V--kR0W4myw__ILbS9_2pvML8w=.edd9d2ff-710e-4188-a456-14ed149667a6@github.com>

On Wed, 6 Nov 2024 01:23:31 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.
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

@tkiriyama 
Your change (at version c6ee9e0e0389c577c773e757342133595b3eb0ee) is now ready to be sponsored by a Committer.

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

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

From jpai at openjdk.org  Wed Nov  6 05:41:50 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 6 Nov 2024 05:41:50 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows [v2]
In-Reply-To: <9H3u8DP6f-08S-_V-J2mcJXybl0I6idLV6ICZVuCCu0=.1bc0ccd0-2859-4ae4-a9f4-7c298ef12027@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.023ff4da-8e73-402d-ace1-f529d29d881e@github.com>
 <9H3u8DP6f-08S-_V-J2mcJXybl0I6idLV6ICZVuCCu0=.1bc0ccd0-2859-4ae4-a9f4-7c298ef12027@github.com>
Message-ID: <_TWugZW6KamKjp-vS0OMn-Jb0gLjDgCF2JB0FysUF2Y=.d92cb8ea-9b48-4c18-97a9-d84baecdb442@github.com>

On Wed, 6 Nov 2024 01:23:31 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.
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Jon has approved the PR and I ran this change against our CI for tier1 and that passed. I'll go ahead and sponsor this now.

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

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

From duke at openjdk.org  Wed Nov  6 05:41:51 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 6 Nov 2024 05:41:51 GMT
Subject: Integrated: 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: <8nJ3uKIPvrDdE8EHQD6E2LCWU2ht-zSoGKK2ZJBjxP8=.444b86bc-6d44-43d1-afd7-8ae3d54ce094@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.

This pull request has now been integrated.

Changeset: 1b0281dc
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b0281dc77f41fc5df323c7f7b25a4138b1ffb9e
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8333427: langtools/tools/javac/newlines/NewLineTest.java is failing on Japanese Windows

Reviewed-by: jjg

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

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

From prappo at openjdk.org  Wed Nov  6 11:36:01 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 6 Nov 2024 11:36:01 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of source
 file
Message-ID: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>

Please review this PR to exempt the [trick that JBang uses]() from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.

The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.

Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.

Skimming through tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. A test I introduced here does not do this; am I missing something?

[trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html

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

Commit messages:
 - Initial commit

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

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

From abimpoudis at openjdk.org  Wed Nov  6 14:54:40 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 6 Nov 2024 14:54:40 GMT
Subject: Integrated: 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: <ba7hoeeEqMEdgRYlyAcBwkX_qAjuCs2s_B8ok2xcxOQ=.489ef22a-2cb5-488e-af5e-bd0975276601@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`.

This pull request has now been integrated.

Changeset: 6811a11e
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6811a11e278118b8b2781f1eaf45d363a3d2db49
Stats:     138 lines in 4 files changed: 132 ins; 3 del; 3 mod

8341408: Implement JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)

Reviewed-by: vromero, jlahoda

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

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

From darcy at openjdk.org  Wed Nov  6 20:08:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Nov 2024 20:08:54 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <_cMEb_DycFx605fxkjmSja7db4SJ2RbMZiR1oIb2c1s=.59015f58-375a-47f1-9403-71d21c2856f9@github.com>

On Tue, 5 Nov 2024 19:51:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Hi @vicente-romero-oracle , please file a CSR to evaluate the behavioral changes here. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21914#issuecomment-2458209273

From vromero at openjdk.org  Wed Nov  6 20:08:54 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Nov 2024 20:08:54 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v2]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

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

 - fixing build error
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - 8343286: Redundant cast in polymorphic method call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/3ead0d87..34b5b020

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

  Stats: 6969 lines in 231 files changed: 5321 ins; 959 del; 689 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

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

From jjg at openjdk.org  Wed Nov  6 21:09:45 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 6 Nov 2024 21:09:45 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file
In-Reply-To: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
Message-ID: <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>

On Wed, 6 Nov 2024 11:31:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
> 
> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
> 
> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
> 
> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
> 
> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 672:

> 670:                 if (lint.isEnabled(Lint.LintCategory.DANGLING_DOC_COMMENTS) &&
> 671:                         (c.getStyle() != Comment.CommentStyle.JAVADOC_LINE ||
> 672:                                 c.getPos().getStartPosition() != 0)) {

For consideration, you could further refine the test by making sure it is a single line comment (perhaps optionally terminated by a newline).  In other words, maybe the warning should be given if the leading comment is a multi-line comment -- which would unlikely be a JBang-style comment.

test/langtools/tools/javac/danglingDocComments/JBangExceptionTest.java line 14:

> 12: // the classes need to provide the initial dangling comment, which would
> 13: // otherwise interfere with the JTReg test comment. For similar reasons,
> 14: // the files with test classes do __NOT__ have a copyright header.

FYI, the normal guidance for source files that cannot follow standard stylistic guidance (such as files with tabs etc) is to dynamically generate the files, which is medium easy these days using text blocks.   That being said, that advice does not work well in this case because the `jtreg` infrastructure for `@compile` tags does not work for generated files.

In this case, I would recommend working the text string `nodynamiccopyright` into the head of the two JBang files.  There are two or three possibilities.

1. Just put the word `nodynamiccopyright` at the end of the first line. Syntactically, it would be a command name, but such a command would never be executed after the `exit` statement.
2. Put a comment `#nodynamiccopyright` at the end of the first line.
3. Put a separate Java comment on the second line, using either an end-of-line comment or traditional comment. It might then be reasonably detected and taken into account by any automated scripts that ensure copyright headers are present unless that work is present.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1831708608
PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1831706267

From jjg at openjdk.org  Wed Nov  6 21:13:44 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 6 Nov 2024 21:13:44 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file
In-Reply-To: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
Message-ID: <yETkqwhaG8fwrFM52JdfXYrGKzMs864awaWU366tRhM=.e24d1f4e-9351-48f7-adea-acc5c901f596@github.com>

On Wed, 6 Nov 2024 11:31:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I was unsure why they compile itself first without any /ref= construct. 

My recollection is that this just a convenience to get the output of the compilation into the log without any `/ref` analysis, for the situations where the test in invalid and fails to compile.

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

PR Comment: https://git.openjdk.org/jdk/pull/21923#issuecomment-2460788755

From archie.cobbs at gmail.com  Wed Nov  6 21:40:54 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 6 Nov 2024 15:40:54 -0600
Subject: Regression tests compiled with -Xlint:all,-path
Message-ID: <CANSoFxsodHEZ9R4Z24=TMAz+Mgvcmo561PP62Jw5eVAEhzQk_g@mail.gmail.com>

Question for the list...

I've noticed that several compiler regression tests are compiled with
-Xlint:all,-path or Xlint:-path.

I'm wondering what the suppression of path is for. When I remove the -path
part, the tests still pass.

Does anyone know why those tests are compiled with path suppressed? Is it
some Windows thing?

Examples:

test/langtools/tools/javac/6304921/T6304921.java
test/langtools/tools/javac/T5048776.java
test/langtools/tools/javac/T6245591.java
test/langtools/tools/javac/T6247324.java
test/langtools/tools/javac/processing/TestWarnErrorCount.java
test/langtools/tools/javac/warnings/DivZero.java
test/langtools/tools/javac/warnings/FallThrough.java
test/langtools/tools/javac/warnings/Unchecked.java

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241106/131bb03d/attachment-0001.htm>

From prappo at openjdk.org  Wed Nov  6 23:00:42 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 6 Nov 2024 23:00:42 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file
In-Reply-To: <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
Message-ID: <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>

On Wed, 6 Nov 2024 21:06:46 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
>> 
>> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
>> 
>> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
>> 
>> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
>> 
>> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 672:
> 
>> 670:                 if (lint.isEnabled(Lint.LintCategory.DANGLING_DOC_COMMENTS) &&
>> 671:                         (c.getStyle() != Comment.CommentStyle.JAVADOC_LINE ||
>> 672:                                 c.getPos().getStartPosition() != 0)) {
> 
> For consideration, you could further refine the test by making sure it is a single line comment (perhaps optionally terminated by a newline).  In other words, maybe the warning should be given if the leading comment is a multi-line comment -- which would unlikely be a JBang-style comment.

I admit, I thought about it initially, but couldn't quickly come up with a simple and robust way to figure out if a comment tree spans a single line. I'm not yet comfortable working with compiler coordinate system (incl. source positions). If you propose such a way, I'd happily incorporate it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1831817245

From prappo at openjdk.org  Wed Nov  6 23:20:42 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 6 Nov 2024 23:20:42 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file
In-Reply-To: <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
Message-ID: <b2BTaGF0DqQnIChHkMzXmuJ1Hi-jpSnOgjTJFleFd2k=.f4e08ef9-6892-4a1b-9bc2-a7fbf99a6cb1@github.com>

On Wed, 6 Nov 2024 21:04:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
>> 
>> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
>> 
>> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
>> 
>> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
>> 
>> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html
>
> test/langtools/tools/javac/danglingDocComments/JBangExceptionTest.java line 14:
> 
>> 12: // the classes need to provide the initial dangling comment, which would
>> 13: // otherwise interfere with the JTReg test comment. For similar reasons,
>> 14: // the files with test classes do __NOT__ have a copyright header.
> 
> FYI, the normal guidance for source files that cannot follow standard stylistic guidance (such as files with tabs etc) is to dynamically generate the files, which is medium easy these days using text blocks.   That being said, that advice does not work well in this case because the `jtreg` infrastructure for `@compile` tags does not work for generated files.
> 
> In this case, I would recommend working the text string `nodynamiccopyright` into the head of the two JBang files.  There are two or three possibilities.
> 
> 1. Just put the word `nodynamiccopyright` at the end of the first line. Syntactically, it would be a command name, but such a command would never be executed after the `exit` statement.
> 2. Put a comment `#nodynamiccopyright` at the end of the first line.
> 3. Put a separate Java comment on the second line, using either an end-of-line comment or traditional comment. It might then be reasonably detected and taken into account by any automated scripts that ensure copyright headers are present unless that work is present.

Number 3 seems to be the cleanest. I'll try it; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1831842921

From prappo at openjdk.org  Wed Nov  6 23:41:00 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 6 Nov 2024 23:41:00 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v2]
In-Reply-To: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
Message-ID: <jThM4UwT2wdXuKxfba2qQB5WEqDvasAEoH3WAV56Oq0=.015c895a-0119-45fa-8484-ae370451c2fc@github.com>

> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
> 
> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
> 
> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
> 
> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
> 
> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html

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

  Address copyright issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21923/files
  - new: https://git.openjdk.org/jdk/pull/21923/files/2134396b..cc9a379d

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

  Stats: 26 lines in 3 files changed: 25 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21923/head:pull/21923

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

From jjg at openjdk.org  Wed Nov  6 23:59:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 6 Nov 2024 23:59:42 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v2]
In-Reply-To: <b2BTaGF0DqQnIChHkMzXmuJ1Hi-jpSnOgjTJFleFd2k=.f4e08ef9-6892-4a1b-9bc2-a7fbf99a6cb1@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
 <b2BTaGF0DqQnIChHkMzXmuJ1Hi-jpSnOgjTJFleFd2k=.f4e08ef9-6892-4a1b-9bc2-a7fbf99a6cb1@github.com>
Message-ID: <EFJaEjIiYQ3pwXju8MmISz4VTE5f0kuWBs_aZdDuxZI=.f0713d46-d91e-42b5-b6ff-bff3942d9e67@github.com>

On Wed, 6 Nov 2024 23:18:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/tools/javac/danglingDocComments/JBangExceptionTest.java line 14:
>> 
>>> 12: // the classes need to provide the initial dangling comment, which would
>>> 13: // otherwise interfere with the JTReg test comment. For similar reasons,
>>> 14: // the files with test classes do __NOT__ have a copyright header.
>> 
>> FYI, the normal guidance for source files that cannot follow standard stylistic guidance (such as files with tabs etc) is to dynamically generate the files, which is medium easy these days using text blocks.   That being said, that advice does not work well in this case because the `jtreg` infrastructure for `@compile` tags does not work for generated files.
>> 
>> In this case, I would recommend working the text string `nodynamiccopyright` into the head of the two JBang files.  There are two or three possibilities.
>> 
>> 1. Just put the word `nodynamiccopyright` at the end of the first line. Syntactically, it would be a command name, but such a command would never be executed after the `exit` statement.
>> 2. Put a comment `#nodynamiccopyright` at the end of the first line.
>> 3. Put a separate Java comment on the second line, using either an end-of-line comment or traditional comment. It might then be reasonably detected and taken into account by any automated scripts that ensure copyright headers are present unless that keyword is present.
>
> Number 3 seems to be the cleanest. I'll try it; thanks.

OK, but since we're not testing the files here with JBang, all that matters is the recognition of the overall comment, regardless of its content. But #3 is OK too.  The main thing is to have the keyword present so that any checkers scripts have explicit evidence that no comment is intended in these files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1831869967

From jjg at openjdk.org  Thu Nov  7 00:11:41 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 7 Nov 2024 00:11:41 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v2]
In-Reply-To: <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
 <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>
Message-ID: <41pFo0XzIFRGHKC99rStHtu-YwJOTdbio7eUnUtVDqw=.dd7e701c-9a08-4f62-9724-100cb9a9cb8e@github.com>

On Wed, 6 Nov 2024 22:58:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>  If you propose such a way, I'd happily incorporate it.

Does the content of the comment (`c.getText()`) contain a newline character that is not at the end of the content?  Maybe something like 
  `c.getText().matches("(?s)\\R.")` 
although there may be more effective ways to do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1831878566

From nbenalla at openjdk.org  Thu Nov  7 10:32:51 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 7 Nov 2024 10:32:51 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: <Wcav4R4vtKYAH24Sycu93EKhUetlIZlfaTz4pu5wNiA=.d00bb12d-af9b-4afd-aaca-34ab9a9752bb@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

Passes tier 1-3, thanks all for the reviews on this. Here goes

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

PR Comment: https://git.openjdk.org/jdk/pull/21663#issuecomment-2461868208

From nbenalla at openjdk.org  Thu Nov  7 10:32:52 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 7 Nov 2024 10:32:52 GMT
Subject: Integrated: 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: <vFe5wNABtd_GZyC3lrTNxLWto6tOTWzvNO_PluAwbOM=.f775c5ee-781b-4faf-a2a2-dba2babbd881@github.com>

On Wed, 23 Oct 2024 11:45:15 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

This pull request has now been integrated.

Changeset: 42446823
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4244682309e7ae1be892280dfd6a6f70ccecc760
Stats:     165 lines in 5 files changed: 165 ins; 0 del; 0 mod

8339190: Parameter arrays that are capped during annotation processing report incorrect length

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Thu Nov  7 12:03:43 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 12:03:43 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v6]
In-Reply-To: <fBPuS7YR_HLfktERI27HgDiEpp1SiV42VXSCfBcP450=.10284966-be20-4c6f-a35c-ae2f3e961677@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
 <fBPuS7YR_HLfktERI27HgDiEpp1SiV42VXSCfBcP450=.10284966-be20-4c6f-a35c-ae2f3e961677@github.com>
Message-ID: <MaOvobvcBg5KPvjonbtkI80u1-IyucOfKd585y2zu8A=.13719c83-8fde-46e3-a8cd-8b07459bff20@github.com>

On Mon, 4 Nov 2024 18:30:50 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
>> 
>> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
>> 
>> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
>> 
>> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny change in test summary

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21542#pullrequestreview-2420781852

From mcimadamore at openjdk.org  Thu Nov  7 14:01:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 14:01:42 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v2]
In-Reply-To: <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>
Message-ID: <7kV-EtrszbxJk8rD4Og8ErcLP7zy-a-ZgLim78KW77U=.06fc43c5-6d5b-4945-8422-24783d09d944@github.com>

On Wed, 6 Nov 2024 20:08:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is not issuing a mandated unchecked cast warning for code like:
>> 
>> 
>> import java.lang.invoke.VarHandle;
>> 
>> class VarHandleCast<V> {
>>      VarHandle vh;
>>      V method(Object obj) {
>>          return (V)vh.getAndSet(this, obj);
>>      }
>> }
>> 
>> 
>> according to the spec the return type inferred for this method polymorphic method should be Object see:
>> 
>> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
>> ...
>>     ? The compile-time result is determined as follows:
>>         Otherwise, 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).
>> 
>> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
>> 
>> TIA
>> 
>> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug
>
> 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 four additional commits since the last revision:
> 
>  - fixing build error
>  - Merge branch 'master' into JDK-8343286
>  - fixing build error
>  - 8343286: Redundant cast in polymorphic method call

Changes look good. The extra suppress warnings seem to indicate that the logic is now working as intended :-)

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21914#pullrequestreview-2421062251

From mcimadamore at openjdk.org  Thu Nov  7 14:06:50 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 14:06:50 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
Message-ID: <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>

On Sun, 3 Nov 2024 23:20:12 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:
> 
>   addressing review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1697:

> 1695:                         } else if (csym.isSealed()) {
> 1696:                             return areDisjoint(isym, csym.getPermittedSubclasses());
> 1697:                         } else if (isym.isSealed()) {

where did the freely extensible check go? That part is in the spec, but there's no code for it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1832737043

From vromero at openjdk.org  Thu Nov  7 14:24:45 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 14:24:45 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
 <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
Message-ID: <6WE1VqNrzGxuU1V-TK95HJWZ03TaCu4IhVK7ZmiPTO4=.4ffa043d-c0ea-43ec-8779-9dfb3e727924@github.com>

On Thu, 7 Nov 2024 14:04:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1697:
> 
>> 1695:                         } else if (csym.isSealed()) {
>> 1696:                             return areDisjoint(isym, csym.getPermittedSubclasses());
>> 1697:                         } else if (isym.isSealed()) {
> 
> where did the freely extensible check go? That part is in the spec, but there's no code for it?

Jan suggested in a previous comment that: `isClassFreelyExtensible == !csym.isSealed() && !csym.isFinal()`, which I think is correct. At this point we have checked that the class is not final and not sealed so if the interface is sealed we do the check for disjoint-ness between the class and the interface's permitted subclasses

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1832765628

From vromero at openjdk.org  Thu Nov  7 14:26:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 14:26:42 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v2]
In-Reply-To: <7kV-EtrszbxJk8rD4Og8ErcLP7zy-a-ZgLim78KW77U=.06fc43c5-6d5b-4945-8422-24783d09d944@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>
 <7kV-EtrszbxJk8rD4Og8ErcLP7zy-a-ZgLim78KW77U=.06fc43c5-6d5b-4945-8422-24783d09d944@github.com>
Message-ID: <u9v3SPpQETXZTeZQSfrH0IZ_2hUK0ODYaxILLL1uzBQ=.6ba1cf16-e3eb-40a8-9bba-107affb45429@github.com>

On Thu, 7 Nov 2024 13:59:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Changes look good. The extra suppress warnings seem to indicate that the logic is now working as intended :-)

thanks for the review. As suggested above I created a CSR, could you please review it too? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21914#issuecomment-2462367928

From jlahoda at openjdk.org  Thu Nov  7 14:44:52 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Nov 2024 14:44:52 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <6WE1VqNrzGxuU1V-TK95HJWZ03TaCu4IhVK7ZmiPTO4=.4ffa043d-c0ea-43ec-8779-9dfb3e727924@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
 <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
 <6WE1VqNrzGxuU1V-TK95HJWZ03TaCu4IhVK7ZmiPTO4=.4ffa043d-c0ea-43ec-8779-9dfb3e727924@github.com>
Message-ID: <PGY_5wtUhW4ygI5vh509OTl61bpBYhLLaMGN80nqG0Q=.01356148-df9b-4b7b-8249-1615812f1ab4@github.com>

On Thu, 7 Nov 2024 14:22:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1697:
>> 
>>> 1695:                         } else if (csym.isSealed()) {
>>> 1696:                             return areDisjoint(isym, csym.getPermittedSubclasses());
>>> 1697:                         } else if (isym.isSealed()) {
>> 
>> where did the freely extensible check go? That part is in the spec, but there's no code for it?
>
> Jan suggested in a previous comment that: `isClassFreelyExtensible == !csym.isSealed() && !csym.isFinal()`, which I think is correct. At this point we have checked that the class is not final and not sealed so if the interface is sealed we do the check for disjoint-ness between the class and the interface's permitted subclasses

Yes, I suggested that. The idea being that even if a class has a sealed supertype, then it must be one of `final`, `sealed` and `non-sealed` itself (or a compile-time error is produced). So, basically all classes that are not freely extensible are either `final` or `sealed`, and other (legal) classes are freely extensible, unless I am missing something.

And unless I am mistaken, the `non-sealed` flag is not written to the classfiles, and is not reconstituted when reading from classfiles, so using `Symbol.isNonSealed()` is not easy, and we could only reconstitute the flag based on the fact that some of the supertypes are sealed, but the class itself is neither `final` nor `sealed.

It would be possible to implement the freely extensible check exactly as written, if desired, but it seems unnecessarily complex to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1832799701

From vromero at openjdk.org  Thu Nov  7 15:31:10 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 15:31:10 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v3]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <ILALv3qFqzV2al0VAAiylmg9c99cPehLQOxdEXCyAOE=.0130eeff-5828-46c3-8e41-78d1a360f1ff@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

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

 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - 8343286: Redundant cast in polymorphic method call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/34b5b020..5bfcf8ef

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

  Stats: 996 lines in 62 files changed: 572 ins; 306 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

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

From vromero at openjdk.org  Thu Nov  7 15:38:43 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 15:38:43 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
 <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
Message-ID: <E52Akq3lKg233c8-kRzp073ujJ-eVZ7qfGjbgGKjacw=.0896d59b-e8de-45cd-8a73-690e53b7e7b2@github.com>

On Thu, 7 Nov 2024 14:04:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1697:
> 
>> 1695:                         } else if (csym.isSealed()) {
>> 1696:                             return areDisjoint(isym, csym.getPermittedSubclasses());
>> 1697:                         } else if (isym.isSealed()) {
> 
> where did the freely extensible check go? That part is in the spec, but there's no code for it?

@mcimadamore I can add a comment in this section of the code that refers to why we think that the current checks cover the reference in the spec to freely extensible class

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1832893204

From jlahoda at openjdk.org  Thu Nov  7 15:44:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Nov 2024 15:44:57 GMT
Subject: RFR: 8343540: Report preview error for inherited effectively-preview
 methods
Message-ID: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>

Consider a case where a new preview interface is introduced to JDK, and an existing non-preview class is retrofitted to use it. I.e. a case like:


//JDK types:
@PreviewFeature(...)
public interface NewAPI {
    public default void test() {}
}
public class ExistingRetrofittedClass implements NewAPI {}

//user type:
class Test {
    void t(ExistingRetrofittedClass c) {
        c.test();
    }
}


There is currently no error or warning about the invocation of the test method, as the method itself is not marked as preview, and the receiver is not preview either.

The proposal herein is that invoking a method on a receiver that is not of preview type itself, but the method is declared in a preview class or interface, the method will be considered to be a preview method, and the appropriate error or warning will be printed. Similar behavior is implementing for dereferencing fields.


Similarly when implementing or overriding such "effectively" preview methods, like:

//user types:
class Test1 extends ExistingRetrofittedClass {
    public void test() {}
}

java also does not produce any error or warning. If the method itself would be marked as preview, an error or warning would be printed.

The proposal herein is to produce an error or warning for method declared inside a non-preview class or interface, which is overridden by a method declared inside a preview class or interface.

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

Commit messages:
 - Adding one more testcase.
 - Cleanup.
 - Produce errors/warnings for also methods overriding methods from preview types.
 - Report preview error/warning when invoking methods whose owner is a preview class/interface on a site that is non-preview. Dtto for dereferencing fields.

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

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

From alex.buckley at oracle.com  Thu Nov  7 16:29:16 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 7 Nov 2024 08:29:16 -0800
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods
In-Reply-To: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
Message-ID: <6e8d80c6-b758-450c-9789-71fe572c567b@oracle.com>

On 11/7/2024 7:44 AM, Jan Lahoda wrote:
> The proposal herein is that invoking a method on a receiver that is
> not of preview type itself, but the method is declared in a preview
> class or interface, the method will be considered to be a preview
> method, and the appropriate error or warning will be printed.
> Similar behavior is implementing for dereferencing fields.

> The proposal herein is to produce an error or warning for method
> declared inside a non-preview class or interface, which is
> overridden by a method declared inside a preview class or interface.
Thank you Jan, these are important improvements to javac's handling of 
preview APIs.

For the second proposal above, I think you mean "... which ~is 
overridden by~ +overrides+ a method declared inside a preview class or 
interface."

javac will give a warning/error where the non-preview class Test1 
declares the test method, because Test1 overrides the test method 
declared in the preview interface NewAPI.


I would add that the JDK class ExistingRetrofittedClass, which 
implements NewAPI, can override the test method without a warning/error. 
This is because ExistingRetrofittedClass is "participating" in the 
preview API.


Suppose ExistingRetrofittedClass does indeed override the test method. I 
would expect both of the examples in your original mail to give a 
warning/error. Both the invocation of `c.test()`, and the overriding of 
test in Test1, refer to an "effectively" preview method.

Alex

From jjg3 at pobox.com  Thu Nov  7 16:30:08 2024
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Thu, 7 Nov 2024 08:30:08 -0800
Subject: Regression tests compiled with -Xlint:all,-path
In-Reply-To: <CANSoFxsodHEZ9R4Z24=TMAz+Mgvcmo561PP62Jw5eVAEhzQk_g@mail.gmail.com>
References: <CANSoFxsodHEZ9R4Z24=TMAz+Mgvcmo561PP62Jw5eVAEhzQk_g@mail.gmail.com>
Message-ID: <a2d2524f-3a06-4575-aa66-85c68e5dcc70@pobox.com>

Archie,

I looked at a selection of those tests. I note that in general, these 
tests are all very old, and (mostly) predate OpenJDK. I don't think 
there was ever any explicit reason (as in, test failure) to suppress 
path warnings; my recollection is that it was more about defensively 
ignoring any unrelated warnings.

 From the current source in LintCategory, I note:

/** * Warn about invalid path elements on the command line. * Such 
warnings cannot be suppressed with the SuppressWarnings * annotation. */ 
PATH("path"),

which means that the tests are more susceptible to invalid path entries 
on the classpath, sourcepath etc.
That may have been a bigger deal back in the day, before we had better 
control of the test execution
environment.

My guess is that looking at the overall set of tests that use `-Xlint` 
or `-Xlint:all`, we are not
consistent about using `-path`, suggesting that there are no failures 
when it is not used, and thus
no longer any reason to specify it on the tests that you list.

-- Jon

On 11/6/24 1:40 PM, Archie Cobbs wrote:
> Question for the list...
>
> I've noticed that several compiler regression tests are compiled with 
> -Xlint:all,-path or Xlint:-path.
>
> I'm wondering what the suppression of path is for. When I remove the 
> -path part, the tests still pass.
>
> Does anyone know why those tests are compiled with path suppressed? Is 
> it some Windows thing?
>
> Examples:
>
> test/langtools/tools/javac/6304921/T6304921.java
> test/langtools/tools/javac/T5048776.java
> test/langtools/tools/javac/T6245591.java
> test/langtools/tools/javac/T6247324.java
> test/langtools/tools/javac/processing/TestWarnErrorCount.java
> test/langtools/tools/javac/warnings/DivZero.java
> test/langtools/tools/javac/warnings/FallThrough.java
> test/langtools/tools/javac/warnings/Unchecked.java
>
> Thanks,
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241107/dfde347c/attachment.htm>

From archie.cobbs at gmail.com  Thu Nov  7 16:38:32 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 7 Nov 2024 10:38:32 -0600
Subject: Regression tests compiled with -Xlint:all,-path
In-Reply-To: <a2d2524f-3a06-4575-aa66-85c68e5dcc70@pobox.com>
References: <CANSoFxsodHEZ9R4Z24=TMAz+Mgvcmo561PP62Jw5eVAEhzQk_g@mail.gmail.com>
 <a2d2524f-3a06-4575-aa66-85c68e5dcc70@pobox.com>
Message-ID: <CANSoFxtuUjVTz0ubnKS1x9=xyO4KS-qNE8-Oxq7h2abEa+wRLw@mail.gmail.com>

Hi Jon,

Thanks for that confirmation. I was guessing these were probably just
"leftovers" but am glad to hear your more informed second opinion.

In case you're wondering where this question comes from (pretty random I
realize), it relates to some lint-related cleanup I'm working on where
those tests got flagged.

Thanks,
-Archie

On Thu, Nov 7, 2024 at 10:30?AM Jonathan Gibbons <jjg3 at pobox.com> wrote:

> Archie,
>
> I looked at a selection of those tests. I note that in general, these
> tests are all very old, and (mostly) predate OpenJDK. I don't think there
> was ever any explicit reason (as in, test failure) to suppress path
> warnings; my recollection is that it was more about defensively ignoring
> any unrelated warnings.
>
> From the current source in LintCategory, I note:
>
> /** * Warn about invalid path elements on the command line. * Such warnings cannot be suppressed with the SuppressWarnings * annotation. */PATH("path"),
>
> which means that the tests are more susceptible to invalid path entries on
> the classpath, sourcepath etc.
> That may have been a bigger deal back in the day, before we had better
> control of the test execution
> environment.
>
> My guess is that looking at the overall set of tests that use `-Xlint` or
> `-Xlint:all`, we are not
> consistent about using `-path`, suggesting that there are no failures when
> it is not used, and thus
> no longer any reason to specify it on the tests that you list.
>
> -- Jon
>
>
> On 11/6/24 1:40 PM, Archie Cobbs wrote:
>
> Question for the list...
>
> I've noticed that several compiler regression tests are compiled with
> -Xlint:all,-path or Xlint:-path.
>
> I'm wondering what the suppression of path is for. When I remove the -path
> part, the tests still pass.
>
> Does anyone know why those tests are compiled with path suppressed? Is it
> some Windows thing?
>
> Examples:
>
> test/langtools/tools/javac/6304921/T6304921.java
> test/langtools/tools/javac/T5048776.java
> test/langtools/tools/javac/T6245591.java
> test/langtools/tools/javac/T6247324.java
> test/langtools/tools/javac/processing/TestWarnErrorCount.java
> test/langtools/tools/javac/warnings/DivZero.java
> test/langtools/tools/javac/warnings/FallThrough.java
> test/langtools/tools/javac/warnings/Unchecked.java
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241107/f78ee03f/attachment-0001.htm>

From jlahoda at openjdk.org  Thu Nov  7 17:22:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Nov 2024 17:22:44 GMT
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods
In-Reply-To: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
Message-ID: <6f07Q03ohOJtGw_-3M6Nfty7ddtIvQ4uYjHvouRVYzM=.d85353fe-a367-4ea7-b0f6-393a12a75882@github.com>

On Thu, 7 Nov 2024 13:10:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a case where a new preview interface is introduced to JDK, and an existing non-preview class is retrofitted to use it. I.e. a case like:
> 
> 
> //JDK types:
> @PreviewFeature(...)
> public interface NewAPI {
>     public default void test() {}
> }
> public class ExistingRetrofittedClass implements NewAPI {}
> 
> //user type:
> class Test {
>     void t(ExistingRetrofittedClass c) {
>         c.test();
>     }
> }
> 
> 
> There is currently no error or warning about the invocation of the test method, as the method itself is not marked as preview, and the receiver is not preview either.
> 
> The proposal herein is that invoking a method on a receiver that is not of preview type itself, but the method is declared in a preview class or interface, the method will be considered to be a preview method, and the appropriate error or warning will be printed. Similar behavior is implementing for dereferencing fields.
> 
> 
> Similarly when implementing or overriding such "effectively" preview methods, like:
> 
> 
> //user types:
> class Test1 extends ExistingRetrofittedClass {
>     public void test() {}
> }
> 
> 
> java also does not produce any error or warning. If the method itself would be marked as preview, an error or warning would be printed.
> 
> The proposal herein is to produce an error or warning for method declared inside a non-preview class or interface, which is overridden by a method declared inside a preview class or interface.

> _Mailing list message from [Alex Buckley](mailto:alex.buckley at oracle.com) on [compiler-dev](mailto:compiler-dev at mail.openjdk.org):_
> Suppose ExistingRetrofittedClass does indeed override the test method. I would expect both of the examples in your original mail to give a warning/error. Both the invocation of `c.test()`, and the overriding of test in Test1, refer to an "effectively" preview method.

If `ExistingRetrofittedClass` would override the effectively preview method "`test`", without marking the method as preview, I am not sure it is desirable for the uses of the overriding method in `ExistingRetrofittedClass` to report errors/warnings.

There are two reasons for that:
- what if the `test` method existed before, and now is it is just being included in the superinterface? The method existed, and should still be generally usable, but if it would automatically get the preview handling, there would be no way to "un-subscribe" from the preview handling. But if the overriding method is by default an ordinary, non-preview, method, and the library developer desires the override to also be handled as a preview method, the solution is simple: use `@PreviewFeature` of the overriding method.
- for each method invocation, javac would need to go through all methods that the invoked method overrides, to see if some of them are (effectively) preview methods. This would be fairly costly, but only very few (if any) methods are overriding a preview method. So, overall, it seems it would be a considerable cost in the compilation time, for a very small gain. (Where the gain is only avoiding the addition of `@PreviewFeature` on a very limited number of methods.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21953#issuecomment-2462815311

From mcimadamore at openjdk.org  Thu Nov  7 17:41:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 17:41:44 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <E52Akq3lKg233c8-kRzp073ujJ-eVZ7qfGjbgGKjacw=.0896d59b-e8de-45cd-8a73-690e53b7e7b2@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
 <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
 <E52Akq3lKg233c8-kRzp073ujJ-eVZ7qfGjbgGKjacw=.0896d59b-e8de-45cd-8a73-690e53b7e7b2@github.com>
Message-ID: <1W7ti1vta1uLRS3ujAeAQGnxfiaJrCYX4KGp_TbyEsA=.0623f39b-3d9c-4232-a683-36194b7400f7@github.com>

On Thu, 7 Nov 2024 15:35:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1697:
>> 
>>> 1695:                         } else if (csym.isSealed()) {
>>> 1696:                             return areDisjoint(isym, csym.getPermittedSubclasses());
>>> 1697:                         } else if (isym.isSealed()) {
>> 
>> where did the freely extensible check go? That part is in the spec, but there's no code for it?
>
> @mcimadamore I can add a comment in this section of the code that refers to why we think that the current checks cover the reference in the spec to freely extensible class

But, according to the spec, if I have:


sealed class Sup { }
non-sealed class Sub extends Sup { }


Then `Sub` is not freely extensible. Becaus, even though it is neither `sealed` nor `final`, its direct superclass is `sealed`. I agree that, in spirit, `Sub` can be extended, but that's not what the JLS seems to say?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1833113029

From alex.buckley at oracle.com  Thu Nov  7 17:53:30 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 7 Nov 2024 09:53:30 -0800
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods
In-Reply-To: <6f07Q03ohOJtGw_-3M6Nfty7ddtIvQ4uYjHvouRVYzM=.d85353fe-a367-4ea7-b0f6-393a12a75882@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
 <6f07Q03ohOJtGw_-3M6Nfty7ddtIvQ4uYjHvouRVYzM=.d85353fe-a367-4ea7-b0f6-393a12a75882@github.com>
Message-ID: <992af5ab-2788-4610-899d-d169ba313d30@oracle.com>

On 11/7/2024 9:22 AM, Jan Lahoda wrote:
> If `ExistingRetrofittedClass` would override the effectively preview
> method "`test`", without marking the method as preview, I am not
> sure it is desirable for the uses of the overriding method in
> `ExistingRetrofittedClass` to report errors/warnings.
> 
> There are two reasons for that:
> - what if the `test` method existed before, and now is it is just
> being included in the superinterface? The method existed, and should
> still be generally usable, but if it would automatically get the
> preview handling, there would be no way to "un-subscribe" from the
> preview handling. But if the overriding method is by default an
> ordinary, non-preview, method, and the library developer desires the
> override to also be handled as a preview method, the solution is
> simple: use `@PreviewFeature` of the overriding method.
>
> - for each method invocation, javac would need to go through all
> methods that the invoked method overrides, to see if some of them
> are (effectively) preview methods. This would be fairly costly, but
> only very few (if any) methods are overriding a preview method. So,
> overall, it seems it would be a considerable cost in the compilation
> time, for a very small gain. (Where the gain is only avoiding the
> addition of `@PreviewFeature` on a very limited number of methods.)

You're right. If a participating class (ExistingRetrofittedClass) 
overrides an "effectively" preview method, and the participating class 
doesn't mark its *overriding* method with @PreviewFeature, then the 
"effectively" preview status of the *overridden* method should be 
invisible to clients of the participating class.

Now the maintainer of the participating class is in charge. If they have 
been declaring a method for years, they won't mark it. If they just 
started declaring a method in order to override something in a preview 
supertype, they ought to mark it -- even if their new declaration is 
simply `throw new UnsupportedOperationException("Not supported by this 
class")`.

I retract my earlier comment:

 >> Suppose ExistingRetrofittedClass does indeed override the test
 >> method. I would expect both of the examples in your original mail
 >> to give a warning/error. Both the invocation of `c.test()`, and
 >> the overriding of test in Test1, refer to an "effectively" preview
 >> method.

Alex

From jlahoda at openjdk.org  Thu Nov  7 17:53:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Nov 2024 17:53:44 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <1W7ti1vta1uLRS3ujAeAQGnxfiaJrCYX4KGp_TbyEsA=.0623f39b-3d9c-4232-a683-36194b7400f7@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
 <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
 <E52Akq3lKg233c8-kRzp073ujJ-eVZ7qfGjbgGKjacw=.0896d59b-e8de-45cd-8a73-690e53b7e7b2@github.com>
 <1W7ti1vta1uLRS3ujAeAQGnxfiaJrCYX4KGp_TbyEsA=.0623f39b-3d9c-4232-a683-36194b7400f7@github.com>
Message-ID: <qNKuBTdkrqdLJLEOrTcOpOYFxwumFsDUWrdIADNEPGE=.e5f0fcfe-f951-446d-a643-b99d1e84090a@github.com>

On Thu, 7 Nov 2024 17:39:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> @mcimadamore I can add a comment in this section of the code that refers to why we think that the current checks cover the reference in the spec to freely extensible class
>
> But, according to the spec, if I have:
> 
> 
> sealed class Sup { }
> non-sealed class Sub extends Sup { }
> 
> 
> Then `Sub` is not freely extensible. Becaus, even though it is neither `sealed` nor `final`, its direct superclass is `sealed`. I agree that, in spirit, `Sub` can be extended, but that's not what the JLS seems to say?

I believe the spec says it is freely extensible: a class which has a sealed direct super class or super interface is freely extensible iff the is non-sealed. Maybe I am missing something?
https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.1.1.2

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1833127794

From mcimadamore at openjdk.org  Thu Nov  7 18:02:48 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 18:02:48 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <qNKuBTdkrqdLJLEOrTcOpOYFxwumFsDUWrdIADNEPGE=.e5f0fcfe-f951-446d-a643-b99d1e84090a@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
 <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
 <E52Akq3lKg233c8-kRzp073ujJ-eVZ7qfGjbgGKjacw=.0896d59b-e8de-45cd-8a73-690e53b7e7b2@github.com>
 <1W7ti1vta1uLRS3ujAeAQGnxfiaJrCYX4KGp_TbyEsA=.0623f39b-3d9c-4232-a683-36194b7400f7@github.com>
 <qNKuBTdkrqdLJLEOrTcOpOYFxwumFsDUWrdIADNEPGE=.e5f0fcfe-f951-446d-a643-b99d1e84090a@github.com>
Message-ID: <QrHv44bhSclJAgXqBlvz_M4VLxA9Kln5_oH2zbVLsUM=.1c794129-b5ea-4542-bdfd-768ee5676ab3@github.com>

On Thu, 7 Nov 2024 17:51:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> But, according to the spec, if I have:
>> 
>> 
>> sealed class Sup { }
>> non-sealed class Sub extends Sup { }
>> 
>> 
>> Then `Sub` is not freely extensible. Becaus, even though it is neither `sealed` nor `final`, its direct superclass is `sealed`. I agree that, in spirit, `Sub` can be extended, but that's not what the JLS seems to say?
>
> I believe the spec says it is freely extensible: a class which has a sealed direct super class or super interface is freely extensible iff the is non-sealed. Maybe I am missing something?
> https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.1.1.2

Ah, missed this:

 A class that has a sealed direct superclass or a sealed direct superinterface is freely extensible if and only if it is declared non-sealed. 
 ```
 
 Both statements, coupled together seem a very roundabout way to do roughly what the new code is doing. I will investigate as to why this form was preferred, to make sure we're not missing anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1833137678

From mcimadamore at openjdk.org  Thu Nov  7 18:15:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 18:15:45 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v6]
In-Reply-To: <QrHv44bhSclJAgXqBlvz_M4VLxA9Kln5_oH2zbVLsUM=.1c794129-b5ea-4542-bdfd-768ee5676ab3@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <eprJXqIkFx_vA0-XWJBwMhvPiPBT9C9t3LIHmeHyFos=.354f9631-5402-4ce5-a024-b767265b1b7c@github.com>
 <QZvYo29v949WpcYGSXCqLoTPWmRt3GYX19tDmDQTCsk=.a5ec5ee6-01d0-4454-b2ee-cdea4ab09844@github.com>
 <E52Akq3lKg233c8-kRzp073ujJ-eVZ7qfGjbgGKjacw=.0896d59b-e8de-45cd-8a73-690e53b7e7b2@github.com>
 <1W7ti1vta1uLRS3ujAeAQGnxfiaJrCYX4KGp_TbyEsA=.0623f39b-3d9c-4232-a683-36194b7400f7@github.com>
 <qNKuBTdkrqdLJLEOrTcOpOYFxwumFsDUWrdIADNEPGE=.e5f0fcfe-f951-446d-a643-b99d1e84090a@github.com>
 <QrHv44bhSclJAgXqBlvz_M4VLxA9Kln5_oH2zbVLsUM=.1c794129-b5ea-4542-bdfd-768ee5676ab3@github.com>
Message-ID: <VnozzQ-ofEnoW1uEGs9zjoYWOyGuZU1kyppuCz81rEg=.3c5e6230-dc41-4f15-aa36-f3a0a2698809@github.com>

On Thu, 7 Nov 2024 17:59:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I believe the spec says it is freely extensible: a class which has a sealed direct super class or super interface is freely extensible iff the is non-sealed. Maybe I am missing something?
>> https://docs.oracle.com/javase/specs/jls/se22/html/jls-8.html#jls-8.1.1.2
>
> Ah, missed this:
> 
>  A class that has a sealed direct superclass or a sealed direct superinterface is freely extensible if and only if it is declared non-sealed. 
>  ```
>  
>  Both statements, coupled together seem a very roundabout way to do roughly what the new code is doing. I will investigate as to why this form was preferred, to make sure we're not missing anything.

Ok, this seems to be mostly a spec thing. We do have declarations (like records) that are not freely extensible, but do not need `final` or `sealed`. I suppose this is not a problem for javac because javac adds `final` to records and enums.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21794#discussion_r1833152748

From prappo at openjdk.org  Thu Nov  7 18:27:45 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 7 Nov 2024 18:27:45 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v2]
In-Reply-To: <41pFo0XzIFRGHKC99rStHtu-YwJOTdbio7eUnUtVDqw=.dd7e701c-9a08-4f62-9724-100cb9a9cb8e@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
 <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>
 <41pFo0XzIFRGHKC99rStHtu-YwJOTdbio7eUnUtVDqw=.dd7e701c-9a08-4f62-9724-100cb9a9cb8e@github.com>
Message-ID: <NVfF3kMmc-260YsOXmPZ313dmFxrBf5GeFfmhiqXpJM=.d7606a1b-9f78-4346-96f2-17072d71d5c4@github.com>

On Thu, 7 Nov 2024 00:09:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> I admit, I thought about it initially, but couldn't quickly come up with a simple and robust way to figure out if a comment tree spans a single line. I'm not yet comfortable working with compiler coordinate system (incl. source positions). If you propose such a way, I'd happily incorporate it.
>
>>  If you propose such a way, I'd happily incorporate it.
> 
> Does the content of the comment (`c.getText()`) contain a newline character that is not at the end of the content?  Maybe something like 
>   `c.getText().matches("(?s)\\R.")` 
> although there may be more effective ways to do that.

Regex sounds simple and robust. However, I thought we could concoct a more idiomatic compiler solution, using trees, start and end diagnostic positions, and also line numbers.

So, if a comment tree start and end position are on the same line that is also the first line of the file, we don't output the warning. Can we do that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1833166696

From jjg at openjdk.org  Thu Nov  7 19:47:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 7 Nov 2024 19:47:42 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v2]
In-Reply-To: <NVfF3kMmc-260YsOXmPZ313dmFxrBf5GeFfmhiqXpJM=.d7606a1b-9f78-4346-96f2-17072d71d5c4@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
 <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>
 <41pFo0XzIFRGHKC99rStHtu-YwJOTdbio7eUnUtVDqw=.dd7e701c-9a08-4f62-9724-100cb9a9cb8e@github.com>
 <NVfF3kMmc-260YsOXmPZ313dmFxrBf5GeFfmhiqXpJM=.d7606a1b-9f78-4346-96f2-17072d71d5c4@github.com>
Message-ID: <6x0GlGdmQRgGBEVuiysNloWPKlHgwdp16tm6dCJwthQ=.a0c82921-0abc-4c7d-a455-8be533b76f9f@github.com>

On Thu, 7 Nov 2024 18:24:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>>  If you propose such a way, I'd happily incorporate it.
>> 
>> Does the content of the comment (`c.getText()`) contain a newline character that is not at the end of the content?  Maybe something like 
>>   `c.getText().matches("(?s)\\R.")` 
>> although there may be more effective ways to do that.
>
> Regex sounds simple and robust. However, I thought we could concoct a more idiomatic compiler solution, using trees, start and end diagnostic positions, and also line numbers.
> 
> So, if a comment tree start and end position are on the same line that is also the first line of the file, we don't output the warning. Can we do that?

Computing line numbers is a relatively expensive operation, because the internal coordinates are character-offset based. That being said, there is a bunch of caching going on under the covers, and, the check can be guarded by the additional (proposed) check that the check is only suppressed if the comment begins at offset 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1833257972

From jjg at openjdk.org  Thu Nov  7 20:17:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 7 Nov 2024 20:17:43 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v2]
In-Reply-To: <QXG6aM3ls_xREmKKU-dosoXavcWff0E2pnWnlXF2mj0=.411b0774-0182-4b24-829b-6c42dbb9a9bc@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
 <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>
 <41pFo0XzIFRGHKC99rStHtu-YwJOTdbio7eUnUtVDqw=.dd7e701c-9a08-4f62-9724-100cb9a9cb8e@github.com>
 <NVfF3kMmc-260YsOXmPZ313dmFxrBf5GeFfmhiqXpJM=.d7606a1b-9f78-4346-96f2-17072d71d5c4@github.com>
 <6x0GlGdmQRgGBEVuiysNloWPKlHgwdp16tm6dCJwthQ=.a0c82921-0abc-4c7d-a455-8be533b76f9f@github.com>
 <QXG6aM3ls_xREmKKU-dosoXavcWff0E2pnWnlXF2mj0=.411b0774-0182-4b24-829b-6c42dbb9a9bc@github.com>
Message-ID: <_ED6TVQPT8XBBFR88n6EFmVOgImImD_E2WOb2eMCK2M=.b40973b7-4989-410d-b0ad-fb6059bf016e@github.com>

On Thu, 7 Nov 2024 20:13:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Computing line numbers is a relatively expensive operation, because the internal coordinates are character-offset based. That being said, there is a bunch of caching going on under the covers, and, the check can be guarded by the additional (proposed) check that the check is only suppressed if the comment begins at offset 0.
>
> Generally, the method you want is `DiagnosticSource.getLineNumber(int pos)`, which means you need a `DiagnosticSource` object.   `JavacParser` (that is, this class) has a `Log log` member, and `[Abstract]Log` provides `currentSource()`, so to get the line number for a position it should be possible to use something like `log.currentSource().getLineNumber(pos)`, assuming that the current source is set up correctly at the time you need it.

> So, if a comment tree start and end position are on the same line that is also the first line of the file

The end position will always be after the start position, so you only need check if the line number of the end position of the comment is line 1. (Line numbers are 1-based.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1833313690

From jjg at openjdk.org  Thu Nov  7 20:17:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 7 Nov 2024 20:17:43 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v2]
In-Reply-To: <6x0GlGdmQRgGBEVuiysNloWPKlHgwdp16tm6dCJwthQ=.a0c82921-0abc-4c7d-a455-8be533b76f9f@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
 <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>
 <41pFo0XzIFRGHKC99rStHtu-YwJOTdbio7eUnUtVDqw=.dd7e701c-9a08-4f62-9724-100cb9a9cb8e@github.com>
 <NVfF3kMmc-260YsOXmPZ313dmFxrBf5GeFfmhiqXpJM=.d7606a1b-9f78-4346-96f2-17072d71d5c4@github.com>
 <6x0GlGdmQRgGBEVuiysNloWPKlHgwdp16tm6dCJwthQ=.a0c82921-0abc-4c7d-a455-8be533b76f9f@github.com>
Message-ID: <QXG6aM3ls_xREmKKU-dosoXavcWff0E2pnWnlXF2mj0=.411b0774-0182-4b24-829b-6c42dbb9a9bc@github.com>

On Thu, 7 Nov 2024 19:45:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Regex sounds simple and robust. However, I thought we could concoct a more idiomatic compiler solution, using trees, start and end diagnostic positions, and also line numbers.
>> 
>> So, if a comment tree start and end position are on the same line that is also the first line of the file, we don't output the warning. Can we do that?
>
> Computing line numbers is a relatively expensive operation, because the internal coordinates are character-offset based. That being said, there is a bunch of caching going on under the covers, and, the check can be guarded by the additional (proposed) check that the check is only suppressed if the comment begins at offset 0.

Generally, the method you want is `DiagnosticSource.getLineNumber(int pos)`, which means you need a `DiagnosticSource` object.   `JavacParser` (that is, this class) has a `Log log` member, and `[Abstract]Log` provides `currentSource()`, so to get the line number for a position it should be possible to use something like `log.currentSource().getLineNumber(pos)`, assuming that the current source is set up correctly at the time you need it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1833311736

From vromero at openjdk.org  Fri Nov  8 01:29:23 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Nov 2024 01:29:23 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v7]
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <Ye3DK_LdUiw24HugmUnaj79zOIL3_S17Rb0m7IQ7o28=.09980c24-9e05-4541-92e0-bbda2e85f609@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:

  adding comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21794/files
  - new: https://git.openjdk.org/jdk/pull/21794/files/d88da991..719a9f7e

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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  Fri Nov  8 09:56:45 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 8 Nov 2024 09:56:45 GMT
Subject: Integrated: 8341399: Add since checker tests to the langtools modules
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <5iZbg1dFV5meKMJ3NAPm1vDLPGijejGYf7dl81TRZVg=.93c706a0-5dcc-4ce5-b6f8-311c96657764@github.com>

On Wed, 16 Oct 2024 16:23:41 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

This pull request has now been integrated.

Changeset: 2e58ede1
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e58ede18c7cfe7364a8d6a630989b0ff2ea6447
Stats:     219 lines in 9 files changed: 184 ins; 34 del; 1 mod

8341399: Add since checker tests to the langtools modules

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Fri Nov  8 10:11:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Nov 2024 10:11:06 GMT
Subject: RFR: 8335989: JEP 494: Implement Module Import Declarations
 (Second Preview) [v6]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <hHSAfrSwZTRpGqvuXq7Nu0ZSx4fztfYG57vTS9rqEhc=.5aadc7fb-289b-49ff-9a34-eefa2d90758c@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 20 commits:

 - Merge branch 'master' into JDK-8335989
 - Moving operators to the beginning of line, as suggested.
 - Updating PreviewFeature metadata
 - Cleanup.
 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - ... and 10 more: https://git.openjdk.org/jdk/compare/a10b1ccd...21c835ca

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

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=05
  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  Fri Nov  8 12:04:48 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Nov 2024 12:04:48 GMT
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods
In-Reply-To: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
Message-ID: <5KMFTeLdRlnWDwqEqJEfdhouRzZ7NysqnCQmfVTgp44=.da60a668-3859-40a7-9cba-51f68f2ca50b@github.com>

On Thu, 7 Nov 2024 13:10:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a case where a new preview interface is introduced to JDK, and an existing non-preview class is retrofitted to use it. I.e. a case like:
> 
> 
> //JDK types:
> @PreviewFeature(...)
> public interface NewAPI {
>     public default void test() {}
> }
> public class ExistingRetrofittedClass implements NewAPI {}
> 
> //user type:
> class Test {
>     void t(ExistingRetrofittedClass c) {
>         c.test();
>     }
> }
> 
> 
> There is currently no error or warning about the invocation of the test method, as the method itself is not marked as preview, and the receiver is not preview either.
> 
> The proposal herein is that invoking a method on a receiver that is not of preview type itself, but the method is declared in a preview class or interface, the method will be considered to be a preview method, and the appropriate error or warning will be printed. Similar behavior is implementing for dereferencing fields.
> 
> 
> Similarly when implementing or overriding such "effectively" preview methods, like:
> 
> 
> //user types:
> class Test1 extends ExistingRetrofittedClass {
>     public void test() {}
> }
> 
> 
> java also does not produce any error or warning. If the method itself would be marked as preview, an error or warning would be printed.
> 
> The proposal herein is to produce an error or warning for a method declared inside a non-preview class or interface, which directly overrides a method declared inside a preview class or interface.
> 
> In particular, for the two example above, javac is currently producing no errors. With the change proposed herein, javac will produce output like (with no `--enable-preview`):
> 
> 
> src/Test1.java:4: error: test() is a preview API and is disabled by default.
>     public void test() {}
>                 ^
>   (use --enable-preview to enable preview APIs)
> src/Test.java:5: error: test() is a preview API and is disabled by default.
>         c.test();
>          ^
>   (use --enable-preview to enable preview APIs)
> 2 errors

> _Mailing list message from [Alex Buckley](mailto:alex.buckley at oracle.com) on [compiler-dev](mailto:compiler-dev at mail.openjdk.org):_
> For the second proposal above, I think you mean "... which ~is overridden by~ +overrides+ a method declared inside a preview class or interface."

Correct! I've fixed the description. Thanks for pointing this out!

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

PR Comment: https://git.openjdk.org/jdk/pull/21953#issuecomment-2464576181

From prappo at openjdk.org  Fri Nov  8 12:23:22 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 8 Nov 2024 12:23:22 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v3]
In-Reply-To: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
Message-ID: <7rxM5KUjHBdwWVlDZac6OJmMsgsN6XR4r-cijPeqSak=.7050db52-01a7-49f9-b421-420669c184cb@github.com>

> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
> 
> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
> 
> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
> 
> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
> 
> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Fix a pre-existing doc typo
 - Make the check more specific

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21923/files
  - new: https://git.openjdk.org/jdk/pull/21923/files/cc9a379d..65ba8dca

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

  Stats: 38 lines in 5 files changed: 35 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21923/head:pull/21923

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

From prappo at openjdk.org  Fri Nov  8 12:23:22 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 8 Nov 2024 12:23:22 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v3]
In-Reply-To: <_ED6TVQPT8XBBFR88n6EFmVOgImImD_E2WOb2eMCK2M=.b40973b7-4989-410d-b0ad-fb6059bf016e@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <OvGpGK8WgwTYKV6tt6HsVLkkAvN_Xp0ED-Uuc0_1Nx4=.7689dd4e-6b1b-46d4-b0f2-fcfe93d1a6b9@github.com>
 <aS1wAmzHhTl9brfB8ixR6VNCZjv4GNfDcVr8aUybkbg=.5b55829b-1552-42f4-8ebe-932150eb9f50@github.com>
 <41pFo0XzIFRGHKC99rStHtu-YwJOTdbio7eUnUtVDqw=.dd7e701c-9a08-4f62-9724-100cb9a9cb8e@github.com>
 <NVfF3kMmc-260YsOXmPZ313dmFxrBf5GeFfmhiqXpJM=.d7606a1b-9f78-4346-96f2-17072d71d5c4@github.com>
 <6x0GlGdmQRgGBEVuiysNloWPKlHgwdp16tm6dCJwthQ=.a0c82921-0abc-4c7d-a455-8be533b76f9f@github.com>
 <QXG6aM3ls_xREmKKU-dosoXavcWff0E2pnWnlXF2mj0=.411b0774-0182-4b24-829b-6c42dbb9a9bc@github.com>
 <_ED6TVQPT8XBBFR88n6EFmVOgImImD_E2WOb2eMCK2M=.b40973b7-4989-410d-b0ad-fb6059bf016e@github.com>
Message-ID: <CB1KulOxmi2BM16mF-GDNZk7aT61CdH886mf2R8tV9s=.63ef863b-f434-44a1-b7e5-0418993e3df8@github.com>

On Thu, 7 Nov 2024 20:15:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Generally, the method you want is `DiagnosticSource.getLineNumber(int pos)`, which means you need a `DiagnosticSource` object.   `JavacParser` (that is, this class) has a `Log log` member, and `[Abstract]Log` provides `currentSource()`, so to get the line number for a position it should be possible to use something like `log.currentSource().getLineNumber(pos)`, assuming that the current source is set up correctly at the time you need it.
>
>> So, if a comment tree start and end position are on the same line that is also the first line of the file
> 
> The end position will always be after the start position, so you only need check if the line number of the end position of the comment is line 1. (Line numbers are 1-based.)

Jon, please have a look at the updated version and approve if it is to your liking; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21923#discussion_r1834310946

From jlahoda at openjdk.org  Fri Nov  8 12:30:49 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Nov 2024 12:30:49 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v7]
In-Reply-To: <Ye3DK_LdUiw24HugmUnaj79zOIL3_S17Rb0m7IQ7o28=.09980c24-9e05-4541-92e0-bbda2e85f609@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <Ye3DK_LdUiw24HugmUnaj79zOIL3_S17Rb0m7IQ7o28=.09980c24-9e05-4541-92e0-bbda2e85f609@github.com>
Message-ID: <biikDz1LzCCU9Yv90hYXdu9AIh_K2_48fBUWh-LtXAo=.8de48aee-c267-4f57-b772-7e5eb5bbc29a@github.com>

On Fri, 8 Nov 2024 01:29:23 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:
> 
>   adding comment

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21794#pullrequestreview-2423672886

From vromero at openjdk.org  Fri Nov  8 12:30:50 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Nov 2024 12:30:50 GMT
Subject: RFR: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint [v7]
In-Reply-To: <Ye3DK_LdUiw24HugmUnaj79zOIL3_S17Rb0m7IQ7o28=.09980c24-9e05-4541-92e0-bbda2e85f609@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
 <Ye3DK_LdUiw24HugmUnaj79zOIL3_S17Rb0m7IQ7o28=.09980c24-9e05-4541-92e0-bbda2e85f609@github.com>
Message-ID: <5XJEkps_blQCveLtfnpSETzbIpdjax7sgyxcnJIV928=.cc3c10e6-d9a4-4f39-a556-2b5c02e5231a@github.com>

On Fri, 8 Nov 2024 01:29:23 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:
> 
>   adding comment

thanks to the reviewers for the comments!

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

PR Comment: https://git.openjdk.org/jdk/pull/21794#issuecomment-2464638977

From vromero at openjdk.org  Fri Nov  8 12:30:50 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Nov 2024 12:30:50 GMT
Subject: Integrated: 8343306: javac is failing to determine if a class and a
 sealed interface are disjoint
In-Reply-To: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
References: <BRsIZsuh-HvkuDcmBlEoekFoUt9e2u6eICU795WRkzs=.db218543-a801-4ca3-bc8f-3288a80e8b63@github.com>
Message-ID: <gTZ9qjSQwOjJxkJbPoUP8L-oXZupJBSYxgusYnTyHFE=.4029841b-92c3-44e2-80c6-db21ff8c45bc@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

This pull request has now been integrated.

Changeset: 96eed7fa
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96eed7fa6c025374bc10039bca2949a76d78f890
Stats:     69 lines in 2 files changed: 45 ins; 0 del; 24 mod

8343306: javac is failing to determine if a class and a sealed interface are disjoint

Reviewed-by: jlahoda, mcimadamore

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

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

From prappo at openjdk.org  Fri Nov  8 12:38:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 8 Nov 2024 12:38:06 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v5]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <0Qqgqopg8A8uXWPafyVBz8LpW6M1HTLMqnF3M-KPHHg=.7b8e11f9-5978-4497-9ed3-c4997d53c31b@github.com>

> Prepare for JDK 25.

Pavel Rappo 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 --release 24 symbol information for JDK 24 build 23
   
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 21
   
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
 - Add forgotten .jcheck/conf
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/9a0553bb..84dce9a3

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

  Stats: 132677 lines in 806 files changed: 104773 ins; 9792 del; 18112 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 alanb at openjdk.org  Fri Nov  8 12:56:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 12:56:20 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v2]
In-Reply-To: <3J4BybOBLEvHajoowPmaESUb0lfmWvB51buu68o9mSQ=.78df4cd7-edc2-4ec4-9782-7f2bbf18cd53@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <3J4BybOBLEvHajoowPmaESUb0lfmWvB51buu68o9mSQ=.78df4cd7-edc2-4ec4-9782-7f2bbf18cd53@github.com>
Message-ID: <xq5vzIPSa18O9FPzdzzy4uUXGXRQHhZTvOvVhB9p1mQ=.36bff480-d606-49de-af08-2d453d88eba9@github.com>

On Mon, 4 Nov 2024 16:10:47 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright years and removing an unneccessary import for Gatherers

Looks fine, you'll need to sync up the PR to resolve the merge conflict, and you'll need to update the copyright header of several files (esp. tests) before integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2464686608

From vklang at openjdk.org  Fri Nov  8 13:43:26 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 13:43:26 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v3]
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: <U29E6VqWoNuH9A9990kbQPATuFC4kU0R8zu0p5ZG_QE=.1acb1273-7fab-4780-b909-c51b4b7c16e4@github.com>

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Updating copyright years and removing an unneccessary import for Gatherers
 - 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=02
  Stats: 39 lines in 24 files changed: 0 ins; 19 del; 20 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 vklang at openjdk.org  Fri Nov  8 13:49:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 13:49:32 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v3]
In-Reply-To: <U29E6VqWoNuH9A9990kbQPATuFC4kU0R8zu0p5ZG_QE=.1acb1273-7fab-4780-b909-c51b4b7c16e4@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <U29E6VqWoNuH9A9990kbQPATuFC4kU0R8zu0p5ZG_QE=.1acb1273-7fab-4780-b909-c51b4b7c16e4@github.com>
Message-ID: <PdeiuNW-Aqa1161UJeEuicfEtakSBplXvZTIYFTPlOM=.086c34f3-49eb-4c68-86d0-3aec5434709d@github.com>

On Fri, 8 Nov 2024 13:43:26 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Updating copyright years and removing an unneccessary import for Gatherers
>  - Removing PreviewFeature from Gatherers
>  - Updating @since to 24 for Gatherers

@liach @AlanBateman rebase on current mainline and fixed the conflicts and pushed the update. The CSR is accepted so this should be ready to merge.

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

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2464805059

From mullan at openjdk.org  Fri Nov  8 13:49:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 8 Nov 2024 13:49:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@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 224 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=08
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 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 vklang at openjdk.org  Fri Nov  8 13:56:38 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 13:56:38 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
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: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

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

  Updating the copyright year of the Gatherer benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21686/files
  - new: https://git.openjdk.org/jdk/pull/21686/files/6e8e1415..d4a6cfaa

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

  Stats: 11 lines in 11 files changed: 0 ins; 0 del; 11 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 alanb at openjdk.org  Fri Nov  8 14:16:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 14:16:33 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
Message-ID: <cRr3T8G6Px8ccWcZpfYnh6gjIjsA0Je3VDF-q0PNYos=.d655ea83-07eb-4819-b91c-28cf11b7ebae@github.com>

On Fri, 8 Nov 2024 13:56:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating the copyright year of the Gatherer benchmarks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21686#pullrequestreview-2423918386

From liach at openjdk.org  Fri Nov  8 16:22:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Nov 2024 16:22:13 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
Message-ID: <2GUfR_26OiD5yS6fM4InA4PPngjwrfCAEYhES8DcRMk=.83a6cb05-9a8a-40e0-8f07-415da9827e9f@github.com>

On Fri, 8 Nov 2024 13:56:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating the copyright year of the Gatherer benchmarks

The removal of preview toggles look good. Confirmed that since in stream packages and removal of preview toggles tests/micro look good.

Side comment: With the `jvmArgs` cleared on benchmark `@Fork`, you can just make it `@Fork(1)` instead of `@Fork(value = 1)`.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21686#pullrequestreview-2424229448

From vklang at openjdk.org  Fri Nov  8 16:28:56 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 16:28:56 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <2GUfR_26OiD5yS6fM4InA4PPngjwrfCAEYhES8DcRMk=.83a6cb05-9a8a-40e0-8f07-415da9827e9f@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
 <2GUfR_26OiD5yS6fM4InA4PPngjwrfCAEYhES8DcRMk=.83a6cb05-9a8a-40e0-8f07-415da9827e9f@github.com>
Message-ID: <gza4QT8nV8wKCYAcOYysUDYtdR0nCDhRr9kL0hSwozU=.c211bc3d-9d6e-46ed-ac24-d1be5c32d31f@github.com>

On Fri, 8 Nov 2024 16:17:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating the copyright year of the Gatherer benchmarks
>
> The removal of preview toggles look good. Confirmed that since in stream packages and removal of preview toggles tests/micro look good.
> 
> Side comment: With the `jvmArgs` cleared on benchmark `@Fork`, you can just make it `@Fork(1)` instead of `@Fork(value = 1)`.

@liach 

>Side comment: With the jvmArgs cleared on benchmark @Fork, you can just make it @Fork(1) instead of @Fork(value = 1).

Yeah, I opted to keep it as-is to make the delta between old-and-new low (and to make adding additional params slightly faster). I'd be happy to change it if you insist, tho! :)

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

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2465208982

From liach at openjdk.org  Fri Nov  8 17:01:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Nov 2024 17:01:14 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
Message-ID: <NLEcCoYK_MBVYwO-xXEiAjRY1Kh_B1FQLCXgk__H424=.251065bf-bd7f-46b8-baa5-2c2fa370122d@github.com>

On Fri, 8 Nov 2024 13:56:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating the copyright year of the Gatherer benchmarks

The current form makes it easy to add jvm args in the future, too.  It's totally fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2465277946

From jjg at openjdk.org  Fri Nov  8 17:04:50 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 8 Nov 2024 17:04:50 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v3]
In-Reply-To: <7rxM5KUjHBdwWVlDZac6OJmMsgsN6XR4r-cijPeqSak=.7050db52-01a7-49f9-b421-420669c184cb@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
 <7rxM5KUjHBdwWVlDZac6OJmMsgsN6XR4r-cijPeqSak=.7050db52-01a7-49f9-b421-420669c184cb@github.com>
Message-ID: <HtbDBbW8-xwqjMEgKG-ZSGgYNLz9uG8hLbFN3idYzuU=.e20a5b21-32ab-4aae-866e-370c73f167af@github.com>

On Fri, 8 Nov 2024 12:23:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
>> 
>> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
>> 
>> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
>> 
>> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
>> 
>> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix a pre-existing doc typo
>  - Make the check more specific

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21923#pullrequestreview-2424386640

From aivanov at openjdk.org  Fri Nov  8 18:18:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Nov 2024 18:18:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
Message-ID: <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>

On Tue, 29 Oct 2024 17:06:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> 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?
>
>> Is it intentional?
> 
> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again?

It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).

Without the `@see` tag, one has to read the entire description to find the link.

It looks subtle. We can restore the `@see`-link later if deemed necessary.

Does anyone else have an opinion?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826266398

From honkar at openjdk.org  Fri Nov  8 18:36:29 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 8 Nov 2024 18:36:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
Message-ID: <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>

On Fri, 1 Nov 2024 20:26:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Is it intentional?
>> 
>> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again?
>
> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).
> 
> Without the `@see` tag, one has to read the entire description to find the link.
> 
> It looks subtle. We can restore the `@see`-link later if deemed necessary.
> 
> Does anyone else have an opinion?

I can add it back if it is more convenient and readable to have the `@see` tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1834883137

From acobbs at openjdk.org  Fri Nov  8 19:07:16 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 8 Nov 2024 19:07:16 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v3]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <dnV6AR8eTDXrX505rYy-j0mocbws2Nlf2-HWGGCoVac=.cf4f83dd-e6cb-4d1b-96c8-680cf64457f3@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update copyright years.
 - Remove a few more @SuppressWarnings annotations.
 - Remove a few more @SuppressWarnings annotations.
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/7842dfea..a64d5594

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

  Stats: 131613 lines in 758 files changed: 103986 ins; 9698 del; 17929 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From acobbs at openjdk.org  Fri Nov  8 19:07:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 8 Nov 2024 19:07:40 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v3]
In-Reply-To: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
Message-ID: <MtT4ei-dVkqHNiS7LOzFHGmZF9ECQqWv9IOLkaQl4YU=.c81791dd-cca8-4d4f-88ed-a2f2ba6bd0bf@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Apply change that was missed somehow.
 - Undo change that will be moved to the core-libs branch.
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21851/files
  - new: https://git.openjdk.org/jdk/pull/21851/files/033f7631..d955b538

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

  Stats: 131587 lines in 749 files changed: 103986 ins; 9680 del; 17921 mod
  Patch: https://git.openjdk.org/jdk/pull/21851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21851/head:pull/21851

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

From acobbs at openjdk.org  Fri Nov  8 19:47:14 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 8 Nov 2024 19:47:14 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v4]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <gyv3FuuYnMooqIZ-RUDCDFFipdJUOZglHH6-k8WMv38=.f203c313-72a8-4f69-b47e-c97f5a5afe6c@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

  Put back @SuppressWarnings annotations to be fixed by JDK-8343286.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/a64d5594..9137373f

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

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

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

From prr at openjdk.org  Fri Nov  8 21:05:41 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Nov 2024 21:05:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
Message-ID: <dhLdeBXtuGvkkliM-T9_iulm4XDPiHmO7jzAkk64sfQ=.71503749-f671-4a6f-b734-0e75e944aca8@github.com>

On Fri, 8 Nov 2024 13:49: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 224 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2424915104

From prr at openjdk.org  Fri Nov  8 21:05:42 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Nov 2024 21:05:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@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>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
 <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>
Message-ID: <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@github.com>

On Fri, 1 Nov 2024 18:06:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > 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.
> 
> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
> 
> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
> 
> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198

I think I was just saying there appeared to be dead code in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1835053637

From weijun at openjdk.org  Sat Nov  9 00:57:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 9 Nov 2024 00:57:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
Message-ID: <R5hyTWGUzhiJE4SpPYJPTygHl6poBtz11qYOO6jeegQ=.32767fc6-3ca5-48bc-b491-d039d99083b8@github.com>

On Fri, 8 Nov 2024 13:49: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 224 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2425106253

From cushon at openjdk.org  Sat Nov  9 20:57:39 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 9 Nov 2024 20:57:39 GMT
Subject: RFR: 8343882: BasicAnnoTests doesn't handle multiple annotations at
 the same position
Message-ID: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>

Please consider this fix to `test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java`. Due to a long-standing bug in the test, some test cases were not being processed if there were multiple assertions for annotations at the same position. All existing cases in the test still pass after this fix.

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

Commit messages:
 - 8343882: BasicAnnoTests doesn't handle multiple annotations at the same position

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

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

From archie.cobbs at gmail.com  Sat Nov  9 22:50:57 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sat, 9 Nov 2024 16:50:57 -0600
Subject: Proposal: Warnings for unnecessary warning suppression
Message-ID: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>

*Overview*

This is a proposal to add the ability for the compiler to detect and report
unnecessary warning suppressions.

An "unnecessary warning suppression" is when one of the following happens:

   - There is a @SuppressWarnings("foo") annotation, but if it hadn't been
   there, no foo warning would have been generated within the annotation's
   scope
   - The compiler is passed -Xlint:-foo, but if it hadn't been, no foo
   warning would have been generated during the entire compilation

*Motivation*

@SuppressWarnings and -Xlint:-foo are blunt instruments. The latter is
maximally blunt: it covers the entire compilation. The former is somewhat
blunt, especially when the warning occurs at a specific statement other
than a variable declaration and so the annotation has to annotate and cover
the entire containing method.

In practice @SuppressWarnings and -Xlint:-foo are also very sticky: once
they get added to a source file or a build process, they are rarely
removed, because that would require an audit to determine if the original
problem is now resolved (or the compiler behavior has changed), which is
tedious.

Sometimes @SuppressWarnings annotations are never needed in the first
place: they're added to the code proactively as the code is written because
the developer thinks they *might* be needed. In this situation, the
compiler provides the same feedback either way (i.e. none), so this type of
mistake is almost never caught.

As code evolves over time, newly added bugs that warnings are designed to
catch can escape detection if they happen to appear within the scope of a
@SuppressWarnings or -Xlint:-foo flag. That problem can't be solved
completely, but it can be minimized by ensuring that all @SuppressWarnings
annotations and -Xlint:-foo flags that do exist are actually serving some
purpose.

More generally, there is the natural and healthy need to "declutter", and
also the "peace of mind" factor: We want to know we're doing everything we
reasonably can to prevent bugs... and since the compiler is the thing that
generates the warnings in the first place, shouldn't it also be able to
detect and report when a warning is being unnecessarily suppressed?

*Caveats*

There are real-world concerns with adding something like this. Lots of
people build with -Xlint:all. We don't want to constrict the compiler so
tightly that it becomes more frustrating than helpful for people trying to
build software in the real world. Warning behavior can differ not only
across JDK versions but also across operating systems, so we don't want to
force over-complexification of builds.

There is a balance to strike; the functionality should be easy to disable.

*Proposal*

Add two new lint categories, as described by this --help-lint output:

  suppression          Warn about @SuppressWarnings values that don't
actually suppress any warnings.
  suppression-option   Warn about -Xlint:-key options that don't actually
suppress any warnings (requires "options").

Notice that for suppression-option to work, you also have to enable options
(see below for discussion).

The behavior in a nutshell:

   - When warnable code is detected, the warning "bubbles up" until it hits
   the first @SuppressWarning annotation in scope, or if none, the
   -Xlint:-foo option (if any).
   - If the warning doesn't hit anything and "escapes", the warning is
   emitted (this is what happens today)
   - Otherwise, the warning has hit a *suppression* - either a
   @SuppressWarning annotation or global -Xlint:-foo option - and so:
      - It is suppressed (this is what happens today), and
      - NEW: That suppression is marked as *validated*
   - NEW: After processing each file, the suppression category warns about
   @SuppressWarning annotations in that file containing unvalidated
   categories
   - NEW: After processing the entire compilation, the
suppression-option category
   warns about unvalidated -Xlint:-foo options.

Here's an example using rawtypes to demonstrate the proposed behavior:

@SuppressWarnings("rawtypes")      // annotation #1
public class Test {

    @SuppressWarnings("rawtypes")  // annotation #2
    public Iterable obj = null;    // "rawtypes" warning here
}

For a rawtypes warning to be emitted, the following must be true:

   - -Xlint:rawtypes must be enabled
   - Annotation #1 and annotation #2 must both NOT be present

This is the same logic that we already have.

For a suppression warning to be emitted at outer annotation #1 the
following must be true:

   - -Xlint:suppression must be enabled
   - Annotation #1 AND annotation #2 must BOTH be present

Note that in this case either annotation could be declared as the
"unnecessary" one, but when nested annotations suppress the same warning,
we will always assume that the innermost annotation is the "real" one (it's
the first to "catch" the warning as it bubbles up) and any containing
annotations are therefore the "unnecessary" ones.

As a result, it would never be possible for a suppression warning to be
emitted at annotation #2.

Also note that the category being suppressed does not itself need to be
enabled: the lint categories rawtypes and suppression warn about two
different things, and so they are enabled/disabled independently (*)

(*) This might be debatable. One could argue that if rawtypes is not
enabled, then all activity related to the rawtypes warning should be shut
down, including determining whether there is any unnecessary suppression of
it. This would be a more conservative change, but it would mean that only
the warnings that are actually enabled could be detected as unnecessarily
suppressed, which is a less robust check. In addition, it would mean that
for any given lint category, only one of the suppression or
suppression-option categories could be applicable at a time, which seems
too limiting.

For a suppression-option warning to be emitted for the above example, the
following must be true:

   - -Xlint:options must be enabled
   - -Xlint:suppression-option must be enabled
   - -Xlint:-rawtypes must be specified (i.e., it must be actively
   suppressed, not just disabled which is the default)
   - At least one of annotation #1 or annotation #2 must be present

The reason for requiring options is that the warning does in fact relate to
a command line option and so it seems appropriate that it be included. In
practice, options appears to be already in use as a "catch-all" when
building on multiple operating systems and/or JDK versions, etc., so this
will make for a cleaner upgrade path.


*Gory Details*

Some lint categories don't support @SuppressWarnings annotation scoping,
e.g, classfile, output-file-clash, path, and text-blocks (the latter
because it is calculated by the scanner before annotation symbols are
available). Putting them in a @SuppressWarnings annotation is always
useless (and will be reported as such). However, they are still viable
candidates for the suppression-option warning.

Some lint categories will be omitted from "suppression tracking" altogether:

   - path
   - options
   - suppression
   - suppression-option

The path category is omitted because it is used too early in the pipeline
(before singletons are created).

The options category is omitted because including it would be pointless:

   - It doesn't support @SuppressWarnings, so suppressions doesn't apply
   - If there's -Xlint:-options, then suppression-option is also disabled

What about the self-referential nature of suppressing suppression itself?
Consider this example:

@SuppressWarnings({ "rawtypes", "suppression" })
public class Test { }

There is no rawtypes warning in there, so the suppression of rawtypes is
indeed unnecessary and would normally result in a suppression warning. But
we also are suppressing the suppression warning itself, so the end result
is that no warning would be generated.

OK what about this?

@SuppressWarnings("suppression")
public class Test { }

If suppression were itself subject to suppression tracking, this example
would lead to a paradox. Instead, we exclude suppression itself from
suppression tracking. So that example would generate no warning. Analogous
logic applies to suppression-option - it doesn't apply to itself.

Note that @SuppressWarnings("suppression") is not totally useless, because
it can affect nested annotations:

@SuppressWarnings("suppression")   // this is NOT unnecessary
public class Test {

     // Suppression of "rawtypes" is unnecessary - but that won't be
reported
@SuppressWarnings("rawtypes")
public int x = 1;
}

Making suppression-option a separate warning from suppression seems a
reasonably obvious thing to do but there are also some subtle reasons for
doing that.

First, any system that does incremental builds (like the JDK itself) can
have a problem if the suppression-option warning is applied to a partial
compilation, because what if the file(s) that generate the warning being
suppressed are not part of that particular build? Then you would get a
false positive. So incremental builds could disable suppression-option  but
still safely leave suppression enabled.

Also, different versions of the JDK support different lint flags and have
different warning logic, so that warnings in some versions don't occur in
other versions. When the same source needs to be compiled under multiple
JDK versions, some -Xlint:-foo flags may be necessary in some versions and
useless in others. We want to ensure there's a reasonably simple way to use
the same command line flags when compiling under different JDK versions
without having to disable suppression tracking altogether.

Similarly, for some warnings the operating system might affect whether
warnings are generated.

*Prototype Status*

What follows is probably TMI but I figured I'd include a full brain dump
while top of mind...

I originally implemented this just to see how hard it would be and to play
around with the idea; it seems like the experiment has worked fairly well.

Of course the first thing I wanted to try was to run it on the JDK itself.
This revealed 400+ unnecessary @SuppressWarnings annotations and 11
unnecessary -Xlint:foo flags detected. That showed that the issue being
addressed is not imaginary.

Of course, because most of the JDK is built with -Xlint:all (or close to
it), that also meant tracking down and removing all of the unnecessary
suppressions; I had to semi-automate the process. A side-effect of that
effort is a series of separate PR's
<https://github.com/openjdk/jdk/pulls?q=author%3Aarchiecobbs+is%3Apr+%22Remove+unnecessary%22+in%3Atitle+>
to remove unnecessary @SuppressWarnings annotations and -Xlint:-foo flags.
Of course, those PR's can be evaluated independently from this proposal.

(You may wonder: How did all those useless suppressions get in there? See this
PR comment
<https://github.com/openjdk/jdk/pull/21853#issuecomment-2462566874>.)

I played around with a couple of different API designs. The API design is
key to ensuring we avoid various annoying inconsistencies that can easily
occur; a worst case scenario is a foo warning that gets reported somewhere,
but then when you add the @SuppressWarnings("foo") annotation to suppress
it, the annotation is reported as unnecessary - a catch-22. So I tried to
design & document the API to make it easy for compiler developers to avoid
inconsistencies (regression tests also contribute to this effort).

The key challenges as you might guess are:

   - Ensuring warning detection logic is no longer skipped when a category
   is suppressed if suppression is enabled (easy)
   - Ensuring that anywhere a warning is detected but isn't reported
   because the category is suppressed, the suppression is still validated
   (harder)

Summary of internal compiler changes:

   - Lint now keeps track of the current symbol "in scope" - this is
   whatever symbol was last used for Lint.augment(). Validations are
   tracked against these symbols, or null for the global scope.
   - A new singleton LintSuppression is responsible for maintaining this
   tracking information on a per-symbol and per-category basis, and generating
   warnings as needed when the time comes.
   - A new method Lint.isActive() answers the question "Should I bother
   doing some non-trivial calculation that might or might not generate a
   warning?" It returns true if the category is enabled OR if it's suppressed
   but subject to suppression tracking and the current suppression in scope
   has not yet been validated. This is entirely optional and usually not
   needed. An obvious example: before invoking Check.checkSerialStructure().
   - A new method Lint.validate() means "If this lint category is currently
   suppressed, then validate that suppression". In other words, you are saying
   that a warning would be generated here.
   - A new method Lint.emit() simplifies the logic when a lint warning is
   detected:
      - If the category is enabled, it logs the message
      - If the category is suppressed, it validates the suppression

So code that looked like this:

if (lint.isEnabled(LintCategory.FOO)) {
    log.warning(LintCategory.FOO, pos, SomeWarning(x, y));
}

can be simplified to this:

lint.emit(log, LintCategory.FOO, pos, SomeWarning(x, y));

A minor downside of that simplification is that the Warning object is
constructed even if the warning is suppressed. The upside is that
suppression validation happens automatically. Since warnings are relatively
rare, I felt this was a worthwhile trade-off, but it's not forced on people
- you can always do this instead:

if (lint.validate(LintCategory.FOO).isEnabled(LintCategory.FOO)) {
    log.warning(LintCategory.FOO, pos, SomeWarning(x, y));
}

When we're ready to report on unnecessary suppressions in a file, we scan
the file for @SuppressWarnings (and @Deprecated) annotations, then look at
the validatations of the corresponding symbol declarations, and do the
"propagation" step where all the validations bubble up. Any suppressions
that aren't validated are then reported as unnecessary. A similar thing
happens at the global scope to generate the suppression-option warnings,
using validations that escape individual source files, at the end of the
overall compilation.

There were two tricky refactorings: The overloads warning reports when two
methods are ambiguous when called with lambdas, but the warning itself has
the property that a @SuppressWarnings("overloads") annotation on *either*
of two such methods suffices to suppress the warning. So we have to be
careful with the logic, e.g., if both methods have the annotation, we don't
want to randomly validate one of them and then declare the other as
unnecessary, etc. To avoid this, both annotations are validated
simultaneously.

The other is the "this-escape" analyzer. When a constructor invokes this()
or a method, control flow jumps to that constructor or method; when it
executes super(), control flow jumps to all the field initializers and
non-static initializer blocks. This jumping around conflicts with the AST
tree-based scoping of @SuppressWarnings annotations. We apply "fixups" so
the suppression effect follows the control flow, not the AST. This is how
it already worked, but the code had to be updated to validate properly.

What about DeferredLintHandler and MandatoryWarningHandler? These were not
really an issue; all you need is a handle on the correct Lint instance and
one is always available.

The prototype is available here:
https://github.com/archiecobbs/jdk/tree/suppression

This prototype patch is a little unwieldy because it includes:

   - Compiler changes to support the new lint categories (in the diff
   starting with Lint.java)
   - Removal of 400+ @SuppressWarnings annotations to continue to allow the
   use of -Xlint:all everywhere (build logs
   <https://github.com/archiecobbs/jdk/actions/runs/11728281642>)
   - Several build-related cleanups, e.g., adding -Xlint:-suppression-option
   to unbreak incremental builds
   - Temporary build workaround for JDK-8340341

I'm interested in any opinions and/or folks who have large bodies of code
or specific test cases they would like to run this on.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241109/26ee195b/attachment-0001.htm>

From jjg3 at pobox.com  Sat Nov  9 23:28:40 2024
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Sat, 9 Nov 2024 15:28:40 -0800
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
Message-ID: <6cc2414d-e030-4c8a-acb7-02badac3e19b@pobox.com>

Archie,

Various concerns for your consideration:

1. The set of strings that are valid for @SuppressWarnings is undefined 
and open-ended. Yes, the JDK compiler `javac` defines a set of strings 
but there is no guarantee that code will only be compiled by `javac` and 
that there are no other strings in use. Some IDEs may also use the 
@SuppressWarnings mechanism.

2. JLS 9.6.4.5 says:

The Java programming language defines four kinds of warnings that can be 
specified by|@SuppressWarnings|:

  *

    Unchecked warnings (?4.8
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-4.html#jls-4.8>,?5.1.6
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-5.html#jls-5.1.6>,?5.1.9
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-5.html#jls-5.1.9>,?8.4.1
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-8.html#jls-8.4.1>,?8.4.8.3
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-8.html#jls-8.4.8.3>,?15.12.4.2
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.4.2>,?15.13.2
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.13.2>,?15.27.3
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.27.3>)
    are specified by the string "|unchecked|".

  *

    Deprecation warnings (?9.6.4.6
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-9.html#jls-9.6.4.6>)
    are specified by the string "|deprecation|".

  *

    Removal warnings (?9.6.4.6
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-9.html#jls-9.6.4.6>)
    are specified by the string "|removal|".

  *

    Preview warnings (?1.5
    <https://docs.oracle.com/javase/specs/jls/se23/html/jls-1.html#jls-1.5>)
    are specified by the string "|preview|".

Any other string specifies a non-standard warning. A Java compiler must 
ignore any such string that it does not recognize.

Note that last sentence: /A Java compiler must ignore any such string 
that it does not recognize.
/I think this means the proposal should be more clear that the proposed 
effect only applies to strings that are recognized by the tool running 
the check.? JLS also says Compiler vendors are encouraged to document 
the strings they support for|@SuppressWarnings|, and to cooperate to 
ensure that the same strings are recognized across multiple compilers. 
so we should document this in such a way that other tools are encouraged 
to support the same string with the same semantics.

3. I note that the JDK `javadoc` tool supports variations on 
`@SuppressWarnings("doclint"), corresponding to the `-Xdoclint` option 
supported by both `javac` and `javadoc`, although there has been 
informal discussions on dropping support from `javac`.? See here: 
https://docs.oracle.com/en/java/javase/23/docs/specs/man/javadoc.html#doclint

-- Jon


On 11/9/24 2:50 PM, Archie Cobbs wrote:
> *Overview*
>
> This is a proposal to add the ability for the compiler to detect and 
> report unnecessary warning suppressions.
>
> An "unnecessary warning suppression" is when one of the following happens:
>
>   * There is a @SuppressWarnings("foo")annotation, but if it hadn't
>     been there, no foo warning would have been generated within the
>     annotation's scope
>   * The compiler is passed -Xlint:-foo, but if it hadn't been, no foo
>     warning wouldhave been generated during the entire compilation
>
> *Motivation*
>
> @SuppressWarnings and -Xlint:-foo are blunt instruments. The latter is 
> maximally blunt: it covers the entire compilation. The former is 
> somewhat blunt, especially when the warning occurs at a specific 
> statement other than a variable declaration and so the annotation has 
> to annotate and cover the entire containing method.
>
> In practice @SuppressWarnings and -Xlint:-foo are also very sticky: 
> once they get added to a source file or a build process, they are 
> rarely removed, because that would require an audit to determine if 
> the original problem is now resolved (or the compiler behavior has 
> changed), which is tedious.
>
> Sometimes @SuppressWarnings annotations are never needed in the first 
> place: they're added to the code proactively as the code is written 
> because the developer thinks they /might/ be needed. In this 
> situation, the compiler provides the same feedback either way (i.e. 
> none), so this type of mistake is almost never caught.
>
> As code evolves over time, newly added bugs that warnings are designed 
> to catch can escape detection if they happen to appear within the 
> scope of a @SuppressWarnings or -Xlint:-foo flag. That problem can't 
> be solved completely, but it can be minimized by ensuring that all 
> @SuppressWarnings annotations and -Xlint:-foo flags that do exist are 
> actually serving some purpose.
>
> More generally, there is the natural and healthy need to "declutter", 
> and also the "peace of mind" factor: We want to know we're doing 
> everything we reasonably can to prevent bugs... and since the compiler 
> is the thing that generates the warnings in the first place, shouldn't 
> it also be able to detect and report when a warning is being 
> unnecessarily suppressed?
>
> *Caveats*
>
> There are real-world concerns with adding something like this. Lots of 
> people build with -Xlint:all. We don't want to constrict the compiler 
> so tightly that it becomes more frustrating than helpful for people 
> trying to build software in the real world. Warning behavior can 
> differ not only across JDK versions but also across operating systems, 
> so we don't want to force over-complexification of builds.
>
> There is a balance to strike; the functionality should be easy to disable.
>
> *Proposal*
>
> Add two new lint categories, as described by this --help-lint output:
>
> ? suppression ? ? ? ? ?Warn about @SuppressWarnings values that don't 
> actually suppress any warnings.
> suppression-option ? Warn about -Xlint:-key options that don't 
> actually suppress any warnings (requires "options").
>
> Notice that for suppression-option to work, you also have to enable 
> options (see below for discussion).
>
> The behavior in a nutshell:
>
>   * When warnable code is detected, the warning "bubbles up" until it
>     hits the first @SuppressWarning annotation in scope, or if none,
>     the -Xlint:-foo option (if any).
>   * If the warning doesn't hit anything and "escapes", the warning is
>     emitted (this is what happens today)
>   * Otherwise, the warning has hit a /suppression/ - either a
>     @SuppressWarning annotation or global -Xlint:-foo option - and so:
>       o It is suppressed (this is what happens today), and
>       o NEW: That suppression is marked as /validated/
>   * NEW: After processing each file, the suppression category warns
>     about @SuppressWarning annotations in that file containing
>     unvalidated categories
>   * NEW: After processing the entire compilation, the
>     suppression-option?category warns about unvalidated -Xlint:-foo
>     options.
>
> Here's an example using rawtypes to demonstrate the proposed behavior:
>
> @SuppressWarnings("rawtypes") // annotation #1
> public class Test {
>
> @SuppressWarnings("rawtypes") // annotation #2
> ??? public Iterable obj = null;??? // "rawtypes" warning here
> }
>
> For a rawtypes warning to be emitted, the following must be true:
>
>   * -Xlint:rawtypes must be enabled
>   * Annotation #1 and annotation #2 must both NOT be present
>
> This is the same logic that we already have.
>
> For a suppression warning to be emitted at outer annotation #1 the 
> following must be true:
>
>   * -Xlint:suppression must be enabled
>   * Annotation #1 AND annotation #2 must BOTH be present
>
> Note that in this case either annotation could be declared as the 
> "unnecessary" one, but when nested annotations suppress the same 
> warning, we will always assume that the innermost annotation is the 
> "real" one (it's the first to "catch" the warning as it bubbles up) 
> and any containing annotations are therefore the "unnecessary" ones.
>
> As a result, it would never be possible for a suppression warning to 
> be emitted at annotation #2.
>
> Also note that the category being suppressed does not itself need to 
> be enabled: the lint categories rawtypes and suppression warn about 
> two different things, and so they are enabled/disabled independently (*)
>
> (*) This might be debatable. One could argue that if rawtypes is not 
> enabled, then all activity related to the rawtypes warning should be 
> shut down, including determining whether there is any unnecessary 
> suppression of it. This would be a more conservative change, but it 
> would mean that only the warnings that are actually enabled could be 
> detected as unnecessarily suppressed, which is a less robust check. In 
> addition, it would mean that for any given lint category, only one of 
> the suppression or suppression-option categories could be applicable 
> at a time, which seems too limiting.
>
> For a suppression-option warning to be emitted for the above example, 
> the following must be true:
>
>   * -Xlint:options must be enabled
>   * -Xlint:suppression-option must be enabled
>   * -Xlint:-rawtypes must be specified (i.e., it must be actively
>     suppressed, not just disabled which is the default)
>   * At least one of annotation #1 or annotation #2 must be present
>
> The reason for requiring options is that the warning does in fact 
> relate to a command line option and so it seems appropriate that it be 
> included. In practice, options appears to be already in use as a 
> "catch-all" when building on multiple operating systems and/or JDK 
> versions, etc., so this will make for a cleaner upgrade path.
> *
> *
> *Gory Details
> *
>
> Some lint categories don't support @SuppressWarnings annotation 
> scoping, e.g, classfile, output-file-clash, path, and text-blocks (the 
> latter because it is calculated by the scanner before annotation 
> symbols are available). Putting them in a @SuppressWarnings annotation 
> is always useless (and will be reported as such). However, they are 
> still viable candidates for the suppression-option warning.
> *
> *
> Some lint categories will be omitted from "suppression tracking" 
> altogether:
>
>   * path
>   * options
>   * suppression
>   * suppression-option
>
> The path category is omitted because it is used too early in the 
> pipeline (before singletons are created).
>
> The options category is omitted because including it would be pointless:
>
>   * It doesn't support @SuppressWarnings, so suppressions doesn't apply
>   * If there's -Xlint:-options, then suppression-option is also disabled
>
> What about the self-referential nature of suppressing suppression 
> itself? Consider this example:
>
> @SuppressWarnings({ "rawtypes", "suppression" })
> public class Test { }
>
> There is no rawtypes warning in there, so the suppression of rawtypes 
> is indeed unnecessary and would normally result in a suppression 
> warning. But we also are suppressing the suppression warning itself, 
> so the end result is that no warning would be generated.
>
> OK what about this?
>
> @SuppressWarnings("suppression")
> public class Test { }
>
> If suppression were itself subject to suppression tracking, this 
> example would lead to a paradox. Instead, we exclude suppression 
> itself from suppression tracking. So that example would generate no 
> warning. Analogous logic applies to suppression-option - it doesn't 
> apply to itself.
>
> Note that @SuppressWarnings("suppression") is not totally useless, 
> because it can affect nested annotations:
>
> @SuppressWarnings("suppression") // this is NOT unnecessary
> public class Test {
>
> // Suppression of "rawtypes" is unnecessary - but that won't be reported
> @SuppressWarnings("rawtypes")
> public int x = 1;
> }
>
> Making suppression-option a separate warning from suppression seems a 
> reasonably obvious thing to do but there are also some subtle reasons 
> for doing that.
>
> First, any system that does incremental builds (like the JDK itself) 
> can have a problem if the suppression-option warning is applied to a 
> partial compilation, because what if the file(s) that generate the 
> warning being suppressed are not part of that particular build? Then 
> you would get a false positive. So incremental builds could disable 
> suppression-option? but still safely leave suppression enabled.
> *
> *
> Also, different versions of the JDK support different lint flags and 
> have different warning logic, so that warnings in some versions don't 
> occur in other versions. When the same source needs to be compiled 
> under multiple JDK versions, some -Xlint:-foo flags may be necessary 
> in some versions and useless in others. We want to ensure there's a 
> reasonably simple way to use the same command line flags when 
> compiling under different JDK versions without having to disable 
> suppression tracking altogether.
>
> Similarly,?for some warnings the operating system might affect whether 
> warnings are generated.
>
> *Prototype Status*
>
> What follows is probably TMI but I figured I'd include a full brain 
> dump while top of mind...
>
> I originally implemented this just to see how hard it would be and to 
> play around with the idea; it seems like the experiment has worked 
> fairly well.
>
> Of course the first thing I wanted to try was to run it on the JDK 
> itself. This revealed 400+ unnecessary @SuppressWarnings annotations 
> and 11 unnecessary -Xlint:foo flags detected. That showed that the 
> issue being addressed is not imaginary.
>
> Of course, because most of the JDK is built with -Xlint:all (or close 
> to it), that also meant tracking down and removing all of the 
> unnecessary suppressions; I had to semi-automate the process. A 
> side-effect of that effort is a series of separate PR's 
> <https://github.com/openjdk/jdk/pulls?q=author%3Aarchiecobbs+is%3Apr+%22Remove+unnecessary%22+in%3Atitle+> 
> to remove unnecessary @SuppressWarnings annotations and -Xlint:-foo 
> flags. Of course, those PR's can be evaluated independently from this 
> proposal.
>
> (You may wonder: How did all those useless suppressions get in there? 
> See this PR comment 
> <https://github.com/openjdk/jdk/pull/21853#issuecomment-2462566874>.)
>
> I played around with a couple of different API designs. The API design 
> is key to ensuring we avoid various annoying inconsistencies that can 
> easily occur; a worst case scenario is a foo warning that gets 
> reported somewhere, but then when you add the @SuppressWarnings("foo") 
> annotation to suppress it, the annotation is reported as unnecessary - 
> a catch-22. So I tried to design & document the API to make it easy 
> for compiler developers to avoid inconsistencies (regression tests 
> also contribute to this effort).
>
> The key challenges as you might guess are:
>
>   * Ensuring warning detection logic is no longer skipped when a
>     category is suppressed if suppression is enabled (easy)
>   * Ensuring that anywhere a warning is detected but isn't reported
>     because the category is suppressed, the suppression is still
>     validated (harder)
>
> Summary of internal compiler changes:
>
>   * Lint now keeps track of the current symbol "in scope" - this is
>     whatever symbol was last used for Lint.augment(). Validations are
>     tracked against these symbols, or null for the global scope.
>   * A new singleton LintSuppression is responsible for maintaining
>     this tracking information on a per-symbol and per-category basis,
>     and generating warnings as needed when the time comes.
>   * A new method Lint.isActive() answers the question "Should I bother
>     doing some non-trivial calculation that might or might not
>     generate a warning?" It returns true if the category is enabled OR
>     if it's suppressed but subject to suppression tracking and the
>     current suppression in scope has not yet been validated. This is
>     entirely optional and usually not needed. An obvious example:
>     before invoking Check.checkSerialStructure().
>   * A new method Lint.validate() means "If this lint category is
>     currently suppressed, then validate that suppression". In other
>     words, you are saying that a warning would be generated here.
>   * A new method Lint.emit() simplifies the logic when a lint warning
>     is detected:
>       o If the category is enabled, it logs the message
>       o If the category is suppressed, it validates the suppression
>
> So code that looked like this:
>
> if (lint.isEnabled(LintCategory.FOO)) {
> log.warning(LintCategory.FOO, pos, SomeWarning(x, y));
> }
>
> can be simplified to this:
>
> lint.emit(log, LintCategory.FOO, pos, SomeWarning(x, y));
>
> A minor downside of that simplification is that the Warning object is 
> constructed even if the warning is suppressed. The upside is that 
> suppression validation happens automatically. Since warnings are 
> relatively rare, I felt this was a worthwhile trade-off, but it's not 
> forced on people - you can always do this instead:
>
> if (lint.validate(LintCategory.FOO).isEnabled(LintCategory.FOO)) {
> log.warning(LintCategory.FOO, pos, SomeWarning(x, y));
> }
>
> When we're ready to report on unnecessary suppressions in a file, we 
> scan the file for @SuppressWarnings (and @Deprecated) annotations, 
> then look at the validatations of the corresponding symbol 
> declarations, and do the "propagation" step where all the validations 
> bubble up. Any suppressions that aren't validated are then reported as 
> unnecessary. A similar thing happens at the global scope to generate 
> the suppression-option warnings, using validations that escape 
> individual source files, at the end of the overall compilation.
>
> There were two tricky refactorings: The overloads warning reports when 
> two methods are ambiguous when called with lambdas, but the warning 
> itself has the property that a @SuppressWarnings("overloads") 
> annotation on /either/ of two such methods suffices to suppress the 
> warning. So we have to be careful with the logic, e.g., if both 
> methods have the annotation, we don't want to randomly validate one of 
> them and then declare the other as unnecessary, etc. To avoid this, 
> both annotations are validated simultaneously.
>
> The other is the "this-escape" analyzer. When a constructor invokes 
> this() or a method, control flow jumps to that constructor or method; 
> when it executes super(), control flow jumps to all the field 
> initializers and non-static initializer blocks. This jumping around 
> conflicts with the AST tree-based scoping of @SuppressWarnings 
> annotations. We apply "fixups" so the suppression effect follows the 
> control flow, not the AST. This is how it already worked, but the code 
> had to be updated to validate properly.
>
> What about DeferredLintHandler and MandatoryWarningHandler? These were 
> not really an issue; all you need is a handle on the correct Lint 
> instance and one is always available.
>
> The prototype is available here: 
> https://github.com/archiecobbs/jdk/tree/suppression
>
> This prototype patch is a little unwieldy because it includes:
>
>   * Compiler changes to support the new lint categories (in the diff
>     starting with Lint.java)
>   * Removal of 400+ @SuppressWarnings annotations to continue to allow
>     the use of -Xlint:all everywhere (build logs
>     <https://github.com/archiecobbs/jdk/actions/runs/11728281642>)
>   * Several build-related cleanups, e.g., adding
>     -Xlint:-suppression-option to unbreak incremental builds
>   * Temporary build workaround for JDK-8340341
>
> I'm interested in any opinions and/or folks who have large bodies of 
> code or specific test cases they would like to run this on.
>
> Thanks,
> -Archie
> *
> *
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241109/ce547f13/attachment-0001.htm>

From archie.cobbs at gmail.com  Sun Nov 10 14:25:25 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 10 Nov 2024 08:25:25 -0600
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <6cc2414d-e030-4c8a-acb7-02badac3e19b@pobox.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <6cc2414d-e030-4c8a-acb7-02badac3e19b@pobox.com>
Message-ID: <CANSoFxvk=yuYKdGBGnCLwcaytoqtsYtvSiNBS+_PaL6my7Up2A@mail.gmail.com>

Hi Jon,

Thanks for the comments.

On Sat, Nov 9, 2024 at 5:29?PM Jonathan Gibbons <jjg3 at pobox.com> wrote:

> 1. The set of strings that are valid for @SuppressWarnings is undefined
> and open-ended. Yes, the JDK compiler `javac` defines a set of strings but
> there is no guarantee that code will only be compiled by `javac` and that
> there are no other strings in use. Some IDEs may also use the
> @SuppressWarnings mechanism.
>
Thanks - I should have made that point clear. This new functionality would
be limited to the actual warnings implemented by javac.

In other words, there must be a corresponding LintCategory enum value;
string values in @SuppressWarnings annotations that don't correspond to
actual javac warnings would be completely ignored/unaffected by this.

> JLS also says Compiler vendors are encouraged to document the strings
> they support for @SuppressWarnings, and to cooperate to ensure that the
> same strings are recognized across multiple compilers. so we should
> document this in such a way that other tools are encouraged to support the
> same string with the same semantics.
>
Yep, thanks. A basic Google search didn't reveal any examples of other
compilers having a similar option for the @SuppressWarnings annotation. If
you know of any, we should certainly try to be consistent.

> 3. I note that the JDK `javadoc` tool supports variations on
> `@SuppressWarnings("doclint"), corresponding to the `-Xdoclint` option
> supported by both `javac` and `javadoc`, although there has been informal
> discussions on dropping support from `javac`.  See here:
> https://docs.oracle.com/en/java/javase/23/docs/specs/man/javadoc.html#doclint
>
I've run across a few of these. For now they're being treated just like any
other unknown value - i.e., being ignored.

A reasonable future task would be to implement the analogous functionality
for Javadoc warnings but I haven't investigated that.

In any case it seems clear that this should be done as part of the javadoc
tool, not javac. The two "worlds" (i.e., javac vs. javadoc) should be
handled separately for this kind of analysis. In other words, I wouldn't
want my javac compiler warning me about unnecessary doclint:foo
suppressions, or vice-versa.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241110/6b7c7c1a/attachment.htm>

From liach at openjdk.org  Sun Nov 10 17:06:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Nov 2024 17:06:30 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v5]
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: <3LLsHC9azQPo4CbObJAMKk18NNSTjwjrObTKBt1UJac=.098b7ad2-0fca-47ea-b268-42a37c34417c@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 12 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Improve getRawType
 - Intro and other various improvements
 - 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
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b1a8df87...35abd93c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/83feba99..35abd93c

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

  Stats: 141342 lines in 1043 files changed: 110613 ins; 11443 del; 19286 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 maurizio.cimadamore at oracle.com  Mon Nov 11 11:32:12 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 11 Nov 2024 11:32:12 +0000
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
Message-ID: <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>

Hi Archie,
the idea is surely intriguing. Reminds me of teh way exception analysis 
work, but applied to Lint warnings :-)

Logistically, I'd like to air some concerns:

* There have been other requests to alter and/or enhance Lint warnings 
recently, and some changes in the area are likely unavoidable because of 
null-restricted types (Valhalla). One common request is to allow for 
"families" of logically-related warnings (so that, on the command line, 
I can decide at which level of granularity I want lint warnings to be 
enabled/disabled). Something like this has a non-trivial chance to 
interact with your proposal.

* Implementation-wise, I've always been unhappy about the way in which 
Lint warnings are so deeply integrated inside the core javac classes. 
Maybe for some of them (e.g. the file manager ones) not much can be 
done... but for most of them I do wonder whether they should all be done 
in a separate pass, after flow analysis is complete -- and I also wonder 
if this should be some kind of mechanism that should be open for 
extension (e.g. so that developers can define their own analyses). Of 
course, the more Lint warnings are a core part of javac, and the harder 
this is.

* Even if we never implement the proposal in full, I think there are 
useful bits and pieces in your email - such as consolidating the way in 
which lint warnings are reported. I believe these are good changes to 
make, and I'd like to perhaps consider them separately. It is likely 
that any improvement and consolidation in this area will make any 
subsequent change to the way in which lint warnings are reported easier 
to implement, so I support such changes and refactorings.

* On a similar note, it would perhaps be better to separate the javac 
changes required to enable the new analysis, from the JDK changes to 
remove redundant suppressions. In other similar cases where a new 
analysis has been added, we have been filing umbrella issues for the 
various JDK subcomponents:

https://bugs.openjdk.org/browse/JDK-8244681

Cheers
Maurizio

On 09/11/2024 22:50, Archie Cobbs wrote:
> *Overview*
>
> This is a proposal to add the ability for the compiler to detect and 
> report unnecessary warning suppressions.
>
> An "unnecessary warning suppression" is when one of the following happens:
>
>   * There is a @SuppressWarnings("foo")annotation, but if it hadn't
>     been there, no foo warning would have been generated within the
>     annotation's scope
>   * The compiler is passed -Xlint:-foo, but if it hadn't been, no foo
>     warning wouldhave been generated during the entire compilation
>
> *Motivation*
>
> @SuppressWarnings and -Xlint:-foo are blunt instruments. The latter is 
> maximally blunt: it covers the entire compilation. The former is 
> somewhat blunt, especially when the warning occurs at a specific 
> statement other than a variable declaration and so the annotation has 
> to annotate and cover the entire containing method.
>
> In practice @SuppressWarnings and -Xlint:-foo are also very sticky: 
> once they get added to a source file or a build process, they are 
> rarely removed, because that would require an audit to determine if 
> the original problem is now resolved (or the compiler behavior has 
> changed), which is tedious.
>
> Sometimes @SuppressWarnings annotations are never needed in the first 
> place: they're added to the code proactively as the code is written 
> because the developer thinks they /might/ be needed. In this 
> situation, the compiler provides the same feedback either way (i.e. 
> none), so this type of mistake is almost never caught.
>
> As code evolves over time, newly added bugs that warnings are designed 
> to catch can escape detection if they happen to appear within the 
> scope of a @SuppressWarnings or -Xlint:-foo flag. That problem can't 
> be solved completely, but it can be minimized by ensuring that all 
> @SuppressWarnings annotations and -Xlint:-foo flags that do exist are 
> actually serving some purpose.
>
> More generally, there is the natural and healthy need to "declutter", 
> and also the "peace of mind" factor: We want to know we're doing 
> everything we reasonably can to prevent bugs... and since the compiler 
> is the thing that generates the warnings in the first place, shouldn't 
> it also be able to detect and report when a warning is being 
> unnecessarily suppressed?
>
> *Caveats*
>
> There are real-world concerns with adding something like this. Lots of 
> people build with -Xlint:all. We don't want to constrict the compiler 
> so tightly that it becomes more frustrating than helpful for people 
> trying to build software in the real world. Warning behavior can 
> differ not only across JDK versions but also across operating systems, 
> so we don't want to force over-complexification of builds.
>
> There is a balance to strike; the functionality should be easy to disable.
>
> *Proposal*
>
> Add two new lint categories, as described by this --help-lint output:
>
> ? suppression ? ? ? ? ?Warn about @SuppressWarnings values that don't 
> actually suppress any warnings.
> suppression-option ? Warn about -Xlint:-key options that don't 
> actually suppress any warnings (requires "options").
>
> Notice that for suppression-option to work, you also have to enable 
> options (see below for discussion).
>
> The behavior in a nutshell:
>
>   * When warnable code is detected, the warning "bubbles up" until it
>     hits the first @SuppressWarning annotation in scope, or if none,
>     the -Xlint:-foo option (if any).
>   * If the warning doesn't hit anything and "escapes", the warning is
>     emitted (this is what happens today)
>   * Otherwise, the warning has hit a /suppression/ - either a
>     @SuppressWarning annotation or global -Xlint:-foo option - and so:
>       o It is suppressed (this is what happens today), and
>       o NEW: That suppression is marked as /validated/
>   * NEW: After processing each file, the suppression category warns
>     about @SuppressWarning annotations in that file containing
>     unvalidated categories
>   * NEW: After processing the entire compilation, the
>     suppression-option?category warns about unvalidated -Xlint:-foo
>     options.
>
> Here's an example using rawtypes to demonstrate the proposed behavior:
>
> @SuppressWarnings("rawtypes") // annotation #1
> public class Test {
>
> @SuppressWarnings("rawtypes") // annotation #2
> ??? public Iterable obj = null;??? // "rawtypes" warning here
> }
>
> For a rawtypes warning to be emitted, the following must be true:
>
>   * -Xlint:rawtypes must be enabled
>   * Annotation #1 and annotation #2 must both NOT be present
>
> This is the same logic that we already have.
>
> For a suppression warning to be emitted at outer annotation #1 the 
> following must be true:
>
>   * -Xlint:suppression must be enabled
>   * Annotation #1 AND annotation #2 must BOTH be present
>
> Note that in this case either annotation could be declared as the 
> "unnecessary" one, but when nested annotations suppress the same 
> warning, we will always assume that the innermost annotation is the 
> "real" one (it's the first to "catch" the warning as it bubbles up) 
> and any containing annotations are therefore the "unnecessary" ones.
>
> As a result, it would never be possible for a suppression warning to 
> be emitted at annotation #2.
>
> Also note that the category being suppressed does not itself need to 
> be enabled: the lint categories rawtypes and suppression warn about 
> two different things, and so they are enabled/disabled independently (*)
>
> (*) This might be debatable. One could argue that if rawtypes is not 
> enabled, then all activity related to the rawtypes warning should be 
> shut down, including determining whether there is any unnecessary 
> suppression of it. This would be a more conservative change, but it 
> would mean that only the warnings that are actually enabled could be 
> detected as unnecessarily suppressed, which is a less robust check. In 
> addition, it would mean that for any given lint category, only one of 
> the suppression or suppression-option categories could be applicable 
> at a time, which seems too limiting.
>
> For a suppression-option warning to be emitted for the above example, 
> the following must be true:
>
>   * -Xlint:options must be enabled
>   * -Xlint:suppression-option must be enabled
>   * -Xlint:-rawtypes must be specified (i.e., it must be actively
>     suppressed, not just disabled which is the default)
>   * At least one of annotation #1 or annotation #2 must be present
>
> The reason for requiring options is that the warning does in fact 
> relate to a command line option and so it seems appropriate that it be 
> included. In practice, options appears to be already in use as a 
> "catch-all" when building on multiple operating systems and/or JDK 
> versions, etc., so this will make for a cleaner upgrade path.
> *
> *
> *Gory Details
> *
>
> Some lint categories don't support @SuppressWarnings annotation 
> scoping, e.g, classfile, output-file-clash, path, and text-blocks (the 
> latter because it is calculated by the scanner before annotation 
> symbols are available). Putting them in a @SuppressWarnings annotation 
> is always useless (and will be reported as such). However, they are 
> still viable candidates for the suppression-option warning.
> *
> *
> Some lint categories will be omitted from "suppression tracking" 
> altogether:
>
>   * path
>   * options
>   * suppression
>   * suppression-option
>
> The path category is omitted because it is used too early in the 
> pipeline (before singletons are created).
>
> The options category is omitted because including it would be pointless:
>
>   * It doesn't support @SuppressWarnings, so suppressions doesn't apply
>   * If there's -Xlint:-options, then suppression-option is also disabled
>
> What about the self-referential nature of suppressing suppression 
> itself? Consider this example:
>
> @SuppressWarnings({ "rawtypes", "suppression" })
> public class Test { }
>
> There is no rawtypes warning in there, so the suppression of rawtypes 
> is indeed unnecessary and would normally result in a suppression 
> warning. But we also are suppressing the suppression warning itself, 
> so the end result is that no warning would be generated.
>
> OK what about this?
>
> @SuppressWarnings("suppression")
> public class Test { }
>
> If suppression were itself subject to suppression tracking, this 
> example would lead to a paradox. Instead, we exclude suppression 
> itself from suppression tracking. So that example would generate no 
> warning. Analogous logic applies to suppression-option - it doesn't 
> apply to itself.
>
> Note that @SuppressWarnings("suppression") is not totally useless, 
> because it can affect nested annotations:
>
> @SuppressWarnings("suppression") // this is NOT unnecessary
> public class Test {
>
> // Suppression of "rawtypes" is unnecessary - but that won't be reported
> @SuppressWarnings("rawtypes")
> public int x = 1;
> }
>
> Making suppression-option a separate warning from suppression seems a 
> reasonably obvious thing to do but there are also some subtle reasons 
> for doing that.
>
> First, any system that does incremental builds (like the JDK itself) 
> can have a problem if the suppression-option warning is applied to a 
> partial compilation, because what if the file(s) that generate the 
> warning being suppressed are not part of that particular build? Then 
> you would get a false positive. So incremental builds could disable 
> suppression-option? but still safely leave suppression enabled.
> *
> *
> Also, different versions of the JDK support different lint flags and 
> have different warning logic, so that warnings in some versions don't 
> occur in other versions. When the same source needs to be compiled 
> under multiple JDK versions, some -Xlint:-foo flags may be necessary 
> in some versions and useless in others. We want to ensure there's a 
> reasonably simple way to use the same command line flags when 
> compiling under different JDK versions without having to disable 
> suppression tracking altogether.
>
> Similarly,?for some warnings the operating system might affect whether 
> warnings are generated.
>
> *Prototype Status*
>
> What follows is probably TMI but I figured I'd include a full brain 
> dump while top of mind...
>
> I originally implemented this just to see how hard it would be and to 
> play around with the idea; it seems like the experiment has worked 
> fairly well.
>
> Of course the first thing I wanted to try was to run it on the JDK 
> itself. This revealed 400+ unnecessary @SuppressWarnings annotations 
> and 11 unnecessary -Xlint:foo flags detected. That showed that the 
> issue being addressed is not imaginary.
>
> Of course, because most of the JDK is built with -Xlint:all (or close 
> to it), that also meant tracking down and removing all of the 
> unnecessary suppressions; I had to semi-automate the process. A 
> side-effect of that effort is a series of separate PR's 
> <https://github.com/openjdk/jdk/pulls?q=author%3Aarchiecobbs+is%3Apr+%22Remove+unnecessary%22+in%3Atitle+> 
> to remove unnecessary @SuppressWarnings annotations and -Xlint:-foo 
> flags. Of course, those PR's can be evaluated independently from this 
> proposal.
>
> (You may wonder: How did all those useless suppressions get in there? 
> See this PR comment 
> <https://github.com/openjdk/jdk/pull/21853#issuecomment-2462566874>.)
>
> I played around with a couple of different API designs. The API design 
> is key to ensuring we avoid various annoying inconsistencies that can 
> easily occur; a worst case scenario is a foo warning that gets 
> reported somewhere, but then when you add the @SuppressWarnings("foo") 
> annotation to suppress it, the annotation is reported as unnecessary - 
> a catch-22. So I tried to design & document the API to make it easy 
> for compiler developers to avoid inconsistencies (regression tests 
> also contribute to this effort).
>
> The key challenges as you might guess are:
>
>   * Ensuring warning detection logic is no longer skipped when a
>     category is suppressed if suppression is enabled (easy)
>   * Ensuring that anywhere a warning is detected but isn't reported
>     because the category is suppressed, the suppression is still
>     validated (harder)
>
> Summary of internal compiler changes:
>
>   * Lint now keeps track of the current symbol "in scope" - this is
>     whatever symbol was last used for Lint.augment(). Validations are
>     tracked against these symbols, or null for the global scope.
>   * A new singleton LintSuppression is responsible for maintaining
>     this tracking information on a per-symbol and per-category basis,
>     and generating warnings as needed when the time comes.
>   * A new method Lint.isActive() answers the question "Should I bother
>     doing some non-trivial calculation that might or might not
>     generate a warning?" It returns true if the category is enabled OR
>     if it's suppressed but subject to suppression tracking and the
>     current suppression in scope has not yet been validated. This is
>     entirely optional and usually not needed. An obvious example:
>     before invoking Check.checkSerialStructure().
>   * A new method Lint.validate() means "If this lint category is
>     currently suppressed, then validate that suppression". In other
>     words, you are saying that a warning would be generated here.
>   * A new method Lint.emit() simplifies the logic when a lint warning
>     is detected:
>       o If the category is enabled, it logs the message
>       o If the category is suppressed, it validates the suppression
>
> So code that looked like this:
>
> if (lint.isEnabled(LintCategory.FOO)) {
> log.warning(LintCategory.FOO, pos, SomeWarning(x, y));
> }
>
> can be simplified to this:
>
> lint.emit(log, LintCategory.FOO, pos, SomeWarning(x, y));
>
> A minor downside of that simplification is that the Warning object is 
> constructed even if the warning is suppressed. The upside is that 
> suppression validation happens automatically. Since warnings are 
> relatively rare, I felt this was a worthwhile trade-off, but it's not 
> forced on people - you can always do this instead:
>
> if (lint.validate(LintCategory.FOO).isEnabled(LintCategory.FOO)) {
> log.warning(LintCategory.FOO, pos, SomeWarning(x, y));
> }
>
> When we're ready to report on unnecessary suppressions in a file, we 
> scan the file for @SuppressWarnings (and @Deprecated) annotations, 
> then look at the validatations of the corresponding symbol 
> declarations, and do the "propagation" step where all the validations 
> bubble up. Any suppressions that aren't validated are then reported as 
> unnecessary. A similar thing happens at the global scope to generate 
> the suppression-option warnings, using validations that escape 
> individual source files, at the end of the overall compilation.
>
> There were two tricky refactorings: The overloads warning reports when 
> two methods are ambiguous when called with lambdas, but the warning 
> itself has the property that a @SuppressWarnings("overloads") 
> annotation on /either/ of two such methods suffices to suppress the 
> warning. So we have to be careful with the logic, e.g., if both 
> methods have the annotation, we don't want to randomly validate one of 
> them and then declare the other as unnecessary, etc. To avoid this, 
> both annotations are validated simultaneously.
>
> The other is the "this-escape" analyzer. When a constructor invokes 
> this() or a method, control flow jumps to that constructor or method; 
> when it executes super(), control flow jumps to all the field 
> initializers and non-static initializer blocks. This jumping around 
> conflicts with the AST tree-based scoping of @SuppressWarnings 
> annotations. We apply "fixups" so the suppression effect follows the 
> control flow, not the AST. This is how it already worked, but the code 
> had to be updated to validate properly.
>
> What about DeferredLintHandler and MandatoryWarningHandler? These were 
> not really an issue; all you need is a handle on the correct Lint 
> instance and one is always available.
>
> The prototype is available here: 
> https://github.com/archiecobbs/jdk/tree/suppression
>
> This prototype patch is a little unwieldy because it includes:
>
>   * Compiler changes to support the new lint categories (in the diff
>     starting with Lint.java)
>   * Removal of 400+ @SuppressWarnings annotations to continue to allow
>     the use of -Xlint:all everywhere (build logs
>     <https://github.com/archiecobbs/jdk/actions/runs/11728281642>)
>   * Several build-related cleanups, e.g., adding
>     -Xlint:-suppression-option to unbreak incremental builds
>   * Temporary build workaround for JDK-8340341
>
> I'm interested in any opinions and/or folks who have large bodies of 
> code or specific test cases they would like to run this on.
>
> Thanks,
> -Archie
> *
> *
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241111/8705e573/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Mon Nov 11 11:42:10 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 11 Nov 2024 11:42:10 +0000
Subject: syntax of type pattern vs. local variable declaration
In-Reply-To: <eb8b9f24-688d-45df-a835-d63e8b4d423c@berlin.de>
References: <eb8b9f24-688d-45df-a835-d63e8b4d423c@berlin.de>
Message-ID: <d03ed008-b974-48bb-8e18-6aa5c67d36b5@oracle.com>

There is some complex disambiguation logic between constant expression 
and patterns when we see "case" in javac parser. The analysis recognizes 
certain tokens and uses them to disambiguate. I wouldn't be surprised if 
"." was missed.

Filed:
https://bugs.openjdk.org/browse/JDK-8343932

Thanks
Maurizio

On 01/11/2024 21:31, Stephan Herrmann wrote:
> We have this test case:
>
> -------------------
> abstract sealed class J<T1, T2> permits X.S, A {}
>
> final class A extends J<Integer, String> {}
>
> public class X<T> {
>
> ????final class S<U> extends J<T, U> {}
>
> ????int testExhaustive(J<Integer, String> ji) {
> ??????? return switch (ji) {
> ??????????? case A a -> 42;
> ??????????? case X<Integer>.S<String> e -> 4200;
> ??????? };
> ????}
> ????public static void main(String[] args) {
> ??????? X<Integer>.S<String> xs = null;
> ??????? System.out.println(new X<Integer>().testExhaustive(new 
> X<Integer>().new S<String>()));
> ????}
> }
> -------------------
>
> In comparing with javac we noticed that javac reports this error:
>
> X.java:12: error: illegal start of type
> ???? case X<Integer>.S<String> e -> 4200;
> ?????????????????????????????? ^
>
> The grammar states that the syntax for TypePattern is the same as 
> LocalVariableDeclaration. Now see that in main() a local variable with 
> the same shape is accepted by javac, so it should also accept the type 
> pattern, right?
>
> regards,
> Stephan

From archie.cobbs at gmail.com  Mon Nov 11 14:49:16 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 11 Nov 2024 08:49:16 -0600
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>
Message-ID: <CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com>

Hi Maurizio,

Thanks for the feedback.

On Mon, Nov 11, 2024 at 5:32?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> * There have been other requests to alter and/or enhance Lint warnings
> recently, and some changes in the area are likely unavoidable because of
> null-restricted types (Valhalla). One common request is to allow for
> "families" of logically-related warnings (so that, on the command line, I
> can decide at which level of granularity I want lint warnings to be
> enabled/disabled). Something like this has a non-trivial chance to interact
> with your proposal.
>
Grouping warnings into "families" is a nice idea. I suppose a lot depends
on whether it were implemented at the "parsing" layer or more deeply. In
other words, it would be easy to build a simple grouping concept based on
"grouping aliases" into Options.java, so you could say e.g.,
-Xlint:file-stuff instead of -Xlint:classfile,path,output-file-clash. This
wouldn't require changing any of the existing warning logic.

OTOH a deeper refactoring would replace the LintCategory enum with
something more complicated in a tree-like hierarchy.

Are there any concrete design thoughts on this yet?

* Implementation-wise, I've always been unhappy about the way in which Lint
> warnings are so deeply integrated inside the core javac classes. Maybe for
> some of them (e.g. the file manager ones) not much can be done... but for
> most of them I do wonder whether they should all be done in a separate
> pass, after flow analysis is complete -- and I also wonder if this should
> be some kind of mechanism that should be open for extension (e.g. so that
> developers can define their own analyses). Of course, the more Lint
> warnings are a core part of javac, and the harder this is.
>
The same thoughts occurred to me early in the process when trying to answer
the question, "Where do these new warnings get reported?" There's no
central obvious place to add new warning calculations.

As you can see my answer was to shoehorn it into Flow.java (after the flow
analysis) even though this has nothing to do with "flow analysis". This
was simply following the precedent established by ThisEscapeAnalyzer.java,
which faced the same question before. That's twice now so maybe that's a
hint we need a better answer :)

Dumb question: would adding a new compiler "step" be (roughly speaking) as
straightforward as adding CompileState.WARN and doing something like this?

-    generate(desugar(flow(attribute(x))));
+    generate(desugar(warn(flow(attribute(x)))));

As for consolidating all of the warning logic, I like that idea and the
potential ability to make warnings more pluggable. The refactoring would be
tedious but straightforward, at least for those warnings that simply
inspect the information already being gathered by the compiler.

Also, refactoring wouldn't need to be done all at once and could be done
over time, but new valhalla warnings would have a home available immediately
.

* Even if we never implement the proposal in full, I think there are useful
> bits and pieces in your email - such as consolidating the way in which lint
> warnings are reported. I believe these are good changes to make, and I'd
> like to perhaps consider them separately. It is likely that any improvement
> and consolidation in this area will make any subsequent change to the way
> in which lint warnings are reported easier to implement, so I support such
> changes and refactorings.


I assume you're referring to the lint.emit() method with built-in
suppression checking...  and there are some other general cleanups in
Lint.java that could be included as well.

I'll work on a separate patch containing the "non-controversial" cleanups.

* On a similar note, it would perhaps be better to separate the javac
> changes required to enable the new analysis, from the JDK changes to remove
> redundant suppressions. In other similar cases where a new analysis has
> been added, we have been filing umbrella issues for the various JDK
> subcomponents:
>
Yes, this initial patch is a giant blob that is for testing only and
obviously will need to be split up.

The various @SuppressWarnings cleanup clearly deserve an umbrella issue.

Should I create issues for the following? Let me know your thoughts:

   - Minor lint refactoring cleanups
   - Add a new warn() compiler step after flow analysis
      - ThisEscapeAnalyzer is a charter member
      - Refactor to move lint warnings into the warn() step (umbrella)
      - Add issues over time under this umbrella for migrating existing
      warnings
      - Depends on: Add new warn() step
   - Umbrella issue for the @SuppressWarnings cleanup
      - Existing cleanup issues go under here
      - Suppression warnings (this proposal)
      - Depends on: Add new warn() step
      - Depends on: Umbrella issue for the @SuppressWarnings cleanup
      - Depends on: Minor lint refactoring cleanups

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241111/28f59396/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Mon Nov 11 14:57:57 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 11 Nov 2024 14:57:57 +0000
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>
 <CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com>
Message-ID: <a06a4392-ebc1-4615-91c4-20ce396bb228@oracle.com>


>
> OTOH a deeper refactoring would replace the LintCategory enum with 
> something more complicated in a tree-like hierarchy.
>
> Are there any concrete design thoughts on this yet?
We have no concrete design on this yet. But this is influenced by making 
Lint more pluggable. E.g. perhaps the families will be reflected in some 
sealed hierarchy that will be part of the JDK, something that programs 
can reason about.
> Dumb question: would adding a new compiler "step" be (roughly 
> speaking) as straightforward as adding CompileState.WARN and 
> doingsomething like this?
>
> - generate(desugar(flow(attribute(x))));
> + generate(desugar(warn(flow(attribute(x)))));
>
> As for consolidating all of the warning logic, I like that idea and 
> the potential ability to make warnings more pluggable. The refactoring 
> would be tedious but straightforward, at least for those warnings that 
> simply inspect the information already being gatheredby the compiler.

I believe having a new step consolidating the various logic is a good 
way to approach this. I suspect that, when doing this exercise, we will 
find commonalities between the various Linters, and maybe some abstract 
class, with some entry point will be the start of a more pluggable way 
to think about these problems (maybe this API will initially be 
javac-only, but when mature enough we can re-consider).

We should also look at what others have done in this space - most 
notably ErrorProne.

>
>
> Should I create issues for the following? Let me know your thoughts:
>
>   * Minor lint refactoring cleanups
>   * Add a new warn() compiler step after flow analysis
>       o ThisEscapeAnalyzer is a charter member
>   * Refactor to move lint warnings into the warn() step (umbrella)
>       o Add issues over time under this umbrella for migrating
>         existing warnings
>       o Depends on: Add new warn() step
>   * Umbrella issue for the @SuppressWarnings cleanup
>       o Existing cleanup issues go under here
>   * Suppression warnings (this proposal)
>       o Depends on: Add new warn() step
>       o Depends on: Umbrella issue for the @SuppressWarnings cleanup
>       o Depends on: Minor lint refactoring cleanups
>
Yep. Not sure whether this proposal depends on the @SuppressWarnings 
cleanup: in principle you could also add the analysis and disable it 
when building the JDK, and let the various components to be updated at 
their pace.

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241111/c97eeec6/attachment.htm>

From alautiero at gmail.com  Mon Nov 11 16:30:19 2024
From: alautiero at gmail.com (Alessandro Autiero)
Date: Mon, 11 Nov 2024 17:30:19 +0100
Subject: Proposal: Allow annotations on module directives
Message-ID: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>

*Summary*
This proposal suggests allowing annotations on module directives in a
module-info, similar to how module declarations can currently be annotated.
This enhancement, while narrow in scope, would give developers more
flexibility when designing libraries deeply integrated with Java's built-in
module system. I have built a proof of concept on Github
<https://github.com/Auties00/jdk/tree/module_directives_annotations> which
is already fully working and completely backwards compatible. I still
haven't:

   1. Build automated integration tests
   2. Added support for the new ClassFile API <https://openjdk.org/jeps/457>


Before doing that though I wanted to collect some feedback on my
implementation, especially on:

   1. Whether this change makes sense to the maintainers
   2. The new bytecode instructions I introduced and whether better
   alternatives exist
   3. The uses() accessor in ModuleDescriptor

All changes I made are documented in the respective commits I made, but if
you have any questions please let me know.

*Bytecode*
My implementation introduces two new bytecode attributes:

   - ModuleDirectivesRuntimeInvisibleAnnotations
   - ModuleDirectivesRuntimeVisibleAnnotations

which both contain, for each type of module directive, the number of
directives that were annotated and for each directive that was annotated:

   1. The index of the directive relative to all the directives of the same
   type that are present in the module
   2. The number of annotations that were attached to the directive
   3. The metadata of the annotation in the standard format used in the
   bytecode

Before working on this implementation, I had never designed bytecode
instructions so my approach might be suboptimal, so if any better
alternatives exist, I'll implement the changes as soon as possible. Other
approaches I considered:

   - Using RuntimeInvisibleAnnotations and RuntimeVisibleAnnotations
   Module directives are stored in the Module attribute alongside the
   module name, flags and version, instead of in a specialized table like
   class fields or local variables. For this reason, they cannot declare their
   own attributes(nested attributes are not supported by the JVM).
   - Modifying the Module attribute to contain the annotations directly in
   the existing directives metadata
   While this approach doesn't require additional bytecode attributes, it
   breaks completely existing tooling that parses a module-info because of the
   same constraints explained for the previous approach.

In conclusion, while my proposed implementation is fully backwards
compatible, it introduces two new bytecode attributes.


*Public API changes*
All changes are backwards-compatible, but I've included some reasoning on
some design choices I made.
*javax.lang.model.element.ModuleElement$Directive*

   - Implement AnnotatedConstruct to support annotations during
   compile-time processing
   - Directive does not currently implement Element and cannot do so in the
   future as it already defines a method named getKind which clashes with
   Element's getKind because of their different return types(DirectiveKind and
   ElementKind respectively). Implementing Element would also require
   ElementVisitor to implement DirectiveVisitor. I don't think that it's
   necessary for Directive to implement Element as it wasn't intended to do so
   when Java 9 was introduced, so I see no reason or backwards-compatible way
   to do so.

*java.lang.module.ModuleDescriptor*

   - Added a new sealed common class named Directive that Exports,
   Requires, Opens, Uses and Provides extend. This class contains an
   annotations() accessor to allow callers to access annotations
   - Added a new Uses class that represents uses directives. This
   introduces a slight backwards compatibility issue as an accessor named
   uses() already exists in ModuleDescriptor and it returns a Set<String>
   instead of a Set<Uses>. For now I added an accessor named used() that
   returns a Set<Uses>, but usedServices could be a better name. I don't think
   that changing uses() to return Set<Uses> is an option as that would break
   backwards compatibility and having an odd-named accessor shouldn't be that
   much of an issue if we find a fitting name.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241111/7feb53fb/attachment-0001.htm>

From aivanov at openjdk.org  Mon Nov 11 17:43:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Nov 2024 17:43:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@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>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
 <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>
 <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@github.com>
Message-ID: <VilcXY4GAxFg7sMG9MUvtI6XuOGtJLr1uokZFIV1ipc=.1ad3e90d-fd00-49f4-9468-24651fa74cd5@github.com>

On Fri, 8 Nov 2024 21:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

>>> 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.
>> 
>> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>> 
>> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
>> 
>> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198
>
>> > 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.
>> 
>> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>> 
>> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
>> 
>> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198
> 
> I think I was just saying there appeared to be dead code in the test.

> > @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>
> I think I was just saying there appeared to be dead code in the test.

Hmm? `createPrivateValue` had been called from the `main` method, so it had been used in the test until it was removed in https://github.com/openjdk/jdk/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea

Since `MultiUIDefaults` is still used in `UIManager` and we're keeping the test, I'm for keeping a test for `createPrivateValue` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1837009964

From vklang at openjdk.org  Mon Nov 11 20:00:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Nov 2024 20:00:16 GMT
Subject: Integrated: 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: <Ng_UXdk-ROCyhjZ8Re--lZErpjzKSb7cAB14fcFuj3I=.d2e537d4-fc92-4c1f-ae5f-2e67635ff42d@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.

This pull request has now been integrated.

Changeset: ef0dc251
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef0dc2518e7636cc8a9ca580613ff5edeb4c19fd
Stats:     50 lines in 24 files changed: 0 ins; 19 del; 31 mod

8342707: Prepare Gatherers for graduation from Preview

Reviewed-by: alanb, liach

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

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

From asotona at openjdk.org  Tue Nov 12 12:04:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 12 Nov 2024 12:04:52 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v8]
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: <dAysFRhzl5k_OY54-VsCdMGAavFsoCYpmrXLPJJeaS4=.2b1021da-f853-49b6-97e3-1d88e41df373@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 10 commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - 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=07
  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 mullan at openjdk.org  Tue Nov 12 13:01:33 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 13:01:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@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 229 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=09
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 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 asotona at openjdk.org  Tue Nov 12 13:05:42 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 12 Nov 2024 13:05:42 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v7]
In-Reply-To: <doMm2Xlr7u8znabCBkNwAE7ildmYuQyCriNDZLwGZtc=.00a16391-f2a5-43c7-a56d-3158799f13ba@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@github.com>
 <doMm2Xlr7u8znabCBkNwAE7ildmYuQyCriNDZLwGZtc=.00a16391-f2a5-43c7-a56d-3158799f13ba@github.com>
Message-ID: <0mCmNTLH8wzdrq-q-p790HZXvCaD7gpQkveAfOeCsqk=.4a86b328-842f-4853-8966-e3837f079b9a@github.com>

On Mon, 21 Oct 2024 15:53:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> 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/cons...
>
> 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

VerifierImpl should be the best possible 1:1 transcription of the HotSpot verifier (for easy maintenance). I also have to suppress itching to rewrite it ;) Fortunately why would someone need to verify Object, Class, String or Throwable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1838065287

From liach at openjdk.org  Tue Nov 12 13:44:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Nov 2024 13:44:26 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v8]
In-Reply-To: <dAysFRhzl5k_OY54-VsCdMGAavFsoCYpmrXLPJJeaS4=.2b1021da-f853-49b6-97e3-1d88e41df373@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <dAysFRhzl5k_OY54-VsCdMGAavFsoCYpmrXLPJJeaS4=.2b1021da-f853-49b6-97e3-1d88e41df373@github.com>
Message-ID: <zE-a5zjlSVA2KDXFqL-_-k_Y5I_EnCXcZRIUZRZ4upA=.a5d62180-10ef-4099-8aa2-febc1443ef6b@github.com>

On Tue, 12 Nov 2024 12:04:52 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 10 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - 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/classfil...

The latest merge of PreviewFeature.java looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2429630362

From ron.pressler at oracle.com  Tue Nov 12 13:57:09 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 12 Nov 2024 13:57:09 +0000
Subject: Proposal: Allow annotations on module directives
In-Reply-To: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>
References: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>
Message-ID: <7DEEC905-2B7F-479E-8F5F-BF71CDE72CB6@oracle.com>

Before getting to any implementation issue, you haven?t explained what problem you?re trying to solve and why it?s a big-enough problem to merit solving. Getting to the bottom of that is usually the hardest (and longest) part of any feature.

? Ron

> On 11 Nov 2024, at 16:30, Alessandro Autiero <alautiero at gmail.com> wrote:
> 
> Summary
> This proposal suggests allowing annotations on module directives in a module-info, similar to how module declarations can currently be annotated. This enhancement, while narrow in scope, would give developers more flexibility when designing libraries deeply integrated with Java's built-in module system. I have built a proof of concept on Github which is already fully working and completely backwards compatible. I still haven't:
>     ? Build automated integration tests
>     ? Added support for the new ClassFile API 
> Before doing that though I wanted to collect some feedback on my implementation, especially on:
>     ? Whether this change makes sense to the maintainers
>     ? The new bytecode instructions I introduced and whether better alternatives exist
>     ? The uses() accessor in ModuleDescriptor
> All changes I made are documented in the respective commits I made, but if you have any questions please let me know.
> 
> Bytecode
> My implementation introduces two new bytecode attributes:
>     ? ModuleDirectivesRuntimeInvisibleAnnotations
>     ? ModuleDirectivesRuntimeVisibleAnnotations
> which both contain, for each type of module directive, the number of directives that were annotated and for each directive that was annotated:
>     ? The index of the directive relative to all the directives of the same type that are present in the module
>     ? The number of annotations that were attached to the directive
>     ? The metadata of the annotation in the standard format used in the bytecode
> 
> Before working on this implementation, I had never designed bytecode instructions so my approach might be suboptimal, so if any better alternatives exist, I'll implement the changes as soon as possible. Other approaches I considered:
>     ? Using RuntimeInvisibleAnnotations and RuntimeVisibleAnnotations 
> Module directives are stored in the Module attribute alongside the module name, flags and version, instead of in a specialized table like class fields or local variables. For this reason, they cannot declare their own attributes(nested attributes are not supported by the JVM). 
>     ? Modifying the Module attribute to contain the annotations directly in the existing directives metadata
> While this approach doesn't require additional bytecode attributes, it breaks completely existing tooling that parses a module-info because of the same constraints explained for the previous approach.
> In conclusion, while my proposed implementation is fully backwards compatible, it introduces two new bytecode attributes.
> 
> Public API changes
> All changes are backwards-compatible, but I've included some reasoning on some design choices I made.
> javax.lang.model.element.ModuleElement$Directive
>     ? 
> Implement AnnotatedConstruct to support annotations during compile-time processing
>     ? Directive does not currently implement Element and cannot do so in the future as it already defines a method named getKind which clashes with Element's getKind because of their different return types(DirectiveKind and ElementKind respectively). Implementing Element would also require ElementVisitor to implement DirectiveVisitor. I don't think that it's necessary for Directive to implement Element as it wasn't intended to do so when Java 9 was introduced, so I see no reason or backwards-compatible way to do so.
> 
> java.lang.module.ModuleDescriptor
>     ? 
> Added a new sealed common class named Directive that Exports, Requires, Opens, Uses and Provides extend. This class contains an annotations() accessor to allow callers to access annotations
>     ? Added a new Uses class that represents uses directives. This introduces a slight backwards compatibility issue as an accessor named uses() already exists in ModuleDescriptor and it returns a Set<String> instead of a Set<Uses>. For now I added an accessor named used() that returns a Set<Uses>, but usedServices could be a better name. I don't think that changing uses() to return Set<Uses> is an option as that would break backwards compatibility and having an odd-named accessor shouldn't be that much of an issue if we find a fitting name.
> 


From kevinw at openjdk.org  Tue Nov 12 14:18:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Nov 2024 14:18:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
Message-ID: <k5Fku2GFLG_4KD-l9l4gX4gnu8qrfvtTcWWNxvZQTus=.b710907b-e5a3-4516-bdbf-047a74a5eacd@github.com>

On Tue, 12 Nov 2024 13:01:33 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 229 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429727015

From rriggs at openjdk.org  Tue Nov 12 14:25:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 14:25:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
Message-ID: <T-riVwSNCriZvC4nhb9XDviF7n0SacK4KEJz3f8t2b0=.93469aae-25e3-4e33-9232-7b3337219821@github.com>

On Tue, 12 Nov 2024 13:01:33 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 229 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

Good to go!

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429741829

From mullan at openjdk.org  Tue Nov 12 14:44:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 14:44:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@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 230 commits:

 - Merge
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=10
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 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 kevinw at openjdk.org  Tue Nov 12 14:48:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Nov 2024 14:48:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <qw2I4_NVSBXQhXFeevleFvLgLEvPhUspdKzt2D4vSxo=.4251f226-49c6-450c-95f1-5bbd252554a2@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429813961

From rriggs at openjdk.org  Tue Nov 12 14:55:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 14:55:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <yAGTVrMWpR2BOpXL3-RivxcpB7UUrza89gERwz1BarA=.70d7df81-ea72-4379-848b-6438759d92a3@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429830332

From mullan at openjdk.org  Tue Nov 12 15:05:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:09 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
 <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>
Message-ID: <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@github.com>

On Fri, 8 Nov 2024 18:31:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).
>> 
>> Without the `@see` tag, one has to read the entire description to find the link.
>> 
>> It looks subtle. We can restore the `@see`-link later if deemed necessary.
>> 
>> Does anyone else have an opinion?
>
> I can add it back if it is more convenient and readable to have the `@see` tag.

This can be taken care of later after integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838260852

From mullan at openjdk.org  Tue Nov 12 15:05:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:14 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: <-KIDgN-bR6eT5GTOj2hiyz0oLJXR7Ewx1taEzXeaRsw=.3d2f141a-8183-4f70-af74-c06b47f29478@github.com>

On Thu, 24 Oct 2024 17:03: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
>
> 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?

This can be handled later in a more general cleanup task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838259103

From mullan at openjdk.org  Tue Nov 12 15:05:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:15 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@github.com>
Message-ID: <yml_wtm2Rsmw63hY1b6cxp1EvRCPyJFD7cVRxerdgb4=.6ef7f62e-7ce0-4661-9951-3445f851d94b@github.com>

On Fri, 1 Nov 2024 19:40:03 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 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
>
> test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1:
> 
>> 1: /*
> 
> I wonder if we should add an Oracle copyright to the update test file.

I don't think it is necessary for that small of a change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838256317

From vromero at openjdk.org  Tue Nov 12 15:13:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Nov 2024 15:13:41 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v4]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <ADVBMFnQnFL-nReDC1yheWqDvNudx-VioTinlWoFWoQ=.d32ccddc-1abe-46e0-912f-380c9c651625@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

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

 - Merge branch 'master' into JDK-8343286
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - 8343286: Redundant cast in polymorphic method call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/5bfcf8ef..f66ee79d

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

  Stats: 15056 lines in 470 files changed: 11106 ins; 2074 del; 1876 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

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

From rriggs at openjdk.org  Tue Nov 12 15:17:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 15:17:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <y18nI8ZKAB47qMMhqmhSOhr-kknoaDFEyLm2UHrcK7E=.07f02e84-b49e-485d-82c0-5f8ef3a78718@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429896801

From aivanov at openjdk.org  Tue Nov 12 15:17:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Nov 2024 15:17:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
 <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>
 <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@github.com>
Message-ID: <ZJ2gt2LT5Xcrgjc9gpjOIn87PHt9uFilNQKSplRKd3g=.7da1b1dc-c572-4a7a-a07c-460a38a1f637@github.com>

On Tue, 12 Nov 2024 15:02:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I can add it back if it is more convenient and readable to have the `@see` tag.
>
> This can be taken care of later after integration.

Agreed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838282210

From lancea at openjdk.org  Tue Nov 12 16:00:20 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 12 Nov 2024 16:00:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <T4XvpsK7Crm19k2etafDqv0D5yoZLmLgGNw9Xk2ogdg=.5af67060-a5a1-49a5-8014-4b808b810e4f@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Thank you for all of your hard work on this JEP Sean.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430018834

From coffeys at openjdk.org  Tue Nov 12 16:03:27 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 12 Nov 2024 16:03:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <S2BNzehI36J_Jflq6pI9AuDrfYsA8dTAeE3jCac-Bh8=.7baf781b-3caa-44cd-acb6-9f75055c353b@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430024985

From vromero at openjdk.org  Tue Nov 12 16:05:15 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Nov 2024 16:05:15 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v5]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <lZLWIP4VsWUu83ZmAovkduFOZO-Cwzg3G95Ract0A6s=.f030a5df-f7a7-4a05-a749-a351c1128697@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

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

  addressing CSR comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/f66ee79d..7fd18f47

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

  Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

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

From aivanov at openjdk.org  Tue Nov 12 16:11:19 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Nov 2024 16:11:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <y-mlQzl5xkWAglmNtQjN9AQH27dL2Lj1uviN_EQ5wTk=.29bd4e0c-560a-4b39-a743-9aefd78009a4@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430049235

From vromero at openjdk.org  Tue Nov 12 16:15:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Nov 2024 16:15:31 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v6]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <wGw56NfcZDgy2xiyV-UDq8B6SuyT3SbsHB93ebjida0=.1a2e9fca-62a2-4aa1-b32f-12507364e562@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

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

  adding regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/7fd18f47..a99c4547

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=04-05

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

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

From mullan at openjdk.org  Tue Nov 12 17:20:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 17:20:26 GMT
Subject: Integrated: 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: <Q0nD82TeeHNB3GUN883I9z2gNYRVerdm8O57BFweQMM=.43d95216-fd1d-4252-abb0-8eaec40efb61@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 pull request has now been integrated.

Changeset: db850905
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db85090553ab14a84c3ed0a2604dd56c5b6e6982
Stats:     68914 lines in 1889 files changed: 2475 ins; 62597 del; 3842 mod

8338411: Implement JEP 486: Permanently Disable the Security Manager

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Co-authored-by: Aleksei Efimov <aefimov at openjdk.org>
Co-authored-by: Brian Burkhalter <bpb at openjdk.org>
Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Co-authored-by: Harshitha Onkar <honkar at openjdk.org>
Co-authored-by: Joe Wang <joehw at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Justin Lu <jlu at openjdk.org>
Co-authored-by: Kevin Walls <kevinw at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Naoto Sato <naoto at openjdk.org>
Co-authored-by: Roger Riggs <rriggs at openjdk.org>
Co-authored-by: Brent Christian <bchristi at openjdk.org>
Co-authored-by: Stuart Marks <smarks at openjdk.org>
Co-authored-by: Ian Graves <igraves at openjdk.org>
Co-authored-by: Phil Race <prr at openjdk.org>
Co-authored-by: Erik Gahlin <egahlin at openjdk.org>
Co-authored-by: Jaikiran Pai <jpai at openjdk.org>
Reviewed-by: kevinw, aivanov, rriggs, lancea, coffeys, dfuchs, ihse, erikj, cjplummer, coleenp, naoto, mchung, prr, weijun, joehw, azvegint, psadhukhan, bchristi, sundar, attila

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

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

From alautiero at gmail.com  Tue Nov 12 18:47:54 2024
From: alautiero at gmail.com (Alessandro Autiero)
Date: Tue, 12 Nov 2024 19:47:54 +0100
Subject: [External] : Re: Proposal: Allow annotations on module directives
In-Reply-To: <4A476AE6-5721-48D4-B1BD-0B01CDE8635F@oracle.com>
References: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>
 <7DEEC905-2B7F-479E-8F5F-BF71CDE72CB6@oracle.com>
 <CAM0RScn2n-OSxTiCJ+YwokYBhNH+1gWfvAKKQh2WoK_hzW=jwQ@mail.gmail.com>
 <4A476AE6-5721-48D4-B1BD-0B01CDE8635F@oracle.com>
Message-ID: <CAM0RScnrbSB=yngtrb0zC+i+jdw_fiSuMmEKf5N1WSM6fEtMpQ@mail.gmail.com>

I've found a similar JEP which might help my case, JEP 120(Repeating
Annotations) <https://openjdk.org/jeps/120>: the aim of that JEP was to
allow developers to use multiple annotations of the same type on an
element, a limitation which was previously being addressed by developers by
using container annotations.
In the case of this hypothetical JEP, the aim is to allow developers to
annotate module directives instead of using the enclosing module definition
as a target for annotations that should actually belong to the single
directives.
I'd like to pinpoint a particular issue, but I'd argue that, as this is a
limitation of the language itself, it's impossible to find instances in the
ecosystem where this is an issue as the projects that would use this
feature can't exist yet.
Similarly, I see that in JEP 104(Type Annotations)
<https://openjdk.org/jeps/104> the Checker Framework existence is used as a
success metric, but that project could be built only after annotations
could be applied to types.
If I had to find a possible application of this JEP similar to the Checker
Framework for JEP 104, I'd say that a build system's dependency management
could be built only around the module-info instead of having a seperate
file like in the case of Maven or Gradle.
I could also research on public code platforms such as GitHub how often
annotations that target a module contain attributes that could/should be
delegated to a particular directive, assuming the sample size isn't too
large and that this data point isn't considered too subjective.
I've included this possibility as last as I don't see any indication that
any similar work was done for JEP 120, where the only claimed motivation

> Frequently-used idioms of programming with annotations in EE and elsewhere
> awkwardly use a container annotation just to simulate the ability to apply
> multiple annotations

seems to be purely anecdotal.


Il giorno mar 12 nov 2024 alle ore 16:59 Ron Pressler <
ron.pressler at oracle.com> ha scritto:

>
>
> > On 12 Nov 2024, at 15:25, Alessandro Autiero <alautiero at gmail.com>
> wrote:
> >
> >
> > I'd argue that it's not consistent to allow the members of
> TypeDeclarations to be annotated, while not doing the same for
> ModuleDeclaration's.
> > I won't argue that this is a large issue: most developers will never
> write an annotation processor, let alone one that walks through a module,
> but not being able to annotate the directives that define most of the
> metadata of a module is a major limitation to the annotation system in this
> scope.
> > I'll also mention the fact that in the javadocs at
> ModuleElement$DirectiveKind it's clearly stated that new module directives
> might be introduced in future versions, so supporting annotations might be
> a "nice to have" for that scenario, but this is purely hypothetical.
>
> I would suggest to first identify some actual problems that this would
> solve. I don?t think that an inconsistency *in itself* is enough to justify
> a feature.
>
> ? Ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241112/0161ca82/attachment.htm>

From alex.buckley at oracle.com  Tue Nov 12 19:01:18 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 12 Nov 2024 11:01:18 -0800
Subject: [External] : Re: Proposal: Allow annotations on module directives
In-Reply-To: <CAM0RScnrbSB=yngtrb0zC+i+jdw_fiSuMmEKf5N1WSM6fEtMpQ@mail.gmail.com>
References: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>
 <7DEEC905-2B7F-479E-8F5F-BF71CDE72CB6@oracle.com>
 <CAM0RScn2n-OSxTiCJ+YwokYBhNH+1gWfvAKKQh2WoK_hzW=jwQ@mail.gmail.com>
 <4A476AE6-5721-48D4-B1BD-0B01CDE8635F@oracle.com>
 <CAM0RScnrbSB=yngtrb0zC+i+jdw_fiSuMmEKf5N1WSM6fEtMpQ@mail.gmail.com>
Message-ID: <90c83597-6463-4bdd-b4e0-352cea3cb1ba@oracle.com>

On 11/12/2024 10:47 AM, Alessandro Autiero wrote:
> I've included this possibility as last as I don't see any indication 
> that any similar work was done for JEP 120, where the only claimed 
> motivation
> 
>     Frequently-used idioms of programming with annotations in EE and
>     elsewhere awkwardly use a container annotation just to simulate the
>     ability to apply multiple annotations
> 
> seems to be purely anecdotal.

The claim about needing awkward container annotations came directly from 
a Java EE spec lead. Here's an example:

https://docs.oracle.com/cd/E13222_01/wls/docs100/programming/annotate_dependency.html#wp1111955

I forget the other examples, but the use cases are easily found:

https://stackoverflow.com/questions/17000193/can-we-have-more-than-one-path-annotation-for-same-rest-method

https://stackoverflow.com/questions/2513031/how-to-use-multiple-requestmapping-annotations-in-spring?noredirect=1&lq=1

Alex


From alautiero at gmail.com  Tue Nov 12 19:28:37 2024
From: alautiero at gmail.com (Alessandro Autiero)
Date: Tue, 12 Nov 2024 20:28:37 +0100
Subject: [External] : Re: Proposal: Allow annotations on module directives
In-Reply-To: <90c83597-6463-4bdd-b4e0-352cea3cb1ba@oracle.com>
References: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>
 <7DEEC905-2B7F-479E-8F5F-BF71CDE72CB6@oracle.com>
 <CAM0RScn2n-OSxTiCJ+YwokYBhNH+1gWfvAKKQh2WoK_hzW=jwQ@mail.gmail.com>
 <4A476AE6-5721-48D4-B1BD-0B01CDE8635F@oracle.com>
 <CAM0RScnrbSB=yngtrb0zC+i+jdw_fiSuMmEKf5N1WSM6fEtMpQ@mail.gmail.com>
 <90c83597-6463-4bdd-b4e0-352cea3cb1ba@oracle.com>
Message-ID: <CAM0RSc=_5K-CZjSCH4KZ2GnX=DA+H51cftD19OHs9oQNW_fFjQ@mail.gmail.com>

Thanks for the insight.
Would collecting the data as I suggested in the previous message then be a
valuable data point in your opinion?
I can also think of trying to assess if maintainers of popular build tools
ever considered shipping a dialect that relied on module-info, but didn?t
do so as there wasn?t enough flexibility with the current annotations.
After all I?m aware that maven maintains a polyglot module which supports
other markup languages other than XML and scripting languages, so in my
opinion it?s not such a far fetched possibility.

On Tue, 12 Nov 2024 at 20:01, Alex Buckley <alex.buckley at oracle.com> wrote:

> On 11/12/2024 10:47 AM, Alessandro Autiero wrote:
> > I've included this possibility as last as I don't see any indication
> > that any similar work was done for JEP 120, where the only claimed
> > motivation
> >
> >     Frequently-used idioms of programming with annotations in EE and
> >     elsewhere awkwardly use a container annotation just to simulate the
> >     ability to apply multiple annotations
> >
> > seems to be purely anecdotal.
>
> The claim about needing awkward container annotations came directly from
> a Java EE spec lead. Here's an example:
>
>
> https://docs.oracle.com/cd/E13222_01/wls/docs100/programming/annotate_dependency.html#wp1111955
>
> I forget the other examples, but the use cases are easily found:
>
>
> https://stackoverflow.com/questions/17000193/can-we-have-more-than-one-path-annotation-for-same-rest-method
>
>
> https://stackoverflow.com/questions/2513031/how-to-use-multiple-requestmapping-annotations-in-spring?noredirect=1&lq=1
>
> Alex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241112/5e4dd67f/attachment-0001.htm>

From ron.pressler at oracle.com  Tue Nov 12 19:44:45 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 12 Nov 2024 19:44:45 +0000
Subject: [External] : Re: Proposal: Allow annotations on module directives
In-Reply-To: <CAM0RScnrbSB=yngtrb0zC+i+jdw_fiSuMmEKf5N1WSM6fEtMpQ@mail.gmail.com>
References: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>
 <7DEEC905-2B7F-479E-8F5F-BF71CDE72CB6@oracle.com>
 <CAM0RScn2n-OSxTiCJ+YwokYBhNH+1gWfvAKKQh2WoK_hzW=jwQ@mail.gmail.com>
 <4A476AE6-5721-48D4-B1BD-0B01CDE8635F@oracle.com>
 <CAM0RScnrbSB=yngtrb0zC+i+jdw_fiSuMmEKf5N1WSM6fEtMpQ@mail.gmail.com>
Message-ID: <47C688E1-8086-4D77-B1E7-A997E5F8D8A2@oracle.com>



> On 12 Nov 2024, at 18:47, Alessandro Autiero <alautiero at gmail.com> wrote:
> 
> I'd like to pinpoint a particular issue, but I'd argue that, as this is a limitation of the language itself, it's impossible to find instances in the ecosystem where this is an issue as the projects that would use this feature can't exist yet.

That it?s not always easy to articulate the justification for a feature that doesn?t yet exist is why this work is often the hardest and longest part of any feature. It?s not even enough to describe how a feature could be used. We need to establish why it would be significantly superior to alternatives.

I?m not saying there's no substantial benefit to the feature you?re proposing, but identifying the right motivation is the core of the contribution. That?s the work. The implementation is secondary. 

> I've included this possibility as last as I don't see any indication that any similar work was done for JEP 120, where the only claimed motivation
> Frequently-used idioms of programming with annotations in EE and elsewhere awkwardly use a container annotation just to simulate the ability to apply multiple annotationsseems to be purely anecdotal. 

Both JEPs 104 and 120 were, indeed, written before we started requiring a more detailed Motivation section, but as Alex points out, the motivation was established (outside the JEP text) before the features were accepted.

? Ron

From alex.buckley at oracle.com  Tue Nov 12 20:25:55 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 12 Nov 2024 12:25:55 -0800
Subject: [External] : Re: Proposal: Allow annotations on module directives
In-Reply-To: <CAM0RSc=_5K-CZjSCH4KZ2GnX=DA+H51cftD19OHs9oQNW_fFjQ@mail.gmail.com>
References: <CAM0RSc=zwWLj6LjTjMgBPe2J+n7bQ166cyvo1TA9cM0CZ5NBVw@mail.gmail.com>
 <7DEEC905-2B7F-479E-8F5F-BF71CDE72CB6@oracle.com>
 <CAM0RScn2n-OSxTiCJ+YwokYBhNH+1gWfvAKKQh2WoK_hzW=jwQ@mail.gmail.com>
 <4A476AE6-5721-48D4-B1BD-0B01CDE8635F@oracle.com>
 <CAM0RScnrbSB=yngtrb0zC+i+jdw_fiSuMmEKf5N1WSM6fEtMpQ@mail.gmail.com>
 <90c83597-6463-4bdd-b4e0-352cea3cb1ba@oracle.com>
 <CAM0RSc=_5K-CZjSCH4KZ2GnX=DA+H51cftD19OHs9oQNW_fFjQ@mail.gmail.com>
Message-ID: <191f7c98-9f93-4c66-b3fc-4b85b6490a53@oracle.com>

On 11/12/2024 11:28 AM, Alessandro Autiero wrote:
> Would collecting the data as I suggested in the previous message then be 
> a valuable data point in your opinion?
> I can also think of trying to assess if maintainers of popular build 
> tools ever considered shipping a dialect that relied on module-info, but 
> didn?t do so as there wasn?t enough flexibility with the current 
> annotations.

Yes, it would be interesting to know the incidence of annotations on 
module declarations.

As for Maven/Gradle, there was substantial outreach to their maintainers 
in the JDK 9 era. The Maven lead wrote about module declarations at the 
time: 
https://www.sitepoint.com/maven-cannot-generate-module-declaration/  As 
a result, it seems pretty complicated to use Maven and Java modules 
today: https://www.baeldung.com/maven-multi-module-project-java-jpms 
Maybe you can convince the Maven maintainers that more annotations are 
what they need, I don't know.

Alex

From acobbs at openjdk.org  Wed Nov 13 02:45:34 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Nov 2024 02:45:34 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related code
Message-ID: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>

Please review these changes with some minor lint-related fixes and cleanups.

See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.

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

Commit messages:
 - Fix typo in comment.
 - Minor lint-related cleanups.

Changes: https://git.openjdk.org/jdk/pull/22056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344079
  Stats: 273 lines in 8 files changed: 137 ins; 85 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/22056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22056/head:pull/22056

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

From jlahoda at openjdk.org  Wed Nov 13 12:33:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Nov 2024 12:33:16 GMT
Subject: RFR: 8335989: JEP 494: Implement Module Import Declarations
 (Second Preview) [v7]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <4ybB5B_AJXd-L8tGumK4LJz4oil4sLOO9xXtpO3eMK8=.3c6fe57d-1f1b-45d0-aae7-fd1ccb5773d1@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 21 commits:

 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Moving operators to the beginning of line, as suggested.
 - Updating PreviewFeature metadata
 - Cleanup.
 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - ... and 11 more: https://git.openjdk.org/jdk/compare/79345bbb...babcfccf

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

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=06
  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 prappo at openjdk.org  Wed Nov 13 13:20:00 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 13 Nov 2024 13:20:00 GMT
Subject: RFR: 8341907: javac -Xlint should ignore /// on first line of
 source file [v4]
In-Reply-To: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
Message-ID: <DTzy23CSXnjbGC-Sb-kFD8HjrlZF7C3iohPIorL8OB0=.45aeb8e6-3686-4deb-9f1e-0c1b0d231b92@github.com>

> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
> 
> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
> 
> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
> 
> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
> 
> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html

Pavel Rappo 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:

 - Merge branch 'master' into 8341907
 - Fix a pre-existing doc typo
 - Make the check more specific
 - Address copyright issues
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21923/files
  - new: https://git.openjdk.org/jdk/pull/21923/files/65ba8dca..e57eb6e7

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

  Stats: 98358 lines in 2729 files changed: 22126 ins; 68748 del; 7484 mod
  Patch: https://git.openjdk.org/jdk/pull/21923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21923/head:pull/21923

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

From mcimadamore at openjdk.org  Wed Nov 13 15:22:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 15:22:20 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v6]
In-Reply-To: <wGw56NfcZDgy2xiyV-UDq8B6SuyT3SbsHB93ebjida0=.1a2e9fca-62a2-4aa1-b32f-12507364e562@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <wGw56NfcZDgy2xiyV-UDq8B6SuyT3SbsHB93ebjida0=.1a2e9fca-62a2-4aa1-b32f-12507364e562@github.com>
Message-ID: <ax1mtXG6Sv3MIF7RwJY-Zpj4aWOUHIQAErNVCI2yEOI=.5ccb0364-d6fd-4683-b7f9-292e418d7139@github.com>

On Tue, 12 Nov 2024 16:15:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is not issuing a mandated unchecked cast warning for code like:
>> 
>> 
>> import java.lang.invoke.VarHandle;
>> 
>> class VarHandleCast<V> {
>>      VarHandle vh;
>>      V method(Object obj) {
>>          return (V)vh.getAndSet(this, obj);
>>      }
>> }
>> 
>> 
>> according to the spec the return type inferred for this method polymorphic method should be Object see:
>> 
>> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
>> ...
>>     ? The compile-time result is determined as follows:
>>         Otherwise, 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).
>> 
>> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
>> 
>> TIA
>> 
>> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding regression test

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

> 264:         MODULE_IMPORTS(JDK23, Fragments.FeatureModuleImports, DiagKind.PLURAL),
> 265:         PRIVATE_MEMBERS_IN_PERMITS_CLAUSE(JDK19),
> 266:         COMPILE_TIME_TYPE_SIG_POLYMORPHIC_MTH(JDK24),

Nit: I'd pick a name that is more representative of what the behavior is. E.g. `erase_poly_sig_return_type`. Same for the field in `Infer` storing the boolean flag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21914#discussion_r1840566249

From vromero at openjdk.org  Wed Nov 13 15:35:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Nov 2024 15:35:30 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v7]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <A3CuI2UqyYDYGe2J55I9vIm5SGoTyaTEWVykqK6bv2E=.708273e9-96db-40be-94ad-6c5a696f2e69@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

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

  address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/a99c4547..36011fa7

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

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

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

From mcimadamore at openjdk.org  Wed Nov 13 15:35:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 15:35:30 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v7]
In-Reply-To: <A3CuI2UqyYDYGe2J55I9vIm5SGoTyaTEWVykqK6bv2E=.708273e9-96db-40be-94ad-6c5a696f2e69@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <A3CuI2UqyYDYGe2J55I9vIm5SGoTyaTEWVykqK6bv2E=.708273e9-96db-40be-94ad-6c5a696f2e69@github.com>
Message-ID: <8EUvDlccN0eNRa4qj-i32rQRnDraTCOR2_fLkQUBLFc=.67d3ff9f-b7dc-4c9d-83b8-6ced8c707e2a@github.com>

On Wed, 13 Nov 2024 15:31:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is not issuing a mandated unchecked cast warning for code like:
>> 
>> 
>> import java.lang.invoke.VarHandle;
>> 
>> class VarHandleCast<V> {
>>      VarHandle vh;
>>      V method(Object obj) {
>>          return (V)vh.getAndSet(this, obj);
>>      }
>> }
>> 
>> 
>> according to the spec the return type inferred for this method polymorphic method should be Object see:
>> 
>> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
>> ...
>>     ? The compile-time result is determined as follows:
>>         Otherwise, 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).
>> 
>> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
>> 
>> TIA
>> 
>> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21914#pullrequestreview-2433605574

From vromero at openjdk.org  Wed Nov 13 15:35:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Nov 2024 15:35:30 GMT
Subject: Integrated: 8343286: Missing unchecked cast warning in polymorphic
 method call
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <Fqx0NIJJkeQHLnYesAgdBrxmS8W4C8Tgt-Dk2KbwytU=.36fcc7c3-123f-4754-9675-360a31e5c029@github.com>

On Tue, 5 Nov 2024 19:51:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, 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).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

This pull request has now been integrated.

Changeset: cc2acd14
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc2acd14b13ada243fc13dc4d9007c4e2df56148
Stats:     40 lines in 10 files changed: 38 ins; 0 del; 2 mod

8343286: Missing unchecked cast warning in polymorphic method call

Reviewed-by: mcimadamore

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

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

From acobbs at openjdk.org  Wed Nov 13 16:04:33 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Nov 2024 16:04:33 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v4]
In-Reply-To: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
Message-ID: <uKDghixcKWjD-r8cCc8ndmxEsDp1BrLPsxiTcM5E9vg=.10ad0434-361d-4f2a-b3aa-dd4ba3b49a34@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Apply change that was missed somehow.
 - Undo change that will be moved to the core-libs branch.
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21851/files
  - new: https://git.openjdk.org/jdk/pull/21851/files/d955b538..8b95d372

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

  Stats: 95175 lines in 2626 files changed: 19948 ins; 68244 del; 6983 mod
  Patch: https://git.openjdk.org/jdk/pull/21851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21851/head:pull/21851

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

From acobbs at openjdk.org  Wed Nov 13 16:32:26 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Nov 2024 16:32:26 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v5]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <iqCXfJ4MwX4AbwXNhpEN6_aMMcaSdeEDB4Ag3xR8LNY=.1343bace-e197-4625-a5c5-bb5e2c7f1ce4@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update copyright years.
 - Remove a few more @SuppressWarnings annotations.
 - Remove a few more @SuppressWarnings annotations.
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=04
  Stats: 187 lines in 94 files changed: 0 ins; 95 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From acobbs at openjdk.org  Wed Nov 13 18:06:50 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Nov 2024 18:06:50 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v6]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <NOQPsQeegsOHLymZgFafYENdx8ZCVcECa6a_mSHvGRY=.746f8151-34fa-48e7-91d9-b614f9bd2d65@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

  Remove more unnecessary warning suppressions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/300c0f98..378ca601

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=04-05

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

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

From jjg at openjdk.org  Wed Nov 13 18:11:11 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 13 Nov 2024 18:11:11 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <poXB1Eqc6-PMAJbrqpAf9c5t3wzhkFIRJz_r356snx0=.ff1deb7a-1842-4909-87cf-a6e205ab3187@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Without looking in detail at the changes, this is indeed a welcome and long-overdue change!

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474339519

From ihse at openjdk.org  Wed Nov 13 18:11:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Nov 2024 18:11:11 GMT
Subject: RFR: 8344056: Use markdown format for man pages
Message-ID: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>

Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.

Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.

This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

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

Commit messages:
 - Replace tabs with spaces
 - Remove logic for copying .1 man pages
 - Insert GPL header
 - Add missing Windows man pages for kerberos and accessibility
 - Replace generated troff man pages with markdown version

Changes: https://git.openjdk.org/jdk/pull/22081/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344056
  Stats: 41443 lines in 65 files changed: 18943 ins; 22500 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081

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

From kevinw at openjdk.org  Wed Nov 13 20:21:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 13 Nov 2024 20:21:08 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <Ii7cVmWIyFLR4Q5q7TAl2NENV2_ixQJAGYEqdbdzkCc=.1bec7144-ad3e-4818-98f8-643daadba001@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

I think this means the one-true-master copy of a man page is now the public .md file.
All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes.
(Which is great, I just didn't see it being explicitly said.)

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474701337

From vromero at openjdk.org  Wed Nov 13 20:43:44 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Nov 2024 20:43:44 GMT
Subject: RFR: 8335989: Implement JEP 494: Module Import Declarations
 (Second Preview) [v7]
In-Reply-To: <4ybB5B_AJXd-L8tGumK4LJz4oil4sLOO9xXtpO3eMK8=.3c6fe57d-1f1b-45d0-aae7-fd1ccb5773d1@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <4ybB5B_AJXd-L8tGumK4LJz4oil4sLOO9xXtpO3eMK8=.3c6fe57d-1f1b-45d0-aae7-fd1ccb5773d1@github.com>
Message-ID: <U4b-12wHJ0rQERBY8emTn-go1YXcWB7YbVXcgm6xd7I=.f5a9abb1-7df2-4f16-96c1-d3db79d7ee34@github.com>

On Wed, 13 Nov 2024 12:33:16 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 21 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Merge branch 'master' into JDK-8335989
>  - Moving operators to the beginning of line, as suggested.
>  - Updating PreviewFeature metadata
>  - Cleanup.
>  - Merge branch 'master' into JDK-8335989
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/79345bbb...babcfccf

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2434370098

From cstein at openjdk.org  Wed Nov 13 20:56:51 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 13 Nov 2024 20:56:51 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <PHyC5A7Ex4Q-AenCRUvAu_Jov2pnSGiIiCmmsfcRg44=.19e00289-a896-48a7-8ea8-05f63ed0b3e8@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

So glad to see progress here!

https://github.com/openjdk/jdk/blob/1484153c1a092cefc20270b35aa1e508280843a4/test/langtools/jdk/javadoc/tool/CheckManPageOptions.java#L141

should read `return findRootDir().resolve("src/jdk.javadoc/share/man/javadoc.md");` now.

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474760888

From jjg at openjdk.org  Wed Nov 13 21:21:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 13 Nov 2024 21:21:32 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <Ii7cVmWIyFLR4Q5q7TAl2NENV2_ixQJAGYEqdbdzkCc=.1bec7144-ad3e-4818-98f8-643daadba001@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <Ii7cVmWIyFLR4Q5q7TAl2NENV2_ixQJAGYEqdbdzkCc=.1bec7144-ad3e-4818-98f8-643daadba001@github.com>
Message-ID: <hs9l_aVDMpskTmhf_ovJv8cHP9FepHgxV3UCdxSe7DE=.230ad939-6314-4add-a921-7dea6249c191@github.com>

On Wed, 13 Nov 2024 20:17:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I think this means the one-true-master copy of a man page is now the public .md file. All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes. (Which is great, I just didn't see it being explicitly said.)

Yes, related: 
Non-trivial updates to these pages should be approved in a CSR, maybe along with any code changes that may make such an update necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474804913

From dholmes at openjdk.org  Wed Nov 13 21:35:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Nov 2024 21:35:39 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Great to finally see this happen!

Just one glitch with the GPL headers.

Thanks

src/java.base/share/man/java.md line 9:

> 7: # published by the Free Software Foundation.  Oracle designates this
> 8: # particular file as subject to the "Classpath" exception as provided
> 9: # by Oracle in the LICENSE file that accompanied this code.

Documentation files should not have the Classpath exception.

make/data/license-templates/gpl-header

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434474132
PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841189067

From cstein at openjdk.org  Wed Nov 13 21:35:40 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 13 Nov 2024 21:35:40 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <XOo88TaSl5QEwAEJISAsUq0BYBtieHSYSBQHovdgdEU=.9894ac56-793f-4ec1-901b-eb476eec2a51@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

A missing `.1` to `.md` file extension change in `javadoc`'s manpage self-test `CheckManPageOptions.java` is causing the CI to fail.

Details in https://github.com/openjdk/jdk/pull/22081#issuecomment-2474760888

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

Changes requested by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434491865

From iris at openjdk.org  Wed Nov 13 21:59:34 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 13 Nov 2024 21:59:34 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>
Message-ID: <QyBh2MR7GEWc2oQ3NimEgV8rHcbvbLEoOK_vAwVaMjo=.2fc260cc-25c2-47fd-8bc1-57d0f45e7d62@github.com>

On Wed, 13 Nov 2024 21:27:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> src/java.base/share/man/java.md line 9:
> 
>> 7: # published by the Free Software Foundation.  Oracle designates this
>> 8: # particular file as subject to the "Classpath" exception as provided
>> 9: # by Oracle in the LICENSE file that accompanied this code.
> 
> Documentation files should not have the Classpath exception.
> 
> make/data/license-templates/gpl-header

Agree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841231909

From archie.cobbs at gmail.com  Thu Nov 14 02:57:38 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 13 Nov 2024 20:57:38 -0600
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <a06a4392-ebc1-4615-91c4-20ce396bb228@oracle.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>
 <CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com>
 <a06a4392-ebc1-4615-91c4-20ce396bb228@oracle.com>
Message-ID: <CANSoFxtCCkiG1-vH_3bjSpH-bhCQKrEVJZ4zNTcG=WL=sKNMug@mail.gmail.com>

On Mon, Nov 11, 2024 at 8:58?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Should I create issues for the following? Let me know your thoughts:
>
>    - Minor lint refactoring cleanups
>    - Add a new warn() compiler step after flow analysis
>       - ThisEscapeAnalyzer is a charter member
>       - Refactor to move lint warnings into the warn() step (umbrella)
>       - Add issues over time under this umbrella for migrating existing
>       warnings
>       - Depends on: Add new warn() step
>    - Umbrella issue for the @SuppressWarnings cleanup
>       - Existing cleanup issues go under here
>       - Suppression warnings (this proposal)
>       - Depends on: Add new warn() step
>       - Depends on: Umbrella issue for the @SuppressWarnings cleanup
>       - Depends on: Minor lint refactoring cleanups
>
> Yep. Not sure whether this proposal depends on the @SuppressWarnings
> cleanup: in principle you could also add the analysis and disable it when
> building the JDK, and let the various components to be updated at their
> pace.
>
Thanks. Here are the issues I've created...

Minor lint refactoring cleanups


JDK-8344079: Minor fixes and cleanups to compiler lint-related code

Add a new warn() compiler step after flow analysis


JDK-8344148: Add an explicit compiler phase for warning generation

Refactor to move lint warnings into the warn() step (umbrella)


I figured this one can come later.

 Umbrella issue for the @SuppressWarnings cleanup


JDK-8344076: Remove unnecessary @SuppressWarnings annotations and
Xlint:-foo options (umbrella)

Suppression warnings (this proposal)


JDK-8344159: Add lint warnings for unnecessary warning suppression

There are also PR's for the first two.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241113/f62466a7/attachment-0001.htm>

From acobbs at openjdk.org  Thu Nov 14 02:58:57 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 02:58:57 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
Message-ID: <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>

> Please review these changes with some minor lint-related fixes and cleanups.
> 
> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.

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

 - Merge branch 'master' into JDK-8344079
 - Fix typo in comment.
 - Minor lint-related cleanups.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22056/files
  - new: https://git.openjdk.org/jdk/pull/22056/files/de60c11c..8b961d48

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

  Stats: 95175 lines in 2626 files changed: 19948 ins; 68244 del; 6983 mod
  Patch: https://git.openjdk.org/jdk/pull/22056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22056/head:pull/22056

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

From acobbs at openjdk.org  Thu Nov 14 03:05:30 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 03:05:30 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning generation
Message-ID: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>

Please review which does some minor refactoring to the compiler:
* Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
* Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
* Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
* Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes

See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

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

Commit messages:
 - Update copyright years.
 - Add an explicit compiler phase for warning generation.

Changes: https://git.openjdk.org/jdk/pull/22088/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344148
  Stats: 218 lines in 19 files changed: 190 ins; 2 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/22088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22088/head:pull/22088

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

From jlahoda at openjdk.org  Thu Nov 14 06:16:56 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Nov 2024 06:16:56 GMT
Subject: Integrated: 8335989: Implement JEP 494: 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: <JkE9oXRZo6VVxhbGIy4P3kTDms8cCjAy1S0JECbmyjw=.4b342b90-e065-4d6c-ae92-cb6dfdf16f3b@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

This pull request has now been integrated.

Changeset: 1e97c1c9
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e97c1c913220b07ff0c1c977cea80bc9436729d
Stats:     762 lines in 28 files changed: 580 ins; 46 del; 136 mod

8335989: Implement JEP 494: Module Import Declarations (Second Preview)

Reviewed-by: vromero, abimpoudis, mcimadamore, alanb

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

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

From dfuchs at openjdk.org  Thu Nov 14 09:05:42 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 14 Nov 2024 09:05:42 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <AycUeSLX9L93ofeVSrDSkhF7_vgwwoT0_h8_Hq_4qko=.03fef401-4f94-41bf-82c7-1b50d35e2ee0@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

The jwebserver.md looks OK to me.

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

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2435435938

From mcimadamore at openjdk.org  Thu Nov 14 10:55:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 10:55:18 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <kQ9FSf8ue-rOgg54FfP2cAtlqe-E1Y_SJMG4NdXZiqI=.ef7cf1b3-7ec4-4d3a-a303-9b7a526a9d71@github.com>

On Wed, 13 Nov 2024 22:25:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which does some minor refactoring to the compiler:
> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
> 
> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

Note that javac has another way to perform analysis on code -- that's the `Analyzer` class. I've added that class a while ago, in an attempt to consolidate various "finders" that were scattered across the compiler code base. What is a "finder" ? Well, it's a piece of analysis that takes a piece of existing code, rewrites it in a certain way, and then see if the result preserve some properties of the original tree. Example:

* original tree: `new HashMap<String, Integer>`
* rewritten tree: `new HashMap<>`
* property to preserve: is the type of the `JCNewTree` AST node preserved by the transformation?

While we have been able to move the finders elsewhere and consolidate some of the logic, there is still some coupling between `Attr` and the `Analyzer` class that I'm not too proud if: namely, `Attr` has to "register" trees with `Analizer`, so that these trees can be queued up for further inspection.

If we are to have a dedicated pass for all kind of "pluggable" analyses, then it seems to me that a "finder" is just a special kind of analysis that is carried out - whereas a "linter" is another kind. Both need to process the attributed tree in some way, the difference is only in what they end up producing (a finder results in simplification suggestions, whereas a linter will typically result in new warnings).

Even though the code in `Analyzer` is a bit arcane, I think it highlight a potential scalability issue that we need to be aware of with the new `Warn` step: as the number of linters that go through the new step grows, we are faced with a dilemma: we could fold all the various linter analyses in a single tree scanner -- or we could have oen tree scanner per linter (or somewhere in between). The first is more efficient, but leads to code nightmare (evidence: look at `Lower`). The latter is cleaner to read (each scanner does something different, and we can compose them), but less efficient (the tree need to be scanned N times where N is the number of enabled linters -- for code running with `Xlint:all` that number is rather high).

So, I believe that whatever we do in this area needs to be able to solve this fundamental tension between scalability and maintainability. `Analyzer` went there full blazing with a convoluted mechanism where trees are put in a queue if any of the analyzers is interested -- then each analyzer works off the queue w/o having to process stuff it's not interested in. This was made possible by the simplifying assumption that each "finder" was only interested in a single JCTree kind (which might be too simplistic). Maybe all this complexity is not required, and having one pass per linter will work just fine (and lead to better code than the one in `Analyzer`). But either way, we should explore this space consciously, compare alternatives, assess performance, etc. before we come up with a proposal on how to rearchitect linters.

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2476024242

From ihse at openjdk.org  Thu Nov 14 11:11:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 11:11:54 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Fix CheckManPageOptions test
 - Remove classpath exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22081/files
  - new: https://git.openjdk.org/jdk/pull/22081/files/ffb41ba0..a8d4ea50

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

  Stats: 106 lines in 36 files changed: 0 ins; 70 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/22081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081

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

From ihse at openjdk.org  Thu Nov 14 11:12:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 11:12:52 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <QyBh2MR7GEWc2oQ3NimEgV8rHcbvbLEoOK_vAwVaMjo=.2fc260cc-25c2-47fd-8bc1-57d0f45e7d62@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>
 <QyBh2MR7GEWc2oQ3NimEgV8rHcbvbLEoOK_vAwVaMjo=.2fc260cc-25c2-47fd-8bc1-57d0f45e7d62@github.com>
Message-ID: <Y-yOZblThvBgNy5r1E59_WVTTgFIunkj4KdvlR3Aq7M=.cbfd247a-a955-482c-a150-621a0f683637@github.com>

On Wed, 13 Nov 2024 21:55:53 GMT, Iris Clark <iris at openjdk.org> wrote:

>> src/java.base/share/man/java.md line 9:
>> 
>>> 7: # published by the Free Software Foundation.  Oracle designates this
>>> 8: # particular file as subject to the "Classpath" exception as provided
>>> 9: # by Oracle in the LICENSE file that accompanied this code.
>> 
>> Documentation files should not have the Classpath exception.
>> 
>> make/data/license-templates/gpl-header
>
> Agree.

Yeah, sorry for that, and thanks for catching it. 

I just copied the header from a build file, since it was conveniently already formatted with the leading `#`. I just assumed that this was the pure GPL and did not check close enough to verify. But it turns out that most of the build system files actually have the classpath exception, which makes no sense. 

I've filed https://bugs.openjdk.org/browse/JDK-8344191 to deal with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1842039722

From jlahoda at openjdk.org  Thu Nov 14 11:36:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Nov 2024 11:36:06 GMT
Subject: Integrated: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
Message-ID: <NtcwESgpSWeYWM_vBDkzBdAzwc9E-hq2pbRPgbvt1pA=.cc28b23c-f42b-4c3f-a914-dcc5b12385b5@github.com>

On Wed, 30 Oct 2024 13:01:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: 5731ab7f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5731ab7fed22391e1dea777f6d76b7e75ccf5084
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8335991: Implement Simple Source Files and Instance Main Methods (Fourth Preview)

Reviewed-by: asotona, jpai

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

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

From ihse at openjdk.org  Thu Nov 14 12:28:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 12:28:23 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
Message-ID: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>

In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 

I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.

The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.

This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

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

Commit messages:
 - Update build tools, data and IDE support
 - Update makefiles, autoconf, shell scripts, properties files and configuration files

Changes: https://git.openjdk.org/jdk/pull/22104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344191
  Stats: 2054 lines in 555 files changed: 0 ins; 1118 del; 936 mod
  Patch: https://git.openjdk.org/jdk/pull/22104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104

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

From cstein at openjdk.org  Thu Nov 14 12:31:46 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 14 Nov 2024 12:31:46 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <B5wPJ1nOlZ8FqUq_BanQIjs_CFKZPbhmTHd_MwKHnYk=.4e63cd9e-02be-4e45-b79c-bc325ccd75e5@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). A candidate for an ignore list as fixing it is out of scope of this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476233883

From ihse at openjdk.org  Thu Nov 14 12:44:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 12:44:45 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <B5wPJ1nOlZ8FqUq_BanQIjs_CFKZPbhmTHd_MwKHnYk=.4e63cd9e-02be-4e45-b79c-bc325ccd75e5@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
 <B5wPJ1nOlZ8FqUq_BanQIjs_CFKZPbhmTHd_MwKHnYk=.4e63cd9e-02be-4e45-b79c-bc325ccd75e5@github.com>
Message-ID: <hGn-UQ8cj7rW04rBdwPSG7vy4_fy-L3GIw_IDz3CXvc=.cf326c7c-0f31-483c-939d-8e5193c1e609@github.com>

On Thu, 14 Nov 2024 12:29:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). 

*sigh*

> A candidate for an ignore list as fixing it is out of scope of this PR?

Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476258243

From duke at openjdk.org  Thu Nov 14 13:34:44 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Thu, 14 Nov 2024 13:34:44 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <_LlSFeUxsE5NIZ1tl6Fx_PV0NiHyVfwlkYD-91GkfOQ=.a5f09f9e-6116-4f3b-8860-c1e21474e213@github.com>

On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/22104#pullrequestreview-2436096366

From jjg at openjdk.org  Thu Nov 14 15:26:22 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 14 Nov 2024 15:26:22 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>

On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down.

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

PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2476698524

From acobbs at openjdk.org  Thu Nov 14 18:43:33 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 18:43:33 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <jjgtCW6yYlgSkkHUqWBjbu42hZEf87JMATuOWg3NncI=.9a8b43d8-2f2f-4f40-b807-9a74207fcb50@github.com>

On Wed, 13 Nov 2024 22:25:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which does some minor refactoring to the compiler:
> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
> 
> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

> We are faced with a dilemma: we could fold all the various linter analyses in a single tree scanner -- or we could have one tree scanner per linter (or somewhere in between).

It's an interesting design question. Performance testing is always authoritative of course, but intuitively I would guess the relative cost of doing separate scans would be low because the average `JCTree` probably (?) more-or-less fits into cache, and the efficiency of having a separate scan per "finder" depends mainly on how well the average `JCTree` fits into cache, because that's the memory that is being repeatedly accessed by separate scans that wouldn't be repeatedly accessed in a combined scan.

Moreover, the current `JCTree` should always be "hot" during compilation... it's accessed all over the place... so if it fits in cache, then separate scans are going to be fast, and if it doesn't fit in cache, then things are _already_ going to be slow, and having a single combined scan probably wouldn't increase performance by much.

In any case, what would a combined scanner look like? `TreeScanner`'s are "proactive" and initiate subtree scanning themselves, so you couldn't combine them unless e.g. you changed the semantics of `scan()` to just add the subtree nodes to a queue, which might make life harder. That idea would look something like this:

/** Applies multiple tree scanners to a tree in a single pass.
 */
public class CompositeTreeScanner extends TreeScanner {

    private final LinkedHashMap<JCTree, List<MemberTreeScanner>> queue = new LinkedHashMap<>();

    public void scan(JCTree tree, List<MemberTreeScanner> members) {
        members.forEach(member -> member.parent = this);
        queue.put(tree, members);
        while (!queue.isEmpty())
            dequeueAndScan();
    }

    private void dequeueAndScan() {
        var i = queue.entrySet().iterator();
        var entry = i.next();
        i.remove();
        entry.getValue().forEach(entry.getKey()::accept);
    }

    /** One of multiple scanners applied by a {@link CompositeTreeScanner}.
     *  <b>Warning</b>: Calls to {@link #scan} are executed asynchronously.
     */
    public static class MemberTreeScanner extends TreeScanner {

        private CompositeTreeScanner parent;

        @Override
        public void scan(JCTree tree) {
            parent.queue.computeIfAbsent(tree, t -> new ArrayList<>()).add(this);
        }
    }
}

OTOH you could easily combine `Visitor`'s, which are "reactive", with the downside being that a visitor will scan all of the tree nodes, even those that none of this individual finders wishes to visit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2477155632

From iris at openjdk.org  Thu Nov 14 18:43:38 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 14 Nov 2024 18:43:38 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <hD8dWtCFGyH64MyqGEoAP1aMt9E32eY7_ArUkRi0cT4=.c18c2075-5daf-4cda-9a81-2f968a343734@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

Thanks for updating all the licenses to GPL.

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

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2436927254

From mcimadamore at openjdk.org  Thu Nov 14 19:31:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 19:31:31 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <Y6JvmDGCZJ74gCxqVx0jF3iqVHr6UhrL9pQzL-CRqTU=.e519a450-8867-480f-a252-6e2de1e7710d@github.com>

On Wed, 13 Nov 2024 22:25:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which does some minor refactoring to the compiler:
> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
> 
> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

> > We are faced with a dilemma: we could fold all the various linter analyses in a single tree scanner -- or we could have one tree scanner per linter (or somewhere in between).
> 
> It's an interesting design question. Performance testing is always authoritative of course, but intuitively I would guess the relative cost of doing separate scans would be low because the average `JCTree` probably (?) more-or-less fits into cache, and the efficiency of having a separate scan per "finder" depends mainly on how well the average `JCTree` fits into cache, because that's the memory that is being repeatedly accessed by separate scans that wouldn't be repeatedly accessed in a combined scan.
> 
> Moreover, the current `JCTree` should always be "hot" during compilation... it's accessed all over the place... so if it fits in cache, then separate scans are going to be fast, and if it doesn't fit in cache, then things are _already_ going to be slow, and having a single combined scan probably wouldn't increase performance by much.
> 
> In any case, what would a combined scanner look like? `TreeScanner`'s are "proactive" and initiate subtree scanning themselves, so you couldn't combine them unless e.g. you changed the semantics of `scan()` to just add the subtree nodes to a queue, which might make life harder. That idea would look something like this:
> 
> ```java
> /** Applies multiple tree scanners to a tree in a single pass.
>  */
> public class CompositeTreeScanner extends TreeScanner {
> 
>     private final LinkedHashMap<JCTree, List<MemberTreeScanner>> queue = new LinkedHashMap<>();
> 
>     public void scan(JCTree tree, List<MemberTreeScanner> members) {
>         members.forEach(member -> member.parent = this);
>         queue.put(tree, members);
>         while (!queue.isEmpty())
>             dequeueAndScan();
>     }
> 
>     private void dequeueAndScan() {
>         var i = queue.entrySet().iterator();
>         var entry = i.next();
>         i.remove();
>         entry.getValue().forEach(entry.getKey()::accept);
>     }
> 
>     /** One of multiple scanners applied by a {@link CompositeTreeScanner}.
>      *  <b>Warning</b>: Calls to {@link #scan} are executed asynchronously.
>      */
>     public static class MemberTreeScanner extends TreeScanner {
> 
>         private CompositeTreeScanner parent;
> 
>         @Override
>         public void scan(JCTree tree) {
>             parent.queue.computeIfAbsent(tree, t -> new ArrayList<>()).add(this);
>         }
>     }
> }
> ```
> 
> OTOH you could easily combine `Visitor`'s, which are "reactive", with the downside being that a visitor will scan all of the tree nodes, even those that none of this individual finders wishes to visit.

I think it would be worth starting with a simple design (e.g. one visitor per analysis first), but then try to implement a certain number of them (say 4-5) and see whether e.g. compiling something big (like the JDK) suffers from the number of extra passes. In the past we have been a bit schizophrenic on this topic: sometimes we always apply a pass (e.g. TransTypes), but starting with lambdas we started checking if a pass had anything to do (see LambdaToMethod and TransPatterns). I don't think any evidence was ever gathered to make such passed optional, but I think this is a question we should settle once and for all before aiming for a particular design.

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2477241252

From vromero at openjdk.org  Thu Nov 14 20:20:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Nov 2024 20:20:32 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <cRKzX-DaEkPKZw_lbTnT0Ka2gkLsT-gnPGUghfuMd1Y=.e7ffda20-508b-4fe5-8683-02e23c08d5f9@github.com>

On Wed, 13 Nov 2024 22:25:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which does some minor refactoring to the compiler:
> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
> 
> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/WarningAnalyzer.java line 39:

> 37:  *  deletion without notice.</b>
> 38:  */
> 39: public class WarningAnalyzer {

nice to see this happening :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22088#discussion_r1842837463

From acobbs at openjdk.org  Thu Nov 14 20:48:25 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 20:48:25 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <Y6JvmDGCZJ74gCxqVx0jF3iqVHr6UhrL9pQzL-CRqTU=.e519a450-8867-480f-a252-6e2de1e7710d@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
 <Y6JvmDGCZJ74gCxqVx0jF3iqVHr6UhrL9pQzL-CRqTU=.e519a450-8867-480f-a252-6e2de1e7710d@github.com>
Message-ID: <ANGs55ob2dOeeRxUccC2xBnVU0w-nR2ytIn4fzd2Thk=.992b3e82-6594-409f-83da-bd8595bb9be6@github.com>

On Thu, 14 Nov 2024 19:27:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I think it would be worth starting with a simple design (e.g. one visitor per analysis first), but then try to implement a certain number of them (say 4-5) and see whether e.g. compiling something big (like the JDK) suffers from the number of extra passes.

FWIW I built a very simple version of that idea:

for i in 1 2 3 4 5; do
    echo =========== RUN $i;
    make clean
    find src -name '*.java' -print | xargs touch
    make interim-langtools
    time make
done

and ran that under two scenarios on my MacBook (Apple M1 Pro 32GB):
* Scenario 1: The version of the JDK in this PR
* Scenario 2: The version of the JDK in this PR + the following patch:

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/WarningAnalyzer.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/WarningAnalyzer.java
@@ -58,6 +58,7 @@ protected WarningAnalyzer(Context context) {
     }
 
     public void analyzeTree(Env<AttrContext> env) {
-        thisEscapeAnalyzer.analyzeTree(env);
+        for (int i = 0; i < 25; i++)
+            thisEscapeAnalyzer.analyzeTree(env);
     }
 }

Note that most, but not all, of the JDK (51 out of 70 modules) is built with `this-escape` enabled.

The difference was beneath the noise level, which is somewhat promising:

---------------------
TEST: NORMAL COMPILER
---------------------

=========== RUN 1
real	2m28.721s
user	14m21.497s
sys	2m55.992s
=========== RUN 2
real	2m26.708s
user	14m17.562s
sys	2m52.912s
=========== RUN 3
real	2m32.698s
user	14m25.495s
sys	2m58.030s
=========== RUN 4
real	2m29.797s
user	14m25.312s
sys	2m56.253s
=========== RUN 5
real	2m26.124s
user	14m18.213s
sys	2m51.032s

---------------------
TEST: LOOP 25 TIMES
-------------------

=========== RUN 1
real	2m27.971s
user	14m21.692s
sys	2m54.486s
=========== RUN 2
real	2m28.259s
user	14m19.175s
sys	2m52.646s
=========== RUN 3
real	2m27.913s
user	14m19.559s
sys	2m52.708s
=========== RUN 4
real	2m28.897s
user	14m23.295s
sys	2m55.207s
=========== RUN 5
real	2m26.768s
user	14m20.362s
sys	2m53.447s

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2477376400

From mcimadamore at openjdk.org  Thu Nov 14 22:19:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 22:19:21 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <E6udkAKJ6e7E7ePDqIeq-NvH-e1dOgJdWoM85Tn5pWU=.2883ad6e-cee2-4c97-ab86-2cc1ffc011fc@github.com>

On Wed, 13 Nov 2024 22:25:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which does some minor refactoring to the compiler:
> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
> 
> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

> FWIW I built a very simple version of that idea:
> 
> ```shell
> for i in 1 2 3 4 5; do
>     echo =========== RUN $i;
>     make clean
>     find src -name '*.java' -print | xargs touch
>     make interim-langtools
>     time make
> done
> ```

I'm not sure this test is correct. IIUC, `make interim-langtools` builds the compiler sources, but using the compiler in the bootstrap JDK. That explains, I think, why there's absolutely no difference between the two runs?

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2477512956

From mcimadamore at openjdk.org  Thu Nov 14 22:19:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 22:19:21 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <E6udkAKJ6e7E7ePDqIeq-NvH-e1dOgJdWoM85Tn5pWU=.2883ad6e-cee2-4c97-ab86-2cc1ffc011fc@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
 <E6udkAKJ6e7E7ePDqIeq-NvH-e1dOgJdWoM85Tn5pWU=.2883ad6e-cee2-4c97-ab86-2cc1ffc011fc@github.com>
Message-ID: <a7Vnvq7JYJCuBxo9mG7urCZlX-tq27M7I77IPhOYLVY=.32836ef7-cf4c-48fa-81d6-d2b0551d664d@github.com>

On Thu, 14 Nov 2024 22:14:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > FWIW I built a very simple version of that idea:
> > ```shell
> > for i in 1 2 3 4 5; do
> >     echo =========== RUN $i;
> >     make clean
> >     find src -name '*.java' -print | xargs touch
> >     make interim-langtools
> >     time make
> > done
> > ```
> 
> I'm not sure this test is correct. IIUC, `make interim-langtools` builds the compiler sources, but using the compiler in the bootstrap JDK. That explains, I think, why there's absolutely no difference between the two runs?

Ah, ok, you also use `make` which builds the whole thing. That's good then - thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2477515728

From acobbs at openjdk.org  Thu Nov 14 22:32:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 22:32:56 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <a7Vnvq7JYJCuBxo9mG7urCZlX-tq27M7I77IPhOYLVY=.32836ef7-cf4c-48fa-81d6-d2b0551d664d@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
 <E6udkAKJ6e7E7ePDqIeq-NvH-e1dOgJdWoM85Tn5pWU=.2883ad6e-cee2-4c97-ab86-2cc1ffc011fc@github.com>
 <a7Vnvq7JYJCuBxo9mG7urCZlX-tq27M7I77IPhOYLVY=.32836ef7-cf4c-48fa-81d6-d2b0551d664d@github.com>
Message-ID: <ywvTXEZ_abBPaerkqVs7ZDn3D3gRkH0Ho2NwhLA8fcY=.fd6a8a5a-8538-4944-862d-ae68c049c86f@github.com>

On Thu, 14 Nov 2024 22:16:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Ah, ok, you also use `make` which builds the whole thing. That's good then - thanks!

Right - I was just trying to exclude the step that compiles using the bootstrap compiler, since that's not part of what we want to test.

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2477534212

From ihse at openjdk.org  Fri Nov 15 00:10:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 00:10:24 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
 <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>
Message-ID: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com>

On Thu, 14 Nov 2024 15:23:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The policy has long been to use Classpath Exception in the src and make directories, but not in the test directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down.

I did not know there was such a policy. My understanding is that the classpath exception only makes sense for java files that are distributed as part of the JDK. That `test` was excluded from classpath should therefore be a logical consequence that it is not distributed. And `src` is not generally using CPE; for instance, Hotspot does not have CPE.

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

PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2477665315

From dholmes at openjdk.org  Fri Nov 15 01:25:30 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Nov 2024 01:25:30 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <C-MBQ_G52h3Y1bIQRfxQJOSVS3pmOv6CRy1fxzR0K4M=.67e32bdd-26cd-4450-ba03-766af4e2e98e@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

LGTM!

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2437489438

From dholmes at openjdk.org  Fri Nov 15 01:29:49 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Nov 2024 01:29:49 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

> > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad).
> 
> _sigh_
> 
> > A candidate for an ignore list as fixing it is out of scope of this PR?
> 
> Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix.

I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image.

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2477764902

From mcimadamore at openjdk.org  Fri Nov 15 10:10:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 15 Nov 2024 10:10:40 GMT
Subject: Integrated: 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: <TuFh7lP0IBkHtWrzoipk17UG6RMOOtYl_2038wwT_JA=.301f57d5-cabb-4ea6-a579-43025366c9d7@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.

This pull request has now been integrated.

Changeset: 5b9932f8
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b9932f8f3c320f1d2c95403478a6069d05da52a
Stats:     479 lines in 19 files changed: 314 ins; 140 del; 25 mod

8338288: Compiler Implementation for Flexible Constructor Bodies (Third Preview)
8322882: Null pointer error when compiling Static initializer in a local class
8334248: Invalid error for early construction local class constructor method reference
8330037: Compiler produces invalid bytecode for method class creation from static method

Reviewed-by: jlahoda, vromero

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

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

From prappo at openjdk.org  Fri Nov 15 10:23:42 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Nov 2024 10:23:42 GMT
Subject: Integrated: 8341907: javac -Xlint should ignore /// on first line of
 source file
In-Reply-To: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
References: <_uAuoqDqRp5YcSjgampGbpveKjh8KOnYSMtH9MBvkKU=.30bacd7f-6f53-46d6-8a86-1ee8ec8e7d63@github.com>
Message-ID: <GA5rodOSLb3UEQn_jJcDtNbpt88or-JXGQJinuUNrIo=.8e4f3adf-cc23-4131-b9e0-d586da5c262e@github.com>

On Wed, 6 Nov 2024 11:31:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to exempt the [trick that JBang uses][] from the "dangling comment" lint introduced in JDK 23. For more information see this PR's JBS issue and its comment section.
> 
> The fix makes sure that the warning is not issued if it relates to a leading `///` comment. For simplicity and similarity with the shebang construct, the comment should start from the first character of the file, and not a more permissive first non-whitespace character of the file.
> 
> Since I'm not an expert in `java.compiler`, I'm unsure if my code intercepts warning in the most appropriate layer. Please double-check that.
> 
> Skimming through the tests which I used for inspiration, `test/langtools/tools/javac/danglingDocComments`, I was unsure why they compile itself first without any `/ref=` construct. The test I introduced here does not do this; am I missing something?
> 
> [trick that JBang uses]: https://www.jbang.dev/documentation/guide/latest/usage.html

This pull request has now been integrated.

Changeset: 3eece6e9
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3eece6e941035e091e8ece7dd44a1837417c9b87
Stats:     115 lines in 8 files changed: 113 ins; 0 del; 2 mod

8341907: javac -Xlint should ignore /// on first line of source file

Reviewed-by: jjg

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

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

From jlahoda at openjdk.org  Fri Nov 15 11:08:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 15 Nov 2024 11:08:38 GMT
Subject: RFR: 8341901: Using 'var' keyword switch pattern matching causes
 compiler error [v2]
In-Reply-To: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
References: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
Message-ID: <aKRrfQg-KV6ugeEIce9gRXgFxJFEnYTGk3jKk8LZUtA=.15b50647-6e89-4ed5-933c-83d16e3a1bae@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.

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

  Adding a comment specifying the type that's used to attribute the QualIdent is a raw type.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21495/files
  - new: https://git.openjdk.org/jdk/pull/21495/files/7bf21b9c..e2d5f105

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 prappo at openjdk.org  Fri Nov 15 11:35:40 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Nov 2024 11:35:40 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v6]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <I_76U8sLnYjjksGSKTE55NmlDK5fmk9Pou6t_sUwegY=.bca73f06-7e51-4d83-a31e-65ca4908241c@github.com>

> Prepare for JDK 25.

Pavel Rappo 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:

 - Update --release 24 symbol information for JDK 24 build 24
   
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 23
   
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 21
   
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
 - Add forgotten .jcheck/conf
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/84dce9a3..354ed5a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=04-05

  Stats: 111558 lines in 2961 files changed: 29381 ins; 72609 del; 9568 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 asotona at openjdk.org  Fri Nov 15 11:53:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 11:53:00 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
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: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@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 12 commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - 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
 - ... and 2 more: https://git.openjdk.org/jdk/compare/ba393219...807e8b2a

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

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=08
  Stats: 799 lines in 165 files changed: 0 ins; 487 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 liach at openjdk.org  Fri Nov 15 14:15:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 14:15:00 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <h6Bz3U_UMvkR7g_VmPsKjeoGLFotX4bOVZ2fvMtLbkE=.5706e9c7-d8ae-41fa-a5b1-f01a0bdd28d3@github.com>

On Fri, 15 Nov 2024 11:53:00 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 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - 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/ConstantDynami...

It's finally the time to set sail!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2438721981

From asotona at openjdk.org  Fri Nov 15 14:37:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 14:37:52 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <UGrZ0I-Ehrm3LW1N7wtCZk6BD_pSZgSIyqC68uksZ4Q=.d55aada7-d6e9-425a-98bf-04a2088a1639@github.com>

On Fri, 15 Nov 2024 11:53:00 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 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - 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/ConstantDynami...

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2479030204

From asotona at openjdk.org  Fri Nov 15 14:41:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 14:41:01 GMT
Subject: Integrated: 8334714: Implement JEP 484: Class-File API
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: <r4ddLbwDLxL-HBYxfRKEh8QLiIkWF9NGvxOGeUbvW2k=.52ab53e6-3c93-4e31-aae0-456e35b691a2@github.com>

On Fri, 21 Jun 2024 11:56:37 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

This pull request has now been integrated.

Changeset: 84ffb64c
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84ffb64cd73f8af11cf3670c6f19d282c2ac6961
Stats:     799 lines in 165 files changed: 0 ins; 487 del; 312 mod

8334714: Implement JEP 484: Class-File API

Reviewed-by: liach, vromero

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

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

From ihse at openjdk.org  Fri Nov 15 14:46:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:46:33 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v3]
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix regexes in CheckManPageOptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22081/files
  - new: https://git.openjdk.org/jdk/pull/22081/files/a8d4ea50..dbef493e

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

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

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

From ihse at openjdk.org  Fri Nov 15 14:46:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:46:34 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <OnOhR_4neUIpLLJXyytczQFw_jwjywxQ-o7XAvWVjF4=.971a3357-fa72-4c7c-9025-f295e252dc9f@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

The CheckManPageOptions test had regexps that were not up to date with the latest changes in the markdown file. I fixed those and now the test passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479038178

From ihse at openjdk.org  Fri Nov 15 14:46:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:46:34 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
 <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com>
Message-ID: <H49OafS1oIU1W-O1uMBrGYPeARoh_4nPqPp0cyzjt_k=.fd859280-4110-441d-9ddc-e7e08bb909c9@github.com>

On Fri, 15 Nov 2024 01:25:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix CheckManPageOptions test
>>  - Remove classpath exception
>
>> > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad).
>> 
>> _sigh_
>> 
>> > A candidate for an ignore list as fixing it is out of scope of this PR?
>> 
>> Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix.
> 
> I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image.

@dholmes-ora 

>  I was expecting it to examine the .1 files in the JDK image.

It's been like that since the test was created in https://bugs.openjdk.org/browse/JDK-8274211, so there is no change in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479042569

From ihse at openjdk.org  Fri Nov 15 14:50:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:50:21 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  It's somewhat nicer to use \\s instead of space character in regex

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22081/files
  - new: https://git.openjdk.org/jdk/pull/22081/files/dbef493e..7cba61b5

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

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

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

From cstein at openjdk.org  Fri Nov 15 15:04:51 2024
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 15 Nov 2024 15:04:51 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v3]
In-Reply-To: <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>
Message-ID: <Hc2bnxpU3L_6aq6ywU83kGh6MnUKh7XftL5OuwKErGg=.4c54e3d8-2169-4d25-bfa9-9d2b957e6981@github.com>

On Fri, 15 Nov 2024 14:46:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix regexes in CheckManPageOptions

test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277:

> 275: 
> 276:         // In the defining areas, option names are represented as follows:
> 277:         //      `OPTION` or `OPTION`

`OPTION` or `OPTION` ... where's the difference?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843959156

From liach at openjdk.org  Fri Nov 15 15:08:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 15:08:59 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>

On Fri, 15 Nov 2024 11:53:00 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 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - 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/ConstantDynami...

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 78:

> 76:         STRUCTURED_CONCURRENCY,
> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
> 78:         CLASSFILE_API,

Just remembered that we have to keep this until JDK 24 is the minimum boot JDK; with this removed bootcycle build should fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1843965756

From ihse at openjdk.org  Fri Nov 15 15:11:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 15:11:46 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v3]
In-Reply-To: <Hc2bnxpU3L_6aq6ywU83kGh6MnUKh7XftL5OuwKErGg=.4c54e3d8-2169-4d25-bfa9-9d2b957e6981@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>
 <Hc2bnxpU3L_6aq6ywU83kGh6MnUKh7XftL5OuwKErGg=.4c54e3d8-2169-4d25-bfa9-9d2b957e6981@github.com>
Message-ID: <_OybV6gt9rVOlg2n8GG48jDzgFsqLQ6GLi4R5TvZWTI=.b1f68ebb-dcd5-4fe1-b001-21628221d218@github.com>

On Fri, 15 Nov 2024 15:00:39 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix regexes in CheckManPageOptions
>
> test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277:
> 
>> 275: 
>> 276:         // In the defining areas, option names are represented as follows:
>> 277:         //      `OPTION` or `OPTION`
> 
> `OPTION` or `OPTION` ... where's the difference?

Some options have multiple variants displayed on a single row, like:

 `--classpath` or `-cp`



This was handled in the troff format but not updated for markdown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843969778

From asotona at openjdk.org  Fri Nov 15 15:36:54 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 15:36:54 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
 <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>
Message-ID: <bMakln9SE0MJ_dosAb_xOyo6dpja3iL0GOk6GsBEaYY=.901bfa89-38e2-42df-8891-7d3db507f996@github.com>

On Fri, 15 Nov 2024 15:05:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>>  - 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/jdk/internal/javac/PreviewFeature.java line 78:
> 
>> 76:         STRUCTURED_CONCURRENCY,
>> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
>> 78:         CLASSFILE_API,
> 
> Just remembered that we have to keep this until JDK 24 is the minimum boot JDK; with this removed bootcycle build should fail.

Oops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1844042001

From asotona at openjdk.org  Fri Nov 15 15:47:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 15:47:01 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <bMakln9SE0MJ_dosAb_xOyo6dpja3iL0GOk6GsBEaYY=.901bfa89-38e2-42df-8891-7d3db507f996@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
 <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>
 <bMakln9SE0MJ_dosAb_xOyo6dpja3iL0GOk6GsBEaYY=.901bfa89-38e2-42df-8891-7d3db507f996@github.com>
Message-ID: <JfMUPY10zx_WMCo_PLFK-D-j0_NckrT5BYnbyzyJMkI=.7f083027-742f-4cfa-916e-83997520dd16@github.com>

On Fri, 15 Nov 2024 15:33:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 78:
>> 
>>> 76:         STRUCTURED_CONCURRENCY,
>>> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
>>> 78:         CLASSFILE_API,
>> 
>> Just remembered that we have to keep this until JDK 24 is the minimum boot JDK; with this removed bootcycle build should fail.
>
> Oops.

https://github.com/openjdk/jdk/pull/22150

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1844076730

From asotona at openjdk.org  Fri Nov 15 15:47:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 15:47:03 GMT
Subject: RFR: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
Message-ID: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>

jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.

Please review.

Thank you,
Adam

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

Commit messages:
 - 8344314: Revert removal of jdk.internal.java.PreviewFeature.CLASSFILE_API

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

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

From asotona at openjdk.org  Fri Nov 15 16:01:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 16:01:00 GMT
Subject: RFR: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
In-Reply-To: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
References: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
Message-ID: <UnlOk1Jo1IxCy1J3E0rN4NN-XxlHcDzDKHMTBvKbcKU=.b068c434-262b-4091-833b-751dfa07c133@github.com>

On Fri, 15 Nov 2024 15:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.
> 
> Please review.
> 
> Thank you,
> Adam

I missed it too.
Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22150#issuecomment-2479295705

From liach at openjdk.org  Fri Nov 15 16:01:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 16:01:00 GMT
Subject: RFR: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
In-Reply-To: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
References: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
Message-ID: <3StDzbrqAmKQ4bhWJ_dbb7V4-TLUl4gCRUd3fjJcd1g=.dab69d38-73f4-490f-a589-6d26124c4a3c@github.com>

On Fri, 15 Nov 2024 15:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.
> 
> Please review.
> 
> Thank you,
> Adam

Sorry for forgetting to leave that review earlier.  Viktor told me but I forgot to leave the remark on the PR review.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22150#pullrequestreview-2439021986

From asotona at openjdk.org  Fri Nov 15 16:01:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 16:01:01 GMT
Subject: Integrated: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
In-Reply-To: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
References: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
Message-ID: <RJHkBAZPHGL5f8VapRKfqgaNdrD2wFHcv9jJRRTH7oc=.bee7876c-3665-4daa-a306-b18f5e771be1@github.com>

On Fri, 15 Nov 2024 15:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 3c38ed41
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c38ed4128f8762d04ae093d7e8f015bfd4fc2da
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8344314: Revert removal of jdk.internal.java.PreviewFeature.CLASSFILE_API

Reviewed-by: liach

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

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

From cstein at openjdk.org  Fri Nov 15 16:04:19 2024
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 15 Nov 2024 16:04:19 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
Message-ID: <h-yi4F3ylqaiXJhUvdkQYwbgW7lbhzlFqCpNo_y5pDg=.cd652669-b8ac-4c35-9d02-1a6ec551df87@github.com>

On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It's somewhat nicer to use \\s instead of space character in regex

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2439039366

From vromero at openjdk.org  Fri Nov 15 16:04:24 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Nov 2024 16:04:24 GMT
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods
In-Reply-To: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
Message-ID: <3qEa74HyiZQ79MnMQRdpPGB-FX9bzagBA-T2Wy_wmMU=.77adc8d1-c379-450f-accc-bd786c965423@github.com>

On Thu, 7 Nov 2024 13:10:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a case where a new preview interface is introduced to JDK, and an existing non-preview class is retrofitted to use it. I.e. a case like:
> 
> 
> //JDK types:
> @PreviewFeature(...)
> public interface NewAPI {
>     public default void test() {}
> }
> public class ExistingRetrofittedClass implements NewAPI {}
> 
> //user type:
> class Test {
>     void t(ExistingRetrofittedClass c) {
>         c.test();
>     }
> }
> 
> 
> There is currently no error or warning about the invocation of the test method, as the method itself is not marked as preview, and the receiver is not preview either.
> 
> The proposal herein is that invoking a method on a receiver that is not of preview type itself, but the method is declared in a preview class or interface, the method will be considered to be a preview method, and the appropriate error or warning will be printed. Similar behavior is implementing for dereferencing fields.
> 
> 
> Similarly when implementing or overriding such "effectively" preview methods, like:
> 
> 
> //user types:
> class Test1 extends ExistingRetrofittedClass {
>     public void test() {}
> }
> 
> 
> java also does not produce any error or warning. If the method itself would be marked as preview, an error or warning would be printed.
> 
> The proposal herein is to produce an error or warning for a method declared inside a non-preview class or interface, which directly overrides a method declared inside a preview class or interface.
> 
> In particular, for the two example above, javac is currently producing no errors. With the change proposed herein, javac will produce output like (with no `--enable-preview`):
> 
> 
> src/Test1.java:4: error: test() is a preview API and is disabled by default.
>     public void test() {}
>                 ^
>   (use --enable-preview to enable preview APIs)
> src/Test.java:5: error: test() is a preview API and is disabled by default.
>         c.test();
>          ^
>   (use --enable-preview to enable preview APIs)
> 2 errors

looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3852:

> 3850:         } else {
> 3851:             sIsPreview = false;
> 3852:             previewSymbol = null;

nit: this assignment seems to be unnecessary

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21953#pullrequestreview-2439038038
PR Review Comment: https://git.openjdk.org/jdk/pull/21953#discussion_r1844103204

From iris at openjdk.org  Fri Nov 15 19:30:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 15 Nov 2024 19:30:55 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v6]
In-Reply-To: <I_76U8sLnYjjksGSKTE55NmlDK5fmk9Pou6t_sUwegY=.bca73f06-7e51-4d83-a31e-65ca4908241c@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <I_76U8sLnYjjksGSKTE55NmlDK5fmk9Pou6t_sUwegY=.bca73f06-7e51-4d83-a31e-65ca4908241c@github.com>
Message-ID: <k_5IFbg6b1NiCM6cryK6mcTabp_BI1lbs82pp8SFrsw=.235cfeb1-5ece-412a-93b1-fc29fa2cb56e@github.com>

On Fri, 15 Nov 2024 11:35:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo 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:
> 
>  - Update --release 24 symbol information for JDK 24 build 24
>    
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 23
>    
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 22
>    
>    The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 21
>    
>    The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
>  - Add forgotten .jcheck/conf
>  - Initial commit

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2439451274

From vromero at openjdk.org  Fri Nov 15 20:09:46 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Nov 2024 20:09:46 GMT
Subject: RFR: 8341901: Using 'var' keyword switch pattern matching causes
 compiler error [v2]
In-Reply-To: <aKRrfQg-KV6ugeEIce9gRXgFxJFEnYTGk3jKk8LZUtA=.15b50647-6e89-4ed5-933c-83d16e3a1bae@github.com>
References: <Bi27VR2BpRfVkQF7dBoXa1FGRKuDGT5vOY2gsD51MUk=.1c7df3ce-e005-4790-984b-eb7ae2d8ab18@github.com>
 <aKRrfQg-KV6ugeEIce9gRXgFxJFEnYTGk3jKk8LZUtA=.15b50647-6e89-4ed5-933c-83d16e3a1bae@github.com>
Message-ID: <b5jmvc4nMopqa1dHbTI0wk64dbgayJhEpstpZZwxqi8=.f5162e25-b108-46c8-830a-efb17363d574@github.com>

On Fri, 15 Nov 2024 11:08:38 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.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a comment specifying the type that's used to attribute the QualIdent is a raw type.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21495#pullrequestreview-2439527264

From dholmes at openjdk.org  Sat Nov 16 12:24:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 16 Nov 2024 12:24:42 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
 <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>
 <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com>
Message-ID: <yBnJF8M2Mq6PH2pwEFI1aHQZcOvjPAubcXJJUBfFtMg=.1c674802-e31e-4f50-9d28-b05b31697604@github.com>

On Fri, 15 Nov 2024 00:07:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down.

What policy is that? The Classpath exception is for executing classfiles. It is meaningless in any other context.

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

PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2480542305

From iris at openjdk.org  Mon Nov 18 01:35:07 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 18 Nov 2024 01:35:07 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
Message-ID: <Tp6ovDvXsen9cOyCVWF5mUyuqKBmLJsV0CCd99cOflk=.08ed9a29-6f05-4987-ba14-828ffd450b27@github.com>

On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It's somewhat nicer to use \\s instead of space character in regex

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2441317522

From ihse at openjdk.org  Mon Nov 18 09:29:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 09:29:52 GMT
Subject: Integrated: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <_LM2L_tT9Q4OZvoeWztNyLUkzQcLPQIE_En639Pu_lA=.31310c87-64b4-4b97-bb0c-f044e312e9ef@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

This pull request has now been integrated.

Changeset: 475feb06
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/475feb064bb6b9dfd34fc52762e3e0ab825254ec
Stats:     41386 lines in 66 files changed: 18876 ins; 22500 del; 10 mod

8344056: Use markdown format for man pages

Reviewed-by: cstein, iris, dholmes

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

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

From jlahoda at openjdk.org  Mon Nov 18 11:47:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Nov 2024 11:47:07 GMT
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods [v2]
In-Reply-To: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
Message-ID: <jslh8Bcc29AEfwfBiENX5XdJl05MSQboLjUlel6_qQM=.ce20e51e-a556-4c5f-a34d-ad748bac3ba6@github.com>

> Consider a case where a new preview interface is introduced to JDK, and an existing non-preview class is retrofitted to use it. I.e. a case like:
> 
> 
> //JDK types:
> @PreviewFeature(...)
> public interface NewAPI {
>     public default void test() {}
> }
> public class ExistingRetrofittedClass implements NewAPI {}
> 
> //user type:
> class Test {
>     void t(ExistingRetrofittedClass c) {
>         c.test();
>     }
> }
> 
> 
> There is currently no error or warning about the invocation of the test method, as the method itself is not marked as preview, and the receiver is not preview either.
> 
> The proposal herein is that invoking a method on a receiver that is not of preview type itself, but the method is declared in a preview class or interface, the method will be considered to be a preview method, and the appropriate error or warning will be printed. Similar behavior is implementing for dereferencing fields.
> 
> 
> Similarly when implementing or overriding such "effectively" preview methods, like:
> 
> 
> //user types:
> class Test1 extends ExistingRetrofittedClass {
>     public void test() {}
> }
> 
> 
> java also does not produce any error or warning. If the method itself would be marked as preview, an error or warning would be printed.
> 
> The proposal herein is to produce an error or warning for a method declared inside a non-preview class or interface, which directly overrides a method declared inside a preview class or interface.
> 
> In particular, for the two example above, javac is currently producing no errors. With the change proposed herein, javac will produce output like (with no `--enable-preview`):
> 
> 
> src/Test1.java:4: error: test() is a preview API and is disabled by default.
>     public void test() {}
>                 ^
>   (use --enable-preview to enable preview APIs)
> src/Test.java:5: error: test() is a preview API and is disabled by default.
>         c.test();
>          ^
>   (use --enable-preview to enable preview APIs)
> 2 errors

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

  Adding tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21953/files
  - new: https://git.openjdk.org/jdk/pull/21953/files/95603c9c..cdb2d59f

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

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

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

From abimpoudis at openjdk.org  Mon Nov 18 14:09:37 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 18 Nov 2024 14:09:37 GMT
Subject: RFR: 8340145: Problem with generic pattern matching results in
 internal compiler error [v2]
In-Reply-To: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>
References: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>
Message-ID: <ncTRRDat9Z7BAh1xDV4Ptkq6kR4eBcC4IT11U17Oc1U=.fa3a86ac-efe5-4f4f-91a8-f3cb8712aaa2@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;
>   };
> }

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

  Add test with multiple bounds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21606/files
  - new: https://git.openjdk.org/jdk/pull/21606/files/b8f0742f..f9f98886

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

  Stats: 18 lines in 1 file changed: 17 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 abimpoudis at openjdk.org  Mon Nov 18 14:09:38 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 18 Nov 2024 14:09:38 GMT
Subject: RFR: 8340145: Problem with generic pattern matching results in
 internal compiler error [v2]
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: <T8l5arSw61pqNFS__6-swDnpUNj4aTnF6xk3TLxJRy0=.05a62d9c-491a-4872-884e-03cee72b2db6@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).

Added a test with multiple bounds IIUC @lahodaj: https://github.com/openjdk/jdk/pull/21606/commits/f9f9888674577222ae268fd14fd1fdf978d6418e

Still ok, it seems. Hm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21606#discussion_r1846649291

From darcy at openjdk.org  Tue Nov 19 06:54:00 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 19 Nov 2024 06:54:00 GMT
Subject: RFR: 8341935: javac states that -proc:full is the default but the
 default as of 23 is -proc:none
Message-ID: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>

Update javac man page is describe current behavior; includes updates discussed in CSR [JDK-8321319](https://bugs.openjdk.org/browse/JDK-8321319) that were not included in the man pages for JDK 23 GA.

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

Commit messages:
 - JDK-8341935: javac states that -proc:full is the default but the default as of 23 is -proc:none

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

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

From jpai at openjdk.org  Tue Nov 19 08:06:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 08:06:19 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from java.compiler
 module
Message-ID: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>

Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 

No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

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

Commit messages:
 - 8344471: Remove SecurityManager related code from java.compiler module

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

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

From jlahoda at openjdk.org  Tue Nov 19 09:16:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 19 Nov 2024 09:16:57 GMT
Subject: Integrated: 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: <NhAgeRT7nfrRYB5HzRo5OlCRdRI5bCZREcILyVdpyOM=.f92af27b-90ad-439f-909f-851f798c4827@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.

This pull request has now been integrated.

Changeset: 8bd080bc
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8bd080bcc9ae3eb368e4bcd5fd0f52408dd9050c
Stats:     103 lines in 3 files changed: 99 ins; 1 del; 3 mod

8341901: Using 'var' keyword switch pattern matching causes compiler error

Reviewed-by: vromero, abimpoudis

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

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

From jlahoda at openjdk.org  Tue Nov 19 14:17:47 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 19 Nov 2024 14:17:47 GMT
Subject: RFR: 8341935: javac states that -proc:full is the default but the
 default as of 23 is -proc:none
In-Reply-To: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
References: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
Message-ID: <XJZUgak4s-1sCn4P9qmxHHTURgJySJhMP8UG6-jWSxk=.02fa2fbe-53ec-449e-9cc0-a736a3c2e66a@github.com>

On Tue, 19 Nov 2024 06:48:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javac man page is describe current behavior; includes updates discussed in CSR [JDK-8321319](https://bugs.openjdk.org/browse/JDK-8321319) that were not included in the man pages for JDK 23 GA.

Overall looks good, with one nit comment inline.

src/jdk.compiler/share/man/javac.md line 341:

> 339:     `-proc:none` means that compilation takes place without annotation
> 340:     processing. `-proc:only` means that only annotation processing is done,
> 341:     without any subsequent compilation. and

Nit:
either:
Suggestion:

    without any subsequent compilation.


or:
Suggestion:

    without any subsequent compilation. And


(So that the sentence either starts with a capital letter, or with the `-proc:full`, as the other sentences here do.)

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22227#pullrequestreview-2445601903
PR Review Comment: https://git.openjdk.org/jdk/pull/22227#discussion_r1848441801

From rriggs at openjdk.org  Tue Nov 19 14:51:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 14:51:54 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module
In-Reply-To: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
Message-ID: <8ss2m29IkhAqiMMbvq2qd7EZWLJI4onKNKt_M3V1zp0=.9f95eba3-b384-46ae-9088-41dd16edcc1e@github.com>

On Tue, 19 Nov 2024 08:00:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

With only 1 caller the static matches() method could be inlined.
(No local variables are needed).

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

PR Review: https://git.openjdk.org/jdk/pull/22229#pullrequestreview-2445709041

From jpai at openjdk.org  Tue Nov 19 15:07:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 15:07:09 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module [v2]
In-Reply-To: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
Message-ID: <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>

> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

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

  Roger's suggestion - inline a private method call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22229/files
  - new: https://git.openjdk.org/jdk/pull/22229/files/62748947..d98fc871

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

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

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

From jpai at openjdk.org  Tue Nov 19 15:07:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 15:07:09 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module [v2]
In-Reply-To: <8ss2m29IkhAqiMMbvq2qd7EZWLJI4onKNKt_M3V1zp0=.9f95eba3-b384-46ae-9088-41dd16edcc1e@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
 <8ss2m29IkhAqiMMbvq2qd7EZWLJI4onKNKt_M3V1zp0=.9f95eba3-b384-46ae-9088-41dd16edcc1e@github.com>
Message-ID: <kRpBfrG-nS-8QZSit-Hy2DMyIzJNd7s9qawmvTS1-L0=.b86bc594-1932-4417-b754-dc752c37d941@github.com>

On Tue, 19 Nov 2024 14:48:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With only 1 caller the static matches() method could be inlined.

Done - I've removed that private method and inlined that implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/22229#issuecomment-2485965777

From rriggs at openjdk.org  Tue Nov 19 15:14:49 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 15:14:49 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module [v2]
In-Reply-To: <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
 <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
Message-ID: <pp1lPaWv4qHkMIYbUh1C37KJ4JXmqC0HgBGdmofLXC4=.c32ab1b7-59de-4b53-bdf0-37c52521feb1@github.com>

On Tue, 19 Nov 2024 15:07:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - inline a private method call

Looks good, thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22229#pullrequestreview-2445777399

From cstein at openjdk.org  Tue Nov 19 16:13:23 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 19 Nov 2024 16:13:23 GMT
Subject: RFR: 8278856: javac documentation does not mention use of Manifest
 class-path attribute
Message-ID: <oZ_p5e8xVW9KeZmjdnBZAtYBTjvsibHez8kaym4jnQs=.0a439a5b-b3ff-4de9-add5-d5d83f04bf34@github.com>

Please review this improvement to `javac`'s manpage, section **Directory Hierarchies**.

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

Commit messages:
 - 8278856: javac documentation does not mention use of Manifest class-path attribute

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

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

From prappo at openjdk.org  Tue Nov 19 16:13:40 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 19 Nov 2024 16:13:40 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of the
 methods
Message-ID: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>

Please review this essentially doc only change.

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

Commit messages:
 - Fix copy-paste issues
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22244/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22244&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8174840
  Stats: 90 lines in 6 files changed: 78 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22244/head:pull/22244

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

From cstein at openjdk.org  Tue Nov 19 16:15:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 19 Nov 2024 16:15:16 GMT
Subject: RFR: 8278856: javac documentation does not mention use of Manifest
 class-path attribute
In-Reply-To: <oZ_p5e8xVW9KeZmjdnBZAtYBTjvsibHez8kaym4jnQs=.0a439a5b-b3ff-4de9-add5-d5d83f04bf34@github.com>
References: <oZ_p5e8xVW9KeZmjdnBZAtYBTjvsibHez8kaym4jnQs=.0a439a5b-b3ff-4de9-add5-d5d83f04bf34@github.com>
Message-ID: <fwbI7D8BWqjoYj0_R38wmNfZMQa7hr6l9w3vTtbJrlY=.2b1eaf0e-cd8b-46c2-8191-cded27a79af1@github.com>

On Tue, 19 Nov 2024 16:06:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to `javac`'s manpage, section **Directory Hierarchies**.

src/jdk.compiler/share/man/javac.md line 1291:

> 1289: and the specified JAR file(s) exist, they are automatically inserted into the
> 1290: user class path after the JAR file. This rule also applies recursively to any
> 1291: new JAR files found. Consult the [JAR File Specification](../jar/jar.html#class-path-attribute)

The link to the `jar.html` file using the relative path `../jar/` should lead to the JAR File Specification document. For JavaSE 23, that specification documentation is located at https://docs.oracle.com/en/java/javase/23/docs/specs/jar/jar.html

How can I test that the online version, for 23 hosted at https://docs.oracle.com/en/java/javase/23/docs/specs/man/javac.html, contains the correct link target?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22243#discussion_r1848655668

From eirbjo at openjdk.org  Tue Nov 19 16:30:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 16:30:50 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
Message-ID: <dSX5F0cz58F6KPMi0eaZDqRmHQTGA_hjJBGk9lJXqS4=.b1cbd6d0-9e9e-4166-905e-e59988720bd8@github.com>

On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It's somewhat nicer to use \\s instead of space character in regex

Is the warning log when pandoc is not installed a bit loud?


% make images
Building target 'images' in configuration 'macosx-x86_64-server-release'
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Finished building target 'images' in configuration 'macosx-x86_64-server-release'

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2486187436

From darcy at openjdk.org  Tue Nov 19 16:45:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 19 Nov 2024 16:45:15 GMT
Subject: RFR: 8341935: javac states that -proc:full is the default but the
 default as of 23 is -proc:none [v2]
In-Reply-To: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
References: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
Message-ID: <fETqKNKv1AslueJVoKYcdqcSk48tlU9LRNrVwWJRNdU=.5cc80d05-fa1a-4357-b3b6-697cba48c92a@github.com>

> Update javac man page is describe current behavior; includes updates discussed in CSR [JDK-8321319](https://bugs.openjdk.org/browse/JDK-8321319) that were not included in the man pages for JDK 23 GA.

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/22227/files
  - new: https://git.openjdk.org/jdk/pull/22227/files/af54db1e..846d63f9

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

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

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

From darcy at openjdk.org  Tue Nov 19 16:45:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 19 Nov 2024 16:45:15 GMT
Subject: RFR: 8341935: javac states that -proc:full is the default but the
 default as of 23 is -proc:none [v2]
In-Reply-To: <XJZUgak4s-1sCn4P9qmxHHTURgJySJhMP8UG6-jWSxk=.02fa2fbe-53ec-449e-9cc0-a736a3c2e66a@github.com>
References: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
 <XJZUgak4s-1sCn4P9qmxHHTURgJySJhMP8UG6-jWSxk=.02fa2fbe-53ec-449e-9cc0-a736a3c2e66a@github.com>
Message-ID: <QPZDbcJRurOLx--joiIRyQCXN70wLzxQ91-9Xnij11g=.0c1a0275-23b9-40a0-8ea9-6486ddba0c13@github.com>

On Tue, 19 Nov 2024 14:13:19 GMT, Jan Lahoda <jlahoda 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/jdk.compiler/share/man/javac.md line 341:
> 
>> 339:     `-proc:none` means that compilation takes place without annotation
>> 340:     processing. `-proc:only` means that only annotation processing is done,
>> 341:     without any subsequent compilation. and
> 
> Nit:
> either:
> Suggestion:
> 
>     without any subsequent compilation.
> 
> 
> or:
> Suggestion:
> 
>     without any subsequent compilation. And
> 
> 
> (So that the sentence either starts with a capital letter, or with the `-proc:full`, as the other sentences here do.)

Thanks Jan; looking over the whole documentation for `-proc`, decided to format the information as a bulleted list instead. I think that better captures the intent anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22227#discussion_r1848701187

From vromero at openjdk.org  Tue Nov 19 17:28:51 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 19 Nov 2024 17:28:51 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
Message-ID: <4AaaK9B1sfh5kUPSrcGqc0mKpTwNgaC-YpCEs3vK_ok=.3aeb7e07-a003-4a63-8c1d-010badc8d107@github.com>

On Tue, 19 Nov 2024 16:08:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this essentially doc only change.

csr?

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

PR Comment: https://git.openjdk.org/jdk/pull/22244#issuecomment-2486320346

From acobbs at openjdk.org  Tue Nov 19 21:50:13 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 19 Nov 2024 21:50:13 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v7]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <FbyrPlsyHoA5n00uzetLuQwtOqeRmzjV6IRFSEveyRs=.fc5e3346-4055-4f93-b9a4-923fceded816@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Remove more unnecessary @SuppressWarnings annotations.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary warning suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update copyright years.
 - Remove a few more @SuppressWarnings annotations.
 - Remove a few more @SuppressWarnings annotations.
 - Update copyright years.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/81e43114...1905d6e3

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

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=06
  Stats: 197 lines in 100 files changed: 0 ins; 104 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From acobbs at openjdk.org  Tue Nov 19 22:29:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 19 Nov 2024 22:29:56 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v5]
In-Reply-To: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
Message-ID: <tZOnqxZmCIqx0_JJkh_YMdE7KRU3AXcWIDOCWKXHN84=.19909c4c-1a1f-4824-a03c-307626b4aa8c@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Apply change that was missed somehow.
 - Undo change that will be moved to the core-libs branch.
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21851/files
  - new: https://git.openjdk.org/jdk/pull/21851/files/8b95d372..af81a548

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

  Stats: 85389 lines in 1301 files changed: 40812 ins; 38049 del; 6528 mod
  Patch: https://git.openjdk.org/jdk/pull/21851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21851/head:pull/21851

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

From jlahoda at openjdk.org  Tue Nov 19 22:48:17 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 19 Nov 2024 22:48:17 GMT
Subject: RFR: 8341935: javac states that -proc:full is the default but the
 default as of 23 is -proc:none [v2]
In-Reply-To: <fETqKNKv1AslueJVoKYcdqcSk48tlU9LRNrVwWJRNdU=.5cc80d05-fa1a-4357-b3b6-697cba48c92a@github.com>
References: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
 <fETqKNKv1AslueJVoKYcdqcSk48tlU9LRNrVwWJRNdU=.5cc80d05-fa1a-4357-b3b6-697cba48c92a@github.com>
Message-ID: <uD9QNdZGEor66f47-Z2Hki_T8pRxQD4yzRwGh6aN3ws=.bea02c4c-8607-4d95-a0f5-ba00a26d8962@github.com>

On Tue, 19 Nov 2024 16:45:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Update javac man page is describe current behavior; includes updates discussed in CSR [JDK-8321319](https://bugs.openjdk.org/browse/JDK-8321319) that were not included in the man pages for JDK 23 GA.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22227#pullrequestreview-2446797466

From asemenyuk at openjdk.org  Tue Nov 19 22:58:37 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 22:58:37 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v7]
In-Reply-To: <FbyrPlsyHoA5n00uzetLuQwtOqeRmzjV6IRFSEveyRs=.fc5e3346-4055-4f93-b9a4-923fceded816@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <FbyrPlsyHoA5n00uzetLuQwtOqeRmzjV6IRFSEveyRs=.fc5e3346-4055-4f93-b9a4-923fceded816@github.com>
Message-ID: <orMOnvkrksdnnyBuius74dW6mmg09oQWeoq3JaDSldA=.b65c151e-365d-4dde-bf04-8f5c09cb2018@github.com>

On Tue, 19 Nov 2024 21:50:13 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary warning suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update copyright years.
>  - Remove a few more @SuppressWarnings annotations.
>  - Remove a few more @SuppressWarnings annotations.
>  - Update copyright years.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/81e43114...1905d6e3

jpackage looks good. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2486917552

From darcy at openjdk.org  Wed Nov 20 00:09:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 20 Nov 2024 00:09:21 GMT
Subject: Integrated: 8341935: javac states that -proc:full is the default but
 the default as of 23 is -proc:none
In-Reply-To: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
References: <LfZZUV_gvRIHU1aLubbrNAxZgrfYNl7gH0v3RIPWQ8U=.15c875bb-6e3e-4079-b823-75f6fd3b7826@github.com>
Message-ID: <HwmEjV_vmOraUkjFGanjwkDkMQOwN1y81A8P7JrNMgQ=.36dcacb7-aa56-40da-ab27-620a0ee7d288@github.com>

On Tue, 19 Nov 2024 06:48:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javac man page is describe current behavior; includes updates discussed in CSR [JDK-8321319](https://bugs.openjdk.org/browse/JDK-8321319) that were not included in the man pages for JDK 23 GA.

This pull request has now been integrated.

Changeset: f5252900
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f525290000bf8583617047aaeb894bf90332d2e9
Stats:     33 lines in 1 file changed: 19 ins; 0 del; 14 mod

8341935: javac states that -proc:full is the default but the default as of 23 is -proc:none

Reviewed-by: jlahoda

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

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

From darcy at openjdk.org  Wed Nov 20 05:40:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 20 Nov 2024 05:40:21 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
Message-ID: <lXFnRZfBNtMK7kwxJLiXl9RApLrBzeHokxXhOcLtLm4=.2239bebe-845e-4481-9582-8e3b38eeee35@github.com>

On Tue, 19 Nov 2024 16:08:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this essentially doc only change.

test/langtools/tools/javac/processing/model/util/elements/overrides/S.java line 24:

> 22:  */
> 23: 
> 24: public class S {

If all these testing types could be put into the single test file, that would be preferable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1849561624

From darcy at openjdk.org  Wed Nov 20 05:43:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 20 Nov 2024 05:43:16 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
Message-ID: <GprPIm__gzxyzpq73llmIKvgDZNrf3JoZJAHRhoQrIw=.8fa90dff-99c4-4b79-bb78-96bae2f52953@github.com>

On Tue, 19 Nov 2024 16:08:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this essentially doc only change.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 784:

> 782:      * method's return type, listed exceptions, or, to some extent, access
> 783:      * modifiers. These are additional requirements checked by the compiler
> 784:      * (see {@jls 8.4.8.3}).

Nit: use something like

`(see JLS {@jls 8.4.8.3}).`

as currently written, this would just render a section number pointing to a page.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1849563865

From darcy at openjdk.org  Wed Nov 20 06:01:14 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 20 Nov 2024 06:01:14 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
Message-ID: <x6Kh-gVvYC7AqDrthftNnbFFmftPFfr3TA41RoRNuKM=.82f05ab2-230a-4da2-8590-a030d3ed291d@github.com>

On Tue, 19 Nov 2024 16:08:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this essentially doc only change.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 790:

> 788:      * requirements might not be checked, potentially causing this method
> 789:      * to return a false positive.
> 790:      *

The gist of this paragraph is good; some refinement is needed to not imply any particular requirements on the implementation, something like :"An implementation [of annotation processing] may choose to not check the additional requirements [under some limited conditions]".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1849591890

From jlahoda at openjdk.org  Wed Nov 20 07:36:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 20 Nov 2024 07:36:15 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <x6Kh-gVvYC7AqDrthftNnbFFmftPFfr3TA41RoRNuKM=.82f05ab2-230a-4da2-8590-a030d3ed291d@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <x6Kh-gVvYC7AqDrthftNnbFFmftPFfr3TA41RoRNuKM=.82f05ab2-230a-4da2-8590-a030d3ed291d@github.com>
Message-ID: <KC3HYG8t-Ju14VeVP1lSR3w0RjkRYAZNB3ckxjEwHVY=.e8df81c2-2b6c-40a7-9a57-3f1753975794@github.com>

On Wed, 20 Nov 2024 05:58:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review this essentially doc only change.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 790:
> 
>> 788:      * requirements might not be checked, potentially causing this method
>> 789:      * to return a false positive.
>> 790:      *
> 
> The gist of this paragraph is good; some refinement is needed to not imply any particular requirements on the implementation, something like :"An implementation [of annotation processing] may choose to not check the additional requirements [under some limited conditions]".

Please correct me if I am wrong, but:
- reading JLS 8.4.8.1 and JLS 8.4.8.3, 8.4.8.1 defines the "overrides" relation between two methods, and this relation does not include return type, throw exception, and to some degree modifiers. These are additional conditions, but these are conditions like "if `m_C` overrides `m_A` (when viewed from `C`)", and <some> condition is met a compile-time error occurs. I.e. the fact that there e.g. an incorrect throws clause does not mean that `m_C` does not override `m_A` (when viewed from `C`), it only means a compile-time error occurs.
- the `Elements.overrides` method strives to implement the relation, not the additional checks.

I agree it is reasonable to include a warning that only the relation is checked, not the additional constraints. But I find the wording "has not been sufficiently compiled" fairly confusing. I would try to point out this method only implements the "overrides" relation, not the additional constraints that are not part of the relation as such, as defined in JLS 8.4.8.1 and JLS 8.4.8.3. And hence, the two methods may satisfy the "overrides" relation, but still be part of erroneous code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1849699007

From jlahoda at openjdk.org  Wed Nov 20 10:10:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 20 Nov 2024 10:10:29 GMT
Subject: RFR: 8340145: Problem with generic pattern matching results in
 internal compiler error [v2]
In-Reply-To: <ncTRRDat9Z7BAh1xDV4Ptkq6kR4eBcC4IT11U17Oc1U=.fa3a86ac-efe5-4f4f-91a8-f3cb8712aaa2@github.com>
References: <i6R2OsULUTEAiIFgCfcvL28cawGcQ9ZkrrYjTU3D8Rk=.bc4e9913-845b-48fe-9995-5e8ec7620190@github.com>
 <ncTRRDat9Z7BAh1xDV4Ptkq6kR4eBcC4IT11U17Oc1U=.fa3a86ac-efe5-4f4f-91a8-f3cb8712aaa2@github.com>
Message-ID: <6OqIFpmD5pqN9JppzZ_okOMpXLil5q5i3KmhOmPM8AQ=.48fe0e88-45fa-479b-98a5-083a28450921@github.com>

On Mon, 18 Nov 2024 14:09:37 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;
>>   };
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test with multiple bounds

Looks good to me. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21606#pullrequestreview-2448147344

From abimpoudis at openjdk.org  Wed Nov 20 10:33:26 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 20 Nov 2024 10:33:26 GMT
Subject: Integrated: 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: <XDqRV3ofu37_roTCxM3JwnlTH70sYSt2k0pMqYz3ybY=.d444357d-555b-4bb5-aa91-b2e2c4dfe0cd@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;
>   };
> }

This pull request has now been integrated.

Changeset: 3a4a9b7a
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a4a9b7af7693a836c3caa3112d0d68100535b28
Stats:     67 lines in 2 files changed: 66 ins; 0 del; 1 mod

8340145: Problem with generic pattern matching results in internal compiler error

Reviewed-by: jlahoda

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

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

From jpai at openjdk.org  Wed Nov 20 12:46:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Nov 2024 12:46:20 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module [v2]
In-Reply-To: <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
 <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
Message-ID: <ALWBXiPn9nG_1s3F7h-1R0zJSAav4nbDKeBrk_9k4sQ=.48309d96-d48b-4f7e-b1ad-e3baae789adc@github.com>

On Tue, 19 Nov 2024 15:07:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - inline a private method call

Thank you Roger for the review. 

Could someone from the compiler team too take a look and see if this trivial change looks OK?

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

PR Comment: https://git.openjdk.org/jdk/pull/22229#issuecomment-2488488047

From prappo at openjdk.org  Wed Nov 20 12:50:47 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 20 Nov 2024 12:50:47 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v2]
In-Reply-To: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
Message-ID: <HpGyhh6eyEVn7eleCVskRLyteDsWQAIjmdSSWUCV1eI=.b3d2e73b-8b78-4a42-8707-9061d0274fdc@github.com>

> Please review this essentially doc only change.

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

  Respond to feedback
  
   - Reduce the number of files
   - Rephrase apiNote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22244/files
  - new: https://git.openjdk.org/jdk/pull/22244/files/a4f0b53f..a9a4309b

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

  Stats: 105 lines in 6 files changed: 15 ins; 85 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22244/head:pull/22244

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

From prappo at openjdk.org  Wed Nov 20 12:57:25 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 20 Nov 2024 12:57:25 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v2]
In-Reply-To: <lXFnRZfBNtMK7kwxJLiXl9RApLrBzeHokxXhOcLtLm4=.2239bebe-845e-4481-9582-8e3b38eeee35@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <lXFnRZfBNtMK7kwxJLiXl9RApLrBzeHokxXhOcLtLm4=.2239bebe-845e-4481-9582-8e3b38eeee35@github.com>
Message-ID: <i6zlNMN92vtNDSa7ynmAA7C4OcdY6egdMbd0wZzbTv4=.9993b4bd-5eab-4f34-9777-f6b855b1e5b9@github.com>

On Wed, 20 Nov 2024 05:37:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to feedback
>>   
>>    - Reduce the number of files
>>    - Rephrase apiNote
>
> test/langtools/tools/javac/processing/model/util/elements/overrides/S.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: public class S {
> 
> If all these testing types could be put into the single test file, that would be preferable.

I condensed all the testing types in just one file. I couldn't put them further, in `TestOverrides.java` itself, because they would make it non-compilable. Additionally, I removed `public` from `class S` for symmetry: it shouldn't be special.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1850268703

From prappo at openjdk.org  Wed Nov 20 13:00:29 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 20 Nov 2024 13:00:29 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v2]
In-Reply-To: <KC3HYG8t-Ju14VeVP1lSR3w0RjkRYAZNB3ckxjEwHVY=.e8df81c2-2b6c-40a7-9a57-3f1753975794@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <x6Kh-gVvYC7AqDrthftNnbFFmftPFfr3TA41RoRNuKM=.82f05ab2-230a-4da2-8590-a030d3ed291d@github.com>
 <KC3HYG8t-Ju14VeVP1lSR3w0RjkRYAZNB3ckxjEwHVY=.e8df81c2-2b6c-40a7-9a57-3f1753975794@github.com>
Message-ID: <0OiB14tqQmZaUdjf-zVQTdfIFU98WGERA0kxQKgAm2U=.e37f88fd-bec2-4194-aeff-23583145bfd2@github.com>

On Wed, 20 Nov 2024 07:33:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 790:
>> 
>>> 788:      * requirements might not be checked, potentially causing this method
>>> 789:      * to return a false positive.
>>> 790:      *
>> 
>> The gist of this paragraph is good; some refinement is needed to not imply any particular requirements on the implementation, something like :"An implementation [of annotation processing] may choose to not check the additional requirements [under some limited conditions]".
>
> Please correct me if I am wrong, but:
> - reading JLS 8.4.8.1 and JLS 8.4.8.3, 8.4.8.1 defines the "overrides" relation between two methods, and this relation does not include return type, throw exception, and to some degree modifiers. These are additional conditions, but these are conditions like "if `m_C` overrides `m_A` (when viewed from `C`)", and <some> condition is met a compile-time error occurs. I.e. the fact that there e.g. an incorrect throws clause does not mean that `m_C` does not override `m_A` (when viewed from `C`), it only means a compile-time error occurs.
> - the `Elements.overrides` method strives to implement the relation, not the additional checks.
> 
> I agree it is reasonable to include a warning that only the relation is checked, not the additional constraints. But I find the wording "has not been sufficiently compiled" fairly confusing. I would try to point out this method only implements the "overrides" relation, not the additional constraints that are not part of the relation as such, as defined in JLS 8.4.8.1 and JLS 8.4.8.3. And hence, the two methods may satisfy the "overrides" relation, but still be part of erroneous code.

> The gist of this paragraph is good; some refinement is needed to not imply any particular requirements on the implementation, something like :"An implementation [of annotation processing] may choose to not check the additional requirements [under some limited conditions]".

I tried to rephrase it the way you seem to have proposed; is that better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1850272353

From ihse at openjdk.org  Wed Nov 20 16:24:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Nov 2024 16:24:30 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <dSX5F0cz58F6KPMi0eaZDqRmHQTGA_hjJBGk9lJXqS4=.b1cbd6d0-9e9e-4166-905e-e59988720bd8@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
 <dSX5F0cz58F6KPMi0eaZDqRmHQTGA_hjJBGk9lJXqS4=.b1cbd6d0-9e9e-4166-905e-e59988720bd8@github.com>
Message-ID: <Lm9JH4ilJQSzUz6NveUUZGWppeHKqun_9SXOSwcwhhs=.125acdbf-545e-4d79-aabf-da2bcdc0d6a6@github.com>

On Tue, 19 Nov 2024 16:27:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   It's somewhat nicer to use \\s instead of space character in regex
>
> Is the warning log when pandoc is not installed a bit loud?
> 
> 
> % make images
> Building target 'images' in configuration 'macosx-x86_64-server-release'
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Finished building target 'images' in configuration 'macosx-x86_64-server-release'

@eirbjo Yes, that was not intentional. https://bugs.openjdk.org/browse/JDK-8344559.

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

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2489029819

From jlahoda at openjdk.org  Wed Nov 20 17:40:14 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 20 Nov 2024 17:40:14 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module [v2]
In-Reply-To: <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
 <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
Message-ID: <bfIVFsXAE_23T12hp3ftgGVUg8aESgWD1dT9Go6ZmBk=.83e741c8-77fd-4dc8-be01-e5fc367119f7@github.com>

On Tue, 19 Nov 2024 15:07:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - inline a private method call

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22229#pullrequestreview-2449303613

From jjg at openjdk.org  Thu Nov 21 00:26:17 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 21 Nov 2024 00:26:17 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module [v2]
In-Reply-To: <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
 <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
Message-ID: <z61pbOa8OjElcnPeb47-QGBZya9jR2DF2_Q3m5i2eek=.ccf90db8-a49c-4142-9f89-0c319e1fca70@github.com>

On Tue, 19 Nov 2024 15:07:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - inline a private method call

Looks good to em

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22229#pullrequestreview-2449979290

From smarks at openjdk.org  Thu Nov 21 00:38:34 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 21 Nov 2024 00:38:34 GMT
Subject: RFR: 8272339: Update notes section from serialver man page
Message-ID: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>

Quick doc-only change. I don't think this needs a CSR, since it contains changes only to the "notes" section, which is non-normative.

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

Commit messages:
 - JDK-8272339 Update notes section from serialver man page

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

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

From jpai at openjdk.org  Thu Nov 21 00:52:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 00:52:20 GMT
Subject: RFR: 8344471: Remove SecurityManager related code from
 java.compiler module [v2]
In-Reply-To: <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
 <VJdnL3PkeT25Fa4_rI7v7PxEtHvfSnAqsQpX-Bg2T7U=.464945a2-df10-4fcf-b845-89a4ddd70576@github.com>
Message-ID: <reWpkNX2vV0SOYwcy_GmCODRSKSbKcbORbO9mHf_PYw=.c02ce5c7-08f6-49bf-ac18-97b0fcdaa4bc@github.com>

On Tue, 19 Nov 2024 15:07:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - inline a private method call

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22229#issuecomment-2489838180

From jpai at openjdk.org  Thu Nov 21 00:52:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 00:52:20 GMT
Subject: Integrated: 8344471: Remove SecurityManager related code from
 java.compiler module
In-Reply-To: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
References: <-Yxi6j4gPKVnIliIE6GucGHmCA2QdPF8M91PXRAc4uY=.c103e2ee-2257-4d74-a8c1-fc8a4a194427@github.com>
Message-ID: <j6AH_0RsGtyZGZJnviZfNiJGu_SGUIGQqWjM7tbDiLQ=.1834242b-fb9d-4a4b-bc39-75bffdb2085b@github.com>

On Tue, 19 Nov 2024 08:00:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up the SecurityManager related usages from the `java.compiler` module? 
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

This pull request has now been integrated.

Changeset: a599c301
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a599c30171fe2b1557ad967d61048656fdb8c752
Stats:     21 lines in 1 file changed: 1 ins; 19 del; 1 mod

8344471: Remove SecurityManager related code from java.compiler module

Reviewed-by: rriggs, jlahoda, jjg

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

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

From liach at openjdk.org  Thu Nov 21 03:59:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Nov 2024 03:59:14 GMT
Subject: RFR: 8272339: Update notes section from serialver man page
In-Reply-To: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
References: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
Message-ID: <aupg9bMrbD2jUhA5Ax9XWwyK5FrTdDdlVXVWURqmmWk=.3e95bd25-ccf1-4bba-965c-b3d53c3fb077@github.com>

On Thu, 21 Nov 2024 00:32:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Quick doc-only change. I don't think this needs a CSR, since it contains changes only to the "notes" section, which is non-normative.

src/jdk.compiler/share/man/serialver.md line 63:

> 61:     48 MB.
> 62: 
> 63: ## Warning

Should we move the warning more upfront?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22289#discussion_r1851279549

From jlahoda at openjdk.org  Thu Nov 21 12:26:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 21 Nov 2024 12:26:19 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v2]
In-Reply-To: <0OiB14tqQmZaUdjf-zVQTdfIFU98WGERA0kxQKgAm2U=.e37f88fd-bec2-4194-aeff-23583145bfd2@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <x6Kh-gVvYC7AqDrthftNnbFFmftPFfr3TA41RoRNuKM=.82f05ab2-230a-4da2-8590-a030d3ed291d@github.com>
 <KC3HYG8t-Ju14VeVP1lSR3w0RjkRYAZNB3ckxjEwHVY=.e8df81c2-2b6c-40a7-9a57-3f1753975794@github.com>
 <0OiB14tqQmZaUdjf-zVQTdfIFU98WGERA0kxQKgAm2U=.e37f88fd-bec2-4194-aeff-23583145bfd2@github.com>
Message-ID: <ViPXovZiZ2Ki0Agi-bijZH5-STWZXK_f1Ptt7gQmmOs=.fca41ecb-1ebf-468e-9ddd-f65f10d6e87e@github.com>

On Wed, 20 Nov 2024 12:57:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please correct me if I am wrong, but:
>> - reading JLS 8.4.8.1 and JLS 8.4.8.3, 8.4.8.1 defines the "overrides" relation between two methods, and this relation does not include return type, throw exception, and to some degree modifiers. These are additional conditions, but these are conditions like "if `m_C` overrides `m_A` (when viewed from `C`)", and <some> condition is met a compile-time error occurs. I.e. the fact that there e.g. an incorrect throws clause does not mean that `m_C` does not override `m_A` (when viewed from `C`), it only means a compile-time error occurs.
>> - the `Elements.overrides` method strives to implement the relation, not the additional checks.
>> 
>> I agree it is reasonable to include a warning that only the relation is checked, not the additional constraints. But I find the wording "has not been sufficiently compiled" fairly confusing. I would try to point out this method only implements the "overrides" relation, not the additional constraints that are not part of the relation as such, as defined in JLS 8.4.8.1 and JLS 8.4.8.3. And hence, the two methods may satisfy the "overrides" relation, but still be part of erroneous code.
>
>> The gist of this paragraph is good; some refinement is needed to not imply any particular requirements on the implementation, something like :"An implementation [of annotation processing] may choose to not check the additional requirements [under some limited conditions]".
> 
> I tried to rephrase it the way you seem to have proposed; is that better?

My idea was something along these lines:

> This method implements the overrides relation as specified in JLS 8.4.8.1. It does not implement the additional compile-time checks that Java compilers follow, specified in JLS 8.4.8.1 and 8.4.8.3, in particular the additional constraints on thrown types, return types and those constrains on method modifiers not directly bound to the overriding relation as such.

As I understand now, there may be implementations that also do the additional checks, so if we that should be permitted, the it could say "may not", instead of "does not".

Not sure if this makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1851961847

From prappo at openjdk.org  Thu Nov 21 13:57:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 21 Nov 2024 13:57:56 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v3]
In-Reply-To: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
Message-ID: <mOvr18uhJbOPABS1VY30Vp9aY_z6Fom0TODIbewBAH8=.5eee8fc4-d0f6-4bd4-ba11-13e9f5514821@github.com>

> Please review this essentially doc only change.

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

  Improve characterisation testcases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22244/files
  - new: https://git.openjdk.org/jdk/pull/22244/files/a9a4309b..add209c4

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

  Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22244/head:pull/22244

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

From prappo at openjdk.org  Thu Nov 21 14:01:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 21 Nov 2024 14:01:16 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v3]
In-Reply-To: <ViPXovZiZ2Ki0Agi-bijZH5-STWZXK_f1Ptt7gQmmOs=.fca41ecb-1ebf-468e-9ddd-f65f10d6e87e@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <x6Kh-gVvYC7AqDrthftNnbFFmftPFfr3TA41RoRNuKM=.82f05ab2-230a-4da2-8590-a030d3ed291d@github.com>
 <KC3HYG8t-Ju14VeVP1lSR3w0RjkRYAZNB3ckxjEwHVY=.e8df81c2-2b6c-40a7-9a57-3f1753975794@github.com>
 <0OiB14tqQmZaUdjf-zVQTdfIFU98WGERA0kxQKgAm2U=.e37f88fd-bec2-4194-aeff-23583145bfd2@github.com>
 <ViPXovZiZ2Ki0Agi-bijZH5-STWZXK_f1Ptt7gQmmOs=.fca41ecb-1ebf-468e-9ddd-f65f10d6e87e@github.com>
Message-ID: <zbcqyXcUGjMBhy_ALgjw9Wr3MUk-4FV7u5-IafJyR8I=.1115a4e0-1ccf-4a4d-b31c-83c15aa7a3bd@github.com>

On Thu, 21 Nov 2024 12:23:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> The gist of this paragraph is good; some refinement is needed to not imply any particular requirements on the implementation, something like :"An implementation [of annotation processing] may choose to not check the additional requirements [under some limited conditions]".
>> 
>> I tried to rephrase it the way you seem to have proposed; is that better?
>
> My idea was something along these lines:
> 
>> This method implements the overrides relation as specified in JLS 8.4.8.1. It does not implement the additional compile-time checks that Java compilers follow, specified in JLS 8.4.8.1 and 8.4.8.3, in particular the additional constraints on thrown types, return types and those constrains on method modifiers not directly bound to the overriding relation as such.
> 
> As I understand now, there may be implementations that also do the additional checks, so if we that should be permitted, the it could say "may not", instead of "does not".
> 
> Not sure if this makes sense.

I hear you: the Java Language Specification separates "overrides" from those additional checks.

So, if `Elements.overrides` models "overrides", it is under no obligation to perform those checks. Moreover, I think, it might not be always possible to perform them. Still, I believe we should __NOT__ say that this method always skips them. So your "may not" is better.

Here's why. Whether any additional checks are performed seems to be implementation-dependant. For example, here's how ECJ (Eclipse) runs that same test (after some necessary modifications to decouple the test from our test infrastructure):


% java -jar ecj-4.33.jar --release 22 -classpath . -processor TestOverrides -proc:only S.java
1. ERROR: protected void m()  does not override public void m()  from T1
2. ERROR: void m()  does not override public void m()  from T2
3. ERROR: private void m()  does not override public void m()  from T3
3 problems (3 errors)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22244#discussion_r1852170806

From rriggs at openjdk.org  Thu Nov 21 15:16:17 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Nov 2024 15:16:17 GMT
Subject: RFR: 8272339: Update notes section from serialver man page
In-Reply-To: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
References: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
Message-ID: <OgEtsORzeBawT9pjrKhUJj8VhvpeiQoHtK_WE7QfX30=.133de0e6-1f13-4f11-9e79-994920a51c1a@github.com>

On Thu, 21 Nov 2024 00:32:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Quick doc-only change. I don't think this needs a CSR, since it contains changes only to the "notes" section, which is non-normative.

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22289#pullrequestreview-2451799756

From duke at openjdk.org  Thu Nov 21 15:26:16 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Thu, 21 Nov 2024 15:26:16 GMT
Subject: RFR: 8272339: Update notes section from serialver man page
In-Reply-To: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
References: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
Message-ID: <O9BGoHBh3-Dxnb2x-RG_U8mqJJoUJLAS6Jh07ohvJq4=.3a08a458-0633-4df4-bd7e-8f5312c7a6a0@github.com>

On Thu, 21 Nov 2024 00:32:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Quick doc-only change. I don't think this needs a CSR, since it contains changes only to the "notes" section, which is non-normative.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/22289#pullrequestreview-2451828241

From vromero at openjdk.org  Thu Nov 21 16:30:18 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 21 Nov 2024 16:30:18 GMT
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods [v2]
In-Reply-To: <jslh8Bcc29AEfwfBiENX5XdJl05MSQboLjUlel6_qQM=.ce20e51e-a556-4c5f-a34d-ad748bac3ba6@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
 <jslh8Bcc29AEfwfBiENX5XdJl05MSQboLjUlel6_qQM=.ce20e51e-a556-4c5f-a34d-ad748bac3ba6@github.com>
Message-ID: <KcH4OGY_SeWhCU-jwG-G0_hdb_zMll-EiNiqxpin4kA=.847d3306-537e-4735-9113-479da0c4ef10@github.com>

On Mon, 18 Nov 2024 11:47:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider a case where a new preview interface is introduced to JDK, and an existing non-preview class is retrofitted to use it. I.e. a case like:
>> 
>> 
>> //JDK types:
>> @PreviewFeature(...)
>> public interface NewAPI {
>>     public default void test() {}
>> }
>> public class ExistingRetrofittedClass implements NewAPI {}
>> 
>> //user type:
>> class Test {
>>     void t(ExistingRetrofittedClass c) {
>>         c.test();
>>     }
>> }
>> 
>> 
>> There is currently no error or warning about the invocation of the test method, as the method itself is not marked as preview, and the receiver is not preview either.
>> 
>> The proposal herein is that invoking a method on a receiver that is not of preview type itself, but the method is declared in a preview class or interface, the method will be considered to be a preview method, and the appropriate error or warning will be printed. Similar behavior is implementing for dereferencing fields.
>> 
>> 
>> Similarly when implementing or overriding such "effectively" preview methods, like:
>> 
>> 
>> //user types:
>> class Test1 extends ExistingRetrofittedClass {
>>     public void test() {}
>> }
>> 
>> 
>> java also does not produce any error or warning. If the method itself would be marked as preview, an error or warning would be printed.
>> 
>> The proposal herein is to produce an error or warning for a method declared inside a non-preview class or interface, which directly overrides a method declared inside a preview class or interface.
>> 
>> In particular, for the two example above, javac is currently producing no errors. With the change proposed herein, javac will produce output like (with no `--enable-preview`):
>> 
>> 
>> src/Test1.java:4: error: test() is a preview API and is disabled by default.
>>     public void test() {}
>>                 ^
>>   (use --enable-preview to enable preview APIs)
>> src/Test.java:5: error: test() is a preview API and is disabled by default.
>>         c.test();
>>          ^
>>   (use --enable-preview to enable preview APIs)
>> 2 errors
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21953#pullrequestreview-2452019520

From vromero at openjdk.org  Thu Nov 21 16:56:20 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 21 Nov 2024 16:56:20 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <WzQ2Z8l1lMxs5ufhxLdQkVyXBmwn7JaUPODh9Q3szL4=.4bd8af79-e868-4320-bb91-38290a0f8d73@github.com>

On Wed, 13 Nov 2024 22:25:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which does some minor refactoring to the compiler:
> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
> 
> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 267:

> 265:     }
> 266: 
> 267:     private void doAnalyzeTree(Env<AttrContext> env) {

the doAnalyzeTree method doesn't seems to add much value

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22088#discussion_r1852514258

From acobbs at openjdk.org  Thu Nov 21 17:36:19 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 21 Nov 2024 17:36:19 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation
In-Reply-To: <WzQ2Z8l1lMxs5ufhxLdQkVyXBmwn7JaUPODh9Q3szL4=.4bd8af79-e868-4320-bb91-38290a0f8d73@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
 <WzQ2Z8l1lMxs5ufhxLdQkVyXBmwn7JaUPODh9Q3szL4=.4bd8af79-e868-4320-bb91-38290a0f8d73@github.com>
Message-ID: <hDn6T4MsZ3vDFDiDN2gkxXmFb24TLmIeq9p0sWnge8I=.dcba2b3d-d34f-40e5-a785-36587007cdb7@github.com>

On Thu, 21 Nov 2024 16:53:32 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this patch which does some minor refactoring to the compiler:
>> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
>> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
>> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
>> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
>> 
>> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 267:
> 
>> 265:     }
>> 266: 
>> 267:     private void doAnalyzeTree(Env<AttrContext> env) {
> 
> the doAnalyzeTree method doesn't seems to add much value

This class is being refactored to be a singleton, so now it's crucial that it cleans itself up after each execution, and that required adding the new try/finally structure to ensure this.

It seemed cleaner to have two separate methods, because that more clearly separates the clean up step from the analysis step (also this avoids generating 200 lines of whitespace indention diffs).

But of course this is just a style thing - so I'm happy to inline `doAnalyzeTree()` if you think that's more consistent with the compiler style.

Thanks for taking a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22088#discussion_r1852581567

From smarks at openjdk.org  Thu Nov 21 21:00:15 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 21 Nov 2024 21:00:15 GMT
Subject: RFR: 8272339: Update notes section from serialver man page
In-Reply-To: <aupg9bMrbD2jUhA5Ax9XWwyK5FrTdDdlVXVWURqmmWk=.3e95bd25-ccf1-4bba-965c-b3d53c3fb077@github.com>
References: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
 <aupg9bMrbD2jUhA5Ax9XWwyK5FrTdDdlVXVWURqmmWk=.3e95bd25-ccf1-4bba-965c-b3d53c3fb077@github.com>
Message-ID: <PRIRmhS7A0De2o4oKU0ublJ512eQ7Vp068u_Je-T0IM=.0d4d5011-5a00-4d54-a792-559efedd9ebc@github.com>

On Thu, 21 Nov 2024 03:56:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Quick doc-only change. I don't think this needs a CSR, since it contains changes only to the "notes" section, which is non-normative.
>
> src/jdk.compiler/share/man/serialver.md line 63:
> 
>> 61:     48 MB.
>> 62: 
>> 63: ## Warning
> 
> Should we move the warning more upfront?

I thought it was sufficient to change the "Notes" heading to "Warning" and to leave it in place. The tool docs are styled after Unix "man pages" which typically have Name, Synopsis, Description, Options (sometimes the last two are swapped), and then possibly other sections if the doc is long, followed by things like Notes and Warnings at the end. Of course we needn't adhere to this structure slavishly. If it were sufficiently important we could diverge from the usual structure, but in this case it doesn't seem to me that the severity of the issue is so high that we need to place the warning more prominently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22289#discussion_r1852885770

From smarks at openjdk.org  Thu Nov 21 21:08:19 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 21 Nov 2024 21:08:19 GMT
Subject: Integrated: 8272339: Update notes section from serialver man page
In-Reply-To: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
References: <tXIGXhocY_f3Z6pUMQ1Oiw5wYmdiYGH2YUi-J2xX0Vw=.fa7db331-60b8-479e-b090-079cb7022f45@github.com>
Message-ID: <raxMCzdPHqHsM167zX5-usydNJ_veHRnevGTkX6wzZo=.5b3ad630-10f3-400c-bc40-c941bc0e4187@github.com>

On Thu, 21 Nov 2024 00:32:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Quick doc-only change. I don't think this needs a CSR, since it contains changes only to the "notes" section, which is non-normative.

This pull request has now been integrated.

Changeset: 22149063
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22149063101f0c617d8ccaace659671a645d402e
Stats:     12 lines in 1 file changed: 0 ins; 7 del; 5 mod

8272339: Update notes section from serialver man page

Reviewed-by: rriggs

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

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

From darcy at openjdk.org  Fri Nov 22 03:55:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 22 Nov 2024 03:55:15 GMT
Subject: RFR: 8343882: BasicAnnoTests doesn't handle multiple annotations
 at the same position
In-Reply-To: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
References: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
Message-ID: <zxWadgMDlEO37OcY4uutma4c0se_wHQhlSAnsVv1_og=.a2d0afb6-855b-4eac-aa19-5c5532238d86@github.com>

On Sat, 9 Nov 2024 20:53:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this fix to `test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java`. Due to a long-standing bug in the test, some test cases were not being processed if there were multiple assertions for annotations at the same position. All existing cases in the test still pass after this fix.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21998#pullrequestreview-2453270045

From cushon at openjdk.org  Fri Nov 22 04:05:12 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 22 Nov 2024 04:05:12 GMT
Subject: RFR: 8343882: BasicAnnoTests doesn't handle multiple annotations
 at the same position [v2]
In-Reply-To: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
References: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
Message-ID: <XkdIMClKiv-nz9VSfL_rLZtBXkeEGzm_MOdcjMQlCTo=.f20d28ef-8b47-4174-af44-55590521766a@github.com>

> Please consider this fix to `test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java`. Due to a long-standing bug in the test, some test cases were not being processed if there were multiple assertions for annotations at the same position. All existing cases in the test still pass after this fix.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8343882
 - 8343882: BasicAnnoTests doesn't handle multiple annotations at the same position

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21998/files
  - new: https://git.openjdk.org/jdk/pull/21998/files/f410fa14..3f215817

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

  Stats: 187622 lines in 3928 files changed: 61226 ins; 111841 del; 14555 mod
  Patch: https://git.openjdk.org/jdk/pull/21998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21998/head:pull/21998

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

From jlahoda at openjdk.org  Fri Nov 22 13:47:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 22 Nov 2024 13:47:25 GMT
Subject: RFR: 8344647: JDK-8335989 causes a bad requires flag: ACC_TRANSITIVE
 error for java.se
Message-ID: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>

There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.

This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.

So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

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

Commit messages:
 - Fixing test.
 - 8344647: JDK-8335989 causes a bad requires flag: ACC_TRANSITIVE error for java.se

Changes: https://git.openjdk.org/jdk/pull/22322/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22322&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344647
  Stats: 61 lines in 8 files changed: 51 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22322.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22322/head:pull/22322

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

From mistria at redhat.com  Fri Nov 22 21:47:04 2024
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 22 Nov 2024 22:47:04 +0100
Subject: -proceedOnError option (like ECJ) ?
In-Reply-To: <CAFr6BZQ5JLjvAaMZeXfEvpcSrytRkBSpHbstt+voWGer-ggaEw@mail.gmail.com>
References: <CAFr6BZSk7a22FWrZy6QakmJ0OA5-sOKaga6DYpEJRqSZL4rnSg@mail.gmail.com>
 <3344b2bd-4190-41ac-ae36-ec1afb272c8d@oracle.com>
 <4756ee9e-572d-4a94-8dd3-f88de3366421@oracle.com>
 <CAFr6BZQ5JLjvAaMZeXfEvpcSrytRkBSpHbstt+voWGer-ggaEw@mail.gmail.com>
Message-ID: <CAFr6BZTgyz_-X1PWeJ6yKKuVtRewNxDJyff3ixWkLvPCvgHapg@mail.gmail.com>

Hello,
I'd like to share soe further "progress" (and lack of) on this topic and
some further considerations.

First, we managed to get this to work for a particular case through our
consumer code: we can override the Gen.visitErroneous and Gen.visitExec
methods to generate the bytecode of `throw new
RuntimeException("Compilation error")` instead of crashing. And I could see
that the generate .class throw the exception when expected. So that's very
encouraging.
However this is unfortunately too restricted: one more generic idea is to
override the `Gen.genExpr(...)` method so that is the expression is
JCErroneous or type is null, then we generate the bytecode for `throw new
RuntimeException("Compilation Error")`. But the issue is that one cannot
really override `genExpr` because it returns an object of the
package-visible only Item type, so we can simply not override it. We've
tried to greedily duplicate most of the com.sun.tools.javac.jvm package but
the "Code" type which is used by Symbol but still has some important nested
types that are not open make that even duplicating the code in the package
is diffcult.
So implementation-wise, I think we are getting close to a conclusion that
fully providing such ability through consumer code is for the moment about
impossible. Changes seems necessary in openjdk directly.

On that matter, we came to learn about `should-stop.ifError` and it seems
that in case `should-stop.ifError=GENERATE` then generating the class for
erroneous .java files similarly to what we suggest above is a fair
expectation, isn't it? That would mean that basically, there would be no
need for a new flag, nor a new option, and we'd "just" have to fix the
currently crashing bits of javac?

If anyone has further suggestions to experiment, they are for sure welcome!

Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241122/7e2290e6/attachment.htm>

From jan.lahoda at oracle.com  Sun Nov 24 12:05:39 2024
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 24 Nov 2024 13:05:39 +0100
Subject: -proceedOnError option (like ECJ) ?
In-Reply-To: <CAFr6BZTgyz_-X1PWeJ6yKKuVtRewNxDJyff3ixWkLvPCvgHapg@mail.gmail.com>
References: <CAFr6BZSk7a22FWrZy6QakmJ0OA5-sOKaga6DYpEJRqSZL4rnSg@mail.gmail.com>
 <3344b2bd-4190-41ac-ae36-ec1afb272c8d@oracle.com>
 <4756ee9e-572d-4a94-8dd3-f88de3366421@oracle.com>
 <CAFr6BZQ5JLjvAaMZeXfEvpcSrytRkBSpHbstt+voWGer-ggaEw@mail.gmail.com>
 <CAFr6BZTgyz_-X1PWeJ6yKKuVtRewNxDJyff3ixWkLvPCvgHapg@mail.gmail.com>
Message-ID: <c9fcdf64-4373-4740-87c4-566f0a087ccb@oracle.com>

Hello Mickael,


Without commenting on desirability of this feature for OpenJDK or any 
particular project, and as my personal opinion.


In a very simplified view, javac (as is common) has a front-end and a 
back-end. The front-end parses and analyzes the source, and reports most 
errors, producing an attributed AST; the back-end then 
transforms/simplifies the AST and generates the classfiles. The 
front-end currently ends with Flow, and the back-end currently starts 
with TransTypes. I have doubts it is realistically feasible to take the 
AST for the erroneous code through the back-end. It may be much simpler 
to fix the AST by replacing the erroneous parts with the exceptions at 
the boundary between the front-end and the back-end, hence the back-end 
would only work on AST which represents non-erroneous code. This is 
actually what NetBeans is doing (both in the current, and historical 
implementation of this feature).


Jan


On 22. 11. 24 22:47, Mickael Istria wrote:
> Hello,
> I'd like to share soe further "progress" (and lack of) on this topic 
> and some further considerations.
>
> First, we managed to get this to work for a particular case through 
> our consumer code: we can override the Gen.visitErroneous and 
> Gen.visitExec methods to generate the bytecode of `throw new 
> RuntimeException("Compilation error")` instead of crashing. And I 
> could see that the generate .class throw the exception when expected. 
> So that's very encouraging.
> However this is unfortunately too restricted: one more generic idea is 
> to override the `Gen.genExpr(...)` method so that is the expression is 
> JCErroneous or type is null, then we generate the bytecode for `throw 
> new RuntimeException("Compilation Error")`. But the issue is that one 
> cannot really override `genExpr` because it returns an object of the 
> package-visible only Item type, so we can simply not override it. 
> We've tried to greedily duplicate most of the com.sun.tools.javac.jvm 
> package but the "Code" type which is used by Symbol but still has some 
> important nested types that are not open make that even duplicating 
> the code in the package is diffcult.
> So implementation-wise, I think we are getting close to a conclusion 
> that fully providing such ability through consumer code is for the 
> moment about impossible. Changes seems necessary in openjdk directly.
>
> On that matter, we came to learn about `should-stop.ifError` and it 
> seems that in case `should-stop.ifError=GENERATE` then generating the 
> class for erroneous .java files similarly to what we suggest above is 
> a fair expectation, isn't it? That would mean that basically, there 
> would be no need for a new flag, nor a new option, and we'd "just" 
> have to fix the currently crashing bits of javac?
>
> If anyone has further suggestions to experiment, they are for sure 
> welcome!
>
> Cheers,

From mistria at redhat.com  Sun Nov 24 14:12:23 2024
From: mistria at redhat.com (Mickael Istria)
Date: Sun, 24 Nov 2024 15:12:23 +0100
Subject: -proceedOnError option (like ECJ) ?
In-Reply-To: <c9fcdf64-4373-4740-87c4-566f0a087ccb@oracle.com>
References: <CAFr6BZSk7a22FWrZy6QakmJ0OA5-sOKaga6DYpEJRqSZL4rnSg@mail.gmail.com>
 <3344b2bd-4190-41ac-ae36-ec1afb272c8d@oracle.com>
 <4756ee9e-572d-4a94-8dd3-f88de3366421@oracle.com>
 <CAFr6BZQ5JLjvAaMZeXfEvpcSrytRkBSpHbstt+voWGer-ggaEw@mail.gmail.com>
 <CAFr6BZTgyz_-X1PWeJ6yKKuVtRewNxDJyff3ixWkLvPCvgHapg@mail.gmail.com>
 <c9fcdf64-4373-4740-87c4-566f0a087ccb@oracle.com>
Message-ID: <CAFr6BZTGXap_mjPV6RGQa_D50UzK03=W=D=vo9q06HwPkOEpEQ@mail.gmail.com>

Hi Jan,
Thank you for your answer. I didn't realize that the cursor of "modifiable"
AST was between Flow and TransType, that's one helpful tip.
I had initially implemented something like you suggest (only for syntax
errors, trying to "fix" ASTs after parse). For statements, it was easy
enough to replace a JCErroneous by a `throw new RuntimeException()`, but
the issue was more for random compilation errors in expression, eg
```
class A {
  int n = syntax error here;
  A p = unresolvedReference();
  int q = 1 + unresolvedReference().length();
}
```
I didn't find a good and generic enough substitute AST to build for those.
And that why I though about implementing it on the "backend" part of Javac
you described.
But I have no strong need for this change to be in the "backend",
pragmatically, I'd be happy with whatever works; even if I still think that
such a feature would be a nice to have directly in Javac.
Can you please elaborate on what substitute AST Netbeans generates for such
case? And maybe even link to the piece of code that does it in Netbeans (a
quick search wasn't so successful to me)? I would be very happy if we can
reuse the code and share the effort.

Cheers,
Mickael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241124/ae696de0/attachment.htm>

From prappo at openjdk.org  Mon Nov 25 11:40:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 25 Nov 2024 11:40:16 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v7]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <LbvK_7HLZxB4HwBEFbYci9EJ8wQtWQZta-eKxI9dT0M=.a148362e-a086-4a0c-b983-c665981cb82f@github.com>

> Prepare for JDK 25.

Pavel Rappo 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 11 additional commits since the last revision:

 - Update --release 24 symbol information for JDK 24 build 25
   
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 24
   
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 23
   
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 21
   
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
 - Add forgotten .jcheck/conf
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a4ca909a...4d3461da

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/354ed5a8..4d3461da

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

  Stats: 98525 lines in 1533 files changed: 47573 ins; 44582 del; 6370 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 maurizio.cimadamore at oracle.com  Mon Nov 25 11:54:18 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 25 Nov 2024 11:54:18 +0000
Subject: -proceedOnError option (like ECJ) ?
In-Reply-To: <c9fcdf64-4373-4740-87c4-566f0a087ccb@oracle.com>
References: <CAFr6BZSk7a22FWrZy6QakmJ0OA5-sOKaga6DYpEJRqSZL4rnSg@mail.gmail.com>
 <3344b2bd-4190-41ac-ae36-ec1afb272c8d@oracle.com>
 <4756ee9e-572d-4a94-8dd3-f88de3366421@oracle.com>
 <CAFr6BZQ5JLjvAaMZeXfEvpcSrytRkBSpHbstt+voWGer-ggaEw@mail.gmail.com>
 <CAFr6BZTgyz_-X1PWeJ6yKKuVtRewNxDJyff3ixWkLvPCvgHapg@mail.gmail.com>
 <c9fcdf64-4373-4740-87c4-566f0a087ccb@oracle.com>
Message-ID: <d5c85e57-7e3b-4256-b96f-a9619e265557@oracle.com>

I was about to suggest a similar thing. E.g. use a custom compiler step 
to "fix up" the AST before it gets to the backend.

Maurizio

On 24/11/2024 12:05, Jan Lahoda wrote:
> It may be much simpler to fix the AST by replacing the erroneous parts 
> with the exceptions at the boundary between the front-end and the 
> back-end, hence the back-end would only work on AST which represents 
> non-erroneous code. This is actually what NetBeans is doing (both in 
> the current, and historical implementation of this feature).

From mistria at redhat.com  Mon Nov 25 12:41:40 2024
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 25 Nov 2024 13:41:40 +0100
Subject: -proceedOnError option (like ECJ) ?
In-Reply-To: <CAFr6BZTGXap_mjPV6RGQa_D50UzK03=W=D=vo9q06HwPkOEpEQ@mail.gmail.com>
References: <CAFr6BZSk7a22FWrZy6QakmJ0OA5-sOKaga6DYpEJRqSZL4rnSg@mail.gmail.com>
 <3344b2bd-4190-41ac-ae36-ec1afb272c8d@oracle.com>
 <4756ee9e-572d-4a94-8dd3-f88de3366421@oracle.com>
 <CAFr6BZQ5JLjvAaMZeXfEvpcSrytRkBSpHbstt+voWGer-ggaEw@mail.gmail.com>
 <CAFr6BZTgyz_-X1PWeJ6yKKuVtRewNxDJyff3ixWkLvPCvgHapg@mail.gmail.com>
 <c9fcdf64-4373-4740-87c4-566f0a087ccb@oracle.com>
 <CAFr6BZTGXap_mjPV6RGQa_D50UzK03=W=D=vo9q06HwPkOEpEQ@mail.gmail.com>
Message-ID: <CAFr6BZR2tNZYrgHj8NecMUfTZqz9gbLoYfNtuOip5JU3SG34bQ@mail.gmail.com>

Hi again,

I actually managed to get something working decently enough a few hours
ago, overriding the Gen.
Intestesting parts are:
* setting should-stop.ifError=GENERATE
https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/be1321f92e37952923d61a37b69ce95f7f0a08ec/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/JavacUtils.java#L103
* Overriding condition for genCode to ignore errors and process anyway:
https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/be1321f92e37952923d61a37b69ce95f7f0a08ec/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/JavacCompiler.java#L179
* Overriding TransType to avoid a very probable compiler NPE when types
mismatch in the file being compiled:
https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/be1321f92e37952923d61a37b69ce95f7f0a08ec/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/ProceedOnErrorTransTypes.java#L35
* Overriding Gen to capture usual errors during visitXXX and just generate
code for `throw new RuntimeException` in such case:
https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/blob/dom-with-javac/org.eclipse.jdt.core.javac/src/org/eclipse/jdt/internal/javac/ProceedOnErrorGen.java

This is far from being bullet-proof, but it's not really meant to. It does
already deliver a lot of value in the story of "hotswapping when code still
has errors without crashing debug session" which is our unique target here.
I don't think we'll be trying to push such feature further into
OpenJDK/Javac, but would welcome anyone to try it. If anyone is willing to
contribute to this code, or to reuse it in some way, feel free to join the
discussions at
https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/discussions .

Cheers and thanks!
Mickael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241125/b34e0b4b/attachment.htm>

From duke at openjdk.org  Mon Nov 25 13:02:45 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Mon, 25 Nov 2024 13:02:45 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
Message-ID: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>

Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066

This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.

The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.

## Current behaviour of javap previously differed with and without -verbose in the following way:

### Case: `javap -l -c EmptyLoop.class`


...
  public void emptyLoop();
    Code:
       0: iconst_0
       ...
      14: return
    LineNumberTable:
      line 3: 0
      line 5: 14
...


### Case: `javap -verbose EmptyLoop.class`


...
  public void emptyLoop();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=1
         0: iconst_0
         ...
        14: return
      LineNumberTable:
        line 3: 0
        line 5: 14
...


## New behaviour:
### Case: `javap -l -c EmptyLoop.class`

...
  public void emptyLoop();
    Code:
         0: iconst_0
         ...
        14: return
      LineNumberTable:
        line 3: 0
        line 5: 14
...



## Open Questions
### Add code header for only `-l` case?
Currently for `-l` without `-c` things look as follows:


...
  public void emptyLoop();
    LineNumberTable:
      line 3: 0
      line 5: 14
...


One could also imagine making the output:

...
  public void emptyLoop();
    Code:
      LineNumberTable:
        line 3: 0
        line 5: 14
...

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

Commit messages:
 - fix: Indentation of LineNumberTable and LocalVariableTable in javap output

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

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

From jvernee at openjdk.org  Mon Nov 25 15:57:21 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Nov 2024 15:57:21 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
Message-ID: <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>

On Mon, 25 Nov 2024 12:57:18 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> Add code header for only -l case?

I think that is the right move. `LineNumberTable`, and others listed here: [Add code header for only -l case?](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7-320) are/can be sub-attributes of the code attribute. So I think it makes sense to render them under `Code:`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2498401408

From mcimadamore at openjdk.org  Mon Nov 25 16:04:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Nov 2024 16:04:13 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
Message-ID: <diBd06YhVRTY4Kaa2ZqMuX0qht0Srz39vufqY4rpO10=.dc999960-6d8d-469b-acd2-088b80094ab1@github.com>

On Mon, 25 Nov 2024 15:54:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > Add code header for only -l case?

I also like this option, because it maintains the "nesting" of attributes - e.g. the main thing here is that LNT and LVT are attributes of Code, so they should be nested in there. One option could be to report the general number of opcodes in the Code attribute, if no `-c` is provided (so that at least that can be used as a guidance for interpreting the other attributes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2498420784

From iris at openjdk.org  Mon Nov 25 17:35:17 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 25 Nov 2024 17:35:17 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v7]
In-Reply-To: <LbvK_7HLZxB4HwBEFbYci9EJ8wQtWQZta-eKxI9dT0M=.a148362e-a086-4a0c-b983-c665981cb82f@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <LbvK_7HLZxB4HwBEFbYci9EJ8wQtWQZta-eKxI9dT0M=.a148362e-a086-4a0c-b983-c665981cb82f@github.com>
Message-ID: <8JKyl6HGWdA6SAYlyuFxNmzmvt1SnKPuPzH7oN1Q-YM=.af595de3-22fd-4fd0-951f-81b7c1af2bd6@github.com>

On Mon, 25 Nov 2024 11:40:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo 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 11 additional commits since the last revision:
> 
>  - Update --release 24 symbol information for JDK 24 build 25
>    
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 24
>    
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 23
>    
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 22
>    
>    The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 21
>    
>    The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
>  - Add forgotten .jcheck/conf
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/6419d76d...4d3461da

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2459118158

From liach at openjdk.org  Mon Nov 25 19:53:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 25 Nov 2024 19:53:16 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
Message-ID: <oXEeL7hmxO93AXA25R7ciqw4XdOs_wcAi3oIuwXZsuY=.6e3fbd19-bc4b-4947-b8c8-3dcf7c976b44@github.com>

On Mon, 25 Nov 2024 12:57:18 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
> 
> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
> 
> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
> 
> ## Current behaviour of javap previously differed with and without -verbose in the following way:
> 
> ### Case: `javap -l -c EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     Code:
>        0: iconst_0
>        ...
>       14: return
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> ### Case: `javap -verbose EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> ## New behaviour:
> ### Case: `javap -l -c EmptyLoop.class`
> 
> ...
>   public void emptyLoop();
>     Code:
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> 
> ## Open Questions
> ### Add code header for only `-l` case?
> Currently for `-l` without `-c` things look as follows:
> 
> 
> ...
>   public void emptyLoop();
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> One could also imagine making the output:
> 
> ...
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22359#pullrequestreview-2459492162

From liach at openjdk.org  Mon Nov 25 20:51:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 25 Nov 2024 20:51:25 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
Message-ID: <h7sVIogmD7qo5ibd2h3iKO4_hPvRprxKvOdEfUHmAkQ=.548ec126-9b3f-4a45-8ab5-9172fe7fdc37@github.com>

On Mon, 25 Nov 2024 12:57:18 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
> 
> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
> 
> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
> 
> ## Current behaviour of javap previously differed with and without -verbose in the following way:
> 
> ### Case: `javap -l -c EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     Code:
>        0: iconst_0
>        ...
>       14: return
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> ### Case: `javap -verbose EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> ## New behaviour:
> ### Case: `javap -l -c EmptyLoop.class`
> 
> ...
>   public void emptyLoop();
>     Code:
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> 
> ## Open Questions
> ### Add code header for only `-l` case?
> Currently for `-l` without `-c` things look as follows:
> 
> 
> ...
>   public void emptyLoop();
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> One could also imagine making the output:
> 
> ...
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...

The current output looks fine; adding a `Code` header is more accurate that these attributes are on the Code instead of the method.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2499003201

From duke at openjdk.org  Tue Nov 26 08:57:04 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Tue, 26 Nov 2024 08:57:04 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode [v2]
In-Reply-To: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
Message-ID: <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>

> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
> 
> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
> 
> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
> 
> ## Current behaviour of javap previously differed with and without -verbose in the following way:
> 
> ### Case: `javap -l -c EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     Code:
>        0: iconst_0
>        ...
>       14: return
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> ### Case: `javap -verbose EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> ## New behaviour:
> ### Case: `javap -l -c EmptyLoop.class`
> 
> ...
>   public void emptyLoop();
>     Code:
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> 
> ## Open Questions
> ### Add code header for only `-l` case?
> Currently for `-l` without `-c` things look as follows:
> 
> 
> ...
>   public void emptyLoop();
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> One could also imagine making the output:
> 
> ...
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...

Jonathan Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:

  feat: add Code: header for LNT and LVT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22359/files
  - new: https://git.openjdk.org/jdk/pull/22359/files/35fbd3f8..68ec9aaa

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

  Stats: 83 lines in 3 files changed: 22 ins; 49 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22359/head:pull/22359

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

From duke at openjdk.org  Tue Nov 26 09:14:37 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Tue, 26 Nov 2024 09:14:37 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <diBd06YhVRTY4Kaa2ZqMuX0qht0Srz39vufqY4rpO10=.dc999960-6d8d-469b-acd2-088b80094ab1@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
 <diBd06YhVRTY4Kaa2ZqMuX0qht0Srz39vufqY4rpO10=.dc999960-6d8d-469b-acd2-088b80094ab1@github.com>
Message-ID: <FCz5BRDTVYD15VJL3FHRwIUxcYb54gEOy_X8pIlH2pA=.548f9622-1f7e-4670-858b-f9837ab19a9f@github.com>

On Mon, 25 Nov 2024 16:01:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > > Add code header for only -l case?
> 
> I also like this option, because it maintains the "nesting" of attributes - e.g. the main thing here is that LNT and LVT are attributes of Code, so they should be nested in there. One option could be to report the general number of opcodes in the Code attribute, if no `-c` is provided (so that at least that can be used as a guidance for interpreting the other attributes).


Do you mean comething as simple as this just counting the number of instructions?

### `javap -l EmptyLoop`

Compiled from "EmptyLoop.java"
public class EmptyLoop {
  public EmptyLoop();
    Code:
      Opcode count: 3
      LineNumberTable:
        line 1: 0

  public void emptyLoop();
    Code:
      Opcode count: 8
      LineNumberTable:
        line 3: 0
        line 5: 14
}


<details>
<summary>With code for context: `javap -l -c EmptyLoop`</summary>


Compiled from "EmptyLoop.java"
public class EmptyLoop {
  public EmptyLoop();
    Code:
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 1: 0

  public void emptyLoop();
    Code:
         0: iconst_0
         1: istore_1
         2: iload_1
         3: bipush        10
         5: if_icmpge     14
         8: iinc          1, 1
        11: goto          2
        14: return
      LineNumberTable:
        line 3: 0
        line 5: 14
}


</details>

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2500067046

From duke at openjdk.org  Tue Nov 26 09:17:36 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Tue, 26 Nov 2024 09:17:36 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
Message-ID: <SpJJTGFvw2E6H8Fjlmyvhgd7TVO-MI3WSOLZMGEfrOQ=.56415b79-f998-44da-a4f1-2b14a543b85f@github.com>

On Mon, 25 Nov 2024 15:54:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > Add code header for only -l case?
> 
> I think that is the right move. `LineNumberTable`, and others listed here: https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7-320 are/can be sub-attributes of the code attribute. So I think it makes sense to render them under `Code:`.

I have added this.

Notably I opted to split `writeInternal` into `writeMinimal` and `writeVerbose` as the logic was getting a little unreadable. (things like `if (!minimal || options.showLineAndLocalVariableTables)`). Although some added duplication, I think this is more readable.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2500072948

From vromero at openjdk.org  Tue Nov 26 15:22:11 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 26 Nov 2024 15:22:11 GMT
Subject: RFR: 8345058: javac issues different error messages for the modifiers
 of the requires directive
Message-ID: <QiqlWoESdFzv3pFaccVgyvxmaa0IIMF32kiBaQX0yC0=.6a7b1801-b3e6-415d-aa8b-56ef9679a937@github.com>

javac is issuing different error messages for the modifiers of the `requires` directive. This PR is making javac's output consistent for both modifiers `static` and `transitive`

TIA

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

Commit messages:
 - 8345058: javac issues different error messages for the modifiers of the requires directive

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

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

From mcimadamore at openjdk.org  Tue Nov 26 16:20:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 26 Nov 2024 16:20:42 GMT
Subject: RFR: 8345058: Javac issues different error messages for the
 modifiers of the requires directive
In-Reply-To: <QiqlWoESdFzv3pFaccVgyvxmaa0IIMF32kiBaQX0yC0=.6a7b1801-b3e6-415d-aa8b-56ef9679a937@github.com>
References: <QiqlWoESdFzv3pFaccVgyvxmaa0IIMF32kiBaQX0yC0=.6a7b1801-b3e6-415d-aa8b-56ef9679a937@github.com>
Message-ID: <NVHM-HALw8_FIAO8u4eTqXXIhhABIJzAK5rW2P321y4=.33bf3553-b112-42d7-b32f-011408c757e8@github.com>

On Tue, 26 Nov 2024 15:16:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is issuing different error messages for the modifiers of the `requires` directive. This PR is making javac's output consistent for both modifiers `static` and `transitive`
> 
> TIA

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22392#pullrequestreview-2462041813

From jvernee at openjdk.org  Tue Nov 26 16:38:42 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 26 Nov 2024 16:38:42 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode [v2]
In-Reply-To: <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
Message-ID: <Qih5halA6KxOX2dNLukPhCfcFKjEV8QaNcXSHhr3w0I=.cc5eaf2d-9220-4159-8398-17d48ed86c7c@github.com>

On Tue, 26 Nov 2024 08:57:04 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
>> 
>> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
>> 
>> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
>> 
>> ## Current behaviour of javap previously differed with and without -verbose in the following way:
>> 
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>        0: iconst_0
>>        ...
>>       14: return
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> ### Case: `javap -verbose EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> ## New behaviour:
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> 
>> ## Open Questions
>> ### Add code header for only `-l` case?
>> Currently for `-l` without `-c` things look as follows:
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> One could also imagine making the output:
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>
> Jonathan Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feat: add Code: header for LNT and LVT

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22359#pullrequestreview-2462095848

From liach at openjdk.org  Tue Nov 26 17:32:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Nov 2024 17:32:45 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode [v2]
In-Reply-To: <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
Message-ID: <uaWvhD56S3cc-5wHtknViJlFPtcYlvym2LlHganBVks=.942fdf4e-efdd-407d-85be-f520a48058a9@github.com>

On Tue, 26 Nov 2024 08:57:04 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
>> 
>> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
>> 
>> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
>> 
>> ## Current behaviour of javap previously differed with and without -verbose in the following way:
>> 
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>        0: iconst_0
>>        ...
>>       14: return
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> ### Case: `javap -verbose EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> ## New behaviour:
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> 
>> ## Open Questions
>> ### Add code header for only `-l` case?
>> Currently for `-l` without `-c` things look as follows:
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> One could also imagine making the output:
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>
> Jonathan Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feat: add Code: header for LNT and LVT

Good cleanup to writeInternal.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22359#pullrequestreview-2462261978

From vromero at openjdk.org  Tue Nov 26 20:55:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 26 Nov 2024 20:55:42 GMT
Subject: Integrated: 8345058: Javac issues different error messages for the
 modifiers of the requires directive
In-Reply-To: <QiqlWoESdFzv3pFaccVgyvxmaa0IIMF32kiBaQX0yC0=.6a7b1801-b3e6-415d-aa8b-56ef9679a937@github.com>
References: <QiqlWoESdFzv3pFaccVgyvxmaa0IIMF32kiBaQX0yC0=.6a7b1801-b3e6-415d-aa8b-56ef9679a937@github.com>
Message-ID: <-fra3I2TojavVU3WsWjI7SMk0K3kuAF9sQQ4sY4MpxY=.4e4061cf-142b-415e-8b69-b0c4f27b94e9@github.com>

On Tue, 26 Nov 2024 15:16:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is issuing different error messages for the modifiers of the `requires` directive. This PR is making javac's output consistent for both modifiers `static` and `transitive`
> 
> TIA

This pull request has now been integrated.

Changeset: 8389e24d
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8389e24d388f3761a6963503955207a574c1bbd3
Stats:     38 lines in 2 files changed: 38 ins; 0 del; 0 mod

8345058: Javac issues different error messages for the modifiers of the requires directive

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.org  Wed Nov 27 10:17:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 27 Nov 2024 10:17:38 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <FCz5BRDTVYD15VJL3FHRwIUxcYb54gEOy_X8pIlH2pA=.548f9622-1f7e-4670-858b-f9837ab19a9f@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
 <diBd06YhVRTY4Kaa2ZqMuX0qht0Srz39vufqY4rpO10=.dc999960-6d8d-469b-acd2-088b80094ab1@github.com>
 <FCz5BRDTVYD15VJL3FHRwIUxcYb54gEOy_X8pIlH2pA=.548f9622-1f7e-4670-858b-f9837ab19a9f@github.com>
Message-ID: <BuCpw6dswHBd4pInZ8dcbfizAbTxIj59XIB6pq6Ta7w=.bd87c9ba-fe2f-45a0-aa03-e80df5f6f903@github.com>

On Tue, 26 Nov 2024 09:11:54 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> Do you mean comething as simple as this just counting the number of instructions?

Something like this, yeah, if this is deemed useful

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2503469486

From mcimadamore at openjdk.org  Wed Nov 27 10:17:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 27 Nov 2024 10:17:39 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <BuCpw6dswHBd4pInZ8dcbfizAbTxIj59XIB6pq6Ta7w=.bd87c9ba-fe2f-45a0-aa03-e80df5f6f903@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
 <diBd06YhVRTY4Kaa2ZqMuX0qht0Srz39vufqY4rpO10=.dc999960-6d8d-469b-acd2-088b80094ab1@github.com>
 <FCz5BRDTVYD15VJL3FHRwIUxcYb54gEOy_X8pIlH2pA=.548f9622-1f7e-4670-858b-f9837ab19a9f@github.com>
 <BuCpw6dswHBd4pInZ8dcbfizAbTxIj59XIB6pq6Ta7w=.bd87c9ba-fe2f-45a0-aa03-e80df5f6f903@github.com>
Message-ID: <H6ArhLlsPE9RwDS0HCVVgG5FvxhYesNSykGinSyyao8=.b59bb379-4035-4f79-8246-68eb80cc3bd4@github.com>

On Wed, 27 Nov 2024 10:12:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Something like this, yeah, if this is deemed useful

Or, if code is skipped, should we also skip code attributes? For the records, I'm fine for these issues to be tackled also in separate PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2503472423

From duke at openjdk.org  Wed Nov 27 12:05:37 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Wed, 27 Nov 2024 12:05:37 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <H6ArhLlsPE9RwDS0HCVVgG5FvxhYesNSykGinSyyao8=.b59bb379-4035-4f79-8246-68eb80cc3bd4@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
 <diBd06YhVRTY4Kaa2ZqMuX0qht0Srz39vufqY4rpO10=.dc999960-6d8d-469b-acd2-088b80094ab1@github.com>
 <FCz5BRDTVYD15VJL3FHRwIUxcYb54gEOy_X8pIlH2pA=.548f9622-1f7e-4670-858b-f9837ab19a9f@github.com>
 <BuCpw6dswHBd4pInZ8dcbfizAbTxIj59XIB6pq6Ta7w=.bd87c9ba-fe2f-45a0-aa03-e80df5f6f903@github.com>
 <H6ArhLlsPE9RwDS0HCVVgG5FvxhYesNSykGinSyyao8=.b59bb379-4035-4f79-8246-68eb80cc3bd4@github.com>
Message-ID: <TPE64MFUUP_bqdTPKG6bolHzXdh_bcEyU2wys0wPFmo=.b6918631-381e-441f-b5ab-4eeb81f200c7@github.com>

On Wed, 27 Nov 2024 10:14:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Something like this, yeah, if this is deemed useful

I did implement this locally, but I am not sure of its utility. The values in `LineNumberTable` refer to PC locations, for which the number of opcodes does not really provide much context. What do you think?

> Or, if code is skipped, should we also skip code attributes?

I tend to like this approach, especially if I were starting from scratch. But considering the current functionality may be depended on, I think the current solution is a decent trade off of increasing readability/uniformity, without removing this existing functionality.

> For the records, I'm fine for these issues to be tackled also in separate PRs.

In that case I would suggest integrating as is. I would personally tend towards no further changes thereafter, but would be interested any other opinions/suggestions to the contrary.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2503700433

From liach at openjdk.org  Wed Nov 27 13:22:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 27 Nov 2024 13:22:41 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode [v2]
In-Reply-To: <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
Message-ID: <IKeHBxm4cl-hRPNnMUQZjg9smpV5CqBFJNI89qI930U=.5f5a55d7-e385-44d8-924b-4576634575fa@github.com>

On Tue, 26 Nov 2024 08:57:04 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
>> 
>> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
>> 
>> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
>> 
>> ## Current behaviour of javap previously differed with and without -verbose in the following way:
>> 
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>        0: iconst_0
>>        ...
>>       14: return
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> ### Case: `javap -verbose EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> ## New behaviour:
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> 
>> ## Open Questions
>> ### Add code header for only `-l` case?
>> Currently for `-l` without `-c` things look as follows:
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> One could also imagine making the output:
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>
> Jonathan Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feat: add Code: header for LNT and LVT

For code size rendering, we currently don't even render it even if we print whole list of instructions; users have to know the size of the final instruction to deduce the code size. If we add a code size output, we should do it in another RFE. And this size is useful when people want their code to be below the FreqInlineSize.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2503863302

From duke at openjdk.org  Wed Nov 27 17:28:40 2024
From: duke at openjdk.org (duke)
Date: Wed, 27 Nov 2024 17:28:40 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode [v2]
In-Reply-To: <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
Message-ID: <Qj7T1b2XG6hGMNInVUDISCQ8afuxr3_66cRkygSVirU=.861fdc9f-6f03-4b73-9370-e42845cf20af@github.com>

On Tue, 26 Nov 2024 08:57:04 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
>> 
>> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
>> 
>> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
>> 
>> ## Current behaviour of javap previously differed with and without -verbose in the following way:
>> 
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>        0: iconst_0
>>        ...
>>       14: return
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> ### Case: `javap -verbose EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> ## New behaviour:
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> 
>> ## Open Questions
>> ### Add code header for only `-l` case?
>> Currently for `-l` without `-c` things look as follows:
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> One could also imagine making the output:
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>
> Jonathan Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feat: add Code: header for LNT and LVT

@jonath4ndev 
Your change (at version 68ec9aaa160590fdaf1e70f9ef80e23ed634de0b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2504419608

From duke at openjdk.org  Wed Nov 27 17:28:40 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Wed, 27 Nov 2024 17:28:40 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode [v2]
In-Reply-To: <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
Message-ID: <ERWrJBA5kN2eCg7p53Rji985evjW7Vt8OuWdGxQUhls=.b7a85c5f-68e0-4627-af9f-18742f62b514@github.com>

On Tue, 26 Nov 2024 08:57:04 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
>> 
>> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
>> 
>> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
>> 
>> ## Current behaviour of javap previously differed with and without -verbose in the following way:
>> 
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>        0: iconst_0
>>        ...
>>       14: return
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> ### Case: `javap -verbose EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> ## New behaviour:
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> 
>> ## Open Questions
>> ### Add code header for only `-l` case?
>> Currently for `-l` without `-c` things look as follows:
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> One could also imagine making the output:
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>
> Jonathan Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feat: add Code: header for LNT and LVT

I have created a new Enhancement Issue on JBS: https://bugs.openjdk.org/browse/JDK-8345123 which we can further look into and will go forward with integrating this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2504417363

From duke at openjdk.org  Wed Nov 27 17:34:44 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Wed, 27 Nov 2024 17:34:44 GMT
Subject: Integrated: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
Message-ID: <_Zr6dBcsCjWdl3WWd7iSrbwufNUxDNvFHBntHu_j36o=.db5856fb-6c9f-478c-9b9a-36c59c683b0f@github.com>

On Mon, 25 Nov 2024 12:57:18 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
> 
> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
> 
> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
> 
> ## Current behaviour of javap previously differed with and without -verbose in the following way:
> 
> ### Case: `javap -l -c EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     Code:
>        0: iconst_0
>        ...
>       14: return
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> ### Case: `javap -verbose EmptyLoop.class`
> 
> 
> ...
>   public void emptyLoop();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> ## New behaviour:
> ### Case: `javap -l -c EmptyLoop.class`
> 
> ...
>   public void emptyLoop();
>     Code:
>          0: iconst_0
>          ...
>         14: return
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...
> 
> 
> 
> ## Open Questions
> ### Add code header for only `-l` case?
> Currently for `-l` without `-c` things look as follows:
> 
> 
> ...
>   public void emptyLoop();
>     LineNumberTable:
>       line 3: 0
>       line 5: 14
> ...
> 
> 
> One could also imagine making the output:
> 
> ...
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> ...

This pull request has now been integrated.

Changeset: 1e3a0fdb
Author:    Jonathan Lamp?rth <jonathan.lamperth at oracle.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e3a0fdb5d14550de66faa8472c883a9990a87df
Stats:     164 lines in 3 files changed: 146 ins; 11 del; 7 mod

8035271: Incorrect indentation of LineNumberTable/LocalVariableTable/Exception table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in verbose mode

Reviewed-by: liach, jvernee

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

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

From mcimadamore at openjdk.org  Wed Nov 27 18:54:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 27 Nov 2024 18:54:44 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode
In-Reply-To: <TPE64MFUUP_bqdTPKG6bolHzXdh_bcEyU2wys0wPFmo=.b6918631-381e-441f-b5ab-4eeb81f200c7@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <ZlACnliePc_bCdrGWW26t_lwsUPlLBC_3mRsINg66oc=.341da53f-ec54-4c0c-b3d5-5855f2aa00a9@github.com>
 <diBd06YhVRTY4Kaa2ZqMuX0qht0Srz39vufqY4rpO10=.dc999960-6d8d-469b-acd2-088b80094ab1@github.com>
 <FCz5BRDTVYD15VJL3FHRwIUxcYb54gEOy_X8pIlH2pA=.548f9622-1f7e-4670-858b-f9837ab19a9f@github.com>
 <BuCpw6dswHBd4pInZ8dcbfizAbTxIj59XIB6pq6Ta7w=.bd87c9ba-fe2f-45a0-aa03-e80df5f6f903@github.com>
 <H6ArhLlsPE9RwDS0HCVVgG5FvxhYesNSykGinSyyao8=.b59bb379-4035-4f79-8246-68eb80cc3bd4@github.com>
 <TPE64MFUUP_bqdTPKG6bolHzXdh_bcEyU2wys0wPFmo=.b6918631-381e-441f-b5ab-4eeb81f200c7@github.com>
Message-ID: <QCqUaBmtsxLA70Wy5-SFTNr6ZA2UILVhixmECgsJAVo=.a8d263d8-9797-49de-877f-7c2438a285bd@github.com>

On Wed, 27 Nov 2024 12:03:04 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> I tend to like this approach, especially if I were starting from scratch. But considering the current functionality may be depended on, I think the current solution is a decent trade off of increasing readability/uniformity, without removing this existing functionality.

I'm not too concerned by this TBH. The set of options seem to be contradictory (e.g. I want to omit code attribute, but retain all the attributes nested inside Code, which are often expressed in terms of offset onto the -- omitted -- opcode array). I think it's ok if we decided that `-c` means "really, shut up about Code" :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2504586329

From liach at openjdk.org  Wed Nov 27 23:19:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 27 Nov 2024 23:19:23 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-83324714
Message-ID: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>

Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.

To reviewers, there are some redundant changes and notes:

- There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
- Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
  - `BoundAttribute::payloadLen` for javac attribute tests
  - Annotation reading/writing for javac annotation tests
- Line number changes to:
  - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
  - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
- Move from legacy jdk.internal.classfile to java.lang.classfile in:
  - test/langtools/tools/javac/NoStringToLower.java and 
  - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
- Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java

  - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.

Testing: did a quick tier 1-2 locally, waiting for CI on tier 1-3.  Please inform me if any of these tests belong to higher tiers.

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

Commit messages:
 - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Changes: https://git.openjdk.org/jdk/pull/22420/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22420&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334733
  Stats: 635 lines in 360 files changed: 2 ins; 556 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22420.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22420/head:pull/22420

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

From duke at openjdk.org  Wed Nov 27 23:38:46 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Wed, 27 Nov 2024 23:38:46 GMT
Subject: RFR: 8035271: Incorrect indentation of
 LineNumberTable/LocalVariableTable/Exception
 table/LocalVariableTypeTable/StackMapTable/RuntimeVisibleTypeAnnotations in
 verbose mode [v2]
In-Reply-To: <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
References: <IXdWLkcFsxlIijKG4yV8Hm6-_jTxb3Sz0KPsz2mKfR0=.d9585c37-ee14-4ae9-b7a3-b2a1157faa25@github.com>
 <Vy8uWt8oYVhcS7FHW_z7c_IpX9zoJsFm9mzPv9Cw3GM=.bc7a946a-16c0-4444-b462-0c38ae068b72@github.com>
Message-ID: <y-Ma_nNInSpAGzQ06Baabg4XDtGgzdrZxUB8yQZMfbw=.9aab6be1-3960-437c-b96b-b0bbed21a519@github.com>

On Tue, 26 Nov 2024 08:57:04 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Very similar and related to: https://bugs.openjdk.org/browse/JDK-8034066
>> 
>> This PR includes changes to ensure the indentation of `LineNumberTable` and `LocalVariableTable` behave in the same way both for the `javap -verbose` and `javap -l -c` case. Prior to this PR, for the `javap -l -c` case the `LineNumberTable` and `LocalVariableTable` attributes are not indented with regard to the `Code: ` header.
>> 
>> The only case, where no extra indentation is added is for `javap -l` without `-c` -- As it does not make sense to indent if there is no `Code:` header to indent relative to. I am not sure if there is a use case for `-l` without `-c`, but would leave this functionality as is.
>> 
>> ## Current behaviour of javap previously differed with and without -verbose in the following way:
>> 
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>        0: iconst_0
>>        ...
>>       14: return
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> ### Case: `javap -verbose EmptyLoop.class`
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> ## New behaviour:
>> ### Case: `javap -l -c EmptyLoop.class`
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>          0: iconst_0
>>          ...
>>         14: return
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>> 
>> 
>> 
>> ## Open Questions
>> ### Add code header for only `-l` case?
>> Currently for `-l` without `-c` things look as follows:
>> 
>> 
>> ...
>>   public void emptyLoop();
>>     LineNumberTable:
>>       line 3: 0
>>       line 5: 14
>> ...
>> 
>> 
>> One could also imagine making the output:
>> 
>> ...
>>   public void emptyLoop();
>>     Code:
>>       LineNumberTable:
>>         line 3: 0
>>         line 5: 14
>> ...
>
> Jonathan Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feat: add Code: header for LNT and LVT

I have additionally created https://bugs.openjdk.org/browse/JDK-8345145 to further pursue the `-l` without `-c` case, with the idea of not outputting any code attributes when neither `-c` nor `-v` is specified.

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

PR Comment: https://git.openjdk.org/jdk/pull/22359#issuecomment-2504979528

From asotona at openjdk.org  Thu Nov 28 07:16:40 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 28 Nov 2024 07:16:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-83324714
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <-obkcdGi1-P2yLOYnCFIDo6z_ldLIDE90jbM847BRAU=.87b21383-ded7-4296-8d85-8b256dce0980@github.com>

On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

I would give a go to all trivial removals of `@enablePreview` after a brief check the tests pass.
However all the more complex changes potentially affecting various parts of the JDK infrastructure require deeper review and probably involve more reviewers.
My recommendation for easier review would be to split this 360-files patch into a patch with trivial removals of `@enablePreview` and one or more patches focused on particular area.

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

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2505408069

From liach at openjdk.org  Thu Nov 28 07:47:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Nov 2024 07:47:37 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-83324714
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <daglE0t89kpIo-mIT1Y5MwAlgOtNqRkTsNonb4obFQw=.2dfdfc9a-50de-42be-a55d-71c6a80b8bcd@github.com>

On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

I think the simple removal of `@enablePreview` already require multiple areas of engineers, so to involve a bit more changes to fix them throughoutly is fine; these are all test-only, so we can wait and this can go in after RDP1 began.

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

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2505451198

From jpai at openjdk.org  Thu Nov 28 10:22:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 28 Nov 2024 10:22:10 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from jdk.compiler
 module
Message-ID: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>

Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?

With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.

No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.

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

Commit messages:
 - 8345153: Clean up SecurityManager references from jdk.compiler module

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

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

From duke at openjdk.org  Thu Nov 28 11:37:57 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Thu, 28 Nov 2024 11:37:57 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable iff
 disassembled code output with `-c` or `-v`
Message-ID: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>

This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.

Small changes were also made to existing tests, which seem unproblematic to adjust.

<details>
<summary>Before: `javac -l EmptyLoop`</summary>


Compiled from "EmptyLoop.java"
public class EmptyLoop {
  public EmptyLoop();
    Code:
      LineNumberTable:
        line 1: 0

  public void emptyLoop();
    Code:
      LineNumberTable:
        line 3: 0
        line 5: 14
}


</details>

<details>
<summary>After: `javac -l EmptyLoop`</summary>


Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
Compiled from "EmptyLoop.java"
public class EmptyLoop {
  public EmptyLoop();

  public void emptyLoop();
}


</details>

Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

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

Commit messages:
 - feat: don't display LNT and LVT without -c/-v with warning

Changes: https://git.openjdk.org/jdk/pull/22434/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22434&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345145
  Stats: 118 lines in 8 files changed: 105 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22434.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22434/head:pull/22434

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

From mcimadamore at openjdk.org  Thu Nov 28 12:38:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Nov 2024 12:38:37 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <1GOfceRaLKRKbTe1X_YaBnB6IGgR_Z7YQooVZC7DU6E=.f73614ac-707b-46ec-8d2f-f1a0a517b1bd@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

Nice work!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22434#pullrequestreview-2468042691

From duke at openjdk.org  Thu Nov 28 14:47:36 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Thu, 28 Nov 2024 14:47:36 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <9zwnaLfjq3l19s-Mnp0JuJHv6hYwtxtneyug5-hgy7U=.322dd12b-4c59-4d91-a52d-b89125559eff@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

Thanks for the review and previous input!
Tier 1-3 testing was successful.

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

PR Comment: https://git.openjdk.org/jdk/pull/22434#issuecomment-2506284777

From duke at openjdk.org  Thu Nov 28 14:47:37 2024
From: duke at openjdk.org (duke)
Date: Thu, 28 Nov 2024 14:47:37 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <hbfVeASBQCuex4_lhFY-eZ0HZGK0MTq-gSTEbaZbu98=.deda4014-9736-4f99-b39b-d5148893e0b5@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

@jonath4ndev 
Your change (at version ed67de0ec9b0ac578537cc0038dcadffa3e73985) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22434#issuecomment-2506285547

From liach at openjdk.org  Thu Nov 28 15:12:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Nov 2024 15:12:47 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <JwiryPNM6JkaoFoxyu6M_JW66p-jMSlU2BG3izaSIh8=.10160c08-8e4a-46a5-8f89-3dd84965effc@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

Looks good. However, note that per our guide https://openjdk.org/guide, we usually integrate after about 24 hours to allow sufficient time for all reviewers. So I may sponsor later.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22434#pullrequestreview-2468415451

From duke at openjdk.org  Thu Nov 28 15:16:38 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Thu, 28 Nov 2024 15:16:38 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <JwiryPNM6JkaoFoxyu6M_JW66p-jMSlU2BG3izaSIh8=.10160c08-8e4a-46a5-8f89-3dd84965effc@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
 <JwiryPNM6JkaoFoxyu6M_JW66p-jMSlU2BG3izaSIh8=.10160c08-8e4a-46a5-8f89-3dd84965effc@github.com>
Message-ID: <edMTsLBpyTXACmpAq1ZQ-o0VXYjlOcerLjIViMuZCTk=.c98ec100-51ab-40ac-b6a3-bcd70786c5f5@github.com>

On Thu, 28 Nov 2024 15:09:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> Looks good. However, note that per our guide https://openjdk.org/guide, we usually integrate after about 24 hours to allow sufficient time for all reviewers. So I may sponsor later.

Oh my bad. Thanks for the heads-up!

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

PR Comment: https://git.openjdk.org/jdk/pull/22434#issuecomment-2506340763

From duke at openjdk.org  Thu Nov 28 16:10:43 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Thu, 28 Nov 2024 16:10:43 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <dh3FW5XZMGsjQRRi-f8yB3n0LJfcDwf5Obt5jXvHkiQ=.58b71fc5-1304-4731-9f20-43347aa8b406@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

I made a change to `javap.properties` to make this new change in behaviour more clear in the documentation. 
I just noticed that there is also `javap_de.properties`, `javap_ja.properties` and `javap_zh_CN.properties`, which I have not touched.

I guess leaving out my change in english might be best, to avoid inconsitency between translations? Likely this extra info doesn't provide much value, as one gets the same insight in the warning.

Note: It seems this approach is taken for other cases of incompatible arguments. For example in the case `-public`, `-protected` there is an Error, but no information about the incompatibility in the help output from `javap.properties`:


javap -l -c -private -public EmptyLoop
Error: bad combination of options: -private -public

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

PR Comment: https://git.openjdk.org/jdk/pull/22434#issuecomment-2506441495

From nbenalla at openjdk.org  Thu Nov 28 16:21:43 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 28 Nov 2024 16:21:43 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <CpbT4W7fle3U-5jDphyd9Y-guhUwqde417T4UcwEmds=.ad70bf04-df49-4e77-83b7-4eefca3485db@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

While I am not sure, looking at [JDK-8322041](https://bugs.openjdk.org/browse/JDK-8322041) and[JDK-8333827](https://bugs.openjdk.org/browse/JDK-8333827), it seems that the translations are updated by certain people after RDP1 and then are backported.

At least, it seems out of scope for this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/22434#issuecomment-2506458780

From alanb at openjdk.org  Thu Nov 28 18:23:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 28 Nov 2024 18:23:38 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module
In-Reply-To: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
Message-ID: <lYgEFoPio6qb_8RANuZRxieArqwZ3YZMz3wjPHpNZlQ=.c0969681-c1fb-4444-ac80-037904827f0f@github.com>

On Thu, 28 Nov 2024 10:16:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
> 
> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 354:

> 352:      * relevant path, otherwise if processors are present, logs an
> 353:      * error.  Called when a service loader is unavailable for some
> 354:      * reason, for example, because a service loader class cannot be found.

The comment "because a service loader class cannot be found" is puzzling. Zooming out, the remaining usage of handleServiceLoaderUnavailability is in ServiceIterator where it assumes that the 2-arg SL.load or SL::iterator can throw. SL.load will only throw if the caller (in jdk.compiler) doesn't `uses Processor` or that service class is not accessible, neither is true here. Maybe Jan or someone else can comment further but it looks to me that handleServiceLoaderUnavailability can be removed and the "Fail softly" handling in ServiceIterator can be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22431#discussion_r1862576950

From jlahoda at openjdk.org  Fri Nov 29 08:07:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 29 Nov 2024 08:07:38 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module
In-Reply-To: <lYgEFoPio6qb_8RANuZRxieArqwZ3YZMz3wjPHpNZlQ=.c0969681-c1fb-4444-ac80-037904827f0f@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
 <lYgEFoPio6qb_8RANuZRxieArqwZ3YZMz3wjPHpNZlQ=.c0969681-c1fb-4444-ac80-037904827f0f@github.com>
Message-ID: <eDSKje_AQyUfqSNtYm9d4lMt7lSzg9hY2WtHrVXqccE=.109867d2-327a-445e-8b1d-98e4f67537ea@github.com>

On Thu, 28 Nov 2024 18:21:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
>> 
>> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 354:
> 
>> 352:      * relevant path, otherwise if processors are present, logs an
>> 353:      * error.  Called when a service loader is unavailable for some
>> 354:      * reason, for example, because a service loader class cannot be found.
> 
> The comment "because a service loader class cannot be found" is puzzling. Zooming out, the remaining usage of handleServiceLoaderUnavailability is in ServiceIterator where it assumes that the 2-arg SL.load or SL::iterator can throw. SL.load will only throw if the caller (in jdk.compiler) doesn't `uses Processor` or that service class is not accessible, neither is true here. Maybe Jan or someone else can comment further but it looks to me that handleServiceLoaderUnavailability can be removed and the "Fail softly" handling in ServiceIterator can be removed too.

I went through the code, and I think this is right - the whole `handleServiceLoaderUnavailability` can be dropped, and everything that is referred to from it (`needClassLoader`, `handleException`, and especially(!) `ServiceProxy`; and probably also relevant keys from `compiler.properties`, unless they are used elsewhere) can, I think, be dropped.

More specifically, from `ServiceIterator.<init>`:

            try {
                try {
                    loader = ServiceLoader.load(Processor.class, classLoader);
                    this.iterator = loader.iterator();
                } catch (Exception e) {
                    // Fail softly if a loader is not actually needed.
                    this.iterator = handleServiceLoaderUnavailability("proc.no.service", null);
                }
            } catch (Throwable t) {
                log.error(Errors.ProcServiceProblem);
                throw new Abort(t);
            }


my reading of both the javadoc and code in the `ServiceLoader` is that we can drop both of the `try-catch` statements, leaving only:

loader = ServiceLoader.load(Processor.class, classLoader);
this.iterator = loader.iterator();


Although if we wanted to be very careful, we could keep the outter `try-catch`.

CC @jddarcy

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22431#discussion_r1863105438

From mcimadamore at openjdk.org  Fri Nov 29 13:06:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Nov 2024 13:06:44 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
Message-ID: <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>

On Thu, 14 Nov 2024 02:58:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review these changes with some minor lint-related fixes and cleanups.
>> 
>> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8344079
>  - Fix typo in comment.
>  - Minor lint-related cleanups.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintSuppression.java line 49:

> 47:  *  deletion without notice.</b>
> 48:  */
> 49: public class LintSuppression {

Question: why is this a separate class? E.g. as opposed to just add the methods in this class to the main `Lint` class? After all, it seems that `LintSuppression` has no meaningful state so to speak - it seems mostly a collection of "helper methods". I'd use more encapsulation, as these methods should proabably never used outside `Lint` itself?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java line 1365:

> 1363: 
> 1364:             if (!incubatingModules.isEmpty()) {
> 1365:                 log.warning(LintCategory.INCUBATING, null, Warnings.IncubatingModules(incubatingModules));

Thanks for fixing all these. IMHO the fact we had so many bad usages points at the fact that the system we use to report warning is a bit too loose. I wonder if we should differentiate warning keys from lint warning keys, and have lint warnings be reported with a dedicated method in `Log`, so that there can be no confusion as to which is which (this is for a separate, possible, future PR)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863495369
PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863497722

From jlahoda at openjdk.org  Fri Nov 29 14:21:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 29 Nov 2024 14:21:10 GMT
Subject: RFR: 8345248: Module name 'transitive' not accepted for `requires
 transitive`
Message-ID: <BdvX8oKPAwQCQFwvg4jAVqO_YldAQUYxmw6XP3IXJPU=.0370d7a1-5ee8-4fed-802f-8e02bc5f3817@github.com>

Considering module named `transitive`, it should be possible to write: `requires transitive;`, which works, and also `requires transitive transitive;`, which currently does not work:

$ javac -d out/ --module-source-path . transitive/module-info.java test/module-info.java
test/module-info.java:2: error: repeated modifier
    requires transitive transitive;
                        ^
test/module-info.java:2: error: <identifier> expected
    requires transitive transitive;
                                  ^
2 errors


The proposed solution is to properly handle lookahead if the transitive flag has already been seen.

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

Commit messages:
 - 8345248: Module name 'transitive' not accepted for `requires transitive`

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

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

From jlahoda at openjdk.org  Fri Nov 29 14:30:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 29 Nov 2024 14:30:57 GMT
Subject: RFR: 8345248: Module name 'transitive' not accepted for `requires
 transitive` [v2]
In-Reply-To: <BdvX8oKPAwQCQFwvg4jAVqO_YldAQUYxmw6XP3IXJPU=.0370d7a1-5ee8-4fed-802f-8e02bc5f3817@github.com>
References: <BdvX8oKPAwQCQFwvg4jAVqO_YldAQUYxmw6XP3IXJPU=.0370d7a1-5ee8-4fed-802f-8e02bc5f3817@github.com>
Message-ID: <8jIxgBtGPpMFHk0reDWvvSQKifhxALDsnlH9_JEXZdE=.07575c6c-4832-42e1-b9a2-df25a58acfae@github.com>

> Considering module named `transitive`, it should be possible to write: `requires transitive;`, which works, and also `requires transitive transitive;`, which currently does not work:
> 
> $ javac -d out/ --module-source-path . transitive/module-info.java test/module-info.java
> test/module-info.java:2: error: repeated modifier
>     requires transitive transitive;
>                         ^
> test/module-info.java:2: error: <identifier> expected
>     requires transitive transitive;
>                                   ^
> 2 errors
> 
> 
> The proposed solution is to properly handle lookahead if the transitive flag has already been seen.

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

  Fixing test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22460/files
  - new: https://git.openjdk.org/jdk/pull/22460/files/11932dcc..0a0e6d30

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

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

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

From liach at openjdk.org  Fri Nov 29 16:26:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 29 Nov 2024 16:26:46 GMT
Subject: RFR: 8345145: Display javap LineNumberTable and LocalVariableTable
 iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <sxTv7o-i5tDmNvmYl-Nnm8usXa2frNIiA0AZLvDIOb4=.92a27396-84d8-4db9-9b50-c30f18c7e884@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

It's been over 24 hours. Thanks for everyone's review and patience!

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

PR Comment: https://git.openjdk.org/jdk/pull/22434#issuecomment-2508110686

From duke at openjdk.org  Fri Nov 29 16:26:47 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 29 Nov 2024 16:26:47 GMT
Subject: Integrated: 8345145: Display javap LineNumberTable and
 LocalVariableTable iff disassembled code output with `-c` or `-v`
In-Reply-To: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
References: <9Xn81Ak0IV60zhrEBc-_VNaE91GJDER3vsh368ZY5go=.fd317fbb-3783-4a10-868a-297b5de59b72@github.com>
Message-ID: <7K-6ZVsuGYLiJEAFqriCv2DwzgOxOM4d6G6VC6H_fiY=.89f49e8f-a78b-4af5-b350-1e22a94b20e7@github.com>

On Thu, 28 Nov 2024 11:33:43 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes a suggested change in behaviour of `javap -l` without `-v` or `-c`.
> Previously it was possible to print `LineNumberTable` and `LocalVariableTable` without disassembled code output. This didn't make much sense, as there is no context for this output. This PR proposes to output a warning for this case, as well as not print the `LineNumberTable`and `LocalVariableTable` attrubutes. They are nested attributes of the `CodeAttribute` and thus should only be printed if the `CodeAttribute`  is also printed.
> 
> Small changes were also made to existing tests, which seem unproblematic to adjust.
> 
> <details>
> <summary>Before: `javac -l EmptyLoop`</summary>
> 
> 
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
>     Code:
>       LineNumberTable:
>         line 1: 0
> 
>   public void emptyLoop();
>     Code:
>       LineNumberTable:
>         line 3: 0
>         line 5: 14
> }
> 
> 
> </details>
> 
> <details>
> <summary>After: `javac -l EmptyLoop`</summary>
> 
> 
> Warning: bad combination of options: -l without -c - line number and local variable tables will not be printed
> Compiled from "EmptyLoop.java"
> public class EmptyLoop {
>   public EmptyLoop();
> 
>   public void emptyLoop();
> }
> 
> 
> </details>
> 
> Stems from discussion in: https://github.com/openjdk/jdk/pull/22359

This pull request has now been integrated.

Changeset: ed03f0d9
Author:    Jonathan Lamp?rth <jonathan.lamperth at oracle.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed03f0d9d10518242a3dc6e3685f1bdb0550c723
Stats:     118 lines in 8 files changed: 105 ins; 5 del; 8 mod

8345145: Display javap LineNumberTable and LocalVariableTable iff disassembled code output with `-c` or `-v`

Reviewed-by: mcimadamore, liach

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

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

From acobbs at openjdk.org  Fri Nov 29 16:33:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 29 Nov 2024 16:33:56 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v3]
In-Reply-To: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
Message-ID: <gNtP7x3xG6d-sk6k6zo1AQeFasyxjtKEfj3HSo3018Q=.c08ce16f-3e19-46fb-9569-1699256e3e48@github.com>

> Please review these changes with some minor lint-related fixes and cleanups.
> 
> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.

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

  Fold LintSuppression methods back into existing Lint class.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22056/files
  - new: https://git.openjdk.org/jdk/pull/22056/files/8b961d48..7cb7aa0c

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

  Stats: 197 lines in 2 files changed: 65 ins; 127 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22056/head:pull/22056

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

From acobbs at openjdk.org  Fri Nov 29 16:33:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 29 Nov 2024 16:33:56 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
Message-ID: <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>

On Fri, 29 Nov 2024 13:01:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Question: why is this a separate class?

Simply because it foreshadows [the patch for JDK-8344159](https://github.com/archiecobbs/jdk/blob/suppression/src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintSuppression.java), in which the file becomes a proper singleton responsible for tracking suppressions. Admittedly that's not really a good reason, so I'll fold these methods into `Lint.java` for this patch. Should be fixed in 7cb7aa0cd01.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java line 1365:
> 
>> 1363: 
>> 1364:             if (!incubatingModules.isEmpty()) {
>> 1365:                 log.warning(LintCategory.INCUBATING, null, Warnings.IncubatingModules(incubatingModules));
> 
> Thanks for fixing all these. IMHO the fact we had so many bad usages points at the fact that the system we use to report warning is a bit too loose. I wonder if we should differentiate warning keys from lint warning keys, and have lint warnings be reported with a dedicated method in `Log`, so that there can be no confusion as to which is which (this is for a separate, possible, future PR)

Agree... one of the best ways to ensure a policy is correctly followed is to make the build fail when it's not :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863752620
PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863752769

From mcimadamore at openjdk.org  Fri Nov 29 17:36:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Nov 2024 17:36:40 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v3]
In-Reply-To: <gNtP7x3xG6d-sk6k6zo1AQeFasyxjtKEfj3HSo3018Q=.c08ce16f-3e19-46fb-9569-1699256e3e48@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <gNtP7x3xG6d-sk6k6zo1AQeFasyxjtKEfj3HSo3018Q=.c08ce16f-3e19-46fb-9569-1699256e3e48@github.com>
Message-ID: <IcjUa0Oez_Cx42fUlnKDo_ExZ-Fdl0eBywFp6SB80OA=.ff495ec1-508b-4b54-9b0b-53a05b51d5c0@github.com>

On Fri, 29 Nov 2024 16:33:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review these changes with some minor lint-related fixes and cleanups.
>> 
>> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold LintSuppression methods back into existing Lint class.

Looks good, I've left some additional style-related comment

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 437:

> 435:         return attributes
> 436:           .filter(attribute -> attribute.type.tsym == syms.suppressWarningsType.tsym)
> 437:           .map(attribute -> attribute.member(names.value))

IMHO this could be simplified - there's 5/6 stream calls just to get the suppression value out of the SuppressWarnings. I'd suggest to put that logic in its own helper method and just to a single `map` that points there. I'd also suggest to use imperative logic in that helper method.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22056#pullrequestreview-2470355955
PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863808158

From duke at openjdk.org  Fri Nov 29 17:46:47 2024
From: duke at openjdk.org (Luca Kellermann)
Date: Fri, 29 Nov 2024 17:46:47 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <b68Rkl5iDvoMYYqf4Mr0t-PaoJeQquB2fSPLopN2e54=.e7895747-9588-4cdd-8d07-93cc44b963bb@github.com>

On Fri, 15 Nov 2024 11:53:00 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 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - 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/ConstantDynami...

The `@since 24` tags added in https://github.com/openjdk/jdk/pull/20761 are still there and should probably be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2508202276

From nbenalla at openjdk.org  Fri Nov 29 18:19:50 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 29 Nov 2024 18:19:50 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <ymGxHQFf6gaRA17dCrEpICrp7iEYTg1FuHvXbqKS2E8=.9ab63225-fdf1-41f3-b1fd-3226dd50678f@github.com>

On Fri, 15 Nov 2024 11:53:00 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 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - 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/ConstantDynami...

Thanks for reporting luca, we still don't test for redundant tags so I missed this.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2508245393

From mcimadamore at openjdk.org  Fri Nov 29 18:49:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Nov 2024 18:49:39 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
Message-ID: <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>

On Fri, 29 Nov 2024 16:31:26 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java line 1365:
>> 
>>> 1363: 
>>> 1364:             if (!incubatingModules.isEmpty()) {
>>> 1365:                 log.warning(LintCategory.INCUBATING, null, Warnings.IncubatingModules(incubatingModules));
>> 
>> Thanks for fixing all these. IMHO the fact we had so many bad usages points at the fact that the system we use to report warning is a bit too loose. I wonder if we should differentiate warning keys from lint warning keys, and have lint warnings be reported with a dedicated method in `Log`, so that there can be no confusion as to which is which (this is for a separate, possible, future PR)
>
> Agree... one of the best ways to ensure a policy is correctly followed is to make the build fail when it's not :)

Filed:

https://bugs.openjdk.org/browse/JDK-8345263

I will take a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863853834

From acobbs at openjdk.org  Sat Nov 30 17:35:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 30 Nov 2024 17:35:56 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v4]
In-Reply-To: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
Message-ID: <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>

> Please review these changes with some minor lint-related fixes and cleanups.
> 
> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.

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

  Address review comment by being less Streamy.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22056/files
  - new: https://git.openjdk.org/jdk/pull/22056/files/7cb7aa0c..af342035

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

  Stats: 22 lines in 1 file changed: 8 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/22056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22056/head:pull/22056

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

From acobbs at openjdk.org  Sat Nov 30 17:35:57 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 30 Nov 2024 17:35:57 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v3]
In-Reply-To: <IcjUa0Oez_Cx42fUlnKDo_ExZ-Fdl0eBywFp6SB80OA=.ff495ec1-508b-4b54-9b0b-53a05b51d5c0@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <gNtP7x3xG6d-sk6k6zo1AQeFasyxjtKEfj3HSo3018Q=.c08ce16f-3e19-46fb-9569-1699256e3e48@github.com>
 <IcjUa0Oez_Cx42fUlnKDo_ExZ-Fdl0eBywFp6SB80OA=.ff495ec1-508b-4b54-9b0b-53a05b51d5c0@github.com>
Message-ID: <IfUBjOtUy5knxB0Ywnio3s6AHXcjUmjGfkJdQsVR6z8=.5cee8266-79e8-4edb-aaaf-092521ddf51f@github.com>

On Fri, 29 Nov 2024 17:33:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fold LintSuppression methods back into existing Lint class.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 437:
> 
>> 435:         return attributes
>> 436:           .filter(attribute -> attribute.type.tsym == syms.suppressWarningsType.tsym)
>> 437:           .map(attribute -> attribute.member(names.value))
> 
> IMHO this could be simplified - there's 5/6 stream calls just to get the suppression value out of the SuppressWarnings. I'd suggest to put that logic in its own helper method and just to a single `map` that points there. I'd also suggest to use imperative logic in that helper method.

Yeah, it ended up just being hard to read. See if af342035e0d looks better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1864372293