From rriggs at openjdk.org  Thu Jan  2 18:34:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 2 Jan 2025 18:34:38 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <dr1_0pthFJtf_cDfhekixQSS2XOPM92JjX3vT763Ne8=.3e52b7b1-3420-4e7c-9c35-3fe8b1335eab@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2528039527

From acobbs at openjdk.org  Thu Jan  2 19:05:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 2 Jan 2025 19:05:53 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v9]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <Z2nUvpKRFs7qVkprsEGrF3dkdryrIG30R-vJfrQWp-g=.4ebed668-e3c3-4aa9-bb65-6e5bf1aeabbc@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 17 commits:

 - Bump copyright year to 2025.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - 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
 - ... and 7 more: https://git.openjdk.org/jdk/compare/a77ed30f...40b143c0

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

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=08
  Stats: 231 lines in 99 files changed: 0 ins; 106 del; 125 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  Thu Jan  2 19:13:11 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 2 Jan 2025 19:13:11 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v8]
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: <YCzCnkFwApuogRMxVv3QHNSW5eJkHX1TIj0htS2SETw=.3b99637e-61a7-41e4-ad4b-f9a42b1e3904@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 pull request now contains 11 commits:

 - Bump copyright year to 2025.
 - Merge branch 'master' into JDK-8344079
 - Merge branch 'master' into JDK-8344079
 - Refactor to clarify handling of special flag "-XDwarnOnAccessToMembers".
 - Tighten up declared type of lexWarning() parameter.
 - Merge branch 'master' into JDK-8344079
 - Address review comment by being less Streamy.
 - Fold LintSuppression methods back into existing Lint class.
 - Merge branch 'master' into JDK-8344079
 - Fix typo in comment.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a77ed30f...d58f3ad6

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

Changes: https://git.openjdk.org/jdk/pull/22056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22056&range=07
  Stats: 185 lines in 5 files changed: 72 ins; 56 del; 57 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 Jan  2 19:17:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 2 Jan 2025 19:17:54 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation [v3]
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <8BvHYEKsyX1gpbnef9dk6tnitB1LUe6cVwftydT4rZA=.5344c9bd-3c20-4d9a-975e-429520abd187@github.com>

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

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:

 - Bump copyright year to 2025.
 - Merge branch 'master' into JDK-8344148
 - Merge branch 'master' into JDK-8344148
 - Merge branch 'master' into JDK-8344148
 - Update copyright years.
 - Add an explicit compiler phase for warning generation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22088/files
  - new: https://git.openjdk.org/jdk/pull/22088/files/b1ca46d9..03f67319

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

  Stats: 16289 lines in 412 files changed: 12651 ins; 2312 del; 1326 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 naoto at openjdk.org  Thu Jan  2 19:19:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Jan 2025 19:19:37 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v9]
In-Reply-To: <Z2nUvpKRFs7qVkprsEGrF3dkdryrIG30R-vJfrQWp-g=.4ebed668-e3c3-4aa9-bb65-6e5bf1aeabbc@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <Z2nUvpKRFs7qVkprsEGrF3dkdryrIG30R-vJfrQWp-g=.4ebed668-e3c3-4aa9-bb65-6e5bf1aeabbc@github.com>
Message-ID: <7mW7RDVbl_6nNk0mxOuoWzaw2MNklR_yTClYZniCdZE=.a1e2ca63-2eab-438a-866c-2bc199cfb9f0@github.com>

On Thu, 2 Jan 2025 19:05:53 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 17 commits:
> 
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - 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
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/a77ed30f...40b143c0

Changes related to i18n look good. Looks like some files in `java.desktop` package are also modified. Just wondering they may not be seen by client folks as the title mentions core-libs.

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2568252374

From acobbs at openjdk.org  Thu Jan  2 19:56:16 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 2 Jan 2025 19:56:16 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v10]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <sPaxU6uZsvd8nUNuBXssZsEaPOpKEJY-fta5Qn44MGw=.dc3df45f-e6a6-4cea-bf09-dae9f25c2291@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:

  Revert changes under src/java.desktop (to be moved into a separate PR).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/40b143c0..1102421d

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

  Stats: 27 lines in 9 files changed: 18 ins; 0 del; 9 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  Thu Jan  2 19:56:16 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 2 Jan 2025 19:56:16 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v9]
In-Reply-To: <7mW7RDVbl_6nNk0mxOuoWzaw2MNklR_yTClYZniCdZE=.a1e2ca63-2eab-438a-866c-2bc199cfb9f0@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <Z2nUvpKRFs7qVkprsEGrF3dkdryrIG30R-vJfrQWp-g=.4ebed668-e3c3-4aa9-bb65-6e5bf1aeabbc@github.com>
 <7mW7RDVbl_6nNk0mxOuoWzaw2MNklR_yTClYZniCdZE=.a1e2ca63-2eab-438a-866c-2bc199cfb9f0@github.com>
Message-ID: <2GrurB7a0i-AzuGT-5pepQWBU8F8-Opo09ilUEYMmmc=.5cfa028e-8192-4ee3-ae3d-320e475f3f21@github.com>

On Thu, 2 Jan 2025 19:16:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks like some files in java.desktop package are also modified. Just wondering they may not be seen by client folks as the title mentions core-libs.

Yeah my attempt to split this up was not perfect. I did have a separate, earlier PR (#21850) for the `client` label stuff, but somehow some of it still spilled over into this one... bleh.

But this is easy to fix - I am going to revert the changes under `src/java.destktop` and put them into a new PR. Thanks for the prodding.

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2568294020

From joehw at openjdk.org  Thu Jan  2 20:44:40 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 2 Jan 2025 20:44:40 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v10]
In-Reply-To: <sPaxU6uZsvd8nUNuBXssZsEaPOpKEJY-fta5Qn44MGw=.dc3df45f-e6a6-4cea-bf09-dae9f25c2291@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <sPaxU6uZsvd8nUNuBXssZsEaPOpKEJY-fta5Qn44MGw=.dc3df45f-e6a6-4cea-bf09-dae9f25c2291@github.com>
Message-ID: <vkGDNPYQWDtoCnNUga1aHDaUgO0lx5nkYbjGxeIN81E=.ea51a943-452a-45f4-a4c2-5e172e741cac@github.com>

On Thu, 2 Jan 2025 19:56:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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:
> 
>   Revert changes under src/java.desktop (to be moved into a separate PR).

java.xml changes look good. Please note though, the @LastModified tag needs to be updated as well.

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

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

From acobbs at openjdk.org  Thu Jan  2 21:11:04 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 2 Jan 2025 21:11:04 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v11]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@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:

  Update @LastModified tags.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/1102421d..2049463f

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

  Stats: 9 lines in 9 files changed: 0 ins; 0 del; 9 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  Thu Jan  2 21:11:04 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 2 Jan 2025 21:11:04 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v10]
In-Reply-To: <sPaxU6uZsvd8nUNuBXssZsEaPOpKEJY-fta5Qn44MGw=.dc3df45f-e6a6-4cea-bf09-dae9f25c2291@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <sPaxU6uZsvd8nUNuBXssZsEaPOpKEJY-fta5Qn44MGw=.dc3df45f-e6a6-4cea-bf09-dae9f25c2291@github.com>
Message-ID: <zEaUuyOAoeYlpAqvBu1yOfnZHp7HS3ziTZOMiGVkm2M=.426ca9fe-47f4-41be-92a5-1a3db6e53f52@github.com>

On Thu, 2 Jan 2025 19:56:16 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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:
> 
>   Revert changes under src/java.desktop (to be moved into a separate PR).

> java.xml changes look good. Please note though, the @lastmodified tag needs to be updated as well.

Thanks, didn't know about those. Should be fixed in 2049463f18f.

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2568379841

From joehw at openjdk.org  Thu Jan  2 21:56:40 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 2 Jan 2025 21:56:40 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v11]
In-Reply-To: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com>
Message-ID: <qU2b1xyd4glZ3jqA0cdBSDqt_g1hR-i5TuZhEEOEug8=.7bf90143-d0bf-4fc8-a3b6-c979c6d8a7b1@github.com>

On Thu, 2 Jan 2025 21:11:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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:
> 
>   Update @LastModified tags.

Marked as reviewed by joehw (Reviewer).

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

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

From qxing at openjdk.org  Fri Jan  3 01:36:51 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Fri, 3 Jan 2025 01:36:51 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <7dv3Q8SJD7soOx8rgXMB2_ZOf3RbwtcI7zuzybFjJoQ=.b875ea95-9e62-41b8-9898-0d7d21a14b5e@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Thank you all for your suggestions and reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568590393

From duke at openjdk.org  Fri Jan  3 01:36:51 2025
From: duke at openjdk.org (duke)
Date: Fri, 3 Jan 2025 01:36:51 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <6jso7rCfR9hvxiCw9z222ueaJQxQol9ELecOcr5BQxQ=.d399c10e-79bd-4f4f-9ed1-91f777c3cb8a@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

@MaxXSoft 
Your change (at version 7f85c5e30ab69fe2f94d4604073eb8e610bfc6c2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568591104

From duke at openjdk.org  Fri Jan  3 05:02:36 2025
From: duke at openjdk.org (pcoperatr)
Date: Fri, 3 Jan 2025 05:02:36 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v11]
In-Reply-To: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com>
Message-ID: <D-bhTY_UAqKDiMhsRNmtEmT2xAX8lrB88vQp2cfWe_o=.9fff54f3-3eb5-46f0-a1cb-0ad3c37d4dec@github.com>

On Thu, 2 Jan 2025 21:11:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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:
> 
>   Update @LastModified tags.

Marked as reviewed by pcoperatr at github.com (no known OpenJDK username).

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

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

From duke at openjdk.org  Fri Jan  3 05:11:36 2025
From: duke at openjdk.org (pcoperatr)
Date: Fri, 3 Jan 2025 05:11:36 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v11]
In-Reply-To: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com>
Message-ID: <dILqI8Jx_UcCP0ZzI66FNmYi0VsFbeXhthGSqqrvET4=.096a4bb9-46b9-48af-b05a-d9fefebc54d0@github.com>

On Thu, 2 Jan 2025 21:11:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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:
> 
>   Update @LastModified tags.

Marked as reviewed by pcoperatr at github.com (no known OpenJDK username).

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

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

From dholmes at openjdk.org  Mon Jan  6 06:26:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 06:26:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <Sku5_RiFCfq5hUWlIPyPuShlTEkUjy1puhFyRXD-3PM=.22b1336d-2876-41dd-bb9e-8384c84983ba@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

LGTM2.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2531429430

From qxing at openjdk.org  Mon Jan  6 06:26:47 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Mon, 6 Jan 2025 06:26:47 GMT
Subject: Integrated: 8346773: Fix unmatched brackets in some misc files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <MGlZQfhGaTFiQzpqY86SF5FGLMjKbQ9ibj_l678R8Os=.25c31ede-ade3-4e04-ace9-f69db071d95a@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.

This pull request has now been integrated.

Changeset: f1d85ab3
Author:    Qizheng Xing <qxing at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1d85ab3e61f923b4e120cf30e16109e04505b53
Stats:     10 lines in 7 files changed: 0 ins; 0 del; 10 mod

8346773: Fix unmatched brackets in some misc files

Reviewed-by: kbarrett, alanb, rriggs, dholmes, erikj, liach

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

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

From mcimadamore at openjdk.org  Mon Jan  6 12:18:41 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 12:18:41 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v8]
In-Reply-To: <YCzCnkFwApuogRMxVv3QHNSW5eJkHX1TIj0htS2SETw=.3b99637e-61a7-41e4-ad4b-f9a42b1e3904@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <YCzCnkFwApuogRMxVv3QHNSW5eJkHX1TIj0htS2SETw=.3b99637e-61a7-41e4-ad4b-f9a42b1e3904@github.com>
Message-ID: <cxd_7NHgk3OEyN_to_sSI1H5DoK7Myjjwvc1QZnx8Lw=.018bdcdd-ce6e-40b5-9cdd-f2cc78f565bd@github.com>

On Thu, 2 Jan 2025 19:13:11 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 pull request now contains 11 commits:
> 
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into JDK-8344079
>  - Merge branch 'master' into JDK-8344079
>  - Refactor to clarify handling of special flag "-XDwarnOnAccessToMembers".
>  - Tighten up declared type of lexWarning() parameter.
>  - Merge branch 'master' into JDK-8344079
>  - Address review comment by being less Streamy.
>  - Fold LintSuppression methods back into existing Lint class.
>  - Merge branch 'master' into JDK-8344079
>  - Fix typo in comment.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/a77ed30f...d58f3ad6

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22056#pullrequestreview-2532021535

From nbenalla at openjdk.org  Mon Jan  6 12:34:38 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 12:34:38 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v3]
In-Reply-To: <mOvr18uhJbOPABS1VY30Vp9aY_z6Fom0TODIbewBAH8=.5eee8fc4-d0f6-4bd4-ba11-13e9f5514821@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <mOvr18uhJbOPABS1VY30Vp9aY_z6Fom0TODIbewBAH8=.5eee8fc4-d0f6-4bd4-ba11-13e9f5514821@github.com>
Message-ID: <uZRtVAs7VaZCW3FXt-Bo3vILkYKGqNH2vaMF8Mp56_Y=.59bf9845-68d6-41f1-b085-1de746e1a36d@github.com>

On Thu, 21 Nov 2024 13:57:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

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

This PR has been superseded by https://github.com/openjdk/jdk/pull/22920. Please continue the discussion and review there.

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

PR Comment: https://git.openjdk.org/jdk/pull/22244#issuecomment-2573018804

From nbenalla at openjdk.org  Mon Jan  6 12:39:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 12:39:57 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of the
 methods
Message-ID: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>

Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.

TIA.

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

Commit messages:
 - Respond to feedback around the wording.
 - Respond to feedback. Using Jan's comment to not imply particular requirement on the implementation.
 - (C) 2025
 - Initial commit obtained from a cherry pick/squash of a now superseded PR.

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

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

From liach at openjdk.org  Mon Jan  6 12:39:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Jan 2025 12:39:57 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
Message-ID: <JQLCuH5-DxvIRIKFijbHguFlUA3AxSn8aEQaT_9-rgc=.93c77848-bc02-40d1-ad14-9abb7cdfc1ce@github.com>

On Sun, 5 Jan 2025 22:16:45 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
> 
> TIA.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 785:

> 783:      * specified in JLS {@jls 8.4.8.1} and {@jls 8.4.8.3}. In particular, the additional constraints
> 784:      * on thrown types, return types and those constraints on method modifiers not directly
> 785:      * bound to the overriding relation as such.

Suggestion:

     * on exception types, return types, and method modifiers do not affect
     * the overriding relation.


The original wording has grammatical mistake and makes no sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1903619417

From nbenalla at openjdk.org  Mon Jan  6 12:39:58 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 12:39:58 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <JQLCuH5-DxvIRIKFijbHguFlUA3AxSn8aEQaT_9-rgc=.93c77848-bc02-40d1-ad14-9abb7cdfc1ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <JQLCuH5-DxvIRIKFijbHguFlUA3AxSn8aEQaT_9-rgc=.93c77848-bc02-40d1-ad14-9abb7cdfc1ce@github.com>
Message-ID: <jC9WXPd6xDJeCEZK9uHs4GG1Cr1C8UWoBE_8L0z7CV0=.c202a78c-d19c-4e4f-81ff-be702cffde41@github.com>

On Mon, 6 Jan 2025 03:42:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
>> 
>> TIA.
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 785:
> 
>> 783:      * specified in JLS {@jls 8.4.8.1} and {@jls 8.4.8.3}. In particular, the additional constraints
>> 784:      * on thrown types, return types and those constraints on method modifiers not directly
>> 785:      * bound to the overriding relation as such.
> 
> Suggestion:
> 
>      * on exception types, return types, and method modifiers do not affect
>      * the overriding relation.
> 
> 
> The original wording has grammatical mistake and makes no sense.

I don't agree that it makes no sense but I find this wording simpler, so I'll use it instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904066004

From acobbs at openjdk.org  Mon Jan  6 15:31:42 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 6 Jan 2025 15:31:42 GMT
Subject: Integrated: 8344079: Minor fixes and cleanups to compiler lint-related
 code
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: <wkF0fgIK-a2NmTURtxDlqGSNYALB4ge6OR2pY4M030g=.a7e9e020-c714-47fe-8c44-e7f86182a077@github.com>

On Wed, 13 Nov 2024 02:39:10 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.

This pull request has now been integrated.

Changeset: dd81f8dc
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd81f8dcf504d4329e710623c4c92e4786948ada
Stats:     185 lines in 5 files changed: 72 ins; 56 del; 57 mod

8344079: Minor fixes and cleanups to compiler lint-related code

Reviewed-by: mcimadamore

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

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

From acobbs at openjdk.org  Mon Jan  6 15:31:41 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 6 Jan 2025 15:31:41 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v8]
In-Reply-To: <YCzCnkFwApuogRMxVv3QHNSW5eJkHX1TIj0htS2SETw=.3b99637e-61a7-41e4-ad4b-f9a42b1e3904@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <YCzCnkFwApuogRMxVv3QHNSW5eJkHX1TIj0htS2SETw=.3b99637e-61a7-41e4-ad4b-f9a42b1e3904@github.com>
Message-ID: <mAUmPCkUYhzF4Gmzn-F0t07245FJEouVcDwV6yc6Dl0=.994a1f0d-0a92-4543-a371-5520bad5ccbc@github.com>

On Thu, 2 Jan 2025 19:13:11 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 pull request now contains 11 commits:
> 
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into JDK-8344079
>  - Merge branch 'master' into JDK-8344079
>  - Refactor to clarify handling of special flag "-XDwarnOnAccessToMembers".
>  - Tighten up declared type of lexWarning() parameter.
>  - Merge branch 'master' into JDK-8344079
>  - Address review comment by being less Streamy.
>  - Fold LintSuppression methods back into existing Lint class.
>  - Merge branch 'master' into JDK-8344079
>  - Fix typo in comment.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/a77ed30f...d58f3ad6

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/22056#issuecomment-2573344174

From vromero at openjdk.org  Mon Jan  6 17:14:37 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Jan 2025 17:14:37 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation [v3]
In-Reply-To: <hDn6T4MsZ3vDFDiDN2gkxXmFb24TLmIeq9p0sWnge8I=.dcba2b3d-d34f-40e5-a785-36587007cdb7@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
 <WzQ2Z8l1lMxs5ufhxLdQkVyXBmwn7JaUPODh9Q3szL4=.4bd8af79-e868-4320-bb91-38290a0f8d73@github.com>
 <hDn6T4MsZ3vDFDiDN2gkxXmFb24TLmIeq9p0sWnge8I=.dcba2b3d-d34f-40e5-a785-36587007cdb7@github.com>
Message-ID: <7j8HjdIBVa1L84IiUrP9MtedXtZOnE27JBJ0XxjP2i4=.96b0e2a0-faf6-472f-9c11-ec0fadfbf404@github.com>

On Thu, 21 Nov 2024 17:33:55 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

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

I see, I'm OK with your approach, thanks for the clarification

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22088#discussion_r1904417980

From vromero at openjdk.org  Mon Jan  6 18:18:37 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 6 Jan 2025 18:18:37 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation [v3]
In-Reply-To: <8BvHYEKsyX1gpbnef9dk6tnitB1LUe6cVwftydT4rZA=.5344c9bd-3c20-4d9a-975e-429520abd187@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
 <8BvHYEKsyX1gpbnef9dk6tnitB1LUe6cVwftydT4rZA=.5344c9bd-3c20-4d9a-975e-429520abd187@github.com>
Message-ID: <eXkFd2CEHa_YqbyE8dZEp4XMsEdujnP6HLW_gMrMq1o=.81da40c4-6994-48f0-8285-3f4a5301ad8d@github.com>

On Thu, 2 Jan 2025 19:17:54 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.
>
> 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:
> 
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into JDK-8344148
>  - Merge branch 'master' into JDK-8344148
>  - Merge branch 'master' into JDK-8344148
>  - Update copyright years.
>  - Add an explicit compiler phase for warning generation.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22088#pullrequestreview-2532708559

From acobbs at openjdk.org  Mon Jan  6 18:39:42 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 6 Jan 2025 18:39:42 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation [v3]
In-Reply-To: <8BvHYEKsyX1gpbnef9dk6tnitB1LUe6cVwftydT4rZA=.5344c9bd-3c20-4d9a-975e-429520abd187@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
 <8BvHYEKsyX1gpbnef9dk6tnitB1LUe6cVwftydT4rZA=.5344c9bd-3c20-4d9a-975e-429520abd187@github.com>
Message-ID: <nrx3m6R5WGt8-OpQIASNvsHFlWlXPk4Lv_0hAQzXQTE=.fbb38a1c-3f39-4bab-aea5-7f3c28cbc726@github.com>

On Thu, 2 Jan 2025 19:17:54 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.
>
> 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:
> 
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into JDK-8344148
>  - Merge branch 'master' into JDK-8344148
>  - Merge branch 'master' into JDK-8344148
>  - Update copyright years.
>  - Add an explicit compiler phase for warning generation.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22088#issuecomment-2573688054

From acobbs at openjdk.org  Mon Jan  6 18:39:43 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 6 Jan 2025 18:39:43 GMT
Subject: Integrated: 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: <Tj_npJGNNhXJwyEys5UnAMfsfDtboq3wUah_t4grc0g=.e78b76d7-06f2-4881-9add-e757fded6e4b@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.

This pull request has now been integrated.

Changeset: 27646e55
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27646e551686ec02740600fc73694fc2fbd00a88
Stats:     220 lines in 19 files changed: 190 ins; 1 del; 29 mod

8344148: Add an explicit compiler phase for warning generation

Reviewed-by: vromero

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

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

From liach at openjdk.org  Mon Jan  6 19:20:36 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Jan 2025 19:20:36 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
Message-ID: <JAr-BrRmAkrOm3wunaO9RaOuVkxMT-piEygNBXo-o-A=.9127a1af-86ac-4ee5-b5b2-5216af4774df@github.com>

On Sun, 5 Jan 2025 22:16:45 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
> 
> TIA.

test/langtools/tools/javac/processing/model/util/elements/overrides/S.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.

Is the beginning copyright year 2023 correct?

test/langtools/tools/javac/processing/model/util/elements/overrides/TestOverrides.java line 54:

> 52:                 if (!elements.overrides(tm, sm, t))
> 53:                     messager.printError(String.format(
> 54:                             "%s does not override %s from %s", tm, sm, t.getQualifiedName()));

This message implies `sm` is from `t`, which is not the case. Consider improving the failure message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904537012
PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904542075

From liach at openjdk.org  Mon Jan  6 21:52:36 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Jan 2025 21:52:36 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <JAr-BrRmAkrOm3wunaO9RaOuVkxMT-piEygNBXo-o-A=.9127a1af-86ac-4ee5-b5b2-5216af4774df@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <JAr-BrRmAkrOm3wunaO9RaOuVkxMT-piEygNBXo-o-A=.9127a1af-86ac-4ee5-b5b2-5216af4774df@github.com>
Message-ID: <w1RU1hsKaWjFOaxfXq210xx3JMkQPvMkXRc_d6bX6G0=.1614c06b-442b-409e-873d-467ac393e067@github.com>

On Mon, 6 Jan 2025 19:12:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
>> 
>> TIA.
>
> test/langtools/tools/javac/processing/model/util/elements/overrides/S.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Is the beginning copyright year 2023 correct?

Thanks for the verification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904672962

From prappo at openjdk.org  Mon Jan  6 22:04:35 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Jan 2025 22:04:35 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <JAr-BrRmAkrOm3wunaO9RaOuVkxMT-piEygNBXo-o-A=.9127a1af-86ac-4ee5-b5b2-5216af4774df@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <JAr-BrRmAkrOm3wunaO9RaOuVkxMT-piEygNBXo-o-A=.9127a1af-86ac-4ee5-b5b2-5216af4774df@github.com>
Message-ID: <Wmer5GpTbV41CADoRUCf-ZAq050v8DmKV08IifWRexU=.a8a045e0-c8c9-4802-85a2-23d07f64453b@github.com>

On Mon, 6 Jan 2025 19:12:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
>> 
>> TIA.
>
> test/langtools/tools/javac/processing/model/util/elements/overrides/S.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Is the beginning copyright year 2023 correct?

Yes, it is. The patch attached to the JBS issue is dated 2023. That patch is used in this PR.

> test/langtools/tools/javac/processing/model/util/elements/overrides/TestOverrides.java line 54:
> 
>> 52:                 if (!elements.overrides(tm, sm, t))
>> 53:                     messager.printError(String.format(
>> 54:                             "%s does not override %s from %s", tm, sm, t.getQualifiedName()));
> 
> This message implies `sm` is from `t`, which is not the case. Consider improving the failure message.

This uses the wording from JLS 8.4.8.1 (emphasis mine):

> An instance method `mC` declared in or inherited by class `C`, overrides **from** `C` another method `mA` declared in class `A`, iff all of the following are true:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904667945
PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904681338

From liach at openjdk.org  Mon Jan  6 22:11:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Jan 2025 22:11:37 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <Wmer5GpTbV41CADoRUCf-ZAq050v8DmKV08IifWRexU=.a8a045e0-c8c9-4802-85a2-23d07f64453b@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <JAr-BrRmAkrOm3wunaO9RaOuVkxMT-piEygNBXo-o-A=.9127a1af-86ac-4ee5-b5b2-5216af4774df@github.com>
 <Wmer5GpTbV41CADoRUCf-ZAq050v8DmKV08IifWRexU=.a8a045e0-c8c9-4802-85a2-23d07f64453b@github.com>
Message-ID: <LeuMu9KvIQFsmw_vaBHJA0eqy3w5tAuhnDALOqXYb2I=.9006d2f8-846c-4985-b560-3334ca961fab@github.com>

On Mon, 6 Jan 2025 22:01:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/tools/javac/processing/model/util/elements/overrides/TestOverrides.java line 54:
>> 
>>> 52:                 if (!elements.overrides(tm, sm, t))
>>> 53:                     messager.printError(String.format(
>>> 54:                             "%s does not override %s from %s", tm, sm, t.getQualifiedName()));
>> 
>> This message implies `sm` is from `t`, which is not the case. Consider improving the failure message.
>
> This uses the wording from JLS 8.4.8.1 (emphasis mine):
> 
>> An instance method `mC` declared in or inherited by class `C`, overrides **from** `C` another method `mA` declared in class `A`, iff all of the following are true:

Then we should use
`String.format("%s does not override from %s %s", tm, t.getQualifiedName(), sm)`. `sm` is not from `t`, the override is instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904687031

From prappo at openjdk.org  Mon Jan  6 22:11:42 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Jan 2025 22:11:42 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v3]
In-Reply-To: <mOvr18uhJbOPABS1VY30Vp9aY_z6Fom0TODIbewBAH8=.5eee8fc4-d0f6-4bd4-ba11-13e9f5514821@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <mOvr18uhJbOPABS1VY30Vp9aY_z6Fom0TODIbewBAH8=.5eee8fc4-d0f6-4bd4-ba11-13e9f5514821@github.com>
Message-ID: <Cl9BFnuMiUswYzEtxKCHKnWElyySZx6owoEsuxXffgI=.79412dd3-14d9-4044-b278-6a78871720a9@github.com>

On Thu, 21 Nov 2024 13:57:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

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

Keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/22244#issuecomment-2569179286

From prappo at openjdk.org  Mon Jan  6 22:17:37 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Jan 2025 22:17:37 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <LeuMu9KvIQFsmw_vaBHJA0eqy3w5tAuhnDALOqXYb2I=.9006d2f8-846c-4985-b560-3334ca961fab@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <JAr-BrRmAkrOm3wunaO9RaOuVkxMT-piEygNBXo-o-A=.9127a1af-86ac-4ee5-b5b2-5216af4774df@github.com>
 <Wmer5GpTbV41CADoRUCf-ZAq050v8DmKV08IifWRexU=.a8a045e0-c8c9-4802-85a2-23d07f64453b@github.com>
 <LeuMu9KvIQFsmw_vaBHJA0eqy3w5tAuhnDALOqXYb2I=.9006d2f8-846c-4985-b560-3334ca961fab@github.com>
Message-ID: <dzE7W4xP1g2eGWHnFyFX3SjH8D_8qnjg9QaQltgOVno=.3aafdbf9-a32b-431e-8468-5d5b0e038ed2@github.com>

On Mon, 6 Jan 2025 22:08:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This uses the wording from JLS 8.4.8.1 (emphasis mine):
>> 
>>> An instance method `mC` declared in or inherited by class `C`, overrides **from** `C` another method `mA` declared in class `A`, iff all of the following are true:
>
> Then we should use
> `String.format("%s does not override from %s %s", tm, t.getQualifiedName(), sm)`. `sm` is not from `t`, the override is instead.

If you go with that, consider adding the word "method" in between the last two placeholders to clearly separate them:

> ```from %s method %s"```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904691737

From prappo at openjdk.org  Mon Jan  6 22:31:34 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Jan 2025 22:31:34 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <jC9WXPd6xDJeCEZK9uHs4GG1Cr1C8UWoBE_8L0z7CV0=.c202a78c-d19c-4e4f-81ff-be702cffde41@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <JQLCuH5-DxvIRIKFijbHguFlUA3AxSn8aEQaT_9-rgc=.93c77848-bc02-40d1-ad14-9abb7cdfc1ce@github.com>
 <jC9WXPd6xDJeCEZK9uHs4GG1Cr1C8UWoBE_8L0z7CV0=.c202a78c-d19c-4e4f-81ff-be702cffde41@github.com>
Message-ID: <cdqlgZ4aJwnIDkraLT-6oFXQvDc5ALg0pHEGmhBWnTU=.f98b69bd-6c0b-4c1b-9070-32bcf5ad882e@github.com>

On Mon, 6 Jan 2025 11:56:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 785:
>> 
>>> 783:      * specified in JLS {@jls 8.4.8.1} and {@jls 8.4.8.3}. In particular, the additional constraints
>>> 784:      * on thrown types, return types and those constraints on method modifiers not directly
>>> 785:      * bound to the overriding relation as such.
>> 
>> Suggestion:
>> 
>>      * on exception types, return types, and method modifiers do not affect
>>      * the overriding relation.
>> 
>> 
>> The original wording has grammatical mistake and makes no sense.
>
> I don't agree that it makes no sense but I find this wording simpler, so I'll use it instead.

I would strongly recommend to wait for @jddarcy to review that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904701599

From prappo at openjdk.org  Mon Jan  6 23:04:46 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Jan 2025 23:04:46 GMT
Subject: Withdrawn: 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: <hZdtDaCyNvJ0AsgT2hCrHz1ojx1f5xHTWTWCN055PVs=.89657d21-e21b-4898-b68b-72225c9d2454@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.

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.org  Tue Jan  7 06:18:41 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Jan 2025 06:18:41 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
Message-ID: <fACX4a3APXB6Z0ybbDlMtzZSmpbNWJlrBonD6MC0-Zs=.795ca7e9-6008-4cf9-b0f9-371210221f84@github.com>

On Sun, 5 Jan 2025 22:16:45 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
> 
> TIA.

test/langtools/tools/javac/processing/model/util/elements/overrides/S.java line 24:

> 22:  */
> 23: 
> 24: class S {

Following the usual conventions for annotation processing tests, it would be possible (and IMO desirable) for these declarations to be included in the same file as the test scaffolding, assuming S compiles.

If S does *not* compile, that should be documented.

test/langtools/tools/javac/processing/model/util/elements/overrides/TestOverrides.java line 39:

> 37: import static javax.lang.model.element.ElementKind.METHOD;
> 38: 
> 39: /*

This comment would be helpful immediately before S and it would also be helpful for the various conditions being tested to be documented via comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904952383
PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904953475

From darcy at openjdk.org  Tue Jan  7 06:21:35 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Jan 2025 06:21:35 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <cdqlgZ4aJwnIDkraLT-6oFXQvDc5ALg0pHEGmhBWnTU=.f98b69bd-6c0b-4c1b-9070-32bcf5ad882e@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <JQLCuH5-DxvIRIKFijbHguFlUA3AxSn8aEQaT_9-rgc=.93c77848-bc02-40d1-ad14-9abb7cdfc1ce@github.com>
 <jC9WXPd6xDJeCEZK9uHs4GG1Cr1C8UWoBE_8L0z7CV0=.c202a78c-d19c-4e4f-81ff-be702cffde41@github.com>
 <cdqlgZ4aJwnIDkraLT-6oFXQvDc5ALg0pHEGmhBWnTU=.f98b69bd-6c0b-4c1b-9070-32bcf5ad882e@github.com>
Message-ID: <CAgYhHAvLuS4C0U_wxae3jO1gx8_A-IWnL_CpU0pjUs=.85c1fdf4-946a-4bdc-96be-5ffd4392579b@github.com>

On Mon, 6 Jan 2025 22:29:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I don't agree that it makes no sense but I find this wording simpler, so I'll use it instead.
>
> I would strongly recommend to wait for @jddarcy to review that.

The basic situation is that the "overrides" relation a develop has in mind may not be the same as the more restricted "overrides" relation defined in JLS. However, we don't necessarily want to require the extra checks to be omitted _and_ don't necessarily wan to forbid the extra checks from being done.

The current wording doesn't accomplish this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22920#discussion_r1904955990

From acobbs at openjdk.org  Tue Jan  7 22:34:49 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 7 Jan 2025 22:34:49 GMT
Subject: RFR: 8347141: Several javac tests compile with an unnecessary
 -Xlint:-path flag
Message-ID: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>

Please review this patch which removes unnecessary `-Xlint:-path` flags from a few javac regression tests.

These tests invoke the compiler with the `-Xlint:all,-path` flag, but the `path` option is unrelated to, and not needed for, the test.

The tests all succeed just fine without it, i.e., with `-Xlint:all` instead.

The suppression of the `path` lint category appears to be leftover cruft from long ago (at least, according to [this discussion](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028514.html)).

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

Commit messages:
 - Remove unnecessary "-Xlint:-path" flags in test compilations.

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

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

From cstein at openjdk.org  Wed Jan  8 11:42:18 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 8 Jan 2025 11:42:18 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher
Message-ID: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>

Please review this change request enabling native access in source launch mode when using a modular setup.

The change comes in two parts:
1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`

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

Commit messages:
 - Streamline and document internal property: `jdk.internal.java.launchmode`
 - Handle user modules on the module path
 - Fix build by introducing an internal launch mode flag
 - Initial support for enable native access in source launch mode

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

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

From vromero at openjdk.org  Wed Jan  8 14:52:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 8 Jan 2025 14:52:38 GMT
Subject: RFR: 8347141: Several javac tests compile with an unnecessary
 -Xlint:-path flag
In-Reply-To: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
References: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
Message-ID: <3_-dhHYI9hGeYB_ZMvv_JqZaqBx4RjQshLVulgWI8ts=.538768a8-5e2e-45f4-ae52-c0fc9567b062@github.com>

On Tue, 7 Jan 2025 22:29:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `-Xlint:-path` flags from a few javac regression tests.
> 
> These tests invoke the compiler with the `-Xlint:all,-path` flag, but the `path` option is unrelated to, and not needed for, the test.
> 
> The tests all succeed just fine without it, i.e., with `-Xlint:all` instead.
> 
> The suppression of the `path` lint category appears to be leftover cruft from long ago (at least, according to [this discussion](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028514.html)).

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22958#pullrequestreview-2537356195

From acobbs at openjdk.org  Wed Jan  8 16:42:59 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 8 Jan 2025 16:42:59 GMT
Subject: RFR: 8347141: Several javac tests compile with an unnecessary
 -Xlint:-path flag
In-Reply-To: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
References: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
Message-ID: <R0rml36T7MZUc1gifBzHF0quf7RuGLAZYN5CFmjAUbM=.3c8855c5-912e-4d61-8210-eb19a3de7c61@github.com>

On Tue, 7 Jan 2025 22:29:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `-Xlint:-path` flags from a few javac regression tests.
> 
> These tests invoke the compiler with the `-Xlint:all,-path` flag, but the `path` option is unrelated to, and not needed for, the test.
> 
> The tests all succeed just fine without it, i.e., with `-Xlint:all` instead.
> 
> The suppression of the `path` lint category appears to be leftover cruft from long ago (at least, according to [this discussion](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028514.html)).

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22958#issuecomment-2578129706

From acobbs at openjdk.org  Wed Jan  8 17:44:50 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 8 Jan 2025 17:44:50 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v8]
In-Reply-To: <1A--E365t_-y1kXsWKb_wotAzGiVatMGWyqjdaLkTK8=.72f824e4-07ae-4e5f-b8cc-713280df230d@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <NdcN2a6fhP929YpbPClZ5QfaZDJmjTn3ec-eN14aV_Y=.dfc15018-d90d-4bc3-a91f-b2e51398986f@github.com>
 <1A--E365t_-y1kXsWKb_wotAzGiVatMGWyqjdaLkTK8=.72f824e4-07ae-4e5f-b8cc-713280df230d@github.com>
Message-ID: <AJS_zvFCm1VVmYdRZJSsS0fCPRdWJRBrbXNuqrWmxUA=.5cfaa66f-104f-4d77-915b-cd0fc79ca249@github.com>

On Mon, 9 Dec 2024 22:18:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Remove more unnecessary suppressions.
>>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>>  - 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.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/cc628a13...ee2862e5
>
> Core reflection changes look fine; thanks for the cleanup @archiecobbs .

@jddarcy , thanks for your previous review. A few changes have been added since then so would you mind updating your review? Also, can you confirm all necessary reviews have been made? This covers several areas so want to double-check. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2578254734

From darcy at openjdk.org  Wed Jan  8 18:05:49 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 8 Jan 2025 18:05:49 GMT
Subject: RFR: 8347141: Several javac tests compile with an unnecessary
 -Xlint:-path flag
In-Reply-To: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
References: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
Message-ID: <cKZf5uegYa1i-HsIFoChY6tOcJb3uciYnWUgVtSkUcQ=.d51ee5f0-3aee-4277-b062-48cbda5f66b8@github.com>

On Tue, 7 Jan 2025 22:29:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `-Xlint:-path` flags from a few javac regression tests.
> 
> These tests invoke the compiler with the `-Xlint:all,-path` flag, but the `path` option is unrelated to, and not needed for, the test.
> 
> The tests all succeed just fine without it, i.e., with `-Xlint:all` instead.
> 
> The suppression of the `path` lint category appears to be leftover cruft from long ago (at least, according to [this discussion](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028514.html)).

Looks fine; thanks.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22958#pullrequestreview-2537838275

From acobbs at openjdk.org  Wed Jan  8 18:09:01 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 8 Jan 2025 18:09:01 GMT
Subject: RFR: 8347141: Several javac tests compile with an unnecessary
 -Xlint:-path flag
In-Reply-To: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
References: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
Message-ID: <WFNFHc5TuveO9dtAblmHDSrckJTahRtF9-po8IhjTGc=.213328a4-293e-404a-a3e6-470d9423e596@github.com>

On Tue, 7 Jan 2025 22:29:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `-Xlint:-path` flags from a few javac regression tests.
> 
> These tests invoke the compiler with the `-Xlint:all,-path` flag, but the `path` option is unrelated to, and not needed for, the test.
> 
> The tests all succeed just fine without it, i.e., with `-Xlint:all` instead.
> 
> The suppression of the `path` lint category appears to be leftover cruft from long ago (at least, according to [this discussion](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028514.html)).

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22958#issuecomment-2578308710

From archie.cobbs at gmail.com  Wed Jan  8 18:17:09 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 8 Jan 2025 12:17:09 -0600
Subject: How do you "make everything"?
Message-ID: <CANSoFxs1Wdm+bS4-c2CE6unBNY4y6H=CUSW22ZTaKMdSe6bJXQ@mail.gmail.com>

There are build targets in OpenJDK that the Github actions don't build. For
example, "make bootcycle" is not done by Github actions.

This is of particular concern to compiler developers because most build
targets use the compiler, and one wants to make sure compiler changes don't
break any of those build targets; the success of Github actions is not
sufficient.

So what do people do when they want to "make everything"?

FWIW I've been doing this:

make
make hotspot
make static-libs-bundles
make product-bundles
make test-bundles
make bootcycle-images

but that list is just ad hoc and based mostly on past mistakes. Is there a
more complete list that includes every make target that could possibly be
affected by a change to the Java compiler?

Thanks,
-Archie

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

From mcimadamore at openjdk.org  Wed Jan  8 18:37:40 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Jan 2025 18:37:40 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher
In-Reply-To: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
Message-ID: <HbuKa83CrB0ciq1vnghRmOz0Y1NN720rOX_iogym06I=.16113c5e-a056-493b-a6e6-d4b86df90f2c@github.com>

On Mon, 6 Jan 2025 16:35:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change request enabling native access in source launch mode when using a modular setup.
> 
> The change comes in two parts:
> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
> 
> _Testing of tier1..3 is in progress..._

What happens if the user specifies `--enable-native-access=ALL-UNNAMED` ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2578359780

From cstein at openjdk.org  Wed Jan  8 20:29:03 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 8 Jan 2025 20:29:03 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v2]
In-Reply-To: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
Message-ID: <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>

> Please review this change request enabling native access in source launch mode when using a modular setup.
> 
> The change comes in two parts:
> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
> 
> _Testing of tier1..3 is in progress..._

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

  Ignore already handled `ALL-UNNAMED` name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22930/files
  - new: https://git.openjdk.org/jdk/pull/22930/files/670e8647..7c615966

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

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

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

From cstein at openjdk.org  Wed Jan  8 20:29:04 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 8 Jan 2025 20:29:04 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher
In-Reply-To: <HbuKa83CrB0ciq1vnghRmOz0Y1NN720rOX_iogym06I=.16113c5e-a056-493b-a6e6-d4b86df90f2c@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <HbuKa83CrB0ciq1vnghRmOz0Y1NN720rOX_iogym06I=.16113c5e-a056-493b-a6e6-d4b86df90f2c@github.com>
Message-ID: <DsoLOFrA-GBQM-8TtTpFI04fdWzG6EJB_A4CqudpcKQ=.54d9bc21-2612-4ba3-909c-201030b3dd85@github.com>

On Wed, 8 Jan 2025 18:35:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What happens if the user specifies `--enable-native-access=ALL-UNNAMED` ?

Very good catch! I extended the logic and the test case to cover this special "module name" correctly.

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

PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2578587922

From acobbs at openjdk.org  Thu Jan  9 14:48:40 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 9 Jan 2025 14:48:40 GMT
Subject: Integrated: 8347141: Several javac tests compile with an unnecessary
 -Xlint:-path flag
In-Reply-To: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
References: <BX7OgCwOsNRW_r7QdJa_N2SDZxOaX78ee0iihfA_VSU=.4c085d16-1260-4b39-ab25-fba76ffaa0e7@github.com>
Message-ID: <HW-tTMSm9MEjpxxorOEyi5DndUJ6-nmxbQwS2qLG1bY=.7787a6c6-205f-445d-bf85-a938e498c304@github.com>

On Tue, 7 Jan 2025 22:29:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `-Xlint:-path` flags from a few javac regression tests.
> 
> These tests invoke the compiler with the `-Xlint:all,-path` flag, but the `path` option is unrelated to, and not needed for, the test.
> 
> The tests all succeed just fine without it, i.e., with `-Xlint:all` instead.
> 
> The suppression of the `path` lint category appears to be leftover cruft from long ago (at least, according to [this discussion](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028514.html)).

This pull request has now been integrated.

Changeset: cb9a98b3
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb9a98b31a464e683519df46796339c7cecd82ec
Stats:     10 lines in 8 files changed: 0 ins; 0 del; 10 mod

8347141: Several javac tests compile with an unnecessary -Xlint:-path flag

Reviewed-by: vromero, darcy

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

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

From alanb at openjdk.org  Thu Jan  9 20:09:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Jan 2025 20:09:35 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v2]
In-Reply-To: <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
Message-ID: <9sLyfxjDPJJ9Uml93j13lDSYveieHktAba2Fm8Y5CgY=.0a9cd126-c335-4a6f-bedf-c831c41b4bf1@github.com>

On Wed, 8 Jan 2025 20:29:03 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change request enabling native access in source launch mode when using a modular setup.
>> 
>> The change comes in two parts:
>> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
>> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
>> 
>> _Testing of tier1..3 is in progress..._
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore already handled `ALL-UNNAMED` name

Do you expect any other options that the source launcher might need to handle? Right now, there are warnings when the module or package name is not in modules in the boot layer. There other CLI options would be very advanced so assume not.

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

PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2581155710

From cstein at openjdk.org  Thu Jan  9 20:18:45 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 9 Jan 2025 20:18:45 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v2]
In-Reply-To: <9sLyfxjDPJJ9Uml93j13lDSYveieHktAba2Fm8Y5CgY=.0a9cd126-c335-4a6f-bedf-c831c41b4bf1@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
 <9sLyfxjDPJJ9Uml93j13lDSYveieHktAba2Fm8Y5CgY=.0a9cd126-c335-4a6f-bedf-c831c41b4bf1@github.com>
Message-ID: <YdbjpHn47Mn0wXy8BXn0FnjBt6W4cIsYF0hQquDQVqo=.4dd043af-3b5e-4004-82f2-9d5f87fd9875@github.com>

On Thu, 9 Jan 2025 20:06:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you expect any other options that the source launcher might need to handle? Right now, there are warnings when the module or package name is not in modules in the boot layer. There other CLI options would be very advanced so assume not.

I cannot think of any other useful options in addition to the ones handled in [RelevantJavacOptions.java](https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/RelevantJavacOptions.java) for the time being that should also be forwarded to source launcher module layer setup for compilation or run time.

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

PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2581170181

From archie.cobbs at gmail.com  Fri Jan 10 00:36:39 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 9 Jan 2025 18:36:39 -0600
Subject: Question about preview and classfile versions
Message-ID: <CANSoFxujzUE7OEa0=HvPauz2rC-kqGsK_=zweDuUzN3sRgihXQ@mail.gmail.com>

I have a question about preview and classfile minor versions.

In Preview.java there is this:

    /**
     * Report usage of a preview feature. Usages reported through this
method will affect the
     * set of sourcefiles with dependencies on preview features.
     * @param pos the position at which the preview feature was used.
     * @param feature the preview feature used.
     */
    public void warnPreview(DiagnosticPosition pos, Feature feature) {
        Assert.check(isEnabled());
        Assert.check(isPreview(feature));
        if (!lint.isSuppressed(LintCategory.PREVIEW)) {
            *sourcesWithPreviewFeatures.add(log.currentSourceFile());*
            previewHandler.report(pos, feature.isPlural() ?

LintWarnings.PreviewFeatureUsePlural(feature.nameFragment()) :
                    LintWarnings.PreviewFeatureUse(feature.nameFragment()));
        }
    }

The highlighted line causes the written classfile to have minor version
0xffff, which triggers a preview warning at runtime.

That makes sense, but what I don't understand is: Why is that line inside
the IF statement, instead of before it (i.e., always executed)?

It seems (to me) like the behavior of the generated classfile at runtime
should not depend on how you've configured warning suppression at compile
time.

At least, it seems like --enable-preview would be a better candidate for
controlling the classfile minor version in this case... or perhaps some new
flag.

Thanks for any insights.

-Archie

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

From jan.lahoda at oracle.com  Fri Jan 10 07:49:05 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 10 Jan 2025 08:49:05 +0100
Subject: Question about preview and classfile versions
In-Reply-To: <CANSoFxujzUE7OEa0=HvPauz2rC-kqGsK_=zweDuUzN3sRgihXQ@mail.gmail.com>
References: <CANSoFxujzUE7OEa0=HvPauz2rC-kqGsK_=zweDuUzN3sRgihXQ@mail.gmail.com>
Message-ID: <c46064c4-5094-410c-9fa3-c872c6457dec@oracle.com>

Good question.


I believe this method is only used for preview language features, 
there's a different mechanism for preview API, and warnings for preview 
language features cannot be suppressed as per JEP 12. And the "lint" 
here is the "global" Lint instance, that (AFAIK) never suppresses 
anything. I.e. the condition in the "if" statement is always true, I 
believe. We might want to drop the if altogether, leaving only its body.


Note that if a classfile originates in a source file that does not use 
any preview features, it is not marked as preview. That is intentional, 
so this cannot be controlled by a global flag (it used to be controlled 
by '--enable-preview', and was changed to the per-file handling).


Jan


On 10. 01. 25 1:36, Archie Cobbs wrote:
> I have a question about preview and classfile minor versions.
>
> In Preview.java there is this:
>
> ? ? /**
> ? ? ?* Report usage of a preview feature. Usages reported through this 
> method will affect the
> ? ? ?* set of sourcefiles with dependencies on preview features.
> ? ? ?* @param pos the position at which the preview feature was used.
> ? ? ?* @param feature the preview feature used.
> ? ? ?*/
> ? ? public void warnPreview(DiagnosticPosition pos, Feature feature) {
> ? ? ? ? Assert.check(isEnabled());
> ? ? ? ? Assert.check(isPreview(feature));
> ? ? ? ? if (!lint.isSuppressed(LintCategory.PREVIEW)) {
> *sourcesWithPreviewFeatures.add(log.currentSourceFile());*
> ? ? ? ? ? ? previewHandler.report(pos, feature.isPlural() ?
> LintWarnings.PreviewFeatureUsePlural(feature.nameFragment()) :
> LintWarnings.PreviewFeatureUse(feature.nameFragment()));
> ? ? ? ? }
> ? ? }
>
> The highlighted line causes the written classfile to have minor 
> version 0xffff, which triggers a preview warning at runtime.
>
> That makes sense, but what I don't understand is: Why is that line 
> inside the IF statement, instead of before it (i.e., always executed)?
>
> It seems (to me) like the behavior of the generated classfile at 
> runtime should not depend on how you've configured warning suppression 
> at compile time.
>
> At least, it seems like --enable-preview would be a better candidate 
> for controlling the classfile minor version in this case... or perhaps 
> some new flag.
>
> Thanks for any insights.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250110/430cbda1/attachment-0001.htm>

From jlahoda at openjdk.org  Fri Jan 10 08:17:10 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 10 Jan 2025 08:17:10 GMT
Subject: RFR: 8346751: Internal java compiler error with type annotations in
 constants expression in constant fields
Message-ID: <49o4NtQmCtpsixY8pU2tTGz5HatPIR_r3gi2N8VwMzM=.bae7b887-c3be-4028-9b3b-19d4e7da5e9b@github.com>

Consider code like:

import java.lang.annotation.*;
public class Decl {
    String VALUE = (@Nullable String) "";
}
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE_USE })
@interface Nullable {}


When processing this code, when `Attr.visitVarDef` is called for the field, it will first call `Annotate.queueScanTreeAndTypeAnnotate` on the initializer expression, which will find and attribute type annotations. Then the initializer is attributed, and eventually `Annotate.annotateTypeSecondStage` is called on the annotated type (`@Nullable String`). This second stage depends on the type annotations being already attributed. This works OK.

The problem appears when the code like changed to be like:

import java.lang.annotation.*;
@SuppressWarnings(Decl.VALUE)
public class Decl {
    public static final @Nullable String VALUE = (@Nullable String) "";
}
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE_USE })
@interface Nullable {}


In this code, the field is a constant, and it is used from the annotation before `Attr.visitVarDef` is called on the constant. This will trigger attribution of the constant initializer (`Attr.attribLazyConstantValue`), which will trigger the `Annotate.annotateTypeSecondStage` on the annotated type, but `Annotate.queueScanTreeAndTypeAnnotate` was not yet called on the initializer, and so the type annotations are not attributed yet, and javac crashes with an exception like:


java.lang.AssertionError
	at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
	at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
	at jdk.compiler/com.sun.tools.javac.comp.Annotate.fromAnnotations(Annotate.java:167)
	at jdk.compiler/com.sun.tools.javac.comp.Annotate.lambda$annotateTypeSecondStage$0(Annotate.java:1065)
	at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:194)
	at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
	at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1820)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1080)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:949)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
...


The proposed solution herein is to make sure `Annotate.queueScanTreeAndTypeAnnotate` is called before attributing field initializers in `Attr.attribLazyConstantValue`. A flag is used to make sure it is invoked at most once per field.

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

Commit messages:
 - Using a safer marker bit for type annotations already handled for field inits.
 - 8346751: Internal java compiler error with type annotations in constants expression in constant fields

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

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

From shipilev at amazon.de  Fri Jan 10 09:36:12 2025
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 10:36:12 +0100
Subject: How do you "make everything"?
In-Reply-To: <CANSoFxs1Wdm+bS4-c2CE6unBNY4y6H=CUSW22ZTaKMdSe6bJXQ@mail.gmail.com>
References: <CANSoFxs1Wdm+bS4-c2CE6unBNY4y6H=CUSW22ZTaKMdSe6bJXQ@mail.gmail.com>
Message-ID: <e78254d5-2bbb-4a17-a21b-7526e2972e9e@amazon.de>

On 08.01.25 19:17, Archie Cobbs wrote:
> So what do people do when they want to "make everything"?
> 
> FWIW I've been doing this:
> 
> make
> make hotspot
> make static-libs-bundles
> make product-bundles
> make test-bundles
> make bootcycle-images
> 
> but that list is just ad hoc and based mostly on past mistakes. Is there a more complete list that 
> includes every make target that could possibly be affected by a change to the Java compiler?

Well, I personally run `make bootcycle-images` if I want to make sure the newly-built JDK can build 
itself. I think this is what you want to test compilers. It does not build test code, though.

A conventional way to build everything should be `make all`, but I don't think it actually builds a 
lot of targets in current build system. Consider submitting an RFE for infrastructure/build for it.

-Aleksey


From alanb at openjdk.org  Fri Jan 10 11:13:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Jan 2025 11:13:48 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v2]
In-Reply-To: <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
Message-ID: <f85JlLNzEGRiAunR1nFTAj3zZF5R0TEpfDMRJeu1T_o=.d00606eb-53e2-435a-83b1-0c2a1ccda135@github.com>

On Wed, 8 Jan 2025 20:29:03 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change request enabling native access in source launch mode when using a modular setup.
>> 
>> The change comes in two parts:
>> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
>> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
>> 
>> _Testing of tier1..3 is in progress..._
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore already handled `ALL-UNNAMED` name

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 838:

> 836:      * command line option, and also to JDK modules that need the access.
> 837:      * <p>
> 838:      * In case of being in "source" launchmode, warnings about unknown modules are

Typo, this should say "launcher mode" or "launch mode".

src/java.base/share/native/libjli/java.c line 1376:

> 1374:     if (mode == LM_SOURCE) {
> 1375:         // signal module bootstrap to defer warnings about unknown modules
> 1376:         AddOption("-Djdk.internal.java.launchmode=source", NULL);

This is the launcher code so better if the comment said could say that it communicates the launcher mode to runtime (confusing to say "signal module bootstrap" or anything about warnings here).

I note that the existing property is "sun.java.launcher". If you want then you could continue this contention and use "sun.java.launcher.mode".  It'a all JDK-internal and the system property is removed during startup so the naming doesn't really matter of course, I'd like prefer it end in ".mode" rather than "launchmode".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1910223717
PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1910214018

From alanb at openjdk.org  Fri Jan 10 11:13:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 10 Jan 2025 11:13:46 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v2]
In-Reply-To: <YdbjpHn47Mn0wXy8BXn0FnjBt6W4cIsYF0hQquDQVqo=.4dd043af-3b5e-4004-82f2-9d5f87fd9875@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
 <9sLyfxjDPJJ9Uml93j13lDSYveieHktAba2Fm8Y5CgY=.0a9cd126-c335-4a6f-bedf-c831c41b4bf1@github.com>
 <YdbjpHn47Mn0wXy8BXn0FnjBt6W4cIsYF0hQquDQVqo=.4dd043af-3b5e-4004-82f2-9d5f87fd9875@github.com>
Message-ID: <uSeti5X6FdNCaq3FwJQC4kajI1Vm_QoorWg3yLVtKh4=.6acaabb6-d69a-4006-918d-0737e766c2c3@github.com>

On Thu, 9 Jan 2025 20:16:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> I cannot think of any other useful options in addition to the ones handled in [RelevantJavacOptions.java](https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/RelevantJavacOptions.java) for the time being that should also be forwarded to source launcher module layer setup for compilation or run time.

Okay, main reason for asking is whether we need infrastructure rather than a point solution but I think you are right that the others aren't too interesting at this point.

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

PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2582456903

From archie.cobbs at gmail.com  Fri Jan 10 15:13:30 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 10 Jan 2025 09:13:30 -0600
Subject: How do you "make everything"?
In-Reply-To: <e78254d5-2bbb-4a17-a21b-7526e2972e9e@amazon.de>
References: <CANSoFxs1Wdm+bS4-c2CE6unBNY4y6H=CUSW22ZTaKMdSe6bJXQ@mail.gmail.com>
 <e78254d5-2bbb-4a17-a21b-7526e2972e9e@amazon.de>
Message-ID: <CANSoFxv0wpGbfuft=+W-byhAe6Fv8227KQpXyTbZ1Y6BwWfViA@mail.gmail.com>

Thanks for the input.

Also with some playing around I realized that "make print-targets" prints
out every possible make target... of which there are 2453... :)

So to be more precise, I don't really want to "make everything", but rather
make everything that makes use of the java compiler.

I've found there are lots of little tools and intermediate JAR files that
are built and used for various things, for example, jrt-fs.jar,
benchmarks.jar, etc.

I'll stick with my ad hoc list for now, but of course any suggested
additions are welcome.

Thanks,
-Archie


On Fri, Jan 10, 2025 at 3:36?AM Aleksey Shipilev <shipilev at amazon.de> wrote:

> On 08.01.25 19:17, Archie Cobbs wrote:
> > So what do people do when they want to "make everything"?
> >
> > FWIW I've been doing this:
> >
> > make
> > make hotspot
> > make static-libs-bundles
> > make product-bundles
> > make test-bundles
> > make bootcycle-images
> >
> > but that list is just ad hoc and based mostly on past mistakes. Is there
> a more complete list that
> > includes every make target that could possibly be affected by a change
> to the Java compiler?
>
> Well, I personally run `make bootcycle-images` if I want to make sure the
> newly-built JDK can build
> itself. I think this is what you want to test compilers. It does not build
> test code, though.
>
> A conventional way to build everything should be `make all`, but I don't
> think it actually builds a
> lot of targets in current build system. Consider submitting an RFE for
> infrastructure/build for it.
>
> -Aleksey
>
>

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

From archie.cobbs at gmail.com  Fri Jan 10 15:32:52 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 10 Jan 2025 09:32:52 -0600
Subject: Question about preview and classfile versions
In-Reply-To: <c46064c4-5094-410c-9fa3-c872c6457dec@oracle.com>
References: <CANSoFxujzUE7OEa0=HvPauz2rC-kqGsK_=zweDuUzN3sRgihXQ@mail.gmail.com>
 <c46064c4-5094-410c-9fa3-c872c6457dec@oracle.com>
Message-ID: <CANSoFxskdxASczpYpdh5usQfK7pd00CD5Fbu=1tJB2ppSp6w3A@mail.gmail.com>

On Fri, Jan 10, 2025 at 1:49?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> I And the "lint" here is the "global" Lint instance, that (AFAIK) never
> suppresses anything. I.e. the condition in the "if" statement is always
> true, I believe.
>
The root Lint instance doesn't include any @SuppressWarnings suppressions
but it does include suppressions from command line flags like
-Xlint:-preview, so the "if" statement can be false.

Upon further analysis it appears that this doesn't matter - except in the
case of PREVIEW_REFLECTIVE - because otherwise the code that emits the
warning also explicitly invokes preview.markUsesPreview(pos). See here:
Check.java
<https://github.com/openjdk/jdk/blob/beb0e607d3b66b9e97c263cd8f2e23f447ebfc50/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java#L3827-L3838>
.

So I'm still unsure whether there is a bug. I thought the test below would
trigger that PREVIEW_REFLECTIVE code branch and generate a classfile that
erroneously does NOT have the 0xffff minor version, but it doesn't:

$ cat PreviewTest.java
import java.io.IO;
public class PreviewTest {
    public static void main(String[] args) {
        IO.println("OK");       // preview API
    }
}
$ javac -version
javac 25-internal
$ javac -d classes --enable-preview --release 25 -Xlint:-preview
PreviewTest.java
Note: PreviewTest.java uses preview features of Java SE 25.
Note: Recompile with -Xlint:preview for details.
$ file classes/PreviewTest.class
classes/PreviewTest.class: compiled Java class data, version 69.65535

-Archie

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

From magnus.ihse.bursie at oracle.com  Fri Jan 10 16:39:27 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 10 Jan 2025 17:39:27 +0100
Subject: How do you "make everything"?
In-Reply-To: <CANSoFxv0wpGbfuft=+W-byhAe6Fv8227KQpXyTbZ1Y6BwWfViA@mail.gmail.com>
References: <CANSoFxs1Wdm+bS4-c2CE6unBNY4y6H=CUSW22ZTaKMdSe6bJXQ@mail.gmail.com>
 <e78254d5-2bbb-4a17-a21b-7526e2972e9e@amazon.de>
 <CANSoFxv0wpGbfuft=+W-byhAe6Fv8227KQpXyTbZ1Y6BwWfViA@mail.gmail.com>
Message-ID: <ca4563c1-fb87-48e2-aca7-5fd4991af9b8@oracle.com>

On 2025-01-10 16:13, Archie Cobbs wrote:

> Thanks for the input.
>
> Also with some playing around I realized that "make print-targets" 
> prints out every possible make target... of which there are 2453... :)

If you were to make all these targets, there would be a lot of 
redundancy, since e.g. the target `java` depends on the target 
`java.base-java`, etc.

The conceptually "highest" level targets are the `*-bundles` targets. 
You can create all of them using `make all-bundles`. That would generate 
all output stages that are consumed by any downstream process, at least 
as we use it in Oracle. To save build time, for testing, you will most 
likely be satisfied with the `*-image` targets. Run `make all-images` to 
generate all known images. I guess that is the best answer to your 
question about "making everything".

Apart from these "leaf" targets, there are some other "leaves" as well. 
(Leaves as in that no other make target depends on them, so if the user 
does not specify them on the command line, they will not be executed.) 
These are for specialized stuff, like generating IDE configuration, 
running tests, or as you mentioned, the bootcycle-images target. (This 
is really just a somewhat weird and special case of testing, there the 
"test" in point is if the new JDK can pass the build system.)

I guess it would have been an interesting addition to the build system 
to have it print all "leaf" targets; unfortunately I cannot really think 
of an easy way of doing this in make.

/Magnus



>
> So to be more precise, I don't really want to "make everything", but 
> rather make everything that makes use of the java compiler.
>
> I've found there are lots of little tools and intermediate JAR files 
> that are built and used for various things, for example, jrt-fs.jar, 
> benchmarks.jar, etc.
>
> I'll stick with my ad hoc list for now, but of course any suggested 
> additions are welcome.
>
> Thanks,
> -Archie
>
>
> On Fri, Jan 10, 2025 at 3:36?AM Aleksey Shipilev <shipilev at amazon.de> 
> wrote:
>
>     On 08.01.25 19:17, Archie Cobbs wrote:
>     > So what do people do when they want to "make everything"?
>     >
>     > FWIW I've been doing this:
>     >
>     > make
>     > make hotspot
>     > make static-libs-bundles
>     > make product-bundles
>     > make test-bundles
>     > make bootcycle-images
>     >
>     > but that list is just ad hoc and based mostly on past mistakes.
>     Is there a more complete list that
>     > includes every make target that could possibly be affected by a
>     change to the Java compiler?
>
>     Well, I personally run `make bootcycle-images` if I want to make
>     sure the newly-built JDK can build
>     itself. I think this is what you want to test compilers. It does
>     not build test code, though.
>
>     A conventional way to build everything should be `make all`, but I
>     don't think it actually builds a
>     lot of targets in current build system. Consider submitting an RFE
>     for infrastructure/build for it.
>
>     -Aleksey
>
>
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250110/dc555746/attachment-0001.htm>

From archie.cobbs at gmail.com  Fri Jan 10 17:58:19 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 10 Jan 2025 11:58:19 -0600
Subject: Question about preview and classfile versions
In-Reply-To: <CANSoFxskdxASczpYpdh5usQfK7pd00CD5Fbu=1tJB2ppSp6w3A@mail.gmail.com>
References: <CANSoFxujzUE7OEa0=HvPauz2rC-kqGsK_=zweDuUzN3sRgihXQ@mail.gmail.com>
 <c46064c4-5094-410c-9fa3-c872c6457dec@oracle.com>
 <CANSoFxskdxASczpYpdh5usQfK7pd00CD5Fbu=1tJB2ppSp6w3A@mail.gmail.com>
Message-ID: <CANSoFxudwDWtPhGTPStg6vugvaXzibYaqEE0zJQBPTy7_qAt6w@mail.gmail.com>

On Fri, Jan 10, 2025 at 9:32?AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Fri, Jan 10, 2025 at 1:49?AM Jan Lahoda <jan.lahoda at oracle.com> wrote:
>
>> I And the "lint" here is the "global" Lint instance, that (AFAIK) never
>> suppresses anything. I.e. the condition in the "if" statement is always
>> true, I believe.
>>
> The root Lint instance doesn't include any @SuppressWarnings suppressions
> but it does include suppressions from command line flags like
> -Xlint:-preview, so the "if" statement can be false.
>

Oops - I am wrong about that. You are right - Lint.suppressedValues does
not get initialized from Xlint:-foo flags, only from @SuppressWarnings
annotations.

And that also explains my bogus test for classfile minor versions.

Thanks!

-Archie

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

From liach at openjdk.org  Fri Jan 10 21:49:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 Jan 2025 21:49:40 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v7]
In-Reply-To: <K5ueVC6saRk7aG5uInBJ-bzvUd7XCGUFm3cgDtk-m9I=.bd2cd59b-e3ac-4853-96a0-5a21d2b7a157@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <R6SVN7t6Z0aACoWYoC9CpvJegysiCcuUQsgb5BJWMWU=.f878b315-1c43-48b2-bd4a-f14f6aa8dae6@github.com>
 <K5ueVC6saRk7aG5uInBJ-bzvUd7XCGUFm3cgDtk-m9I=.bd2cd59b-e3ac-4853-96a0-5a21d2b7a157@github.com>
Message-ID: <eNZedvtqDZGWnb63YXO2VhD04Xn1knzspwHjvkOhlb0=.10a0446c-e5b2-47c7-9f88-3e953f883064@github.com>

On Sun, 29 Dec 2024 01:06:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Problems with owner type, kevin suggestions
>
> src/java.base/share/classes/java/lang/reflect/ParameterizedType.java line 124:
> 
>> 122:      * class or interface declaration} and have equal {@linkplain
>> 123:      * #getActualTypeArguments() type parameters}, including those from the
>> 124:      * {@linkplain #getOwnerType() enclosing classes}.
> 
> ... if they are non-static nested types. (etc.)

Not necessary on second thought.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19977#discussion_r1911476971

From liach at openjdk.org  Fri Jan 10 21:53:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 10 Jan 2025 21:53:20 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v8]
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: <qy51peD9h2DREHKx_d4zS_yVCtDEBgyQLocJaiex1qg=.f2526cf0-b0f6-41f4-a5de-0edcc86a8087@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.
> 
> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/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 17 additional commits since the last revision:

 - Year and typos
 - Merge branch 'm5' into doc/owner-type
 - Problems with owner type, kevin suggestions
 - Slightly improve snippet
 - 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
 - Improve getRawType
 - Intro and other various improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Cleanup
 - ... and 7 more: https://git.openjdk.org/jdk/compare/6e722b7a...4f4d9b91

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/1306153e..4f4d9b91

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

  Stats: 64042 lines in 3874 files changed: 36532 ins; 17864 del; 9646 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 acobbs at openjdk.org  Sun Jan 12 22:55:08 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 12 Jan 2025 22:55:08 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
Message-ID: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>

This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.

Please see the follow-up comment for a more complete description (trying to keep the first comment short).

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

Commit messages:
 - Fix comment.
 - Refactor Options and Lint to allow use early during startup.

Changes: https://git.openjdk.org/jdk/pull/23056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347474
  Stats: 323 lines in 14 files changed: 163 ins; 66 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/23056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23056/head:pull/23056

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

From acobbs at openjdk.org  Sun Jan 12 22:55:08 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 12 Jan 2025 22:55:08 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
In-Reply-To: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
Message-ID: <cgvRDI7DCqcTyoPcAgTx1Ty-97qHPCtJ-JcX5NR1zy0=.c756db2a-c2dd-4406-90e1-5bcb7eec45cd@github.com>

On Sun, 12 Jan 2025 22:50:14 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
> 
> Please see the follow-up comment for a more complete description (trying to keep the first comment short).

**Issue A**: In several places in the compiler, the `Options` singleton is queried before it's been populated. Most of the time this is checking for undocumented flags like `-XDonlySyntaxErrorsUnrecoverable`, so unless you are actually using these flags, this does not cause a problem. But on the flip side, if you ever do use these flags, they could be ignored.

**Issue B**: Several classes would like to use the root `Lint` instance but can't due to initialization ordering issues. An example is `BaseFileManager`, which uses `Options.isLintSet()` instead. But that method not only duplicates `Lint.isEnabled()` but also is buggy - it doesn't correctly mirror `Lint`'s  behavior for certain categories like `"preview"`, `"dep-ann"`, etc.

In the bigger picture, the compiler has a bunch of singletons like `Log`, `Options`, `Lint`, `Names`, etc. that are somewhat inter-dependent and being wired up and initialized at the same time, which creates a classic startup ordering puzzle. With no explicitly enforced ordering, it's easy for problems to occur. To complicate things further, the ordering can change depending on which API is used to invoke the compiler; some test cases even test individual singletons, forcing them to be "first".

The `Options` singleton is something of a poster child because so many other singletons query it as part of their own initialization. For example, `Log` depends on flags like `-Xmaxerrs`, which come from `Options`, but the processing of options requires a `Log` for any required output, etc.

To address the situation, this PR proposes the following:

* Define two states for `Options`:
  * _Uninitialized_ means the instance is empty (unpopulated)
  * _Initialized_ means it is (or has started being) populated
* Provide two options for querying `Options`:
  * `Options.get()`:
    * If initialized, behave the same as today
    * If uninitialized, return null/false (same as today) but also later, if/when initialized, `Assert.check()` that the correct answer was given?. This provides backward-compatible behavior while also auto-detecting **Issue A** bugs when they occur.
  * `Options.whenReady(Runnable)`:
    * If initialized, invokes the `Runnable` immediately
    * If uninitialized, registers a listener to invoke the `Runnable` if/when initialized
    * `Options` already has a simple listener notification mechanism, so we piggy-back on that
* "Robustify" a few low-level singletons such as `Log`, `JCDiagnostic`, `Lint`, etc., allowing them to function properly both before and after `Options` is populated
* Update several singletons (such as `BaseFileManager`) to use `Lint` directly, replacing previous homebrew logic

? Two alternatives would be: (a) just log a warning, or (b) only assert if some flag `-XDverifyOptions` was given. But an ignored flag is by definition a bug, so an assertion seems appropriate here.

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

PR Comment: https://git.openjdk.org/jdk/pull/23056#issuecomment-2585950556

From acobbs at openjdk.org  Sun Jan 12 23:59:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 12 Jan 2025 23:59:58 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v2]
In-Reply-To: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
Message-ID: <bFct9C7UhcAcyX3xRiQK8EkH_qn1pjv9df57E8fw3m4=.d5d92449-a1dc-4360-b35a-b0b99a64d890@github.com>

> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
> 
> Please see the follow-up comment for a more complete description (trying to keep the first comment short).

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

  Add regression test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23056/files
  - new: https://git.openjdk.org/jdk/pull/23056/files/d19e9e37..c1639b80

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

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

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

From mcimadamore at openjdk.org  Mon Jan 13 11:16:43 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Jan 2025 11:16:43 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v2]
In-Reply-To: <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
Message-ID: <xYnmGU6dlKErBsjuZDm41YOME5rpp4njuZ2zLrEuySc=.0db4d083-8ef6-4b77-ae70-89e5550c6b16@github.com>

On Wed, 8 Jan 2025 20:29:03 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change request enabling native access in source launch mode when using a modular setup.
>> 
>> The change comes in two parts:
>> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
>> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
>> 
>> _Testing of tier1..3 is in progress..._
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore already handled `ALL-UNNAMED` name

The handling of the new option seems correct:
* `ALL-UNNAMED` is already handled by module bootstrap, so left alone
* source modules are correctly handled
* `illegal-native-access` is a runtime option, so again, not handled (which is ok)

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

PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2586824078

From cstein at openjdk.org  Mon Jan 13 11:29:06 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 13 Jan 2025 11:29:06 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v3]
In-Reply-To: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
Message-ID: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com>

> Please review this change request enabling native access in source launch mode when using a modular setup.
> 
> The change comes in two parts:
> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
> 
> _Testing of tier1..3 is in progress..._

Christian Stein has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
 - Update src/java.base/share/native/libjli/java.c
   
   [skip ci]
 - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
   
   [skip ci]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22930/files
  - new: https://git.openjdk.org/jdk/pull/22930/files/7c615966..6ff0cd30

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

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

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

From cstein at openjdk.org  Mon Jan 13 11:29:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 13 Jan 2025 11:29:07 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v2]
In-Reply-To: <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <nh6P2E4akpTVNb13wwF2SMT_fnT887NH0nuWU876O8k=.a25c70c6-753a-42e4-a7b4-9f729552c488@github.com>
Message-ID: <mahMRzpC3nAYpLQB_or8wdv2x1RX48JEy28lXe4YJVE=.7a04b153-c182-4350-afe6-a917f16b0644@github.com>

On Wed, 8 Jan 2025 20:29:03 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change request enabling native access in source launch mode when using a modular setup.
>> 
>> The change comes in two parts:
>> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
>> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
>> 
>> _Testing of tier1..3 is in progress..._
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore already handled `ALL-UNNAMED` name

Submit improvements as suggested.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 838:

> 836:      * command line option, and also to JDK modules that need the access.
> 837:      * <p>
> 838:      * In case of being in "source" launchmode, warnings about unknown modules are

Suggestion:

     * In case of being in "source" launcher mode, warnings about unknown modules are

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 844:

> 842:     private static void addEnableNativeAccess(ModuleLayer layer) {
> 843:         String launchMode = getAndRemoveProperty("jdk.internal.java.launchmode");
> 844:         boolean shouldWarn = !"source".equals(launchMode);

Suggestion:

        String launcherMode = getAndRemoveProperty("sun.java.launcher.mode");
        boolean shouldWarn = !"source".equals(launcherMode);

src/java.base/share/native/libjli/java.c line 1376:

> 1374:     if (mode == LM_SOURCE) {
> 1375:         // signal module bootstrap to defer warnings about unknown modules
> 1376:         AddOption("-Djdk.internal.java.launchmode=source", NULL);

Suggestion:

        // communicate the launcher mode to runtime
        AddOption("-Dsun.java.launcher.mode=source", NULL);

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

PR Review: https://git.openjdk.org/jdk/pull/22930#pullrequestreview-2546345699
PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1913035292
PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1913038153
PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1913037463

From maurizio.cimadamore at oracle.com  Mon Jan 13 12:56:29 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 13 Jan 2025 12:56:29 +0000
Subject: Question about preview and classfile versions
In-Reply-To: <CANSoFxudwDWtPhGTPStg6vugvaXzibYaqEE0zJQBPTy7_qAt6w@mail.gmail.com>
References: <CANSoFxujzUE7OEa0=HvPauz2rC-kqGsK_=zweDuUzN3sRgihXQ@mail.gmail.com>
 <c46064c4-5094-410c-9fa3-c872c6457dec@oracle.com>
 <CANSoFxskdxASczpYpdh5usQfK7pd00CD5Fbu=1tJB2ppSp6w3A@mail.gmail.com>
 <CANSoFxudwDWtPhGTPStg6vugvaXzibYaqEE0zJQBPTy7_qAt6w@mail.gmail.com>
Message-ID: <ecef17dd-8749-471e-8390-6cf5b66f4c69@oracle.com>

It seems to be that:

* Lint::isEnabled correctly reflects the command line flags
* Lint::isSuppressed does not

As such, isEnabled is correctly used in the constructor of Preview, to 
set the value of MandatoryWarningHandler::verbose.

But the isSuppressed check in Preview::warnPreview seems redundant, 
because no suppression will ever be found this way.

IMHO, Preview should not hold on to Lint after it uses it to initialize 
the MandatoryWarningHandler. The suppressions checks, where possible, 
should be left to clients (as code in Check etc. will be in a better 
position to know which Lint to actually use).

Alternalively, warnPreview could take a Lint as well, but then we'd have 
to think about how to model cases where no meaningful Lint exists 
(Scanner and Parser).

Maurizio

On 10/01/2025 17:58, Archie Cobbs wrote:
> On Fri, Jan 10, 2025 at 9:32?AM Archie Cobbs <archie.cobbs at gmail.com> 
> wrote:
>
>     On Fri, Jan 10, 2025 at 1:49?AM Jan Lahoda <jan.lahoda at oracle.com>
>     wrote:
>
>         I And the "lint" here is the "global" Lint instance, that
>         (AFAIK) never suppresses anything. I.e. the condition in the
>         "if" statement is always true, I believe.
>
>     The root Lint instance doesn't include any @SuppressWarnings
>     suppressions but it does include suppressions from command line
>     flags like -Xlint:-preview, so the "if" statement can be false.
>
>
> Oops - I am wrong about that. You are right - Lint.suppressedValues 
> does not get initialized from Xlint:-foo flags, only from 
> @SuppressWarnings annotations.
>
> And that also explains my bogus test for classfile minor versions.
>
> Thanks!
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250113/b5cbd0b9/attachment.htm>

From hgreule at openjdk.org  Mon Jan 13 13:37:55 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 13 Jan 2025 13:37:55 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause
Message-ID: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>

This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.

Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.

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

Commit messages:
 - fix

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

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

From vromero at openjdk.org  Mon Jan 13 14:30:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 13 Jan 2025 14:30:45 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause
In-Reply-To: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
Message-ID: <wWAx-M-s_B0j3CiThSXf_UPIOMGCvrrYKOy2wQi9SYQ=.4fb96d78-c80f-45fd-aeb6-0d8f23297e1d@github.com>

On Mon, 13 Jan 2025 13:33:13 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
> 
> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.

test/langtools/tools/javac/sealed/erroneous_permits/MultipleErroneousPermittedTypes.java line 2:

> 1: /*
> 2:  * @test /nodynamiccopyright/

it would be preferable for this test to be moved to a subtest in `test/langtools/tools/javac/sealed/SealedCompilationTests.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23069#discussion_r1913272166

From archie.cobbs at gmail.com  Mon Jan 13 14:34:13 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 13 Jan 2025 08:34:13 -0600
Subject: Question about preview and classfile versions
In-Reply-To: <ecef17dd-8749-471e-8390-6cf5b66f4c69@oracle.com>
References: <CANSoFxujzUE7OEa0=HvPauz2rC-kqGsK_=zweDuUzN3sRgihXQ@mail.gmail.com>
 <c46064c4-5094-410c-9fa3-c872c6457dec@oracle.com>
 <CANSoFxskdxASczpYpdh5usQfK7pd00CD5Fbu=1tJB2ppSp6w3A@mail.gmail.com>
 <CANSoFxudwDWtPhGTPStg6vugvaXzibYaqEE0zJQBPTy7_qAt6w@mail.gmail.com>
 <ecef17dd-8749-471e-8390-6cf5b66f4c69@oracle.com>
Message-ID: <CANSoFxs841nNPpjZCp1MEO+NjqW5H=s08qKxOkzJapnkfAE2bg@mail.gmail.com>

Hi Maurizio,

On Mon, Jan 13, 2025 at 6:56?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> It seems to be that:
>
> * Lint::isEnabled correctly reflects the command line flags
> * Lint::isSuppressed does not
>
> As such, isEnabled is correctly used in the constructor of Preview, to set
> the value of MandatoryWarningHandler::verbose.
>
> But the isSuppressed check in Preview::warnPreview seems redundant,
> because no suppression will ever be found this way.
>
> IMHO, Preview should not hold on to Lint after it uses it to initialize
> the MandatoryWarningHandler. The suppressions checks, where possible,
> should be left to clients (as code in Check etc. will be in a better
> position to know which Lint to actually use).
>
> Alternalively, warnPreview could take a Lint as well, but then we'd have
> to think about how to model cases where no meaningful Lint exists (Scanner
> and Parser).
>

Thanks for confirming all of the above.

I'm working on some cleanups in this area (pr #23056) and will include your
suggested simplification to Preview.java.

-Archie

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

From acobbs at openjdk.org  Mon Jan 13 14:37:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 13 Jan 2025 14:37:36 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v3]
In-Reply-To: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
Message-ID: <WYYsrGS2SnYPau5fH_tfrRACvl_d7i4sB08njOsdYbs=.f1575fdd-59b1-4908-88d1-b0c75d14f8f0@github.com>

> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
> 
> Please see the follow-up comment for a more complete description (trying to keep the first comment short).

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

  Eliminate useless isSuppressed() test and eliminate "lint" reference in Preview.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23056/files
  - new: https://git.openjdk.org/jdk/pull/23056/files/c1639b80..a4c4e9f7

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

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

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

From vromero at openjdk.org  Mon Jan 13 15:56:46 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 13 Jan 2025 15:56:46 GMT
Subject: RFR: 8346751: Internal java compiler error with type annotations
 in constants expression in constant fields
In-Reply-To: <49o4NtQmCtpsixY8pU2tTGz5HatPIR_r3gi2N8VwMzM=.bae7b887-c3be-4028-9b3b-19d4e7da5e9b@github.com>
References: <49o4NtQmCtpsixY8pU2tTGz5HatPIR_r3gi2N8VwMzM=.bae7b887-c3be-4028-9b3b-19d4e7da5e9b@github.com>
Message-ID: <GKK5PWJlfQM27cJ8XbeCwIcTNP8QtFWTc9xQ3H53WaY=.10c31a9a-23c0-456a-bd41-97299fb503cd@github.com>

On Fri, 10 Jan 2025 08:11:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> import java.lang.annotation.*;
> public class Decl {
>     String VALUE = (@Nullable String) "";
> }
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ ElementType.TYPE_USE })
> @interface Nullable {}
> 
> 
> When processing this code, when `Attr.visitVarDef` is called for the field, it will first call `Annotate.queueScanTreeAndTypeAnnotate` on the initializer expression, which will find and attribute type annotations. Then the initializer is attributed, and eventually `Annotate.annotateTypeSecondStage` is called on the annotated type (`@Nullable String`). This second stage depends on the type annotations being already attributed. This works OK.
> 
> The problem appears when the code like changed to be like:
> 
> import java.lang.annotation.*;
> @SuppressWarnings(Decl.VALUE)
> public class Decl {
>     public static final @Nullable String VALUE = (@Nullable String) "";
> }
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ ElementType.TYPE_USE })
> @interface Nullable {}
> 
> 
> In this code, the field is a constant, and it is used from the annotation before `Attr.visitVarDef` is called on the constant. This will trigger attribution of the constant initializer (`Attr.attribLazyConstantValue`), which will trigger the `Annotate.annotateTypeSecondStage` on the annotated type, but `Annotate.queueScanTreeAndTypeAnnotate` was not yet called on the initializer, and so the type annotations are not attributed yet, and javac crashes with an exception like:
> 
> 
> java.lang.AssertionError
> 	at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
> 	at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.fromAnnotations(Annotate.java:167)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.lambda$annotateTypeSecondStage$0(Annotate.java:1065)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:194)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
> 	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1820)
> 	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1080)
> 	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:949)
> 	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
> 	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImp...

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23029#pullrequestreview-2547081611

From pyltsinm at gmail.com  Mon Jan 13 17:03:53 2025
From: pyltsinm at gmail.com (Mikhail Pyltsin)
Date: Mon, 13 Jan 2025 18:03:53 +0100
Subject: Using 'transitive' modifier for 'java.base' in user's module-info.java
Message-ID: <CAOo1M==EiH1meSmJATtcVZ6tHF1uUg6CStUPFqtVn27zPVL20g@mail.gmail.com>

Hi!
I am investigating a new version of  jep494
(
https://cr.openjdk.org/~gbierman/jep494/jep494-20241024/specs/module-import-declarations-jls.html#jls-7.7.1
)
This chapter allows to use `transitive` in user's module-info.java, but
after compilation (with --enable-preview) and trying to use this file I've
got the error:
`The requires entry for java.base has ACC_TRANSITIVE set`.

it looks like the problem is here
https://github.com/openjdk/jdk/blob/a7915bb2e1b822b6d9cbeb220765e8c821c71d0b/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java#L420
It requires that classfile must be preview, but it's minor version is not
equal to 65535 (flag  --enable-preview  was used), because it doesn't use
anything from preview.

Could you help me, is this behaviour expected? and how could users
use 'transitive'  with 'java.base' in their 'module-info.java'?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250113/d2c2411c/attachment.htm>

From alanb at openjdk.org  Mon Jan 13 18:26:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Jan 2025 18:26:38 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v3]
In-Reply-To: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com>
Message-ID: <09_Yl-pKAww_X3X4nf_pBjI4wK-PMomd54MfmmBwSXo=.41407acd-47b9-4ef7-9a21-8f4da8c26a56@github.com>

On Mon, 13 Jan 2025 11:29:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change request enabling native access in source launch mode when using a modular setup.
>> 
>> The change comes in two parts:
>> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
>> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
>> 
>> _Testing of tier1..3 is in progress..._
>
> Christian Stein has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
>  - Update src/java.base/share/native/libjli/java.c
>    
>    [skip ci]
>  - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
>    
>    [skip ci]

Good, I don't have any other comments on this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22930#pullrequestreview-2547469239

From hgreule at openjdk.org  Mon Jan 13 18:56:20 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 13 Jan 2025 18:56:20 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v2]
In-Reply-To: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
Message-ID: <J_3b4Zq3wmswBXSdVVL5VV5JXn_zX9aOJ4x03WxxpCg=.36d7e1dc-42b7-4254-ba76-372758e6c2c5@github.com>

> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
> 
> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.

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

  move test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23069/files
  - new: https://git.openjdk.org/jdk/pull/23069/files/7d51b793..f8b7c2fb

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

  Stats: 20 lines in 3 files changed: 9 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23069.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23069/head:pull/23069

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

From hgreule at openjdk.org  Mon Jan 13 18:56:20 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 13 Jan 2025 18:56:20 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v2]
In-Reply-To: <wWAx-M-s_B0j3CiThSXf_UPIOMGCvrrYKOy2wQi9SYQ=.4fb96d78-c80f-45fd-aeb6-0d8f23297e1d@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
 <wWAx-M-s_B0j3CiThSXf_UPIOMGCvrrYKOy2wQi9SYQ=.4fb96d78-c80f-45fd-aeb6-0d8f23297e1d@github.com>
Message-ID: <Z9ArFFLuUc5g_epqvWFhuKAxRJQ0cocDL-6SkKizA8U=.6cb2a069-e110-425c-b11a-bedbcb238ae9@github.com>

On Mon, 13 Jan 2025 14:23:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move test case
>
> test/langtools/tools/javac/sealed/erroneous_permits/MultipleErroneousPermittedTypes.java line 2:
> 
>> 1: /*
>> 2:  * @test /nodynamiccopyright/
> 
> it would be preferable for this test to be moved to a subtest in `test/langtools/tools/javac/sealed/SealedCompilationTests.java`

Moved it into `testTypeVarInPermits`. Please let me know if it is fine like that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23069#discussion_r1913666093

From vromero at openjdk.org  Mon Jan 13 20:24:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 13 Jan 2025 20:24:38 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v2]
In-Reply-To: <J_3b4Zq3wmswBXSdVVL5VV5JXn_zX9aOJ4x03WxxpCg=.36d7e1dc-42b7-4254-ba76-372758e6c2c5@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
 <J_3b4Zq3wmswBXSdVVL5VV5JXn_zX9aOJ4x03WxxpCg=.36d7e1dc-42b7-4254-ba76-372758e6c2c5@github.com>
Message-ID: <dG3-ZsIBppp1lJpNQaaZwD7nsyVtvej7TdU6iJ9QK0Y=.e1f3a2dd-6099-4af3-8713-09701f2fd6a6@github.com>

On Mon, 13 Jan 2025 18:56:20 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
>> 
>> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move test case

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23069#pullrequestreview-2547790582

From vromero at openjdk.org  Mon Jan 13 20:24:41 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 13 Jan 2025 20:24:41 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v2]
In-Reply-To: <Z9ArFFLuUc5g_epqvWFhuKAxRJQ0cocDL-6SkKizA8U=.6cb2a069-e110-425c-b11a-bedbcb238ae9@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
 <wWAx-M-s_B0j3CiThSXf_UPIOMGCvrrYKOy2wQi9SYQ=.4fb96d78-c80f-45fd-aeb6-0d8f23297e1d@github.com>
 <Z9ArFFLuUc5g_epqvWFhuKAxRJQ0cocDL-6SkKizA8U=.6cb2a069-e110-425c-b11a-bedbcb238ae9@github.com>
Message-ID: <rNMVnQJ3D6doSGQnlKPPTl9SjTfreYx7ELZ-ypPiWcM=.41b30c71-0b6c-4c2d-8fdd-d7085d0823ee@github.com>

On Mon, 13 Jan 2025 18:53:19 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> test/langtools/tools/javac/sealed/erroneous_permits/MultipleErroneousPermittedTypes.java line 2:
>> 
>>> 1: /*
>>> 2:  * @test /nodynamiccopyright/
>> 
>> it would be preferable for this test to be moved to a subtest in `test/langtools/tools/javac/sealed/SealedCompilationTests.java`
>
> Moved it into `testTypeVarInPermits`. Please let me know if it is fine like that.

looks good, just please remember to update the copyright year to 2025 before pushing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23069#discussion_r1913762489

From acobbs at openjdk.org  Tue Jan 14 00:45:00 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 14 Jan 2025 00:45:00 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v4]
In-Reply-To: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
Message-ID: <NxcQNi9l-DGmTptx31UZGuFnEBWOikL1pypMgQ5fXs0=.59632201-190f-4c5c-ad86-567482f0157f@github.com>

> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
> 
> Please see the follow-up comment for a more complete description (trying to keep the first comment short).

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:

 - Minor tweaks.
 - Merge branch 'master' into JDK-8347474
 - Eliminate useless isSuppressed() test and eliminate "lint" reference in Preview.
 - Add regression test.
 - Fix comment.
 - Refactor Options and Lint to allow use early during startup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23056/files
  - new: https://git.openjdk.org/jdk/pull/23056/files/a4c4e9f7..5661449b

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

  Stats: 3272 lines in 108 files changed: 1254 ins; 1557 del; 461 mod
  Patch: https://git.openjdk.org/jdk/pull/23056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23056/head:pull/23056

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

From hgreule at openjdk.org  Tue Jan 14 07:09:26 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 14 Jan 2025 07:09:26 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v3]
In-Reply-To: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
Message-ID: <JbF3DJ3EbxLIV_zdrF5I3k7Ti86xuB6I2ZeZAZ-0b84=.e328bc8e-6dd3-45f8-8d0d-11a3bd61d1ce@github.com>

> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
> 
> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.

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

  update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23069/files
  - new: https://git.openjdk.org/jdk/pull/23069/files/f8b7c2fb..41bbac88

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

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

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

From jlahoda at openjdk.org  Tue Jan 14 09:33:21 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 14 Jan 2025 09:33:21 GMT
Subject: RFR: 8347646: module-info classfile missing the preview flag
Message-ID: <Xjs0IciYuzdhZpjEfAr16RbWPA6iFVQ7UCJ4f92v8fw=.d68fc1f5-6872-4db9-9f88-a3f6834f43e8@github.com>

Consider module-info.java like this:

module m {
    requires transitive java.base;
}


When compiled with `--enable-preview --source 24/25`, the resulting classfile is missing the preview flag.

This PR proposes to use `Preview.checkSourceLevel` to check the source level, which marks the source to use the preview feature.

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

Commit messages:
 - 8347646: module-info classfile missing the preview flag

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

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

From asotona at openjdk.org  Tue Jan 14 10:22:46 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 Jan 2025 10:22:46 GMT
Subject: RFR: 8347646: module-info classfile missing the preview flag
In-Reply-To: <Xjs0IciYuzdhZpjEfAr16RbWPA6iFVQ7UCJ4f92v8fw=.d68fc1f5-6872-4db9-9f88-a3f6834f43e8@github.com>
References: <Xjs0IciYuzdhZpjEfAr16RbWPA6iFVQ7UCJ4f92v8fw=.d68fc1f5-6872-4db9-9f88-a3f6834f43e8@github.com>
Message-ID: <0-fwdwJJXOb6C85SFvmIfJpEz_prF3LgBJJfYQmeAB4=.9450376e-063e-4b84-997c-f0f4198292a4@github.com>

On Tue, 14 Jan 2025 09:27:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider module-info.java like this:
> 
> module m {
>     requires transitive java.base;
> }
> 
> 
> When compiled with `--enable-preview --source 24/25`, the resulting classfile is missing the preview flag.
> 
> This PR proposes to use `Preview.checkSourceLevel` to check the source level, which marks the source to use the preview feature.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23097#pullrequestreview-2549315386

From jlahoda at openjdk.org  Tue Jan 14 10:26:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 14 Jan 2025 10:26:46 GMT
Subject: Integrated: 8347646: module-info classfile missing the preview flag
In-Reply-To: <Xjs0IciYuzdhZpjEfAr16RbWPA6iFVQ7UCJ4f92v8fw=.d68fc1f5-6872-4db9-9f88-a3f6834f43e8@github.com>
References: <Xjs0IciYuzdhZpjEfAr16RbWPA6iFVQ7UCJ4f92v8fw=.d68fc1f5-6872-4db9-9f88-a3f6834f43e8@github.com>
Message-ID: <abG_A--0FSgWv44SFEwXikxUdzkXKaeZ3vrs764Hatw=.e2970e42-49c6-4d1c-b76e-fa1fa4d42b24@github.com>

On Tue, 14 Jan 2025 09:27:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider module-info.java like this:
> 
> module m {
>     requires transitive java.base;
> }
> 
> 
> When compiled with `--enable-preview --source 24/25`, the resulting classfile is missing the preview flag.
> 
> This PR proposes to use `Preview.checkSourceLevel` to check the source level, which marks the source to use the preview feature.

This pull request has now been integrated.

Changeset: bb93f67e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb93f67ea8955216e81d1aef58d0ec8bf1fc9bb1
Stats:     99 lines in 4 files changed: 81 ins; 9 del; 9 mod

8347646: module-info classfile missing the preview flag

Reviewed-by: asotona

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

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

From cstein at openjdk.org  Tue Jan 14 10:38:45 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 14 Jan 2025 10:38:45 GMT
Subject: RFR: 8346778: Enable native access should work with the source
 launcher [v3]
In-Reply-To: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
 <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com>
Message-ID: <9nkZ1eJrUbtkSnoTuRIuWPwLoigWn1Oxe7Seu3TEXDg=.b6f54c6f-3061-4bac-806a-73d08b2c7531@github.com>

On Mon, 13 Jan 2025 11:29:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change request enabling native access in source launch mode when using a modular setup.
>> 
>> The change comes in two parts:
>> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
>> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
>> 
>> Tested tier1..3.
>
> Christian Stein has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
>  - Update src/java.base/share/native/libjli/java.c
>    
>    [skip ci]
>  - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
>    
>    [skip ci]

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2589560502

From cstein at openjdk.org  Tue Jan 14 10:38:46 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 14 Jan 2025 10:38:46 GMT
Subject: Integrated: 8346778: Enable native access should work with the source
 launcher
In-Reply-To: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
References: <ymrgVcLN-nN54TaGFRNK3kwC_EBp3N9l3N9roLz_X98=.4e47c2b9-33f5-4127-b44d-fcd276d412ff@github.com>
Message-ID: <8bKSKb4mCjctEm--PsP81y4ZOXycyQgp3Yw7MFUQNIs=.fa345365-bd19-4289-818a-7a1b3f167e49@github.com>

On Mon, 6 Jan 2025 16:35:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change request enabling native access in source launch mode when using a modular setup.
> 
> The change comes in two parts:
> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java`
> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java`
> 
> Tested tier1..3.

This pull request has now been integrated.

Changeset: fec769b0
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fec769b0a840ca4351e2458c24184ec69c112c09
Stats:     82 lines in 6 files changed: 67 ins; 0 del; 15 mod

8346778: Enable native access should work with the source launcher

Reviewed-by: alanb

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

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

From jlahoda at openjdk.org  Tue Jan 14 12:12:16 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 14 Jan 2025 12:12:16 GMT
Subject: [jdk24] RFR: 8347646: module-info classfile missing the preview flag
Message-ID: <W5marE86OCLQg7BQp9pNjZbzpmppDaCYsHTuG1hwBAw=.b299cd4b-b5a1-44e8-b883-1f2bc3a90f00@github.com>

Hi all,

This pull request contains a backport of commit [bb93f67e](https://github.com/openjdk/jdk/commit/bb93f67ea8955216e81d1aef58d0ec8bf1fc9bb1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 14 Jan 2025 and was reviewed by Adam Sotona.

Thanks!

Original description:

Consider module-info.java like this:

module m {
    requires transitive java.base;
}


When compiled with `--enable-preview --source 24/25`, the resulting classfile is missing the preview flag.

This PR proposes to use `Preview.checkSourceLevel` to check the source level, which marks the source to use the preview feature.

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

Commit messages:
 - Backport bb93f67ea8955216e81d1aef58d0ec8bf1fc9bb1

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

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

From jan.lahoda at oracle.com  Tue Jan 14 12:34:33 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 14 Jan 2025 13:34:33 +0100
Subject: Using 'transitive' modifier for 'java.base' in user's
 module-info.java
In-Reply-To: <CAOo1M==EiH1meSmJATtcVZ6tHF1uUg6CStUPFqtVn27zPVL20g@mail.gmail.com>
References: <CAOo1M==EiH1meSmJATtcVZ6tHF1uUg6CStUPFqtVn27zPVL20g@mail.gmail.com>
Message-ID: <b854b802-03c0-4ddf-bd4a-d520fef84019@oracle.com>

Hello Mikhail,


Thanks for the report, I've filled:
https://bugs.openjdk.org/browse/JDK-8347646


Jan


On 13. 01. 25 18:03, Mikhail Pyltsin wrote:
> Hi!
> I am investigating a new version of jep494
> (https://cr.openjdk.org/~gbierman/jep494/jep494-20241024/specs/module-import-declarations-jls.html#jls-7.7.1)
> This chapter allows to use `transitive` in user's module-info.java, but
> after compilation (with --enable-preview) and trying to use this file 
> I've got the error:
> `The requires entry for java.base has ACC_TRANSITIVE set`.
>
> it looks like the problem is here
> https://github.com/openjdk/jdk/blob/a7915bb2e1b822b6d9cbeb220765e8c821c71d0b/src/java.base/share/classes/jdk/internal/module/ModuleInfo.java#L420
> It requires that classfile must be preview, but it's minor version is 
> not equal to?65535 (flag? --enable-preview? was used), because it 
> doesn't use anything from preview.
>
> Could you help me, is this behaviour expected? and how could users 
> use?'transitive'? with 'java.base' in their 'module-info.java'?
>

From asotona at openjdk.org  Tue Jan 14 12:43:39 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 Jan 2025 12:43:39 GMT
Subject: [jdk24] RFR: 8347646: module-info classfile missing the preview
 flag
In-Reply-To: <W5marE86OCLQg7BQp9pNjZbzpmppDaCYsHTuG1hwBAw=.b299cd4b-b5a1-44e8-b883-1f2bc3a90f00@github.com>
References: <W5marE86OCLQg7BQp9pNjZbzpmppDaCYsHTuG1hwBAw=.b299cd4b-b5a1-44e8-b883-1f2bc3a90f00@github.com>
Message-ID: <12Ohc8cZ0XOClxFE9JvBeJ6sJUETaA9OjRYmXILW2QM=.e9d0bfcd-b4b2-48c4-b7d0-6036b4c38a46@github.com>

On Tue, 14 Jan 2025 12:07:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bb93f67e](https://github.com/openjdk/jdk/commit/bb93f67ea8955216e81d1aef58d0ec8bf1fc9bb1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 14 Jan 2025 and was reviewed by Adam Sotona.
> 
> Thanks!
> 
> Original description:
> 
> Consider module-info.java like this:
> 
> module m {
>     requires transitive java.base;
> }
> 
> 
> When compiled with `--enable-preview --source 24/25`, the resulting classfile is missing the preview flag.
> 
> This PR proposes to use `Preview.checkSourceLevel` to check the source level, which marks the source to use the preview feature.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23101#pullrequestreview-2549600201

From duke at openjdk.org  Tue Jan 14 22:12:36 2025
From: duke at openjdk.org (duke)
Date: Tue, 14 Jan 2025 22:12:36 GMT
Subject: Withdrawn: 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: <Ip93nEYM2jFJQbb0DHb9ERJctgrGa7XtZQkeDsn811A=.66ef7d48-f29d-4c43-9e07-10f1f29407d1@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**.

This pull request has been closed without being integrated.

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

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

From jlahoda at openjdk.org  Wed Jan 15 05:17:39 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 15 Jan 2025 05:17:39 GMT
Subject: [jdk24] Integrated: 8347646: module-info classfile missing the preview
 flag
In-Reply-To: <W5marE86OCLQg7BQp9pNjZbzpmppDaCYsHTuG1hwBAw=.b299cd4b-b5a1-44e8-b883-1f2bc3a90f00@github.com>
References: <W5marE86OCLQg7BQp9pNjZbzpmppDaCYsHTuG1hwBAw=.b299cd4b-b5a1-44e8-b883-1f2bc3a90f00@github.com>
Message-ID: <qG9mbuFO8WvIw96faZ983DDwB3RNzawYFnTyWuulIgo=.8503ef3b-36c2-4455-ada8-3bf4515d4cd0@github.com>

On Tue, 14 Jan 2025 12:07:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bb93f67e](https://github.com/openjdk/jdk/commit/bb93f67ea8955216e81d1aef58d0ec8bf1fc9bb1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 14 Jan 2025 and was reviewed by Adam Sotona.
> 
> Thanks!
> 
> Original description:
> 
> Consider module-info.java like this:
> 
> module m {
>     requires transitive java.base;
> }
> 
> 
> When compiled with `--enable-preview --source 24/25`, the resulting classfile is missing the preview flag.
> 
> This PR proposes to use `Preview.checkSourceLevel` to check the source level, which marks the source to use the preview feature.

This pull request has now been integrated.

Changeset: 6965840e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6965840e0dd497325fe1c924c281aa6fde4611fc
Stats:     99 lines in 4 files changed: 81 ins; 9 del; 9 mod

8347646: module-info classfile missing the preview flag

Reviewed-by: asotona
Backport-of: bb93f67ea8955216e81d1aef58d0ec8bf1fc9bb1

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

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

From vromero at openjdk.org  Wed Jan 15 11:30:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 15 Jan 2025 11:30:43 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v3]
In-Reply-To: <JbF3DJ3EbxLIV_zdrF5I3k7Ti86xuB6I2ZeZAZ-0b84=.e328bc8e-6dd3-45f8-8d0d-11a3bd61d1ce@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
 <JbF3DJ3EbxLIV_zdrF5I3k7Ti86xuB6I2ZeZAZ-0b84=.e328bc8e-6dd3-45f8-8d0d-11a3bd61d1ce@github.com>
Message-ID: <2JePoFVBl9EhZSPK0pMB3Kpv0kYTNfb-bmOLK1P9MEc=.331c0e1e-4d12-4e88-b4d0-2a5dc1c4dc09@github.com>

On Tue, 14 Jan 2025 07:09:26 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
>> 
>> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23069#pullrequestreview-2552299462

From hgreule at openjdk.org  Wed Jan 15 12:04:37 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 15 Jan 2025 12:04:37 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v3]
In-Reply-To: <JbF3DJ3EbxLIV_zdrF5I3k7Ti86xuB6I2ZeZAZ-0b84=.e328bc8e-6dd3-45f8-8d0d-11a3bd61d1ce@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
 <JbF3DJ3EbxLIV_zdrF5I3k7Ti86xuB6I2ZeZAZ-0b84=.e328bc8e-6dd3-45f8-8d0d-11a3bd61d1ce@github.com>
Message-ID: <CfOrsdFY69Hg8UA5gozZeQfu890yNjJUSTootQZd0Bs=.e508369f-f2ba-4716-aaf9-bfdbada34e7b@github.com>

On Tue, 14 Jan 2025 07:09:26 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
>> 
>> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Thank you for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23069#issuecomment-2592563683

From duke at openjdk.org  Wed Jan 15 12:04:37 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Jan 2025 12:04:37 GMT
Subject: RFR: 8347562: javac crash due to type vars in permits clause [v3]
In-Reply-To: <JbF3DJ3EbxLIV_zdrF5I3k7Ti86xuB6I2ZeZAZ-0b84=.e328bc8e-6dd3-45f8-8d0d-11a3bd61d1ce@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
 <JbF3DJ3EbxLIV_zdrF5I3k7Ti86xuB6I2ZeZAZ-0b84=.e328bc8e-6dd3-45f8-8d0d-11a3bd61d1ce@github.com>
Message-ID: <uzyGap9v-_E_DP1HhH_hRn5eg5XbKnrlcwOC4B_KkeE=.bf9f29f1-360c-4479-b000-0c075e1a82bf@github.com>

On Tue, 14 Jan 2025 07:09:26 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
>> 
>> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

@SirYwell 
Your change (at version 41bbac883d63b4b5d32b766627315c151d77705c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23069#issuecomment-2592572284

From hgreule at openjdk.org  Wed Jan 15 14:11:49 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 15 Jan 2025 14:11:49 GMT
Subject: Integrated: 8347562: javac crash due to type vars in permits clause
In-Reply-To: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
References: <RrEqntA0zE-UWHHfFdoKOpJPxTCHCykI0VKhPjLwdhc=.c3951640-799e-40cf-af18-009a2b15a032@github.com>
Message-ID: <2Vltlrjk5SUtBdR3xJtskHEfXLFqzpDUYlhI3pk_I4I=.0d122e0b-18e0-4329-8c5d-0d960ce85fa0@github.com>

On Mon, 13 Jan 2025 13:33:13 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This fix ignores erroneous types when attributing permits clauses. Before, multiple erroneous types would lead to an exception in the duplication check. Additionally, such types would cause package mismatch errors. As javac already reports errors before, such an additional error is more confusing than helpful.
> 
> Note that there are additional type var checks, but those only apply if the type vars come from a type other than the type with the permits clause, i.e. an enclosing class.

This pull request has now been integrated.

Changeset: 8193ba3d
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8193ba3de200cb77f778f58c59b8bb2175b53273
Stats:     17 lines in 2 files changed: 13 ins; 0 del; 4 mod

8347562: javac crash due to type vars in permits clause

Reviewed-by: vromero

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

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

From duke at openjdk.org  Wed Jan 15 22:30:45 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Jan 2025 22:30:45 GMT
Subject: Withdrawn: 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: <AJAYVwkH3Ma-yxOCmM0bFSSiFukyr01NVWCAW2YOp_c=.e33de2b1-60db-46f8-9171-8cd2f13c5a64@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)

This pull request has been closed without being integrated.

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

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

From acobbs at openjdk.org  Thu Jan 16 02:43:39 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 16 Jan 2025 02:43:39 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v5]
In-Reply-To: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
Message-ID: <ob-9lG_0nW3CraUhtkn95z9WqIuBW73W9bL427Ykg-w=.deac4a48-458d-4026-9fd2-b67d047e0c60@github.com>

> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
> 
> Please see the follow-up comment for a more complete description (trying to keep the first comment short).

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

  Add some Javadoc/comment improvements to Lint.java.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23056/files
  - new: https://git.openjdk.org/jdk/pull/23056/files/5661449b..91115e3a

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

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

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

From dawid.weiss at gmail.com  Thu Jan 16 12:33:05 2025
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 16 Jan 2025 13:33:05 +0100
Subject: Exponential compilation time for List.of(Map.entry) expressions
Message-ID: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>

Hello,

I came across an interesting quirk of javac today. I was looking at
unusually long compilation times of a bunch of test files. One of those
files looks like this:

public class JavacBoom {
  public void ahem() {
  List<Map.Entry<String, String>> value =
        Arrays.asList(
            Map.entry("key", "value"),
            Map.entry("key", "value"),
            Map.entry("key", "value"),
            ...
            Map.entry("key", "value"),
        );
  }
}

Nothing special, except value is populated with many, many key-value pairs.
I think type inference must have some kind of exponential algorithm in
there because here is what it looks like when you increase the number of
keys:

count of Map.entry(k,v), real time [seconds] javac JavacBoom
1, 0.4
10, 0.43
100, 1.08
200, 3.4
300, 10.8
400, 22.9
500, 50

So if you have 500 entries like the above, it'll take 50 seconds to compile
a single ~10k bytes java source input. Here is a github gist with the
source code containing 500 entries if you'd like to try locally:
https://gist.github.com/dweiss/93caf579a89f3dbbfac5c292048e42ad

The compiler points here (roughly, single stack trace).

"main" #1 [1070081] prio=5 os_prio=0 cpu=1687.19ms elapsed=1.76s
tid=0x00007de1b802a3f0 nid=1070081 runnable  [0x00007de1bcdfb000]
   java.lang.Thread.State: RUNNABLE
at com.sun.tools.javac.code.Type.equalsIgnoreMetadata(jdk.compiler at 23.0.1
/Type.java:563)
at com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1
/Types.java:3355)
at com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1
/Types.java:3331)
at com.sun.tools.javac.code.Type$TypeVar.accept(jdk.compiler at 23.0.1
/Type.java:1709)
at
com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(jdk.compiler at 23.0.1
/Types.java:4920)
at com.sun.tools.javac.code.Type.map(jdk.compiler at 23.0.1/Type.java:319)
at com.sun.tools.javac.code.Types.subst(jdk.compiler at 23.0.1/Types.java:3328)
at com.sun.tools.javac.comp.InferenceContext.asUndetVar(jdk.compiler at 23.0.1
/InferenceContext.java:206)
at
com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.initNodes(jdk.compiler at 23.0.1
/Infer.java:1907)
at
com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.<init>(jdk.compiler at 23.0.1
/Infer.java:1852)
at com.sun.tools.javac.comp.Infer$GraphSolver.solve(jdk.compiler at 23.0.1
/Infer.java:1654)
at com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1
/InferenceContext.java:487)
at com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1
/InferenceContext.java:494)
at com.sun.tools.javac.comp.Infer.instantiateMethod(jdk.compiler at 23.0.1
/Infer.java:211)
at com.sun.tools.javac.comp.Resolve.rawInstantiate(jdk.compiler at 23.0.1
/Resolve.java:619)
at com.sun.tools.javac.comp.Resolve.selectBest(jdk.compiler at 23.0.1
/Resolve.java:1588)
at com.sun.tools.javac.comp.Resolve.findMethodInScope(jdk.compiler at 23.0.1
/Resolve.java:1794)
at com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1
/Resolve.java:1865)
at com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1
/Resolve.java:1838)
at com.sun.tools.javac.comp.Resolve$12.doLookup(jdk.compiler at 23.0.1
/Resolve.java:2770)
at
com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(jdk.compiler at 23.0.1
/Resolve.java:3485)
at com.sun.tools.javac.comp.Resolve.lookupMethod(jdk.compiler at 23.0.1
/Resolve.java:3749)
at
com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1
/Resolve.java:2767)
at
com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1
/Resolve.java:2761)
at com.sun.tools.javac.comp.Attr.selectSym(jdk.compiler at 23.0.1
/Attr.java:4546)
at com.sun.tools.javac.comp.Attr.visitSelect(jdk.compiler at 23.0.1
/Attr.java:4433)
at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(jdk.compiler at 23.0.1
/JCTree.java:2570)
at com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1
/Attr.java:674)
at com.sun.tools.javac.comp.Attr.visitApply(jdk.compiler at 23.0.1
/Attr.java:2641)
at
com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(jdk.compiler at 23.0.1
/JCTree.java:1857)
at com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1
/Attr.java:674)
at com.sun.tools.javac.comp.Attr.attribExpr(jdk.compiler at 23.0.1
/Attr.java:720)
at com.sun.tools.javac.comp.Attr.visitVarDef(jdk.compiler at 23.0.1
/Attr.java:1318)

I don't have the karma to submit jira issues, but I think this can be
considered a showstopper?

Dawid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250116/12a4d158/attachment.htm>

From dawid.weiss at gmail.com  Thu Jan 16 12:34:45 2025
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 16 Jan 2025 13:34:45 +0100
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
Message-ID: <CAM21Rt9r5Whxuk3MLSF_3ZmA7m17vNdritO9HRWvnb4qdyEZCA@mail.gmail.com>

Forgot to mention - happens with any javac I tried it with (from jdk 11 all
the way until 23).

Dawid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250116/b1514ffe/attachment.htm>

From vicente.romero at oracle.com  Thu Jan 16 14:56:54 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 16 Jan 2025 09:56:54 -0500
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
Message-ID: <af1b3d25-c472-4e90-b44f-c5a009945a8a@oracle.com>

HI Dawid,

this looks like another instance of [1], is this something affecting 
test cases or production code?

Thanks,
Vicente

[1] https://bugs.openjdk.org/browse/JDK-8302292


On 1/16/25 07:33, Dawid Weiss wrote:
>
> Hello,
>
> I came across an interesting quirk of javac today. I was looking at 
> unusually long compilation times of a bunch of test files. One of 
> those files looks like this:
>
> public class JavacBoom {
> ? public void ahem() {
> ? List<Map.Entry<String, String>> value =
> ? ? ? ? Arrays.asList(
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? ...
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? );
> ? }
> }
>
> Nothing special, except value is populated with many, many key-value 
> pairs. I think type inference must have some kind of exponential 
> algorithm in there because here is what it looks like when?you 
> increase the number of keys:
>
> count of Map.entry(k,v), real time [seconds] javac JavacBoom
> 1, 0.4
> 10, 0.43
> 100, 1.08
> 200, 3.4
> 300, 10.8
> 400, 22.9
> 500, 50
>
> So if you have 500 entries like the above, it'll take 50 seconds to 
> compile a single ~10k bytes java source input. Here is a github gist 
> with the source code containing 500 entries if you'd like to try locally:
> https://gist.github.com/dweiss/93caf579a89f3dbbfac5c292048e42ad
>
> The compiler points here (roughly, single stack trace).
>
> "main" #1 [1070081] prio=5 os_prio=0 cpu=1687.19ms elapsed=1.76s 
> tid=0x00007de1b802a3f0 nid=1070081 runnable ?[0x00007de1bcdfb000]
> ? ?java.lang.Thread.State: RUNNABLE
> at 
> com.sun.tools.javac.code.Type.equalsIgnoreMetadata(jdk.compiler at 23.0.1/Type.java:563)
> at 
> com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1/Types.java:3355)
> at 
> com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1/Types.java:3331)
> at 
> com.sun.tools.javac.code.Type$TypeVar.accept(jdk.compiler at 23.0.1/Type.java:1709)
> at 
> com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(jdk.compiler at 23.0.1/Types.java:4920)
> at com.sun.tools.javac.code.Type.map(jdk.compiler at 23.0.1/Type.java:319)
> at 
> com.sun.tools.javac.code.Types.subst(jdk.compiler at 23.0.1/Types.java:3328)
> at 
> com.sun.tools.javac.comp.InferenceContext.asUndetVar(jdk.compiler at 23.0.1/InferenceContext.java:206)
> at 
> com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.initNodes(jdk.compiler at 23.0.1/Infer.java:1907)
> at 
> com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.<init>(jdk.compiler at 23.0.1/Infer.java:1852)
> at 
> com.sun.tools.javac.comp.Infer$GraphSolver.solve(jdk.compiler at 23.0.1/Infer.java:1654)
> at 
> com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1/InferenceContext.java:487)
> at 
> com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1/InferenceContext.java:494)
> at 
> com.sun.tools.javac.comp.Infer.instantiateMethod(jdk.compiler at 23.0.1/Infer.java:211)
> at 
> com.sun.tools.javac.comp.Resolve.rawInstantiate(jdk.compiler at 23.0.1/Resolve.java:619)
> at 
> com.sun.tools.javac.comp.Resolve.selectBest(jdk.compiler at 23.0.1/Resolve.java:1588)
> at 
> com.sun.tools.javac.comp.Resolve.findMethodInScope(jdk.compiler at 23.0.1/Resolve.java:1794)
> at 
> com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1/Resolve.java:1865)
> at 
> com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1/Resolve.java:1838)
> at 
> com.sun.tools.javac.comp.Resolve$12.doLookup(jdk.compiler at 23.0.1/Resolve.java:2770)
> at 
> com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(jdk.compiler at 23.0.1/Resolve.java:3485)
> at 
> com.sun.tools.javac.comp.Resolve.lookupMethod(jdk.compiler at 23.0.1/Resolve.java:3749)
> at 
> com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1/Resolve.java:2767)
> at 
> com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1/Resolve.java:2761)
> at 
> com.sun.tools.javac.comp.Attr.selectSym(jdk.compiler at 23.0.1/Attr.java:4546)
> at 
> com.sun.tools.javac.comp.Attr.visitSelect(jdk.compiler at 23.0.1/Attr.java:4433)
> at 
> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(jdk.compiler at 23.0.1/JCTree.java:2570)
> at 
> com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1/Attr.java:674)
> at 
> com.sun.tools.javac.comp.Attr.visitApply(jdk.compiler at 23.0.1/Attr.java:2641)
> at 
> com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(jdk.compiler at 23.0.1/JCTree.java:1857)
> at 
> com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1/Attr.java:674)
> at 
> com.sun.tools.javac.comp.Attr.attribExpr(jdk.compiler at 23.0.1/Attr.java:720)
> at 
> com.sun.tools.javac.comp.Attr.visitVarDef(jdk.compiler at 23.0.1/Attr.java:1318)
>
> I don't have the karma to submit jira issues, but I think this can be 
> considered a showstopper?
>
> Dawid


From dawid.weiss at gmail.com  Thu Jan 16 15:28:12 2025
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 16 Jan 2025 16:28:12 +0100
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <af1b3d25-c472-4e90-b44f-c5a009945a8a@oracle.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <af1b3d25-c472-4e90-b44f-c5a009945a8a@oracle.com>
Message-ID: <CAM21Rt-v-mBARo9YTm_VSMLhsU0h0pjHFWj=kZNexu=Hue3Yaw@mail.gmail.com>

Yes, it seems to be the same issue.


> this looks like another instance of [1], is this something affecting
> test cases or production code?
>

My particular case was in tests, where the code contained a few hundred
language-code-name pairs
but this is affecting compilation in general - any source that contains
this pattern will
be increasingly slow (and computationally expensive) to compile.
Clearly exponential cost with the number of entries.

Dawid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250116/818f7e30/attachment.htm>

From maurizio.cimadamore at oracle.com  Thu Jan 16 22:28:26 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 16 Jan 2025 22:28:26 +0000
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
Message-ID: <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>

Hi,
as Vicente mentioned, this is sadly a known issue. Each call to 
Map.entry adds two inference variables. These variables are all thrown 
into the same cauldron, as the inference engine wants to reason globally 
about them.

We had overcome many similar performance potholes in the past, 
essentially by detecting and pruning away inference variables where e.g. 
X = Y (so we only keep one of them). In this case, unfortunately, 
there's no such equality to detect, and we can't really prune the set of 
inference variables. We have some ideas on how to maybe do it, but they 
are all fairly complex, and the risk of affecting correctness is rather 
high.

In the meantime, there's maybe a workaround for you to try: let's remove 
the generic-ness of Map.Entry from the picture, by declaring a new method:

Map.Entry<String, String> newStringEntry(String key, String val) { 
return Map.entry(key, val); }

Now, call the new method when you build the big list. I believe this 
should bring compilation back to normal times.

Hope this helps.

Maurizio



On 16/01/2025 12:33, Dawid Weiss wrote:
>
> Hello,
>
> I came across an interesting quirk of javac today. I was looking at 
> unusually long compilation times of a bunch of test files. One of 
> those files looks like this:
>
> public class JavacBoom {
> ? public void ahem() {
> ? List<Map.Entry<String, String>> value =
> ? ? ? ? Arrays.asList(
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? ...
> ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? );
> ? }
> }
>
> Nothing special, except value is populated with many, many key-value 
> pairs. I think type inference must have some kind of exponential 
> algorithm in there because here is what it looks like when?you 
> increase the number of keys:
>
> count of Map.entry(k,v), real time [seconds] javac JavacBoom
> 1, 0.4
> 10, 0.43
> 100, 1.08
> 200, 3.4
> 300, 10.8
> 400, 22.9
> 500, 50
>
> So if you have 500 entries like the above, it'll take 50 seconds to 
> compile a single ~10k bytes java source input. Here is a github gist 
> with the source code containing 500 entries if you'd like to try locally:
> https://gist.github.com/dweiss/93caf579a89f3dbbfac5c292048e42ad
>
> The compiler points here (roughly, single stack trace).
>
> "main" #1 [1070081] prio=5 os_prio=0 cpu=1687.19ms elapsed=1.76s 
> tid=0x00007de1b802a3f0 nid=1070081 runnable ?[0x00007de1bcdfb000]
> ? ?java.lang.Thread.State: RUNNABLE
> at 
> com.sun.tools.javac.code.Type.equalsIgnoreMetadata(jdk.compiler at 23.0.1/Type.java:563)
> at 
> com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1/Types.java:3355)
> at 
> com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1/Types.java:3331)
> at 
> com.sun.tools.javac.code.Type$TypeVar.accept(jdk.compiler at 23.0.1/Type.java:1709)
> at 
> com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(jdk.compiler at 23.0.1/Types.java:4920)
> at com.sun.tools.javac.code.Type.map(jdk.compiler at 23.0.1/Type.java:319)
> at 
> com.sun.tools.javac.code.Types.subst(jdk.compiler at 23.0.1/Types.java:3328)
> at 
> com.sun.tools.javac.comp.InferenceContext.asUndetVar(jdk.compiler at 23.0.1/InferenceContext.java:206)
> at 
> com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.initNodes(jdk.compiler at 23.0.1/Infer.java:1907)
> at 
> com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.<init>(jdk.compiler at 23.0.1/Infer.java:1852)
> at 
> com.sun.tools.javac.comp.Infer$GraphSolver.solve(jdk.compiler at 23.0.1/Infer.java:1654)
> at 
> com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1/InferenceContext.java:487)
> at 
> com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1/InferenceContext.java:494)
> at 
> com.sun.tools.javac.comp.Infer.instantiateMethod(jdk.compiler at 23.0.1/Infer.java:211)
> at 
> com.sun.tools.javac.comp.Resolve.rawInstantiate(jdk.compiler at 23.0.1/Resolve.java:619)
> at 
> com.sun.tools.javac.comp.Resolve.selectBest(jdk.compiler at 23.0.1/Resolve.java:1588)
> at 
> com.sun.tools.javac.comp.Resolve.findMethodInScope(jdk.compiler at 23.0.1/Resolve.java:1794)
> at 
> com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1/Resolve.java:1865)
> at 
> com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1/Resolve.java:1838)
> at 
> com.sun.tools.javac.comp.Resolve$12.doLookup(jdk.compiler at 23.0.1/Resolve.java:2770)
> at 
> com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(jdk.compiler at 23.0.1/Resolve.java:3485)
> at 
> com.sun.tools.javac.comp.Resolve.lookupMethod(jdk.compiler at 23.0.1/Resolve.java:3749)
> at 
> com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1/Resolve.java:2767)
> at 
> com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1/Resolve.java:2761)
> at 
> com.sun.tools.javac.comp.Attr.selectSym(jdk.compiler at 23.0.1/Attr.java:4546)
> at 
> com.sun.tools.javac.comp.Attr.visitSelect(jdk.compiler at 23.0.1/Attr.java:4433)
> at 
> com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(jdk.compiler at 23.0.1/JCTree.java:2570)
> at 
> com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1/Attr.java:674)
> at 
> com.sun.tools.javac.comp.Attr.visitApply(jdk.compiler at 23.0.1/Attr.java:2641)
> at 
> com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(jdk.compiler at 23.0.1/JCTree.java:1857)
> at 
> com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1/Attr.java:674)
> at 
> com.sun.tools.javac.comp.Attr.attribExpr(jdk.compiler at 23.0.1/Attr.java:720)
> at 
> com.sun.tools.javac.comp.Attr.visitVarDef(jdk.compiler at 23.0.1/Attr.java:1318)
>
> I don't have the karma to submit jira issues, but I think this can be 
> considered a showstopper?
>
> Dawid

From vromero at openjdk.org  Thu Jan 16 22:53:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Jan 2025 22:53:34 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v5]
In-Reply-To: <ob-9lG_0nW3CraUhtkn95z9WqIuBW73W9bL427Ykg-w=.deac4a48-458d-4026-9fd2-b67d047e0c60@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
 <ob-9lG_0nW3CraUhtkn95z9WqIuBW73W9bL427Ykg-w=.deac4a48-458d-4026-9fd2-b67d047e0c60@github.com>
Message-ID: <CBG_wBIqd53x2aa5SfzS1HuVWm7U2z_doHcxWW2PjQw=.26cc33cc-81d5-4b73-b884-2ff35b42b76e@github.com>

On Thu, 16 Jan 2025 02:43:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
>> 
>> Please see the follow-up comment for a more complete description (trying to keep the first comment short).
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some Javadoc/comment improvements to Lint.java.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 146:

> 144:     // For the root instance only, these are initialized lazily
> 145:     private EnumSet<LintCategory> values;           // categories enabled by default or "-Xlint:key" and not (yet) suppressed
> 146:     private EnumSet<LintCategory> suppressedValues; // categories suppressed by augment() or suppress() (but not "-Xlint:-key")

I was not expecting to find so many changes in this class. From the description I was expecting most changes in Options and some "small" changes in its clients, not saying that this is wrong, just that probably the description should be augmented

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23056#discussion_r1919338981

From acobbs at openjdk.org  Thu Jan 16 23:25:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 16 Jan 2025 23:25:53 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v6]
In-Reply-To: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
Message-ID: <RyA4Emfg3EdHf1WQ27sAVxLGafNS1la25hRT575VYIE=.b406a03c-9d09-437a-815a-dc7334cadb50@github.com>

> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
> 
> Please see the follow-up comment for a more complete description (trying to keep the first comment short).

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

  Revert extraneous changes to Lint.java.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23056/files
  - new: https://git.openjdk.org/jdk/pull/23056/files/91115e3a..4e751f87

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

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

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

From acobbs at openjdk.org  Thu Jan 16 23:25:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 16 Jan 2025 23:25:54 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v5]
In-Reply-To: <CBG_wBIqd53x2aa5SfzS1HuVWm7U2z_doHcxWW2PjQw=.26cc33cc-81d5-4b73-b884-2ff35b42b76e@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
 <ob-9lG_0nW3CraUhtkn95z9WqIuBW73W9bL427Ykg-w=.deac4a48-458d-4026-9fd2-b67d047e0c60@github.com>
 <CBG_wBIqd53x2aa5SfzS1HuVWm7U2z_doHcxWW2PjQw=.26cc33cc-81d5-4b73-b884-2ff35b42b76e@github.com>
Message-ID: <H1WrEVLHnXm5m_vuI1-mK6L_WbxRQFG074piZEQ05aE=.43f23485-b49f-4a54-9c89-be0dfd36bc68@github.com>

On Thu, 16 Jan 2025 22:49:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add some Javadoc/comment improvements to Lint.java.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 146:
> 
>> 144:     // For the root instance only, these are initialized lazily
>> 145:     private EnumSet<LintCategory> values;           // categories enabled by default or "-Xlint:key" and not (yet) suppressed
>> 146:     private EnumSet<LintCategory> suppressedValues; // categories suppressed by augment() or suppress() (but not "-Xlint:-key")
> 
> I was not expecting to find so many changes in this class. From the description I was expecting most changes in Options and some "small" changes in its clients, not saying that this is wrong, just that probably the description should be augmented

Yep - those changes are mainly me trying to clean things up and improve the documentation and not directly related to this ticket.

I have another PR brewing that would be a better place for them so I'll revert those changes from this one - see 4e751f87d33.

Thanks for the feedback!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23056#discussion_r1919361305

From acobbs at openjdk.org  Thu Jan 16 23:52:08 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 16 Jan 2025 23:52:08 GMT
Subject: RFR: 8347958: Minor compiler cleanups relating to
 MandatoryWarningHandler
Message-ID: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com>

After recent improvements to Lint-related classes, there are now a few minor cleanup opportunities relating to `MandatoryWarningHandler`.

1. The new `LintWarning` class provides access to the associated `LintCategory`. This means that the `LintCategory` parameter being passed to the `MandatoryWarningHandler` constructor is no longer needed.
1. The `prefix` string being passed to the `MandatoryWarningHandler` constructor can (in most cases) be inferred as well.
1. The field `Check.sunApiHandler` (which has type `MandatoryWarningHandler`) is no longer used and can be removed.

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

Commit messages:
 - Some cleanups relating to MandatoryWarningHandler.

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

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

From dawid.weiss at gmail.com  Fri Jan 17 06:57:50 2025
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Fri, 17 Jan 2025 07:57:50 +0100
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
Message-ID: <CAM21Rt9r6dDMwPTc7-fPnAQ+s4w-uiT+vUqFURWsGap5rkCLww@mail.gmail.com>

Hi Maurizio,

as Vicente mentioned, this is sadly a known issue.


Thank you and Vicente for pointing at the root problem. I actually did do a
few searches trying to find something similar in Jira but didn't come up
with anything that wasn't closed (like JDK-8263452).


> We have some ideas on how to maybe do it, but they
> are all fairly complex, and the risk of affecting correctness is rather
> high.
>

Fair enough and sorry I can't be more helpful here.


> In the meantime, there's maybe a workaround for you to try: let's remove
> the generic-ness of Map.Entry from the picture, by declaring a new method:

Map.Entry<String, String> newStringEntry(String key, String val) { return
> Map.entry(key, val); }


This is actually a nice hint for adding to Uwe's forbiddenapis checker. [1]
:)

Anyway, I have refactored that initialization into a different code shape
already - this isn't the difficult part.
The difficult part was in figuring out what the problem actually was and
trying to detect it somehow for the
future, until you smart folks figure out how to straighten it up.

This code had been compiling for weeks (slowing down builds) and I only
found out about it because
I was working on something unrelated in the build and noticing these
strange, long compilation times on a literal
dozen of input files. My thought process was: gradle build problem,
hardware problem, extensive I/O somewhere...
javac was way, way at the end of the list (if at all). I mean it as a
compliment - it's typically so robust that it's
hardly ever a suspect.

Thanks again for feedback and sorry for raising an alarm on an existing
issue.

Dawid

[1] https://github.com/policeman-tools/forbidden-apis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250117/30516640/attachment-0001.htm>

From amaembo at gmail.com  Fri Jan 17 08:00:23 2025
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 17 Jan 2025 09:00:23 +0100
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
Message-ID: <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>

Hello!

There's a simpler workaround. No need to declare a method, you can just add
explicit type arguments to Arrays.asList call:

    List<Map.Entry<String, String>> value =
            Arrays.<Map.Entry<String, String>>asList(
                    Map.entry("key", "value"),
                    Map.entry("key", "value"),
                    ...
                    Map.entry("key", "value"),
                    Map.entry("key", "value")
                    );

Now, Arrays.asList becomes a standalone call, and instead of having a
single huge inference session, one has many small sessions, and the
compilation is fast again.

This problem is old and well-known. IntelliJ IDEA even has an inspection
for it since ages. It's called "Javac quirks" [1], and we provide a
quick-fix that adds explicit type arguments when the number of inference
variables exceeds some threshold. Probably thanks to this, the OpenJDK
project receives much fewer complaints about this problem than it could be
:-)

With best regards,
Tagir Valeev

[1] https://www.jetbrains.com/help/inspectopedia/JavacQuirks.html

On Thu, Jan 16, 2025 at 11:29?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> as Vicente mentioned, this is sadly a known issue. Each call to
> Map.entry adds two inference variables. These variables are all thrown
> into the same cauldron, as the inference engine wants to reason globally
> about them.
>
> We had overcome many similar performance potholes in the past,
> essentially by detecting and pruning away inference variables where e.g.
> X = Y (so we only keep one of them). In this case, unfortunately,
> there's no such equality to detect, and we can't really prune the set of
> inference variables. We have some ideas on how to maybe do it, but they
> are all fairly complex, and the risk of affecting correctness is rather
> high.
>
> In the meantime, there's maybe a workaround for you to try: let's remove
> the generic-ness of Map.Entry from the picture, by declaring a new method:
>
> Map.Entry<String, String> newStringEntry(String key, String val) {
> return Map.entry(key, val); }
>
> Now, call the new method when you build the big list. I believe this
> should bring compilation back to normal times.
>
> Hope this helps.
>
> Maurizio
>
>
>
> On 16/01/2025 12:33, Dawid Weiss wrote:
> >
> > Hello,
> >
> > I came across an interesting quirk of javac today. I was looking at
> > unusually long compilation times of a bunch of test files. One of
> > those files looks like this:
> >
> > public class JavacBoom {
> >   public void ahem() {
> >   List<Map.Entry<String, String>> value =
> >         Arrays.asList(
> >             Map.entry("key", "value"),
> >             Map.entry("key", "value"),
> >             Map.entry("key", "value"),
> >             ...
> >             Map.entry("key", "value"),
> >         );
> >   }
> > }
> >
> > Nothing special, except value is populated with many, many key-value
> > pairs. I think type inference must have some kind of exponential
> > algorithm in there because here is what it looks like when you
> > increase the number of keys:
> >
> > count of Map.entry(k,v), real time [seconds] javac JavacBoom
> > 1, 0.4
> > 10, 0.43
> > 100, 1.08
> > 200, 3.4
> > 300, 10.8
> > 400, 22.9
> > 500, 50
> >
> > So if you have 500 entries like the above, it'll take 50 seconds to
> > compile a single ~10k bytes java source input. Here is a github gist
> > with the source code containing 500 entries if you'd like to try locally:
> > https://gist.github.com/dweiss/93caf579a89f3dbbfac5c292048e42ad
> >
> > The compiler points here (roughly, single stack trace).
> >
> > "main" #1 [1070081] prio=5 os_prio=0 cpu=1687.19ms elapsed=1.76s
> > tid=0x00007de1b802a3f0 nid=1070081 runnable  [0x00007de1bcdfb000]
> >    java.lang.Thread.State: RUNNABLE
> > at
> > com.sun.tools.javac.code.Type.equalsIgnoreMetadata(jdk.compiler at 23.0.1
> /Type.java:563)
> > at
> > com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1
> /Types.java:3355)
> > at
> > com.sun.tools.javac.code.Types$Subst.visitTypeVar(jdk.compiler at 23.0.1
> /Types.java:3331)
> > at
> > com.sun.tools.javac.code.Type$TypeVar.accept(jdk.compiler at 23.0.1
> /Type.java:1709)
> > at
> >
> com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(jdk.compiler at 23.0.1
> /Types.java:4920)
> > at com.sun.tools.javac.code.Type.map(jdk.compiler at 23.0.1/Type.java:319)
> > at
> > com.sun.tools.javac.code.Types.subst(jdk.compiler at 23.0.1
> /Types.java:3328)
> > at
> > com.sun.tools.javac.comp.InferenceContext.asUndetVar(jdk.compiler at 23.0.1
> /InferenceContext.java:206)
> > at
> >
> com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.initNodes(jdk.compiler at 23.0.1
> /Infer.java:1907)
> > at
> >
> com.sun.tools.javac.comp.Infer$GraphSolver$InferenceGraph.<init>(jdk.compiler at 23.0.1
> /Infer.java:1852)
> > at
> > com.sun.tools.javac.comp.Infer$GraphSolver.solve(jdk.compiler at 23.0.1
> /Infer.java:1654)
> > at
> > com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1
> /InferenceContext.java:487)
> > at
> > com.sun.tools.javac.comp.InferenceContext.solve(jdk.compiler at 23.0.1
> /InferenceContext.java:494)
> > at
> > com.sun.tools.javac.comp.Infer.instantiateMethod(jdk.compiler at 23.0.1
> /Infer.java:211)
> > at
> > com.sun.tools.javac.comp.Resolve.rawInstantiate(jdk.compiler at 23.0.1
> /Resolve.java:619)
> > at
> > com.sun.tools.javac.comp.Resolve.selectBest(jdk.compiler at 23.0.1
> /Resolve.java:1588)
> > at
> > com.sun.tools.javac.comp.Resolve.findMethodInScope(jdk.compiler at 23.0.1
> /Resolve.java:1794)
> > at
> > com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1
> /Resolve.java:1865)
> > at
> > com.sun.tools.javac.comp.Resolve.findMethod(jdk.compiler at 23.0.1
> /Resolve.java:1838)
> > at
> > com.sun.tools.javac.comp.Resolve$12.doLookup(jdk.compiler at 23.0.1
> /Resolve.java:2770)
> > at
> >
> com.sun.tools.javac.comp.Resolve$BasicLookupHelper.lookup(jdk.compiler at 23.0.1
> /Resolve.java:3485)
> > at
> > com.sun.tools.javac.comp.Resolve.lookupMethod(jdk.compiler at 23.0.1
> /Resolve.java:3749)
> > at
> >
> com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1
> /Resolve.java:2767)
> > at
> >
> com.sun.tools.javac.comp.Resolve.resolveQualifiedMethod(jdk.compiler at 23.0.1
> /Resolve.java:2761)
> > at
> > com.sun.tools.javac.comp.Attr.selectSym(jdk.compiler at 23.0.1
> /Attr.java:4546)
> > at
> > com.sun.tools.javac.comp.Attr.visitSelect(jdk.compiler at 23.0.1
> /Attr.java:4433)
> > at
> > com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(jdk.compiler at 23.0.1
> /JCTree.java:2570)
> > at
> > com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1
> /Attr.java:674)
> > at
> > com.sun.tools.javac.comp.Attr.visitApply(jdk.compiler at 23.0.1
> /Attr.java:2641)
> > at
> >
> com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(jdk.compiler at 23.0.1
> /JCTree.java:1857)
> > at
> > com.sun.tools.javac.comp.Attr.attribTree(jdk.compiler at 23.0.1
> /Attr.java:674)
> > at
> > com.sun.tools.javac.comp.Attr.attribExpr(jdk.compiler at 23.0.1
> /Attr.java:720)
> > at
> > com.sun.tools.javac.comp.Attr.visitVarDef(jdk.compiler at 23.0.1
> /Attr.java:1318)
> >
> > I don't have the karma to submit jira issues, but I think this can be
> > considered a showstopper?
> >
> > Dawid
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250117/f89cc9ce/attachment.htm>

From maurizio.cimadamore at oracle.com  Fri Jan 17 10:12:57 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 17 Jan 2025 10:12:57 +0000
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
Message-ID: <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>


On 17/01/2025 08:00, Tagir Valeev wrote:
> There's a simpler workaround. No need to declare a method, you can 
> just add explicit type arguments to Arrays.asList call:
>
> ? ? List<Map.Entry<String, String>> value =
> ? ? ? ? ? ? Arrays.<Map.Entry<String, String>>asList(
> ? ? ? ? ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? ? ? ? ? ...
> ? ? ? ? ? ? ? ? ? ? Map.entry("key", "value"),
> ? ? ? ? ? ? ? ? ? ? Map.entry("key", "value")
> ? ? ? ? ? ? ? ? ? ? );

Of course (blush) :-)

> This problem is old and well-known. IntelliJ IDEA even has an 
> inspection for it since ages. It's called "Javac quirks" [1], and we 
> provide a quick-fix that adds explicit type arguments when the number 
> of inference variables exceeds some threshold. Probably thanks to 
> this, the OpenJDK project receives much fewer complaints about this 
> problem than it could be :-) 
Didn't know about "javac quirks" :-)

Question: is intellij able to figure out the correct types w/o ending up 
with combinatorial explosion -- or is it using some heuristic to "guess" 
what the likely type arguments are going to be?

Maurizio


From amaembo at gmail.com  Fri Jan 17 10:57:20 2025
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 17 Jan 2025 11:57:20 +0100
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
 <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
Message-ID: <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>

Hello!

On Fri, Jan 17, 2025, 11:13 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> Question: is intellij able to figure out the correct types w/o ending up
> with combinatorial explosion -- or is it using some heuristic to "guess"
> what the likely type arguments are going to be?
>

This is a performance problem for IntelliJ as well. Highlighting becomes
slow on such code. Not sure whether it's slower or faster than javac, but
it's definitely slow. So technically, it's 'javac + IntelliJ quirks' :-)


> Maurizio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250117/01da46e0/attachment.htm>

From maurizio.cimadamore at oracle.com  Fri Jan 17 11:34:41 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 17 Jan 2025 11:34:41 +0000
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
 <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
 <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
Message-ID: <4b32845f-2f53-4510-b6b0-32b89d639024@oracle.com>


On 17/01/2025 10:57, Tagir Valeev wrote:
> Hello!
>
> On Fri, Jan 17, 2025, 11:13 Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>
>     Question: is intellij able to figure out the correct types w/o
>     ending up
>     with combinatorial explosion -- or is it using some heuristic to
>     "guess"
>     what the likely type arguments are going to be?
>
>
> This is a performance problem for IntelliJ as well. Highlighting 
> becomes slow on such code. Not sure whether it's slower or faster than 
> javac, but it's definitely slow. So technically, it's 'javac + 
> IntelliJ quirks' :-)

Ah I see - so you do the full analysis, but when it gets "too slow", you 
suggest to use explicit type parameters. Makes sense.

Now, if you have internal diagnostics on when this happens, and see some 
what code triggered it, it might be useful to report bugs -- so that we 
make sure that we avoid all the performance potholes we can avoid.

Cheers
Maurizio

>
>
>     Maurizio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250117/66de7b8f/attachment.htm>

From amaembo at gmail.com  Fri Jan 17 11:39:42 2025
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 17 Jan 2025 12:39:42 +0100
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <4b32845f-2f53-4510-b6b0-32b89d639024@oracle.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
 <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
 <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
 <4b32845f-2f53-4510-b6b0-32b89d639024@oracle.com>
Message-ID: <CAE+3fjZhvpUD+BKcSUrmnsKpmiCR+vhUwZvhkL2X_MPpzwej8Q@mail.gmail.com>

Hello!

On Fri, Jan 17, 2025 at 12:34?PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Ah I see - so you do the full analysis, but when it gets "too slow", you
> suggest to use explicit type parameters. Makes sense.
>
> Now, if you have internal diagnostics on when this happens, and see some
> what code triggered it, it might be useful to report bugs -- so that we
> make sure that we avoid all the performance potholes we can avoid.
>

Unfortunately, asking users to submit snippets of their code in any
automated or semi-automated way is a very sensitive area. If a user agrees
to send anonymous statistics to us, we may see how often a particular
warning is triggered, and how often a quick-fix is applied, but we don't
see which code exactly triggered it.
Probably more reasonable approach would be to crawl open code repositories
like GitHub and find the files where the problem appears.

With best regards,
Tagir Valeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250117/60e5cf09/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Fri Jan 17 11:44:45 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 17 Jan 2025 11:44:45 +0000
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAE+3fjZhvpUD+BKcSUrmnsKpmiCR+vhUwZvhkL2X_MPpzwej8Q@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
 <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
 <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
 <4b32845f-2f53-4510-b6b0-32b89d639024@oracle.com>
 <CAE+3fjZhvpUD+BKcSUrmnsKpmiCR+vhUwZvhkL2X_MPpzwej8Q@mail.gmail.com>
Message-ID: <04d0b8c3-f109-4632-a8bb-3abbe6af612b@oracle.com>

Apologies, I should have been clearer - I meant if you have internal use 
cases (within Jetbrains code) where you observed this problem.

Maurizio

On 17/01/2025 11:39, Tagir Valeev wrote:
> Hello!
>
> On Fri, Jan 17, 2025 at 12:34?PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Ah I see - so you do the full analysis, but when it gets "too
>     slow", you suggest to use explicit type parameters. Makes sense.
>
>     Now, if you have internal diagnostics on when this happens, and
>     see some what code triggered it, it might be useful to report bugs
>     -- so that we make sure that we avoid all the performance potholes
>     we can avoid.
>
>
> Unfortunately, asking users to submit snippets of their code in any 
> automated or semi-automated way is a very sensitive area. If a user 
> agrees to send anonymous statistics to us, we may see how often a 
> particular warning is triggered, and how often a quick-fix is applied, 
> but we don't see which code exactly triggered it.
> Probably more reasonable approach would be to crawl open code 
> repositories like GitHub and find the files where the problem appears.
>
> With best regards,
> Tagir Valeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250117/5dc3a0e6/attachment.htm>

From jlahoda at openjdk.org  Fri Jan 17 18:27:05 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 Jan 2025 18:27:05 GMT
Subject: RFR: 8347989: Trees.getScope may crash for not-yet attributed source
Message-ID: <YKrhqZxANO20M1DXIF-2MwPKIAFbOeMBJ6ruvKuZjP8=.eb266810-cb9f-4a80-b194-49856a3a4d3b@github.com>

Consider code like this:

class Test {
    private int test(boolean b) {
        int v = b ? test(!b) : 0;
        return v;
    }
}


and consider `Trees.getScope` being called for a `TreePath` corresponding to "return" after the "enter" phase, but before `Attr`. E.g. from an annotation processor. This will lead to an exception like:


Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.accept(com.sun.tools.javac.code.Type$Visitor, Object)" because "t" is null
at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4936)
at jdk.compiler/com.sun.tools.javac.code.Types.memberType(Types.java:2306)
at jdk.compiler/com.sun.tools.javac.comp.Attr.isBooleanOrNumeric(Attr.java:2133)
at jdk.compiler/com.sun.tools.javac.comp.Attr.isBooleanOrNumeric(Attr.java:2122)
at jdk.compiler/com.sun.tools.javac.comp.Attr.visitConditional(Attr.java:2060)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCConditional.accept(JCTree.java:1580)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:723)
at jdk.compiler/com.sun.tools.javac.comp.Attr.visitVarDef(Attr.java:1320)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1066)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:751)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:770)
at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1454)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1136)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:515)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribToTree(Attr.java:428)
at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStatToTree(Attr.java:421)
at jdk.compiler/com.sun.tools.javac.api.JavacTrees.attribStatToTree(JavacTrees.java:882)
at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getAttrContext(JavacTrees.java:857)
at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:723)
at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:159)


The reason is that the `Attr.isBooleanOrNumeric` in this case will refer to `env.encClass.type`, but the type of the enclosing class is filled at the end of `Attr.visitClassDef`. So, the `Trees.getScope` running before `Attr` cannot use it.

The proposal in this PR is to set the `JCClassDecl`'s type (also) in `Enter`.

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

Commit messages:
 - Improving test.
 - 8347989: Trees.getScope may crash for not-yet attributed source

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

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

From jlu at openjdk.org  Fri Jan 17 22:34:45 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Jan 2025 22:34:45 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
Message-ID: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>

Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.

Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.

Once this pull request is integrated, it will be back-ported to the jdk24 branch.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/23184/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23184&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347498
  Stats: 93 lines in 26 files changed: 33 ins; 15 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/23184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23184/head:pull/23184

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

From dnguyen at openjdk.org  Fri Jan 17 22:41:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Jan 2025 22:41:36 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <vW6Cbq7Z47TFE_-9aF9zQJhpIa16s7fCp6Awnt7sKZM=.7efd9002-afdb-4450-af48-923bc4e1a137@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 80:

> 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden
> 79: err.empty.module.path=Kein Modul im Modulpfad "{0}" mit --add-modules ALL-MODULE-PATH gefunden
> 80: err.limit.modules=--limit-modules nicht mit --add-modules ALL-MODULE-PATH zul?ssig

I see German has more being changed when compared to Japanese & Chinese. Are these updated translations for German specifically? I see no related change for the other 2 languages for say `err.runtime.link.not.linkable.runtime`.

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 60:

> 58: main.opt.target-platform.arg=target-platform
> 59: main.opt.module-path=Modulpfad
> 60: main.opt.hash-modules=Berechnet und erfasst Hashes zur Bindung eines verpackten Moduls an Module, die dem angegebenen <Regex-Muster> entsprechen und direkt oder indirekt davon abh?ngen. Die Hashes werden in der erstellten JMOD-Datei oder in einer JMOD- oder modularen JAR-Datei in dem Modulpfad erfasst, der im jmod-Hashbefehl angegeben ist.

I assume this is more evidence that the German differences are just updated translations for German?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920837067
PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920837417

From jlu at openjdk.org  Fri Jan 17 22:44:36 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Jan 2025 22:44:36 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <vW6Cbq7Z47TFE_-9aF9zQJhpIa16s7fCp6Awnt7sKZM=.7efd9002-afdb-4450-af48-923bc4e1a137@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <vW6Cbq7Z47TFE_-9aF9zQJhpIa16s7fCp6Awnt7sKZM=.7efd9002-afdb-4450-af48-923bc4e1a137@github.com>
Message-ID: <S15S8zoEX66JpckRXKzyANXC9_xmN_7Ci3br_FellUE=.ff5d4ea4-81be-49f8-8e1f-4ec7bad532f2@github.com>

On Fri, 17 Jan 2025 22:37:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
>> 
>> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
>> 
>> Once this pull request is integrated, it will be back-ported to the jdk24 branch.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 80:
> 
>> 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden
>> 79: err.empty.module.path=Kein Modul im Modulpfad "{0}" mit --add-modules ALL-MODULE-PATH gefunden
>> 80: err.limit.modules=--limit-modules nicht mit --add-modules ALL-MODULE-PATH zul?ssig
> 
> I see German has more being changed when compared to Japanese & Chinese. Are these updated translations for German specifically? I see no related change for the other 2 languages for say `err.runtime.link.not.linkable.runtime`.

Yes, see the other comment.

> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 60:
> 
>> 58: main.opt.target-platform.arg=target-platform
>> 59: main.opt.module-path=Modulpfad
>> 60: main.opt.hash-modules=Berechnet und erfasst Hashes zur Bindung eines verpackten Moduls an Module, die dem angegebenen <Regex-Muster> entsprechen und direkt oder indirekt davon abh?ngen. Die Hashes werden in der erstellten JMOD-Datei oder in einer JMOD- oder modularen JAR-Datei in dem Modulpfad erfasst, der im jmod-Hashbefehl angegeben ist.
> 
> I assume this is more evidence that the German differences are just updated translations for German?

Yes, there were standalone German translation updates. Some were also reverts to fixes we made last time for German translations specifically, as they were rejected by the translation team. In any case, I think it is probably best not to deviate from their translations unless they are incorrect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920839939
PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920839823

From vromero at openjdk.org  Fri Jan 17 22:56:36 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 17 Jan 2025 22:56:36 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v6]
In-Reply-To: <RyA4Emfg3EdHf1WQ27sAVxLGafNS1la25hRT575VYIE=.b406a03c-9d09-437a-815a-dc7334cadb50@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
 <RyA4Emfg3EdHf1WQ27sAVxLGafNS1la25hRT575VYIE=.b406a03c-9d09-437a-815a-dc7334cadb50@github.com>
Message-ID: <L_xboXuAofpcIxU4iVo3EQ1TwN74qFcKpHgwZwT4aRM=.8266e2ae-36a2-4e0f-9557-3a806df1ab46@github.com>

On Thu, 16 Jan 2025 23:25:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
>> 
>> Please see the follow-up comment for a more complete description (trying to keep the first comment short).
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert extraneous changes to Lint.java.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23056#pullrequestreview-2560115008

From dnguyen at openjdk.org  Fri Jan 17 22:56:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Jan 2025 22:56:36 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <wzbQb16K2_C6WducyAq3D28ckT5yZlnZUGePdQltjxc=.830520af-1615-410a-9a11-c8e7c4e4f561@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

File changes LGTM.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2560114901

From dnguyen at openjdk.org  Fri Jan 17 22:56:37 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Jan 2025 22:56:37 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <S15S8zoEX66JpckRXKzyANXC9_xmN_7Ci3br_FellUE=.ff5d4ea4-81be-49f8-8e1f-4ec7bad532f2@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <vW6Cbq7Z47TFE_-9aF9zQJhpIa16s7fCp6Awnt7sKZM=.7efd9002-afdb-4450-af48-923bc4e1a137@github.com>
 <S15S8zoEX66JpckRXKzyANXC9_xmN_7Ci3br_FellUE=.ff5d4ea4-81be-49f8-8e1f-4ec7bad532f2@github.com>
Message-ID: <t4YFMHLLuaHcCo0p3vWW3HOWrxBdadkgIY9f1JKFEHg=.a354e488-586c-407b-aac4-7b83c2c1e77d@github.com>

On Fri, 17 Jan 2025 22:42:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 60:
>> 
>>> 58: main.opt.target-platform.arg=target-platform
>>> 59: main.opt.module-path=Modulpfad
>>> 60: main.opt.hash-modules=Berechnet und erfasst Hashes zur Bindung eines verpackten Moduls an Module, die dem angegebenen <Regex-Muster> entsprechen und direkt oder indirekt davon abh?ngen. Die Hashes werden in der erstellten JMOD-Datei oder in einer JMOD- oder modularen JAR-Datei in dem Modulpfad erfasst, der im jmod-Hashbefehl angegeben ist.
>> 
>> I assume this is more evidence that the German differences are just updated translations for German?
>
> Yes, there were standalone German translation updates. Some were also reverts to fixes we made last time for German translations specifically, as they were rejected by the translation team. In any case, I think it is probably best not to deviate from their translations unless they are incorrect.

Makes sense. I agree then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920847170

From naoto at openjdk.org  Fri Jan 17 23:08:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Jan 2025 23:08:35 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <tjj19a1sh5zZ5HB6WS5y3hk7hC6qP1Ikeq80S4uFXVM=.8aa61a27-8003-4abc-a637-6fc501c7da2c@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

Should the copyright years be 2025, unless they were *published* in 2024?

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

PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599351096

From jlu at openjdk.org  Fri Jan 17 23:21:35 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Jan 2025 23:21:35 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <3jNTKD4ifvL8RtWl-nr2Jl_QjSv4ohkQnjf2MMo-M-w=.832c9b8f-0fe4-4851-96ce-89e979f228b4@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

> Should the copyright years be 2025, unless they were _published_ in 2024?

I noticed that too. Those copyrights are automatically updated by the translation team. Since the English changes were made in 2024, it seems reasonable that the corresponding l10n changes also have a copyright year of 2024. Conceptually I'm treating it like a backport, where the copyright year should reflect the year of the original change, not the current year. But these are different cases of course, please let me know if I should change it to 2025, I am not fully sure in this scenario.

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

PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599361579

From dnguyen at openjdk.org  Fri Jan 17 23:21:35 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Jan 2025 23:21:35 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <3jNTKD4ifvL8RtWl-nr2Jl_QjSv4ohkQnjf2MMo-M-w=.832c9b8f-0fe4-4851-96ce-89e979f228b4@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <3jNTKD4ifvL8RtWl-nr2Jl_QjSv4ohkQnjf2MMo-M-w=.832c9b8f-0fe4-4851-96ce-89e979f228b4@github.com>
Message-ID: <P7-jY3r6d17WeGew5fOuSeQGlTHuyfpLcTVt7GM7gnA=.8a044d70-40b9-4cd5-af4d-2e56f846e86b@github.com>

On Fri, 17 Jan 2025 23:18:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Should the copyright years be 2025, unless they were _published_ in 2024?

I saw the same but forgot to mention it after looking up the original files to compare to German. I'm also not sure if this should be 2024 vs 2025. I'd assume 2024 since most of the files say "edited on Dec 2024", but not sure if it's based on the original file's date or this translated file.

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

PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599361641

From naoto at openjdk.org  Fri Jan 17 23:55:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Jan 2025 23:55:37 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <Hi37nQ1j5qZIcQqPIa89XtH7tQrNsBXI9kvOoggoLsQ=.9f9607d7-aefd-413b-885f-e90f85d4bf46@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

IANAL, but my understanding is that it reflects the year the last change was open to the public. It does not seem to matter from copyright point if the file is a translation of English one or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599385743

From acobbs at openjdk.org  Sat Jan 18 00:04:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 18 Jan 2025 00:04:36 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v6]
In-Reply-To: <L_xboXuAofpcIxU4iVo3EQ1TwN74qFcKpHgwZwT4aRM=.8266e2ae-36a2-4e0f-9557-3a806df1ab46@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
 <RyA4Emfg3EdHf1WQ27sAVxLGafNS1la25hRT575VYIE=.b406a03c-9d09-437a-815a-dc7334cadb50@github.com>
 <L_xboXuAofpcIxU4iVo3EQ1TwN74qFcKpHgwZwT4aRM=.8266e2ae-36a2-4e0f-9557-3a806df1ab46@github.com>
Message-ID: <UMcOLICHo1ubw9iGIhzxEmDq5_cs-Z3wABzwtm60NFY=.e0dd0086-7c44-4641-b0f3-28e7d5d6171d@github.com>

On Fri, 17 Jan 2025 22:54:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert extraneous changes to Lint.java.
>
> looks sensible

@vicente-romero-oracle thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23056#issuecomment-2599391865

From acobbs at openjdk.org  Sun Jan 19 14:59:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 19 Jan 2025 14:59:47 GMT
Subject: Integrated: 8347474: Options singleton is used before options are
 parsed
In-Reply-To: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
Message-ID: <ryhEdecO3FNRWGoeOa0MXdnR-4m-tgFKg8Rihgcj13o=.d5129756-9a30-4d57-9128-76a2ecc7438c@github.com>

On Sun, 12 Jan 2025 22:50:14 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR proposes some cleanup/refactoring relating to startup ordering issues in the compiler.
> 
> Please see the follow-up comment for a more complete description (trying to keep the first comment short).

This pull request has now been integrated.

Changeset: 644d154c
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/644d154c7c771236904560fc5b91f149a6a646cf
Stats:     434 lines in 16 files changed: 263 ins; 70 del; 101 mod

8347474: Options singleton is used before options are parsed

Reviewed-by: vromero

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

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

From alanb at openjdk.org  Sun Jan 19 15:55:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Jan 2025 15:55:40 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v6]
In-Reply-To: <UMcOLICHo1ubw9iGIhzxEmDq5_cs-Z3wABzwtm60NFY=.e0dd0086-7c44-4641-b0f3-28e7d5d6171d@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
 <RyA4Emfg3EdHf1WQ27sAVxLGafNS1la25hRT575VYIE=.b406a03c-9d09-437a-815a-dc7334cadb50@github.com>
 <L_xboXuAofpcIxU4iVo3EQ1TwN74qFcKpHgwZwT4aRM=.8266e2ae-36a2-4e0f-9557-3a806df1ab46@github.com>
 <UMcOLICHo1ubw9iGIhzxEmDq5_cs-Z3wABzwtm60NFY=.e0dd0086-7c44-4641-b0f3-28e7d5d6171d@github.com>
Message-ID: <Pt_DEvME2IYd1YLJjqdD-WA5P_M7ftg2L70t8M7vVjI=.a751a106-14b6-415f-afa8-859ddda3ff3c@github.com>

On Sat, 18 Jan 2025 00:02:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> looks sensible
>
> @vicente-romero-oracle thanks for the review!

@archiecobbs Can you check the docs build is s working for you? We seems to have breakage, see
[JDK-8348038](https://bugs.openjdk.org/browse/JDK-8348038).

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

PR Comment: https://git.openjdk.org/jdk/pull/23056#issuecomment-2600919945

From acobbs at openjdk.org  Sun Jan 19 16:46:40 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 19 Jan 2025 16:46:40 GMT
Subject: RFR: 8347474: Options singleton is used before options are parsed
 [v6]
In-Reply-To: <Pt_DEvME2IYd1YLJjqdD-WA5P_M7ftg2L70t8M7vVjI=.a751a106-14b6-415f-afa8-859ddda3ff3c@github.com>
References: <MPiLnVM_m7pTL1d16Xn83mN9y3PkJqn3d1Y8J5o8HhM=.d6a34e1f-8830-4833-b7fc-8da588c5c303@github.com>
 <RyA4Emfg3EdHf1WQ27sAVxLGafNS1la25hRT575VYIE=.b406a03c-9d09-437a-815a-dc7334cadb50@github.com>
 <L_xboXuAofpcIxU4iVo3EQ1TwN74qFcKpHgwZwT4aRM=.8266e2ae-36a2-4e0f-9557-3a806df1ab46@github.com>
 <UMcOLICHo1ubw9iGIhzxEmDq5_cs-Z3wABzwtm60NFY=.e0dd0086-7c44-4641-b0f3-28e7d5d6171d@github.com>
 <Pt_DEvME2IYd1YLJjqdD-WA5P_M7ftg2L70t8M7vVjI=.a751a106-14b6-415f-afa8-859ddda3ff3c@github.com>
Message-ID: <qUvv3PDPa5YOKBksr0kSvsZsPH7fRKPodKOl8Uahxm4=.1164003a-35df-43a3-ad16-9b51c0be8d96@github.com>

On Sun, 19 Jan 2025 15:52:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @vicente-romero-oracle thanks for the review!
>
> @archiecobbs Can you check the docs build is s working for you? We seems to have breakage, see
> [JDK-8348038](https://bugs.openjdk.org/browse/JDK-8348038).

@AlanBateman my fault - thanks for the heads-up. I will fix (and also add "docs" to my standard list of things to build check!)

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

PR Comment: https://git.openjdk.org/jdk/pull/23056#issuecomment-2600937336

From acobbs at openjdk.org  Sun Jan 19 18:43:43 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 19 Jan 2025 18:43:43 GMT
Subject: RFR: 8348038: Docs build failing in Options.notifyListeners with
 AssertionError
Message-ID: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>

The change in [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474) caused `make all-docs-bundles` to start failing.

This PR includes a fix, however, the new regression test included with this PR does not actually generate a failure on the current `master` (I haven't yet figured out a way to reproduce the failure in a unit test).

So that will need to be fixed before this PR is applied. However the included fix should still be usable for anyone needing to fix the build in the meantime.

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

Commit messages:
 - Robustify JavacFileManager vs. Options initialization order.

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

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

From acobbs at openjdk.org  Sun Jan 19 20:49:23 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 19 Jan 2025 20:49:23 GMT
Subject: RFR: 8348038: Docs build failing in Options.notifyListeners with
 AssertionError [v2]
In-Reply-To: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
References: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
Message-ID: <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>

> The change in [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474) caused `make all-docs-bundles` to start failing. This PR includes a fix for that.

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

  Replace previous unit test with one that fails before the fix.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23192/files
  - new: https://git.openjdk.org/jdk/pull/23192/files/7ca14398..6f780aed

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

  Stats: 62 lines in 2 files changed: 50 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23192/head:pull/23192

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

From jlahoda at openjdk.org  Mon Jan 20 09:21:42 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Jan 2025 09:21:42 GMT
Subject: RFR: 8348038: Docs build failing in Options.notifyListeners with
 AssertionError [v2]
In-Reply-To: <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>
References: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
 <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>
Message-ID: <_NMpd9cmDNX6SrGjb4UNw3_kk8O0BX6Gmc6yuoaLvBY=.4a8b0dd3-b48b-48db-8b3b-9f61defc0e0c@github.com>

On Sun, 19 Jan 2025 20:49:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The change in [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474) caused `make all-docs-bundles` to start failing. This PR includes a fix for that.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace previous unit test with one that fails before the fix.

I think this is OK in order to fix the broken build quickly. But, the handling of the symbol files for javadoc appears to be quite convoluted, as `ToolEnvironment` hard-disables the symbol file anyway:
https://github.com/openjdk/jdk/blob/4b4b1e912a3193cc95c956acc770015f707449b1/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java#L145

It would probably be good to file a followup cleanup task to seem if we can do something nicer/better/cleaner.

(FWIW, I've submitted a build with this change, but it will probably take some time before it finishes.)

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23192#pullrequestreview-2561788410
PR Comment: https://git.openjdk.org/jdk/pull/23192#issuecomment-2601849837

From mcimadamore at openjdk.org  Mon Jan 20 09:21:43 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 Jan 2025 09:21:43 GMT
Subject: RFR: 8348038: Docs build failing in Options.notifyListeners with
 AssertionError [v2]
In-Reply-To: <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>
References: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
 <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>
Message-ID: <TzU64gB30TEfAbocSxkRn77RaTWXL2jE5AdoHErlSq4=.e82cc23c-c0bf-4dd9-b180-7f48b43ff3dd@github.com>

On Sun, 19 Jan 2025 20:49:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The change in [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474) caused `make all-docs-bundles` to start failing. This PR includes a fix for that.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace previous unit test with one that fails before the fix.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23192#pullrequestreview-2561788934

From jlahoda at openjdk.org  Mon Jan 20 12:04:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Jan 2025 12:04:36 GMT
Subject: RFR: 8348038: Docs build failing in Options.notifyListeners with
 AssertionError [v2]
In-Reply-To: <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>
References: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
 <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>
Message-ID: <CjhWmZwjX1qO0OW9WNa0YwStsN2EzEqZJqb3gwuF_Tk=.fc5673e6-22fb-4922-9d43-6aff6bc56b90@github.com>

On Sun, 19 Jan 2025 20:49:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The change in [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474) caused `make all-docs-bundles` to start failing. This PR includes a fix for that.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace previous unit test with one that fails before the fix.

The build (tier1-3) finished and didn't reveal any problems that would seem relevant to this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/23192#issuecomment-2602240103

From acobbs at openjdk.org  Mon Jan 20 14:22:41 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 20 Jan 2025 14:22:41 GMT
Subject: RFR: 8348038: Docs build failing in Options.notifyListeners with
 AssertionError [v2]
In-Reply-To: <CjhWmZwjX1qO0OW9WNa0YwStsN2EzEqZJqb3gwuF_Tk=.fc5673e6-22fb-4922-9d43-6aff6bc56b90@github.com>
References: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
 <BFPs0fx3KZGXMFJK78NBu8I161I_z71l6f7z7ikS41s=.09ecb9a3-ee04-4764-8c01-e6cd72860cef@github.com>
 <CjhWmZwjX1qO0OW9WNa0YwStsN2EzEqZJqb3gwuF_Tk=.fc5673e6-22fb-4922-9d43-6aff6bc56b90@github.com>
Message-ID: <xBGzybNp5Azj0ECj6lHuk7DUGdZv1y9nttIQ4DhCWLA=.8d0ff5fa-67e8-45f6-8511-13191d9e1788@github.com>

On Mon, 20 Jan 2025 12:01:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace previous unit test with one that fails before the fix.
>
> The build (tier1-3) finished and didn't reveal any problems that would seem relevant to this patch.

@lahodaj and @mcimadamore - thanks for the assistance and quick reviews!

FWIW the regression test in version 6f780aeddc does now fail on the previous master now (duh, I just needed to compare the output instead of the exit value).

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

PR Comment: https://git.openjdk.org/jdk/pull/23192#issuecomment-2602544826

From acobbs at openjdk.org  Mon Jan 20 14:22:42 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 20 Jan 2025 14:22:42 GMT
Subject: Integrated: 8348038: Docs build failing in Options.notifyListeners
 with AssertionError
In-Reply-To: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
References: <Le7ZkMKX2sm37JVh2smZbp2eWjElXDqqWlaVU3S-iAE=.693e0d5a-b5ab-44a9-a541-f5699879ebe1@github.com>
Message-ID: <RgnnEIfBAGlhKKgdCz7ADsPbozeC2rceQuQ7e3jJ6RQ=.d191b0f0-dc35-4afd-94a9-84faa0667701@github.com>

On Sun, 19 Jan 2025 18:38:57 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The change in [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474) caused `make all-docs-bundles` to start failing. This PR includes a fix for that.

This pull request has now been integrated.

Changeset: 0fbf10a9
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0fbf10a9cf51d01d82cd43cf0edfaeee83313a9c
Stats:     73 lines in 3 files changed: 62 ins; 3 del; 8 mod

8348038: Docs build failing in Options.notifyListeners with AssertionError

Reviewed-by: jlahoda, mcimadamore

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

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

From pyltsinm at gmail.com  Mon Jan 20 18:35:31 2025
From: pyltsinm at gmail.com (Mikhail Pyltsin)
Date: Mon, 20 Jan 2025 19:35:31 +0100
Subject: Running static main method inside abstract class, containing another
 main method
Message-ID: <CAOo1M===7MR0XaOxy_53ffExEg0qzeUwpAk_hB=0YZsPcMzFPg@mail.gmail.com>

Hi!
Sorry, I am not sure that it is a correct channel, but probably, it is
related to jep specification.
I am investigating a new version of  jep495
(
https://cr.openjdk.org/~gbierman/jep495/jep495-20241101/specs/simple-source-files-instance-main-methods-jls.html#jls-12.1.3
)
and came up with such an example:
```java
public abstract class AbstractClass {
    public static void main() {
        System.out.println("Hello, World!");
    }

    public void main(String[] args) {
        System.out.println("Hello, World! no constructor, non-static,
args");
    }
}
```
Right now java chooses `void main(String[] args) ` because it contains
argument, but cannot create this class, because it is abstract,
I have got this error: `Exception in thread "main"
java.lang.InstantiationException: AbstractClass`
Could you help me if this is expected? I expect that `public static void
main()` will be chosen.

I cannot find anything related to this in JEP except this one:
`The behavior of an implementation if there is no candidate method to
invoke, or if there is no suitable constructor in the initial class when
invoking an instance candidate method, is beyond the scope of this
specification.', but it doesn't contain this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250120/bbd81355/attachment.htm>

From forax at univ-mlv.fr  Mon Jan 20 18:43:08 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 20 Jan 2025 19:43:08 +0100 (CET)
Subject: Running static main method inside abstract class, containing
 another main method
In-Reply-To: <CAOo1M===7MR0XaOxy_53ffExEg0qzeUwpAk_hB=0YZsPcMzFPg@mail.gmail.com>
References: <CAOo1M===7MR0XaOxy_53ffExEg0qzeUwpAk_hB=0YZsPcMzFPg@mail.gmail.com>
Message-ID: <1071501370.70013144.1737398588875.JavaMail.zimbra@univ-eiffel.fr>

Hello, 
wrong mailing list, 

If you take a look to the header of JEP 495 
[ https://openjdk.org/jeps/495 | https://openjdk.org/jeps/495 ] 
the right mailing list is "amber dash dev at openjdk dot org" 

regards, 
R?mi 

> From: "Mikhail Pyltsin" <pyltsinm at gmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Monday, January 20, 2025 7:35:31 PM
> Subject: Running static main method inside abstract class, containing another
> main method

> Hi!
> Sorry, I am not sure that it is a correct channel, but probably, it is related
> to jep specification.
> I am investigating a new version of jep495
> ( [
> https://cr.openjdk.org/~gbierman/jep495/jep495-20241101/specs/simple-source-files-instance-main-methods-jls.html#jls-12.1.3
> |
> https://cr.openjdk.org/~gbierman/jep495/jep495-20241101/specs/simple-source-files-instance-main-methods-jls.html#jls-12.1.3
> ] )
> and came up with such an example:
> ```java
> public abstract class AbstractClass {
> public static void main() {
> System.out.println("Hello, World!");
> }

> public void main(String[] args) {
> System.out.println("Hello, World! no constructor, non-static, args");
> }
> }
> ```
> Right now java chooses `void main(String[] args) ` because it contains argument,
> but cannot create this class, because it is abstract,
> I have got this error: `Exception in thread "main"
> java.lang.InstantiationException: AbstractClass`
> Could you help me if this is expected? I expect that `public static void main()`
> will be chosen.

> I cannot find anything related to this in JEP except this one:
> `The behavior of an implementation if there is no candidate method to invoke, or
> if there is no suitable constructor in the initial class when invoking an
> instance candidate method, is beyond the scope of this specification.', but it
> doesn't contain this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250120/d6d3d300/attachment.htm>

From syan at openjdk.org  Tue Jan 21 09:23:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 21 Jan 2025 09:23:47 GMT
Subject: [jdk24] RFR: 8343882: BasicAnnoTests doesn't handle multiple
 annotations at the same position
In-Reply-To: <qFxT51lsTVhqTbTnIP3qLP0L9STJQExXRBw3Gv0cV8s=.c2c6752f-dd73-4dc9-8676-f75457d44b82@github.com>
References: <qFxT51lsTVhqTbTnIP3qLP0L9STJQExXRBw3Gv0cV8s=.c2c6752f-dd73-4dc9-8676-f75457d44b82@github.com>
Message-ID: <5wXgKJCmx1hZCLzZMBHzQzemi4NGFPk06yFufDd-GCw=.92896a80-904b-45d1-9878-e9d0c4844d17@github.com>

On Tue, 24 Dec 2024 06:11:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d562d3c7](https://github.com/openjdk/jdk/commit/d562d3c7a9e1e857c095ef908b0957b033972949) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. Test-fix only, no risk.
> 
> The commit being backported was authored by Liam Miller-Cushon on 20 Dec 2024 and was reviewed by Joe Darcy.
> 
> Thanks!

Clean backport to fix the test bug which may cause test can not catch the expected failure, test-fix only, no risk.

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

PR Comment: https://git.openjdk.org/jdk/pull/22875#issuecomment-2604132820

From dawid.weiss at gmail.com  Tue Jan 21 12:38:09 2025
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Tue, 21 Jan 2025 06:38:09 -0600
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
 <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
 <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
Message-ID: <CAM21Rt96OuWW2iS9b5yjOLd9dtRsBQF-8PJa4okhySAQK0A5zw@mail.gmail.com>

> This is a performance problem for IntelliJ as well. Highlighting becomes slow on such code. Not sure whether it's slower or faster than javac, but it's definitely slow. So technically, it's 'javac + IntelliJ quirks' :-)

I can add ecj to this: "javac" + "intellij" + "Eclipse ecj" quirks
because I've tried out of curiosity and ecj also grinds to a halt on
this pattern.

Oh well, thanks for the interesting discussion. I've learnt something new.

Dawid

From maurizio.cimadamore at oracle.com  Tue Jan 21 14:11:11 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 21 Jan 2025 14:11:11 +0000
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAM21Rt96OuWW2iS9b5yjOLd9dtRsBQF-8PJa4okhySAQK0A5zw@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
 <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
 <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
 <CAM21Rt96OuWW2iS9b5yjOLd9dtRsBQF-8PJa4okhySAQK0A5zw@mail.gmail.com>
Message-ID: <e42a15e8-107c-4901-b33a-091948fc2d0a@oracle.com>


On 21/01/2025 12:38, Dawid Weiss wrote:
>> This is a performance problem for IntelliJ as well. Highlighting becomes slow on such code. Not sure whether it's slower or faster than javac, but it's definitely slow. So technically, it's 'javac + IntelliJ quirks' :-)
> I can add ecj to this: "javac" + "intellij" + "Eclipse ecj" quirks
> because I've tried out of curiosity and ecj also grinds to a halt on
> this pattern.
>
> Oh well, thanks for the interesting discussion. I've learnt something new.

I'm not surprised (but thanks for reporting). In the sense that this is 
not really a "bug" but more of the JLS being defined this way.

As I said, when you have nested method calls, are inference variables 
are accumulated in the outermost call, so that the target-type can 
influence even deeply nested inference variables.

Then we run a process known as "incorporation", where we look at the 
bounds of the inference variables and keep deriving new bounds. For 
instance:

* if an inference variable alpha has bounds alpha <: S and T <: alpha, 
we automatically generate the test T <: S, which might result in 
additional constraints
* if an inference variable beta has two upper bounds like beta <: C<S> 
and beta <: C<T>, we generate the test S == T, which might result in 
additional constraints

All this has to repeat every time a new constraint is added, and until 
no more constraints can be derived. Which is why the cost of the 
algorithm grows exponentially with the number of inference variables.

Consequently, the only hope a compiler has is to cut down on the number 
of required inference variables. We have already implemented, with 
success, logic to detect that e.g. multiple inference variable formed an 
equivalence set (e.g. alpha == beta == gamma) - in which case we can 
safely pick one of them (after, of course, we made sure to copy all the 
bounds from other variables in the set).

In this case the problem has more to do with many inference variables 
having the same constraints (meaning they will be resolved in exactly 
the same way). We are hopeful a some solution for this problem is also 
possible, but this one looks a little harder as we can't rely on 
inference variables being the "same" (because of == constraints). 
Instead we'd have to infer "same-ness" based on some other principle.

Cheers
Maurizio

From gavin.bierman at oracle.com  Tue Jan 21 15:34:01 2025
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Tue, 21 Jan 2025 15:34:01 +0000
Subject: Exponential compilation time for List.of(Map.entry) expressions
In-Reply-To: <CAM21Rt96OuWW2iS9b5yjOLd9dtRsBQF-8PJa4okhySAQK0A5zw@mail.gmail.com>
References: <CAM21Rt-aAvrv5mSwLTTJ2cntjUhP_fJ4V76iWESaQBbQrdVkvw@mail.gmail.com>
 <08b30112-05f3-4a20-b9ce-abaed20a5a64@oracle.com>
 <CAE+3fjYhVccg9qFPWwRTzM97-VN1feYvoTc7FH9yKDgYvs=ZKg@mail.gmail.com>
 <067fab7b-7bd5-494d-a6fc-5e8d18a8ef94@oracle.com>
 <CAE+3fjY9OCstcka5TpDKDWWUVE9ijm2rxEqxYp1ZJCV4E8jjZw@mail.gmail.com>
 <CAM21Rt96OuWW2iS9b5yjOLd9dtRsBQF-8PJa4okhySAQK0A5zw@mail.gmail.com>
Message-ID: <8F6AEC73-9E74-46CC-8B2C-56DE2A8DC341@oracle.com>

FWIW There?s extensive research on the complexity of similar type inference problems. For example, the essence of the ML type inference problem (this is the one that inspired most similar "type inference in the presence of generic types" problems, including Java?s) was shown to be doubly-exponential (yikes!) although in most cases that can be cut down a lot. Here's an interesting survey article if you want to learn more:

http://gallium.inria.fr/~fpottier/publis/emlti-final.pdf

Gavin


On 21 Jan 2025, at 12:38, Dawid Weiss <dawid.weiss at gmail.com> wrote:

This is a performance problem for IntelliJ as well. Highlighting becomes slow on such code. Not sure whether it's slower or faster than javac, but it's definitely slow. So technically, it's 'javac + IntelliJ quirks' :-)

I can add ecj to this: "javac" + "intellij" + "Eclipse ecj" quirks
because I've tried out of curiosity and ecj also grinds to a halt on
this pattern.

Oh well, thanks for the interesting discussion. I've learnt something new.

Dawid

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250121/486bfaa8/attachment-0001.htm>

From jlu at openjdk.org  Tue Jan 21 18:05:35 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 21 Jan 2025 18:05:35 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <Hi37nQ1j5qZIcQqPIa89XtH7tQrNsBXI9kvOoggoLsQ=.9f9607d7-aefd-413b-885f-e90f85d4bf46@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <Hi37nQ1j5qZIcQqPIa89XtH7tQrNsBXI9kvOoggoLsQ=.9f9607d7-aefd-413b-885f-e90f85d4bf46@github.com>
Message-ID: <ugyg9mye7vHyPwm28jtyJ2gwb838iCgaQuod4nwFwo4=.5e9eec71-346c-4898-bb1e-f5c9932b85ed@github.com>

On Fri, 17 Jan 2025 23:53:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> IANAL, but my understanding is that it reflects the year the last change was open to the public. It does not seem to matter from copyright point if the file is a translation of English one or not.

While that has been my understanding as well, for L10n specifically we have always reflected the original English file year in the localized copyright. For example, I believe most (if not all) of the other files included in this PR have a 2024 copyright years, not just those .java XML files. I am fine if we make this switch, but it will be a departure from how we have normally done it for the L10n process.

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

PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2605409150

From naoto at openjdk.org  Tue Jan 21 18:31:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Jan 2025 18:31:37 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <XHqcwQVrXb67ybFzs807BkQJpWbUhnM49wzZRQhFGk8=.bc3e22b0-890e-45ea-96e4-24cdf9455fe4@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

> While that has been my understanding as well, for L10n specifically we have always reflected the original English file year in the localized copyright

Yes. I think it is probably time to assure it really is the case. Since we are following the procedure, I approve the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2565411176

From joehw at openjdk.org  Tue Jan 21 19:15:38 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 21 Jan 2025 19:15:38 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <qYkpFXSjbqLeC4QMqsbxKUREnzSqi0Zfs1JiDUqABt0=.9116be83-a8bf-4a9e-990a-dd437ba93214@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

java.xml changes look good.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2565493674

From archie.cobbs at gmail.com  Tue Jan 21 23:35:30 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 21 Jan 2025 17:35:30 -0600
Subject: How do you "make everything"?
In-Reply-To: <ca4563c1-fb87-48e2-aca7-5fd4991af9b8@oracle.com>
References: <CANSoFxs1Wdm+bS4-c2CE6unBNY4y6H=CUSW22ZTaKMdSe6bJXQ@mail.gmail.com>
 <e78254d5-2bbb-4a17-a21b-7526e2972e9e@amazon.de>
 <CANSoFxv0wpGbfuft=+W-byhAe6Fv8227KQpXyTbZ1Y6BwWfViA@mail.gmail.com>
 <ca4563c1-fb87-48e2-aca7-5fd4991af9b8@oracle.com>
Message-ID: <CANSoFxt=-9XGDweoo5EozhTQRY1MPALBOYAcJBYQr4bmK8M0Fw@mail.gmail.com>

Hi Magnus,

Thanks for the info - very helpful.

Funny that just a week or two after posting this question, I was bit by the
very problem described... the fix for JDK-8344148
<https://bugs.openjdk.org/browse/JDK-8348038> passed all of the GitHub
actions and all my standard "compiler proving ground" build targets. But
there was one target that was not included in that list, and it was
failing: all-docs-bundles. D'oh!

So I've added it to my list...

make
make test TEST="langtools_javac"
make hotspot
make static-libs-bundles
make product-bundles
make test-bundles
make bootcycle-images
make all-docs-bundles

Magnus do you think this list could be worth capturing as a new makefile
target, e.g., "javac-proving-ground" or somesuch?

Thanks,
-Archie

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

From dholmes at openjdk.org  Wed Jan 22 00:28:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 00:28:34 GMT
Subject: RFR: 8348203: [JVMCI] Make eager JVMCI initialization observable
 in the debugger
In-Reply-To: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
Message-ID: <ADZVy3-WvySRy1VLSyhyqUXNfC2MAx3ZFl1HSjTj2Oo=.909771b3-a06b-4e79-92e4-720e0aa1daee@github.com>

On Tue, 21 Jan 2025 16:59:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> I realized that I can't debug (i.e. with a Java debugger) the Graal compiler initialization if it happens eagerly (e.g. with `EagerJVMCI`, `JVMCIPrintProperties`, `JVMCILibDumpJNIConfig`). Not that this is something I need every day, but I think it can easily be fixed by moving the early initializing a little further down, right after `JvmtiExport::post_vm_initialized()`:
> 
> 
>  diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp
> index 1cab9bc5d53..191409c22e3 100644
> --- a/src/hotspot/share/runtime/threads.cpp
> +++ b/src/hotspot/share/runtime/threads.cpp
> @@ -806,12 +806,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    }
>  #endif
>  
> -#if INCLUDE_JVMCI
> - if (force_JVMCI_initialization) {
> - JVMCI::initialize_compiler(CHECK_JNI_ERR);
> - }
> -#endif
> -
>    if (NativeHeapTrimmer::enabled()) {
>      NativeHeapTrimmer::initialize();
>    }
> @@ -826,6 +820,12 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    // Notify JVMTI agents that VM initialization is complete - nop if no agents.
>    JvmtiExport::post_vm_initialized();
>  
> +#if INCLUDE_JVMCI
> + if (force_JVMCI_initialization) {
> + JVMCI::initialize_compiler(CHECK_JNI_ERR);
> + }
> +#endif
> +
>    JFR_ONLY(Jfr::on_create_vm_3();)
>  
>  #if INCLUDE_MANAGEMENT

It is not at all obvious what other impacts moving this could have. Is it really appropriate to enter the live phase and claim the VM is initialized if we may error out if JVMCI initialization fails after that point.

What prevents you from doing the debugging you want to do? And why are you "debugging" Graal compiler initialization anyway?

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

PR Review: https://git.openjdk.org/jdk/pull/23219#pullrequestreview-2565944946

From acobbs at openjdk.org  Wed Jan 22 03:12:12 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 22 Jan 2025 03:12:12 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148
Message-ID: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>

In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.

However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.

This PR adds the missing `warn()` calls.

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

Commit messages:
 - Add missing warn() pass to sequential compiler steps.

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

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

From simonis at openjdk.org  Wed Jan 22 14:52:29 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 22 Jan 2025 14:52:29 GMT
Subject: RFR: 8348203: [JVMCI] Make eager JVMCI initialization observable
 in the debugger
In-Reply-To: <ADZVy3-WvySRy1VLSyhyqUXNfC2MAx3ZFl1HSjTj2Oo=.909771b3-a06b-4e79-92e4-720e0aa1daee@github.com>
References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
 <ADZVy3-WvySRy1VLSyhyqUXNfC2MAx3ZFl1HSjTj2Oo=.909771b3-a06b-4e79-92e4-720e0aa1daee@github.com>
Message-ID: <wsgUGHgiMIP4MX-GqD1zMpgCJ4J5kmFQhmpgFulvTRY=.1e0ec113-a00e-4842-894a-367f3b9274a0@github.com>

On Wed, 22 Jan 2025 00:25:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> It is not at all obvious what other impacts moving this could have. Is it really appropriate to enter the live phase and claim the VM is initialized if we may error out if JVMCI initialization fails after that point.
> 

Yes, because that's the normal case. Usually, JVMCI gets initialized lazily, before its first usage which is much after VMInit was posted. We are looking at a special case here because this patch only moves **eager** JVMCI initialization (which happens with `-XX:+EagerJVMCI`, `-XX:+JVMCIPrintProperties` and `-XX:+JVMCILibDumpJNIConfig`) after the VMInit event was posted.

> What prevents you from doing the debugging you want to do? 

Very simple - the debugger is not starting before it gets the VMInit event.
 
> And why are you "debugging" Graal compiler initialization anyway?

Is this a serious question? Because I'm hunting a bug in eager JVMCI initialization.

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

PR Comment: https://git.openjdk.org/jdk/pull/23219#issuecomment-2607443519

From sgehwolf at openjdk.org  Wed Jan 22 17:15:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 22 Jan 2025 17:15:55 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <EeUIB_1CdP1mAK1eegX0CW0dEFK8Kq8aYWBRR8Dd2fY=.1d242cef-ff72-4113-b454-1c7bb280e084@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

I only looked at the jlink changes which look fine to me. Fine to keep with/without the suggestion.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 78:

> 76: err.runtime.link.modified.file={0} wurde ge?ndert
> 77: err.runtime.link.patched.module=jlink unterst?tzt keine Verkn?pfung vom Laufzeitimage unter einer gepatchten Laufzeit mit --patch-module
> 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden

Suggestion:

err.no.module.path=--module-path Option muss mit --add-modules ALL-MODULE-PATH angegeben werden

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2567811411
PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1925680330

From jlu at openjdk.org  Wed Jan 22 18:39:47 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 22 Jan 2025 18:39:47 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <pSXVsoAUQ03Lyqg2eUggTO9JV584xgqgVZz5Kz_Bzig=.b10a7565-7677-4559-9c6c-354442b33de8@github.com>

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

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

  reflect jlink review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23184/files
  - new: https://git.openjdk.org/jdk/pull/23184/files/5ea5ddc9..cc8b23fb

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

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

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

From asemenyuk at openjdk.org  Wed Jan 22 18:39:48 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 22 Jan 2025 18:39:48 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]
In-Reply-To: <pSXVsoAUQ03Lyqg2eUggTO9JV584xgqgVZz5Kz_Bzig=.b10a7565-7677-4559-9c6c-354442b33de8@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <pSXVsoAUQ03Lyqg2eUggTO9JV584xgqgVZz5Kz_Bzig=.b10a7565-7677-4559-9c6c-354442b33de8@github.com>
Message-ID: <m8MTxpkS0smexgEdk01PpdS6rKgFsp-lmLK-YSfoUYk=.6b5974b4-087f-4dc6-8e8e-c32e23fdd8ad@github.com>

On Wed, 22 Jan 2025 18:34:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
>> 
>> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
>> 
>> Once this pull request is integrated, it will be back-ported to the jdk24 branch.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect jlink review

jpackage changes look good.

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2567985117

From jlu at openjdk.org  Wed Jan 22 18:39:49 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 22 Jan 2025 18:39:49 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]
In-Reply-To: <EeUIB_1CdP1mAK1eegX0CW0dEFK8Kq8aYWBRR8Dd2fY=.1d242cef-ff72-4113-b454-1c7bb280e084@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <EeUIB_1CdP1mAK1eegX0CW0dEFK8Kq8aYWBRR8Dd2fY=.1d242cef-ff72-4113-b454-1c7bb280e084@github.com>
Message-ID: <OHBwSsmwc0d3q6EUrHWR6ID3VPTEEw434X1H1L_rnzA=.d168e048-6706-490c-ae77-4bd411428720@github.com>

On Wed, 22 Jan 2025 17:09:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect jlink review
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 78:
> 
>> 76: err.runtime.link.modified.file={0} wurde ge?ndert
>> 77: err.runtime.link.patched.module=jlink unterst?tzt keine Verkn?pfung vom Laufzeitimage unter einer gepatchten Laufzeit mit --patch-module
>> 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden
> 
> Suggestion:
> 
> err.no.module.path=--module-path Option muss mit --add-modules ALL-MODULE-PATH angegeben werden

Fixed it in https://github.com/openjdk/jdk/pull/23184/commits/cc8b23fb9d65a9ea603c6f7576d651f447ac2d5e. The option reads incorrect with "-Option" appended, regardless of language rules.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1925792014

From acobbs at openjdk.org  Wed Jan 22 20:33:31 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 22 Jan 2025 20:33:31 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
Message-ID: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>

This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.

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

Commit messages:
 - Fixes and cleanups.
 - Merge branch 'master' into JDK-8224228
 - Bug fixes.
 - Merge branch 'master' into JDK-8224228
 - Refactor DeferredLintHandler to handle warnings generated during parsing.

Changes: https://git.openjdk.org/jdk/pull/23237/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8224228
  Stats: 729 lines in 22 files changed: 504 ins; 34 del; 191 mod
  Patch: https://git.openjdk.org/jdk/pull/23237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237

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

From acobbs at openjdk.org  Wed Jan 22 20:33:31 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 22 Jan 2025 20:33:31 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <MCt3LudzvWUHYXp3ndz970jVMcnQQ6LUxLOJNRmXJQA=.a8828a63-506a-439d-962b-efb81982be33@github.com>

On Wed, 22 Jan 2025 16:15:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.

**Overview**

The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".

During lexical scanning, `JCTree` nodes don't exist yet, so it is impossible to follow this protocol. Similarly, during parsing, `JCTree` nodes are in the process of being created, so  at best, some awkward gymnastics are required, e.g., see the handling for `"dangling-doc-comments"`.

This PR refactors `DeferredLintHandler` so that it can handle warnings generated during scanning and parsing:
* During scanning and parsing, warnings are temporarily stored by lexical position
* After parsing, the lexical warnings are remapped to the innermost containing `JCTree` declaration

These changes allow us to add `@SuppressWarnings` support for `"preview"` and `"text-blocks"`, and also facilitate any future lexically-based lint categories (e.g., [JDK-8271171](https://bugs.openjdk.org/browse/JDK-8271171), [JDK-8210681](https://bugs.openjdk.org/browse/JDK-8210681)).

One downside is that parsing must now always be done with an `EndPositionTable`, because one is required in order to calculate the lexical extent of declarations. I'm not sure if/how this will meaningfully impact compile time. In any case,  after parsing this table is discarded if no longer needed.

**Per-file notes**

`Preview.java`
* Lexical warnings are now deferred via `DeferredLintHandler`
* Normal warnings via `warnPreview()` are now passed the current `Lint` instance
* Normal warnings via `checkSourceLevel()` are now passed the current `Lint` instance

`Annotate.java`
* Updated for new `DeferredLintHandler` methods for `push()` and `pop()`
* Tighten `DiagnosticPosition deferPos` to `JCTree deferDecl` which is what's actually required
* Line 680: Fix a bug where a `JCExpression` (which is not a declaration supporting `@SuppressWarnings`) was being used for `deferPos`. In this case the correct `deferDecl` should already be established, so we can replace with null.

`Attr.java`
* Updated for new `DeferredLintHandler` methods for `push()` and `pop()`
* Add a couple of missed `flush()`s for variable declarations:
  * Pattern matching binding
  * Enhanced `for()` loop variables

`Check.java`
* Updated for new `DeferredLintHandler` methods for `push()` and `pop()`
* Pass current `Lint` to `preview.reportPreviewWarning()`
* No need to defer in `checkPreview()`
* Update `SuperThisChecker` to handle `@SuppressWarnings("preview")` on constructors

`Modules.java`
* Updated for new `DeferredLintHandler` methods for `push()` and `pop()`
* Update to support `@SuppressWarnings("preview")` on module declarations

`JavaCompiler.java`
* Update `DeferredLintHandler` when entering and exiting parsing
* `EndPositionTable` is now required while parsing, but can be discarded afterwards

`JavaTokenizer.java`
* `lexWarning()` can now defer warnings via `DeferredLintHandler` (this fixes `"text-blocks"`)

`JavacParser.java`
* Make `EmptyEndPosTable` public so `JavaCompiler` can create one

`MandatoryWarningHandler.java`
* Allow overriding `verbose` on a per-report basis to reflect `@SuppressWarnings`

Changes to existing tests:

`ImplicitClass/ErrorRecovery.java`
* The compiler error now results in elimination of the "recompile" note, which was inappropriate in light of the error

`preview/PreviewAutoSuppress.java`
* Warnings reordered as side effect of deferral, but note they are now consistent with the previous test

`preview/PreviewErrors.java`
* Updated to reflect the new effectiveness of `@SuppressWarnings("preview")`

**Other notes**

I tried to cleanup the existing logic in `JavacParser.java` for handling `"dangling-doc-comments"`(+13, -46), but it led to this test failure:

    @SuppressWarnings("dangling-doc-comments")
    /// Bad/misplaced/suppressed comment.
    public void m2() { }

The current code applies the suppression to the misplaced comment, thereby suppressing the warning. But lexically speaking, that comment is not actually within the declaration of `m2()` to which the `@SuppressWarnings` annotation applies, so one could argue that the `@SuppressWarnings` should not apply to it and therefore this test is wrong. Refactoring this code results in the latter interpretation, causing the test to fail, so I didn't do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2607810168

From dholmes at openjdk.org  Thu Jan 23 06:05:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Jan 2025 06:05:51 GMT
Subject: RFR: 8348203: [JVMCI] Make eager JVMCI initialization observable
 in the debugger
In-Reply-To: <wsgUGHgiMIP4MX-GqD1zMpgCJ4J5kmFQhmpgFulvTRY=.1e0ec113-a00e-4842-894a-367f3b9274a0@github.com>
References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
 <ADZVy3-WvySRy1VLSyhyqUXNfC2MAx3ZFl1HSjTj2Oo=.909771b3-a06b-4e79-92e4-720e0aa1daee@github.com>
 <wsgUGHgiMIP4MX-GqD1zMpgCJ4J5kmFQhmpgFulvTRY=.1e0ec113-a00e-4842-894a-367f3b9274a0@github.com>
Message-ID: <sguDaxxt28UrGW-8ofEShscMY2UNxF5JSDhqKK6EOGY=.1e1f5f64-c496-429a-a63e-2fb0bf2b71ae@github.com>

On Wed, 22 Jan 2025 14:46:36 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Yes, because that's the normal case. Usually, JVMCI gets initialized lazily,

Okay that alleviates my concern. I will leave it for JVMCI folk to approve.

> Is this a serious question? Because I'm hunting a bug in eager JVMCI initialization.

Yes a serious question but perhaps poorly framed. I was trying to gauge whether it makes sense to change the way the VM is doing this to address the debugging problem that you ran into i.e was this a general issue to be solved, or a one-of special case that should be handled by a local change instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/23219#issuecomment-2608933519

From stephan.herrmann at berlin.de  Thu Jan 23 10:03:49 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Thu, 23 Jan 2025 11:03:49 +0100
Subject: Preview flag required at runtime is not checked at compile time
Message-ID: <b47228d4-74de-4eb3-93d4-159187db5b51@berlin.de>

Using javac versions 23 and 24-ea it is possible to compile the following 
program without passing `--enable-preview`:

public class Test {

	public static void main(String[] args) {
		new Test().d(true);
	}

	void d(Boolean b) {
		switch (b) {
			case true  -> System.out.println("1");
			case false -> System.out.println("2");
		};
	}
}

When trying to run this program the following exception is thrown:

Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method 
initialization exception
         at 
java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:187)
         at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:316)
         at 
java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:275)
         at 
java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:265)
         at Test.d(Test.java:8)
         at Test.main(Test.java:4)
Caused by: java.lang.IllegalArgumentException: label with illegal type found: 
class java.lang.Boolean
         at 
java.base/java.lang.runtime.SwitchBootstraps.verifyLabel(SwitchBootstraps.java:214)
         at 
java.base/java.lang.runtime.SwitchBootstraps.typeSwitch(SwitchBootstraps.java:188)
         at 
java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:143)
         ... 5 more

Only when running with --enable-preview the program executes as expected.

This confirms that the compiler should have checked the preview flag, so that 
execution without --enable-preview would signal the following, rather than the 
BootstrapMethodError:

Error: LinkageError occurred while loading main class Test
         java.lang.UnsupportedClassVersionError: Preview features are not 
enabled for Test (class file version 67.65535). Try running with '--enable-preview'


The same observation also holds for other pairs of types like Long + long.

best,
Stephan

From sgehwolf at openjdk.org  Thu Jan 23 13:21:47 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 23 Jan 2025 13:21:47 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]
In-Reply-To: <pSXVsoAUQ03Lyqg2eUggTO9JV584xgqgVZz5Kz_Bzig=.b10a7565-7677-4559-9c6c-354442b33de8@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <pSXVsoAUQ03Lyqg2eUggTO9JV584xgqgVZz5Kz_Bzig=.b10a7565-7677-4559-9c6c-354442b33de8@github.com>
Message-ID: <7F5pVmYefDZ12cPCDSFhBuyMJYt8x-xGaqbYruqvfTg=.e06337f6-e22e-4fb7-aec2-faaad2264365@github.com>

On Wed, 22 Jan 2025 18:39:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
>> 
>> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
>> 
>> Once this pull request is integrated, it will be back-ported to the jdk24 branch.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect jlink review

jdk.jlink changes still good.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2569845897

From nbenalla at openjdk.org  Thu Jan 23 13:56:35 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 23 Jan 2025 13:56:35 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v2]
In-Reply-To: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
Message-ID: <VYKBD8I4cuuoEYhdtcEfCo6L_-DMGKCKSdXVKYZtTyU=.d3cfa7e6-ef3f-4e05-abb4-99d133308d91@github.com>

> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
> 
> 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:

 - whitespace
 - Update according to review comments.
 - Merge remote-tracking branch 'upstream/master' into elements-api-note
 - Respond to feedback around the wording.
 - Respond to feedback. Using Jan's comment to not imply particular requirement on the implementation.
 - (C) 2025
 - Initial commit obtained from a cherry pick/squash of a now superseded PR.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22920/files
  - new: https://git.openjdk.org/jdk/pull/22920/files/4f8877a5..54d6890c

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

  Stats: 55229 lines in 3172 files changed: 20793 ins; 22852 del; 11584 mod
  Patch: https://git.openjdk.org/jdk/pull/22920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22920/head:pull/22920

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

From nbenalla at openjdk.org  Thu Jan 23 13:58:47 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 23 Jan 2025 13:58:47 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods
In-Reply-To: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
Message-ID: <laKSP-3vKv3W0oq4rwg6a9kky9FnPey7MW4tcKFWFIk=.5dff3ffe-d4e8-4a11-b90b-c631be6a7096@github.com>

On Sun, 5 Jan 2025 22:16:45 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
> 
> TIA.

Thanks for the reviews, Updated accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/22920#issuecomment-2609872697

From archie.cobbs at gmail.com  Thu Jan 23 15:47:38 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 23 Jan 2025 09:47:38 -0600
Subject: Preview flag required at runtime is not checked at compile time
In-Reply-To: <b47228d4-74de-4eb3-93d4-159187db5b51@berlin.de>
References: <b47228d4-74de-4eb3-93d4-159187db5b51@berlin.de>
Message-ID: <CANSoFxtPd19woL31r9vUrbfNU4VKkRURggk1kKfLbkvbAAvNyA@mail.gmail.com>

Hi Stephan,

Thanks for the report. Created as JDK-8348410
<https://bugs.openjdk.org/browse/JDK-8348410>.

-Archie

On Thu, Jan 23, 2025 at 4:04?AM Stephan Herrmann <stephan.herrmann at berlin.de>
wrote:

> Using javac versions 23 and 24-ea it is possible to compile the following
> program without passing `--enable-preview`:
>
> public class Test {
>
>         public static void main(String[] args) {
>                 new Test().d(true);
>         }
>
>         void d(Boolean b) {
>                 switch (b) {
>                         case true  -> System.out.println("1");
>                         case false -> System.out.println("2");
>                 };
>         }
> }
>
> When trying to run this program the following exception is thrown:
>
> Exception in thread "main" java.lang.BootstrapMethodError: bootstrap
> method
> initialization exception
>          at
>
> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:187)
>          at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:316)
>          at
>
> java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:275)
>          at
>
> java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:265)
>          at Test.d(Test.java:8)
>          at Test.main(Test.java:4)
> Caused by: java.lang.IllegalArgumentException: label with illegal type
> found:
> class java.lang.Boolean
>          at
>
> java.base/java.lang.runtime.SwitchBootstraps.verifyLabel(SwitchBootstraps.java:214)
>          at
>
> java.base/java.lang.runtime.SwitchBootstraps.typeSwitch(SwitchBootstraps.java:188)
>          at
>
> java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:143)
>          ... 5 more
>
> Only when running with --enable-preview the program executes as expected.
>
> This confirms that the compiler should have checked the preview flag, so
> that
> execution without --enable-preview would signal the following, rather than
> the
> BootstrapMethodError:
>
> Error: LinkageError occurred while loading main class Test
>          java.lang.UnsupportedClassVersionError: Preview features are not
> enabled for Test (class file version 67.65535). Try running with
> '--enable-preview'
>
>
> The same observation also holds for other pairs of types like Long + long.
>
> best,
> Stephan
>


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

From abimpoudis at openjdk.org  Thu Jan 23 16:22:00 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 23 Jan 2025 16:22:00 GMT
Subject: RFR: 8326485: Assertion due to Type.addMetadata adding annotations to
 already-annotated type
Message-ID: <8gvMozOrqmReKzLdGSWhQOiVUIZNi7_W6PxXdwfOYD8=.bf2f67ca-4b17-4506-bec2-c1738865b123@github.com>

We end up with an errorType having annotation metadata (which subsequently results in this assertion getting invalidated after `Type ret = typeWithAnnotations(type, enclTy, annotations);` is executed).

What if we continue to try to define the `enclTy` (iteratively)? The error can still be reported appropriately. If this PR is merged it reproduces the original test case by running as expected: many errors without a crash:


javac src/main/java/net/ccbluex/liquidbounce/injection/mixins/minecraft/gui/MixinChatInputSuggestor.java -cp /tmp/jars/annotations-20.1.0.jar:/tmp/jars/kotlin-compiler-embeddable-1.9.0.jar


WDYT?

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

Commit messages:
 - 8326485: Assertion due to Type.addMetadata adding annotations to already-annotated type

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

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

From mcimadamore at openjdk.org  Thu Jan 23 18:19:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Jan 2025 18:19:46 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <6ze6J8aLTzJmsjgT23_ByUNvaqYNuVYLPd7P9TnPB8k=.eb4aa472-1a33-4b1b-8227-179d7e6777a4@github.com>

On Wed, 22 Jan 2025 16:15:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.

Question: the change looks beneficial, but there's a lot going on in the PR. Would it be possible, do you think, to break it down into simpler parts? For instance, the push/pop logic seems something that we could review and integrate separately (and it's adding quite a bit of noise to the PR). Same for missing flushes etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2610626795

From acobbs at openjdk.org  Thu Jan 23 18:26:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 23 Jan 2025 18:26:54 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
In-Reply-To: <6ze6J8aLTzJmsjgT23_ByUNvaqYNuVYLPd7P9TnPB8k=.eb4aa472-1a33-4b1b-8227-179d7e6777a4@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
 <6ze6J8aLTzJmsjgT23_ByUNvaqYNuVYLPd7P9TnPB8k=.eb4aa472-1a33-4b1b-8227-179d7e6777a4@github.com>
Message-ID: <lj_4rktOpEhy2d6nOm16vDJXeBxj0pTe-eo5WNktWKI=.e83b2c03-0a4a-4cf3-9a84-3930e4e12308@github.com>

On Thu, 23 Jan 2025 18:17:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
>
> Question: the change looks beneficial, but there's a lot going on in the PR. Would it be possible, do you think, to break it down into simpler parts? For instance, the push/pop logic seems something that we could review and integrate separately (and it's adding quite a bit of noise to the PR). Same for missing flushes etc.

Hi @mcimadamore,

Thanks for taking a look.

> Would it be possible, do you think, to break it down into simpler parts? 

Absolutely, I will work on that.

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

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2610638948

From acobbs at openjdk.org  Thu Jan 23 21:47:20 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 23 Jan 2025 21:47:20 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
Message-ID: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>

The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".

However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored.

In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration).

The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`.

In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first.

To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API.

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

Commit messages:
 - Refactor the DeferredLintHandler API to maintain the "stack" itself.
 - Add Javadoc to document a subtley in the API.
 - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition.

Changes: https://git.openjdk.org/jdk/pull/23281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23281&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348427
  Stats: 212 lines in 9 files changed: 52 ins; 29 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/23281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23281/head:pull/23281

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

From mcimadamore at openjdk.org  Thu Jan 23 22:04:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 23 Jan 2025 22:04:49 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
In-Reply-To: <6ze6J8aLTzJmsjgT23_ByUNvaqYNuVYLPd7P9TnPB8k=.eb4aa472-1a33-4b1b-8227-179d7e6777a4@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
 <6ze6J8aLTzJmsjgT23_ByUNvaqYNuVYLPd7P9TnPB8k=.eb4aa472-1a33-4b1b-8227-179d7e6777a4@github.com>
Message-ID: <cjb2rz15eQCHM9SEdyKiVtFml-GOwO_We4Wx4o9o1zU=.10acf611-3055-41e4-bac3-baa74f097183@github.com>

On Thu, 23 Jan 2025 18:17:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
>
> Question: the change looks beneficial, but there's a lot going on in the PR. Would it be possible, do you think, to break it down into simpler parts? For instance, the push/pop logic seems something that we could review and integrate separately (and it's adding quite a bit of noise to the PR). Same for missing flushes etc.

> Hi @mcimadamore,
> 
> Thanks for taking a look.
> 
> > Would it be possible, do you think, to break it down into simpler parts?
> 
> Absolutely, I will work on that.

Thanks!!

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

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2611107839

From acobbs at openjdk.org  Thu Jan 23 22:57:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 23 Jan 2025 22:57:27 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v2]
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <dWxlMaAWx0K7Z3nlXkliTwp8ZBI2DsCpTaa4ksmeWaA=.93c62c76-1688-49a3-b209-648de4b0cc08@github.com>

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.

Archie Cobbs has updated the pull request incrementally with five additional commits since the last revision:

 - Remove Attr.flushDeferredLintHandler() which doesn't appear necessary.
 - Merge branch 'JDK-8348427' into JDK-8224228
 - Refactor the DeferredLintHandler API to maintain the "stack" itself.
 - Add Javadoc to document a subtley in the API.
 - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23237/files
  - new: https://git.openjdk.org/jdk/pull/23237/files/25097710..877b16c2

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

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

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

From acobbs at openjdk.org  Thu Jan 23 22:57:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 23 Jan 2025 22:57:27 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <1TBhz3EpaBt8YfEB3_w1EiTRG5OI_IAOKP_rRtY1bYw=.347ec519-f363-45e3-862f-08a97ef91b48@github.com>

On Wed, 22 Jan 2025 16:15:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.

Note: Rebasing this PR on #23281 which should be reviewed first.

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

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2611179485

From acobbs at openjdk.org  Thu Jan 23 23:33:26 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 23 Jan 2025 23:33:26 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v3]
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <oWH3oS8Y7_bgntdQ0GiTCZL9LZ1SbCsis6SUtzFYsV8=.fcaee8e5-c400-4192-8a46-cdc323ffd935@github.com>

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.

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

  Put back required flushing of binding pattern variable declaration.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23237/files
  - new: https://git.openjdk.org/jdk/pull/23237/files/877b16c2..cecb2280

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

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

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

From jlahoda at openjdk.org  Fri Jan 24 08:15:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 Jan 2025 08:15:53 GMT
Subject: Integrated: 8346751: Internal java compiler error with type
 annotations in constants expression in constant fields
In-Reply-To: <49o4NtQmCtpsixY8pU2tTGz5HatPIR_r3gi2N8VwMzM=.bae7b887-c3be-4028-9b3b-19d4e7da5e9b@github.com>
References: <49o4NtQmCtpsixY8pU2tTGz5HatPIR_r3gi2N8VwMzM=.bae7b887-c3be-4028-9b3b-19d4e7da5e9b@github.com>
Message-ID: <VZbCEJDC7q8jVo4ktXRuHcdHvVbvs4k5aSGrRTsZHQ0=.1458fa4f-cee1-47e7-99ba-fff339f2dced@github.com>

On Fri, 10 Jan 2025 08:11:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> import java.lang.annotation.*;
> public class Decl {
>     String VALUE = (@Nullable String) "";
> }
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ ElementType.TYPE_USE })
> @interface Nullable {}
> 
> 
> When processing this code, when `Attr.visitVarDef` is called for the field, it will first call `Annotate.queueScanTreeAndTypeAnnotate` on the initializer expression, which will find and attribute type annotations. Then the initializer is attributed, and eventually `Annotate.annotateTypeSecondStage` is called on the annotated type (`@Nullable String`). This second stage depends on the type annotations being already attributed. This works OK.
> 
> The problem appears when the code like changed to be like:
> 
> import java.lang.annotation.*;
> @SuppressWarnings(Decl.VALUE)
> public class Decl {
>     public static final @Nullable String VALUE = (@Nullable String) "";
> }
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ ElementType.TYPE_USE })
> @interface Nullable {}
> 
> 
> In this code, the field is a constant, and it is used from the annotation before `Attr.visitVarDef` is called on the constant. This will trigger attribution of the constant initializer (`Attr.attribLazyConstantValue`), which will trigger the `Annotate.annotateTypeSecondStage` on the annotated type, but `Annotate.queueScanTreeAndTypeAnnotate` was not yet called on the initializer, and so the type annotations are not attributed yet, and javac crashes with an exception like:
> 
> 
> java.lang.AssertionError
> 	at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
> 	at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.fromAnnotations(Annotate.java:167)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.lambda$annotateTypeSecondStage$0(Annotate.java:1065)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:194)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
> 	at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
> 	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1820)
> 	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1080)
> 	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:949)
> 	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
> 	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImp...

This pull request has now been integrated.

Changeset: 0395593a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0395593a8a1c01a87ae36552c0f2cc9c67e8bbd8
Stats:     110 lines in 5 files changed: 100 ins; 4 del; 6 mod

8346751: Internal java compiler error with type annotations in constants expression in constant fields

Reviewed-by: vromero

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

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

From mcimadamore at openjdk.org  Fri Jan 24 10:41:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 10:41:50 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
Message-ID: <4yQdRMvTKFzKANEFH-5GfdUrwPo7tzGSBr0Sr9nCi_o=.34149fed-0581-41c7-a5e6-238c325f5e79@github.com>

On Thu, 23 Jan 2025 21:11:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".
> 
> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored.
> 
> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration).
> 
> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`.
> 
> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first.
> 
> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java line 120:

> 118:      */
> 119:     public void push(JCTree decl) {
> 120:         Assert.check(decl.getTag() == Tag.MODULEDEF

Nice!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23281#discussion_r1928482811

From mcimadamore at openjdk.org  Fri Jan 24 11:07:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 11:07:47 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
Message-ID: <YIbEbBT8EqlviE0Hzoq8A0thmtSi__yAOCmpOn4Momg=.b6bc6425-29c2-4de9-8c1d-65a3b26c5114@github.com>

On Thu, 23 Jan 2025 21:11:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".
> 
> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored.
> 
> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration).
> 
> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`.
> 
> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first.
> 
> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API.

Question: looking more broadly at the deferred lint handler API, I see that in most cases (all but one) `report` is called with a lambda that ignores its `lint` object. This seems odd - consider this:


private void warnOnExplicitStrictfp(DiagnosticPosition pos) {
        DiagnosticPosition prevLintPos = deferredLintHandler.setPos(pos);
        try {
            deferredLintHandler.report(_ -> lint.logIfEnabled(log, pos, LintWarnings.Strictfp)); // <---------------
        } finally {
            deferredLintHandler.setPos(prevLintPos);
        }
    }


Is the above code correct? E.g. should the call on `lint.logIfEnabled` occur on the `lint` that is the parameter to the lambda expression?

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

PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2612257868

From mcimadamore at openjdk.org  Fri Jan 24 11:15:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 11:15:50 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
Message-ID: <ckO3EwiYHS1D4LLP7Pv5mjxbL85oBF5A-4usdmiW-cY=.01d21ab9-c424-4cab-9662-4dbc15e72735@github.com>

On Thu, 23 Jan 2025 21:11:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".
> 
> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored.
> 
> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration).
> 
> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`.
> 
> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first.
> 
> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java line 119:

> 117:      * @see #pop
> 118:      */
> 119:     public void push(JCTree decl) {

I wonder if `enterDecl`/`leaveDecl` would be more evocative than `push`/`pop`. (but don't have any suggestion for the weird immediate mode).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23281#discussion_r1928521322

From mcimadamore at openjdk.org  Fri Jan 24 11:19:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 11:19:54 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
Message-ID: <rz-6pRvmPgk2JJ28hctbqS1NYhPpHSBI2ns2VzblZa4=.c218cad9-2062-4fc1-ac14-652e22e65296@github.com>

On Thu, 23 Jan 2025 21:11:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".
> 
> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored.
> 
> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration).
> 
> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`.
> 
> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first.
> 
> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API.

I have some doubts about the general deferred lint handler API - but my doubts are completely unrelated to your PR which, I think, does a nice job of making the API a little more tight, and easier to use for clients. Good job!

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

PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2612277918

From mcimadamore at openjdk.org  Fri Jan 24 11:31:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 11:31:56 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
Message-ID: <iL-PxRDFdFRvikQTu_xLGM_IKBE3xV0-5s3JI9dbRVo=.6a9064fe-073c-4b32-82c8-c48774c1161f@github.com>

On Thu, 23 Jan 2025 21:11:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".
> 
> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored.
> 
> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration).
> 
> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`.
> 
> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first.
> 
> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API.

(My doubts re DeferredLintHandler are whether it's a good abstraction or not. It seems to provide, on paper, a good service: allow for lint warnings to be correctly reported in earlier phases of the compiler. However, I note that:
* this class seems to be serving too many masters -- the "immediate" mode seems to be a sign of that
* using this class correctly is rather finicky, and depends on which part of javac you are on. For instance, Flow doesn't use it, because it is after Attr... in other words, reporting of lint warnings is not centralized - and each components does what it needs to get the job done -- understandable, but leads to messy code (this also leads to Check::setLint)
* the synergy between Lint and DeferredLintHandler goes quite deep. For instance, flush has to be called in a place where `Lint` has been augmented with the contents of the relevant `SuppressWarnings`. All these dependencies make it quite hard to verify that the code does what it needs to do.

My general feeling here is that we'd be better off with a separate compilation step that runs after all the various front-end steps (e.g. after Flow). E.g. up to Flow, we keep accumulating lint warnings grouped by declaration. Then, in a single pass we take care of updating Lint with the correct `@SuppressWarning` found in a given declaration, and flush all the pending lint warnings for all that declaration. This would also mean that Attr and Check would be hypothetically be freed from Lint duties. Maybe this is too extreme, and we can't get there in one step - but I'd like to know what you think about the general direction (since we have already added more compilation steps in this area).

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

PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2612299908

From mcimadamore at openjdk.org  Fri Jan 24 11:35:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 11:35:50 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148
In-Reply-To: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
Message-ID: <lOaj3zUlATed_cqLlm2N8m5fgEiyQef9et9cnkAmNmE=.b13bbfa5-8b42-467b-87dc-2d788d9cebb9@github.com>

On Tue, 21 Jan 2025 23:42:29 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.
> 
> However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.
> 
> This PR adds the missing `warn()` calls.

Looks good. Another possibility would be to couple warn with flow (note that `attribute` also calls the `postAttr` visitor, for instance -- e.g. there doesn't need to be an exact 1-1 mapping here).

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23223#pullrequestreview-2572404579

From dnsimon at openjdk.org  Fri Jan 24 12:15:47 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 24 Jan 2025 12:15:47 GMT
Subject: RFR: 8348203: [JVMCI] Make eager JVMCI initialization observable
 in the debugger
In-Reply-To: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
Message-ID: <aJZCoXTvhzdcDPCsfQ8pS8rLAb2d3MEQ3CRfXaYFOUU=.62f64929-1420-4227-bd20-07729efe7872@github.com>

On Tue, 21 Jan 2025 16:59:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> I realized that I can't debug (i.e. with a Java debugger) the Graal compiler initialization if it happens eagerly (e.g. with `EagerJVMCI`, `JVMCIPrintProperties`, `JVMCILibDumpJNIConfig`). Not that this is something I need every day, but I think it can easily be fixed by moving the early initializing a little further down, right after `JvmtiExport::post_vm_initialized()`:
> 
> 
>  diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp
> index 1cab9bc5d53..191409c22e3 100644
> --- a/src/hotspot/share/runtime/threads.cpp
> +++ b/src/hotspot/share/runtime/threads.cpp
> @@ -806,12 +806,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    }
>  #endif
>  
> -#if INCLUDE_JVMCI
> - if (force_JVMCI_initialization) {
> - JVMCI::initialize_compiler(CHECK_JNI_ERR);
> - }
> -#endif
> -
>    if (NativeHeapTrimmer::enabled()) {
>      NativeHeapTrimmer::initialize();
>    }
> @@ -826,6 +820,12 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    // Notify JVMTI agents that VM initialization is complete - nop if no agents.
>    JvmtiExport::post_vm_initialized();
>  
> +#if INCLUDE_JVMCI
> + if (force_JVMCI_initialization) {
> + JVMCI::initialize_compiler(CHECK_JNI_ERR);
> + }
> +#endif
> +
>    JFR_ONLY(Jfr::on_create_vm_3();)
>  
>  #if INCLUDE_MANAGEMENT

Marked as reviewed by dnsimon (Reviewer).

Since this is the non-default mode of execution (JVMCI initialization is normally lazy as Volker pointed out), I think this change is fine.

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

PR Review: https://git.openjdk.org/jdk/pull/23219#pullrequestreview-2572488639
PR Comment: https://git.openjdk.org/jdk/pull/23219#issuecomment-2612383997

From simonis at openjdk.org  Fri Jan 24 15:40:51 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 24 Jan 2025 15:40:51 GMT
Subject: RFR: 8348203: [JVMCI] Make eager JVMCI initialization observable
 in the debugger
In-Reply-To: <sguDaxxt28UrGW-8ofEShscMY2UNxF5JSDhqKK6EOGY=.1e1f5f64-c496-429a-a63e-2fb0bf2b71ae@github.com>
References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
 <ADZVy3-WvySRy1VLSyhyqUXNfC2MAx3ZFl1HSjTj2Oo=.909771b3-a06b-4e79-92e4-720e0aa1daee@github.com>
 <wsgUGHgiMIP4MX-GqD1zMpgCJ4J5kmFQhmpgFulvTRY=.1e0ec113-a00e-4842-894a-367f3b9274a0@github.com>
 <sguDaxxt28UrGW-8ofEShscMY2UNxF5JSDhqKK6EOGY=.1e1f5f64-c496-429a-a63e-2fb0bf2b71ae@github.com>
Message-ID: <etqtBnZPcU6sNdj6ZRvY8pB6SEXm42md0YPXnhl5v1A=.ea87255f-4109-455f-a656-dd2dedf3a4eb@github.com>

On Thu, 23 Jan 2025 06:02:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Is this a serious question? Because I'm hunting a bug in eager JVMCI initialization.
> 
> Yes a serious question but perhaps poorly framed. I was trying to gauge whether it makes sense to change the way the VM is doing this to address the debugging problem that you ran into i.e was this a general issue to be solved, or a one-of special case that should be handled by a local change instead.

Got it. I obviously handled this by a local change first. But I think the JVMCI compiler initialization executes quite some Java code and I think it is  beneficial if this code executions is observable by Java agents (which don't include only the debugger).

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

PR Comment: https://git.openjdk.org/jdk/pull/23219#issuecomment-2612819109

From simonis at openjdk.org  Fri Jan 24 15:40:51 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 24 Jan 2025 15:40:51 GMT
Subject: Integrated: 8348203: [JVMCI] Make eager JVMCI initialization
 observable in the debugger
In-Reply-To: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
Message-ID: <g3qLrqT1HHl2RwPF_JAHdHXLzdk_2se5BouMwXDrYPg=.464937f9-91ec-47fa-9ecc-29590942259d@github.com>

On Tue, 21 Jan 2025 16:59:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> I realized that I can't debug (i.e. with a Java debugger) the Graal compiler initialization if it happens eagerly (e.g. with `EagerJVMCI`, `JVMCIPrintProperties`, `JVMCILibDumpJNIConfig`). Not that this is something I need every day, but I think it can easily be fixed by moving the early initializing a little further down, right after `JvmtiExport::post_vm_initialized()`:
> 
> 
>  diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp
> index 1cab9bc5d53..191409c22e3 100644
> --- a/src/hotspot/share/runtime/threads.cpp
> +++ b/src/hotspot/share/runtime/threads.cpp
> @@ -806,12 +806,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    }
>  #endif
>  
> -#if INCLUDE_JVMCI
> - if (force_JVMCI_initialization) {
> - JVMCI::initialize_compiler(CHECK_JNI_ERR);
> - }
> -#endif
> -
>    if (NativeHeapTrimmer::enabled()) {
>      NativeHeapTrimmer::initialize();
>    }
> @@ -826,6 +820,12 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    // Notify JVMTI agents that VM initialization is complete - nop if no agents.
>    JvmtiExport::post_vm_initialized();
>  
> +#if INCLUDE_JVMCI
> + if (force_JVMCI_initialization) {
> + JVMCI::initialize_compiler(CHECK_JNI_ERR);
> + }
> +#endif
> +
>    JFR_ONLY(Jfr::on_create_vm_3();)
>  
>  #if INCLUDE_MANAGEMENT

This pull request has now been integrated.

Changeset: 76f792b5
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76f792b55263faf883e54cb879d8609f87164e51
Stats:     12 lines in 1 file changed: 6 ins; 6 del; 0 mod

8348203: [JVMCI] Make eager JVMCI initialization observable in the debugger

Reviewed-by: dnsimon

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

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

From acobbs at openjdk.org  Fri Jan 24 16:23:15 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 16:23:15 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v2]
In-Reply-To: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
Message-ID: <gchXBCXYZMMcUq7yBHz4yDhMsYkbPFgPWacjBHdWYkE=.c7053a11-4d49-43e0-a982-2eb925712faf@github.com>

> In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.
> 
> However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.
> 
> This PR adds the missing `warn()` calls.

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

  Add a regression test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23223/files
  - new: https://git.openjdk.org/jdk/pull/23223/files/d07dc1a3..c7b6fcb5

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

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

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

From acobbs at openjdk.org  Fri Jan 24 16:23:15 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 16:23:15 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v2]
In-Reply-To: <lOaj3zUlATed_cqLlm2N8m5fgEiyQef9et9cnkAmNmE=.b13bbfa5-8b42-467b-87dc-2d788d9cebb9@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
 <lOaj3zUlATed_cqLlm2N8m5fgEiyQef9et9cnkAmNmE=.b13bbfa5-8b42-467b-87dc-2d788d9cebb9@github.com>
Message-ID: <xKaPKSpowO2kOCJAb7UBCITtQ4voyqisMGVWTpRrvAY=.d83ece83-42e8-4a30-84ea-bf4fa4baca94@github.com>

On Fri, 24 Jan 2025 11: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:
>> 
>>   Add a regression test.
>
> Looks good. Another possibility would be to couple warn with flow (note that `attribute` also calls the `postAttr` visitor, for instance -- e.g. there doesn't need to be an exact 1-1 mapping here).

@mcimadamore, thanks for the review!

I just realized this PR also should have a regression test - I've added one in c7b6fcb59f2.

You may need to re-review. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23223#issuecomment-2612910582

From mcimadamore at openjdk.org  Fri Jan 24 16:52:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 16:52:48 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v2]
In-Reply-To: <gchXBCXYZMMcUq7yBHz4yDhMsYkbPFgPWacjBHdWYkE=.c7053a11-4d49-43e0-a982-2eb925712faf@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
 <gchXBCXYZMMcUq7yBHz4yDhMsYkbPFgPWacjBHdWYkE=.c7053a11-4d49-43e0-a982-2eb925712faf@github.com>
Message-ID: <hHDRyXktcNL6QDEWAQaDm8-0Suo8P1sAQ9OTzzdl1xE=.2f9c309c-efee-4c3e-bb93-49e3ebb150dd@github.com>

On Fri, 24 Jan 2025 16:23:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.
>> 
>> However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.
>> 
>> This PR adds the missing `warn()` calls.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a regression test.

test/langtools/tools/javac/api/TestJavacTaskWithWarning.java line 74:

> 72: 
> 73:         // Verify warning was generated
> 74:         if (!buf.toString().contains("compiler.warn.possible.this.escape"))

This strategy is good - as an alternative (maybe for more complex tests in the future) you also have the option to register a so called "diagnostic listener".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23223#discussion_r1928973693

From mcimadamore at openjdk.org  Fri Jan 24 16:58:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 16:58:47 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v2]
In-Reply-To: <gchXBCXYZMMcUq7yBHz4yDhMsYkbPFgPWacjBHdWYkE=.c7053a11-4d49-43e0-a982-2eb925712faf@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
 <gchXBCXYZMMcUq7yBHz4yDhMsYkbPFgPWacjBHdWYkE=.c7053a11-4d49-43e0-a982-2eb925712faf@github.com>
Message-ID: <vYn6Y7VKbGj3IyL7xViS1P5UYtlwj8PnruprdhgI6hM=.50209892-ae2f-470d-ba01-ddc0c9bdb88e@github.com>

On Fri, 24 Jan 2025 16:23:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.
>> 
>> However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.
>> 
>> This PR adds the missing `warn()` calls.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a regression test.

test/langtools/tools/javac/api/TestJavacTaskWithWarning.java line 45:

> 43: import javax.tools.ToolProvider;
> 44: 
> 45: public class TestJavacTaskWithWarning extends TestJavacTask {

We don't seem to have any other test doing this... what are you using of the super class?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23223#discussion_r1928980569

From mcimadamore at openjdk.org  Fri Jan 24 16:58:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 16:58:47 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v2]
In-Reply-To: <vYn6Y7VKbGj3IyL7xViS1P5UYtlwj8PnruprdhgI6hM=.50209892-ae2f-470d-ba01-ddc0c9bdb88e@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
 <gchXBCXYZMMcUq7yBHz4yDhMsYkbPFgPWacjBHdWYkE=.c7053a11-4d49-43e0-a982-2eb925712faf@github.com>
 <vYn6Y7VKbGj3IyL7xViS1P5UYtlwj8PnruprdhgI6hM=.50209892-ae2f-470d-ba01-ddc0c9bdb88e@github.com>
Message-ID: <kmchp0ALPvFBsu7MCsjDiP9qLv3wqVrnLePI7XNM5Ok=.ee6a01e8-3414-4d2b-8f54-a875207b5d2b@github.com>

On Fri, 24 Jan 2025 16:55:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a regression test.
>
> test/langtools/tools/javac/api/TestJavacTaskWithWarning.java line 45:
> 
>> 43: import javax.tools.ToolProvider;
>> 44: 
>> 45: public class TestJavacTaskWithWarning extends TestJavacTask {
> 
> We don't seem to have any other test doing this... what are you using of the super class?

probably just add

static final JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
static final StandardJavaFileManager fm = compiler.getStandardFileManager(null, null, null);
 ```
 to the test and get rid of the dependency? Seems to be what other tests are doing in here...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23223#discussion_r1928981961

From acobbs at openjdk.org  Fri Jan 24 17:17:30 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 17:17:30 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation resulting in
 runtime crash
Message-ID: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>

JEP 455 adds support for `switch`'ing on `long`, `float`, `double`, and `boolean`. Since this feature is still in preview, the `--enable-preview` flag is required. The compiler was properly checking that when the expressions had primitive type, but not when the expression a corresponding boxed type (i.e., `Long`, `Float`, `Double`, and `Boolean`). This resulted in `BootstrapMethodError` failures at runtime. This PR closes that loophole.

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

Commit messages:
 - Fix typo in regression test @summary lines.
 - Check preview enabled for switch on boxed Booleam, Long, Float, or Double.

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

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

From acobbs at openjdk.org  Fri Jan 24 17:24:08 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 17:24:08 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v3]
In-Reply-To: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
Message-ID: <sY_t_pJQ50AVkcjYEOLuf9saKP50G9JOMr9RJFFZOUI=.190d5cea-9912-4516-8f55-bce0ddfd6e04@github.com>

> In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.
> 
> However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.
> 
> This PR adds the missing `warn()` calls.

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

  Avoid having the regression test class extend another regression test class.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23223/files
  - new: https://git.openjdk.org/jdk/pull/23223/files/c7b6fcb5..a9b5f2d6

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

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

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

From acobbs at openjdk.org  Fri Jan 24 17:24:09 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 17:24:09 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v2]
In-Reply-To: <kmchp0ALPvFBsu7MCsjDiP9qLv3wqVrnLePI7XNM5Ok=.ee6a01e8-3414-4d2b-8f54-a875207b5d2b@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
 <gchXBCXYZMMcUq7yBHz4yDhMsYkbPFgPWacjBHdWYkE=.c7053a11-4d49-43e0-a982-2eb925712faf@github.com>
 <vYn6Y7VKbGj3IyL7xViS1P5UYtlwj8PnruprdhgI6hM=.50209892-ae2f-470d-ba01-ddc0c9bdb88e@github.com>
 <kmchp0ALPvFBsu7MCsjDiP9qLv3wqVrnLePI7XNM5Ok=.ee6a01e8-3414-4d2b-8f54-a875207b5d2b@github.com>
Message-ID: <Cbd5jmH3c70r7nGWL-opvTtzDxwOrmV8Yig-AQ02Hd0=.cf44e8e5-19c9-45b2-adbe-9ce280fcef00@github.com>

On Fri, 24 Jan 2025 16:56:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> probably just add...

Agreed, that's simpler. At first when writing this test I thought I was going to utilize more stuff from the superclass (`TestJavacTask`) but in the end didn't need it.

Cleaned up in a9b5f2d63cd.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23223#discussion_r1929012938

From mcimadamore at openjdk.org  Fri Jan 24 18:04:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 18:04:51 GMT
Subject: RFR: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148 [v3]
In-Reply-To: <sY_t_pJQ50AVkcjYEOLuf9saKP50G9JOMr9RJFFZOUI=.190d5cea-9912-4516-8f55-bce0ddfd6e04@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
 <sY_t_pJQ50AVkcjYEOLuf9saKP50G9JOMr9RJFFZOUI=.190d5cea-9912-4516-8f55-bce0ddfd6e04@github.com>
Message-ID: <fTu9C3vgMvUG4wV5J9b_ct6e2VZ51E-f3M5n_RBhXyc=.5da2c4e3-5991-4dde-8bf5-2a50e19e5dc0@github.com>

On Fri, 24 Jan 2025 17:24:08 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.
>> 
>> However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.
>> 
>> This PR adds the missing `warn()` calls.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid having the regression test class extend another regression test class.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23223#pullrequestreview-2573286665

From acobbs at openjdk.org  Fri Jan 24 18:20:46 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 18:20:46 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <YIbEbBT8EqlviE0Hzoq8A0thmtSi__yAOCmpOn4Momg=.b6bc6425-29c2-4de9-8c1d-65a3b26c5114@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
 <YIbEbBT8EqlviE0Hzoq8A0thmtSi__yAOCmpOn4Momg=.b6bc6425-29c2-4de9-8c1d-65a3b26c5114@github.com>
Message-ID: <aVnBjfdWOP5Zqnx07hDKh4PrCs10uzG-hPcIfHWv47U=.582c06ad-1fde-4129-8cdb-5a7faa6baac4@github.com>

On Fri, 24 Jan 2025 11:05:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Is the above code correct? E.g. should the call on `lint.logIfEnabled` occur on the `lint` that is the parameter to the lambda expression?

I wondered the same thing, and it seems plainly counter to the whole point of warning deferral. I haven't tried to figure it out yet - I assume it must work because when the lambda executes, the correct `Lint` object happens to still be in place.

But you got me curious... my theory is easy to test with this patch:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
index fe40bf0dad1..3a23c5df6d6 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
@@ -244,7 +244,7 @@ MethodSymbol setMethod(MethodSymbol newMethod) {
      *  @param pos        Position to be used for error reporting.
      *  @param sym        The deprecated symbol.
      */
-    void warnDeprecated(DiagnosticPosition pos, Symbol sym) {
+    void warnDeprecated(Lint lint, DiagnosticPosition pos, Symbol sym) {
         if (sym.isDeprecatedForRemoval()) {
             if (!lint.isSuppressed(LintCategory.REMOVAL)) {
                 if (sym.kind == MDL) {
@@ -284,7 +284,7 @@ public void warnDeclaredUsingPreview(DiagnosticPosition pos, Symbol sym) {
      *  @param pos        Position to be used for error reporting.
      *  @param msg        A Warning describing the problem.
      */
-    public void warnRestrictedAPI(DiagnosticPosition pos, Symbol sym) {
+    public void warnRestrictedAPI(Lint lint, DiagnosticPosition pos, Symbol sym) {
         lint.logIfEnabled(log, pos, LintWarnings.RestrictedMethod(sym.enclClass(), sym));
     }
 
@@ -648,8 +648,8 @@ public void checkRedundantCast(Env<AttrContext> env, final JCTypeCast tree) {
                 && types.isSameType(tree.expr.type, tree.clazz.type)
                 && !(ignoreAnnotatedCasts && TreeInfo.containsTypeAnnotation(tree.clazz))
                 && !is292targetTypeCast(tree)) {
-            deferredLintHandler.report(_l -> {
-                lint.logIfEnabled(log, tree.pos(), LintWarnings.RedundantCast(tree.clazz.type));
+            deferredLintHandler.report(lint2 -> {
+                lint2.logIfEnabled(log, tree.pos(), LintWarnings.RedundantCast(tree.clazz.type));
             });
         }
     }
@@ -1324,7 +1324,7 @@ && checkDisjoint(pos, flags,
     private void warnOnExplicitStrictfp(JCTree tree) {
         deferredLintHandler.push(tree);
         try {
-            deferredLintHandler.report(_ -> lint.logIfEnabled(log, tree.pos(), LintWarnings.Strictfp));
+            deferredLintHandler.report(lint2 -> lint2.logIfEnabled(log, tree.pos(), LintWarnings.Strictfp));
         } finally {
             deferredLintHandler.pop();
         }
@@ -3785,7 +3785,7 @@ void checkDeprecated(Supplier<DiagnosticPosition> pos, final Symbol other, final
                 || s.isDeprecated() && !other.isDeprecated())
                 && (s.outermostClass() != other.outermostClass() || s.outermostClass() == null)
                 && s.kind != Kind.PCK) {
-            deferredLintHandler.report(_l -> warnDeprecated(pos.get(), s));
+            deferredLintHandler.report(lint2 -> warnDeprecated(lint2, pos.get(), s));
         }
     }
 
@@ -3850,7 +3850,7 @@ void checkPreview(DiagnosticPosition pos, Symbol other, Type site, Symbol s) {
 
     void checkRestricted(DiagnosticPosition pos, Symbol s) {
         if (s.kind == MTH && (s.flags() & RESTRICTED) != 0) {
-            deferredLintHandler.report(_l -> warnRestrictedAPI(pos, s));
+            deferredLintHandler.report(lint2 -> warnRestrictedAPI(lint2, pos, s));
         }
     }
 
@@ -4122,7 +4122,7 @@ void checkDivZero(final DiagnosticPosition pos, Symbol operator, Type operand) {
             int opc = ((OperatorSymbol)operator).opcode;
             if (opc == ByteCodes.idiv || opc == ByteCodes.imod
                 || opc == ByteCodes.ldiv || opc == ByteCodes.lmod) {
-                deferredLintHandler.report(_ -> lint.logIfEnabled(log, pos, LintWarnings.DivZero));
+                deferredLintHandler.report(lint2 -> lint2.logIfEnabled(log, pos, LintWarnings.DivZero));
             }
         }
     }
@@ -4135,8 +4135,8 @@ void checkDivZero(final DiagnosticPosition pos, Symbol operator, Type operand) {
      */
     void checkLossOfPrecision(final DiagnosticPosition pos, Type found, Type req) {
         if (found.isNumeric() && req.isNumeric() && !types.isAssignable(found, req)) {
-            deferredLintHandler.report(_ ->
-                lint.logIfEnabled(log, pos, LintWarnings.PossibleLossOfPrecision(found, req)));
+            deferredLintHandler.report(lint2 ->
+                lint2.logIfEnabled(log, pos, LintWarnings.PossibleLossOfPrecision(found, req)));
         }
     }
 
@@ -4335,8 +4335,8 @@ void checkDefaultConstructor(ClassSymbol c, DiagnosticPosition pos) {
                             // Warning may be suppressed by
                             // annotations; check again for being
                             // enabled in the deferred context.
-                            deferredLintHandler.report(_ ->
-                                lint.logIfEnabled(log, pos, LintWarnings.MissingExplicitCtor(c, pkg, modle)));
+                            deferredLintHandler.report(lint2 ->
+                                lint2.logIfEnabled(log, pos, LintWarnings.MissingExplicitCtor(c, pkg, modle)));
                         } else {
                             return;
                         }
@@ -4670,26 +4670,26 @@ private void checkVisible(DiagnosticPosition pos, Symbol what, PackageSymbol inP
 
     void checkModuleExists(final DiagnosticPosition pos, ModuleSymbol msym) {
         if (msym.kind != MDL) {
-            deferredLintHandler.report(_ ->
-                lint.logIfEnabled(log, pos, LintWarnings.ModuleNotFound(msym)));
+            deferredLintHandler.report(lint2 ->
+                lint2.logIfEnabled(log, pos, LintWarnings.ModuleNotFound(msym)));
         }
     }
 
     void checkPackageExistsForOpens(final DiagnosticPosition pos, PackageSymbol packge) {
         if (packge.members().isEmpty() &&
             ((packge.flags() & Flags.HAS_RESOURCE) == 0)) {
-            deferredLintHandler.report(_ ->
-                lint.logIfEnabled(log, pos, LintWarnings.PackageEmptyOrNotFound(packge)));
+            deferredLintHandler.report(lint2 ->
+                lint2.logIfEnabled(log, pos, LintWarnings.PackageEmptyOrNotFound(packge)));
         }
     }
 
     void checkModuleRequires(final DiagnosticPosition pos, final RequiresDirective rd) {
         if ((rd.module.flags() & Flags.AUTOMATIC_MODULE) != 0) {
-            deferredLintHandler.report(_ -> {
-                if (rd.isTransitive() && lint.isEnabled(LintCategory.REQUIRES_TRANSITIVE_AUTOMATIC)) {
+            deferredLintHandler.report(lint2 -> {
+                if (rd.isTransitive() && lint2.isEnabled(LintCategory.REQUIRES_TRANSITIVE_AUTOMATIC)) {
                     log.warning(pos, LintWarnings.RequiresTransitiveAutomatic);
                 } else {
-                    lint.logIfEnabled(log, pos, LintWarnings.RequiresAutomatic);
+                    lint2.logIfEnabled(log, pos, LintWarnings.RequiresAutomatic);
                 }
             });
         }

Turns out it's not quite that simple; the above patch breaks the build:

Building target 'test' in configuration 'macosx-aarch64-server-release'
Compiling up to 360 files for BUILD_jdk.compiler.interim
Updating support/src.zip
Compiling up to 368 files for jdk.compiler
/Users/archie/proj/jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java:142: warning: [deprecation] URL(URL,String) in URL has been deprecated
        URL retVal = new URL(base, input);
                     ^
error: warnings found and -Werror specified
/Users/archie/proj/jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java:269: warning: [restricted] Controller.enableNativeAccess(Module) is a restricted method.
            controller.enableNativeAccess(module);
                      ^
  (Restricted methods are unsafe and, if used incorrectly, might crash the Java runtime or corrupt memory)
1 error
2 warnings
make[3]: *** [/Users/archie/proj/jdk/build/macosx-aarch64-server-release/jdk/modules/jdk.compiler/_the.jdk.compiler_batch] Error 1
make[2]: *** [jdk.compiler-java] Error 2

So I don't know what's going on there exactly and have so far avoided that particular dark corner.

> I wonder if `enterDecl`/`leaveDecl` would be more evocative than push/pop. (but don't have any suggestion for the weird immediate mode).

Yes that naming would be better - if there were no immediate mode. But since immediate mode exists, the stack contains more than just declarations. Also, `push()` hopefully makes it more obvious that you are responsible putting in place a corresponding `pop()`.

> My general feeling here is that we'd be better off with a separate compilation step that runs after all the various front-end steps (e.g. after Flow).

I have that same feeling :) We have the new `warn()` compiler phase, so that would be the logical place to put the grand `flush()` operation.

I think this is do-able. Semantically things would get simpler, which means while the patch would be large, it would consist mostly of decomplexification. Rough sketch (this would include #23237):

* Move the deferral logic of `DeferredLintManager` into `Lint`; the `DeferredLintManager` singleton goes away.
* Lint has a single `flush()` method which is invoked _once_ per source file during the compiler `warn()` step
  * First, lexical deferrals are remapped to innermost containing `JCTree` 
  * Next, all warnings are emitted (in lexical order) by scanning the `JCCompilationUnit` and flushing each declaration
* Lint warnings are created via `Lint.logIfEnabled()` (or similar) at any time during compilation
  * If you can locate the warning with a `JCTree`, you supply that
  * Otherwise, you locate the warning with an integer `pos` source file offset
  * In either case, an assertion verifies that `flush()` has not yet been invoked

What do you think?

One thing I'm unclear of is whether `flush()` can assume that all of the accumulated warnings correspond to the same file. Might not be true with `CompilePolicy.BY_TODO`?

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

PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2613128868

From mcimadamore at openjdk.org  Fri Jan 24 18:45:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 24 Jan 2025 18:45:49 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <aVnBjfdWOP5Zqnx07hDKh4PrCs10uzG-hPcIfHWv47U=.582c06ad-1fde-4129-8cdb-5a7faa6baac4@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
 <YIbEbBT8EqlviE0Hzoq8A0thmtSi__yAOCmpOn4Momg=.b6bc6425-29c2-4de9-8c1d-65a3b26c5114@github.com>
 <aVnBjfdWOP5Zqnx07hDKh4PrCs10uzG-hPcIfHWv47U=.582c06ad-1fde-4129-8cdb-5a7faa6baac4@github.com>
Message-ID: <5h1q3QVhdhAR7agyKX_JmImu4ef57LT830RUYuvXcY0=.2075f449-ab8c-4eb8-95cb-8aec0ab22fd5@github.com>

On Fri, 24 Jan 2025 18:18:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> I think this is do-able. Semantically things would get simpler, which means while the patch would be large, it would consist mostly of decomplexification. Rough sketch (this would come after #23237):
> 
>     * Move the deferral logic of `DeferredLintManager` into `Lint`; the `DeferredLintManager` singleton goes away.
> 
>     * Lint has a single `flush()` method which is invoked _once_ per source file during the compiler `warn()` step
>       
>       * First, lexical deferrals are remapped to innermost containing `JCTree`
>       * Next, all warnings are emitted (in lexical order) by scanning the `JCCompilationUnit` and flushing each declaration
> 
>     * Lint warnings are created via `Lint.logIfEnabled()` (or similar) at any time during compilation
>       
>       * If you can locate the warning with a `JCTree`, you supply that
>       * Otherwise, you locate the warning with an integer `pos` source file offset
>       * In either case, an assertion verifies that `flush()` has not yet been invoked
> 
> 
> What do you think?

This seems like a great plan. We don't have to get there in one step (and this PR can proceed separately). I just want to make sure that we end up somewhere around there :-)

(as your quick experiment with Check suggests, some of this stuff is not trivial at all -- even the use of the immediate mode seems a bit odd to be honest).

> 
> One thing I'm unclear of is whether `flush()` can assume that all of the accumulated warnings correspond to the same file. Might not be true with `CompilePolicy.BY_TODO`?

I believe that in `flow` we still see all the classes in the same source as belonging to the same toplevel unit. It's after desugar that things start to get messier. So, I believe that the warning visitor can assume that it's called once per compilation unit, and call flush on all the stuff that belongs to that unit.

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

PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2613167039

From jlahoda at openjdk.org  Fri Jan 24 18:45:51 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 Jan 2025 18:45:51 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash
In-Reply-To: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
Message-ID: <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>

On Fri, 24 Jan 2025 17:12:00 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> JEP 455 adds support for `switch`'ing on `long`, `float`, `double`, and `boolean`. Since this feature is still in preview, the `--enable-preview` flag is required. The compiler was properly checking that when the expressions had primitive type, but not when the expression a corresponding boxed type (i.e., `Long`, `Float`, `Double`, and `Boolean`). This resulted in `BootstrapMethodError` failures at runtime. This PR closes that loophole.

I think the check needs to be on a different place - please see inline.

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

> 1704:             boolean intSwitch = types.isAssignable(seltype, syms.intType);
> 1705:             boolean patternSwitch;
> 1706:             if (seltypeUnboxed.isPrimitive() && !intSwitch) {

Sorry, but this seems wrong. Having a selector type of type `Boolean` is not a preview feature (since JDK 21). I.e. this is completely valid:

public class Test {
    public static void main(String... args) {
        Boolean b = true;
        System.err.println(switch (b) { case Boolean bb -> bb; });
    }
}


I think there needs to be a preview check in the section that handles constant labels, probably somewhere here:
https://github.com/openjdk/jdk/blob/76f792b55263faf883e54cb879d8609f87164e51/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1808

test/langtools/tools/javac/patterns/PrimitivePatternsSwitchRequirePreviewBoolean.java line 1:

> 1: /*

Having tests like this is not wrong, but instead of introducing 8 new (small) files, I would rather use the `ToolBox` and `TestRunner`, or a combo test. A `TestRunner` test looks like this:
https://github.com/openjdk/jdk/blob/76f792b55263faf883e54cb879d8609f87164e51/test/langtools/tools/javac/recovery/AttrRecovery.java

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

Changes requested by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23303#pullrequestreview-2573352428
PR Review Comment: https://git.openjdk.org/jdk/pull/23303#discussion_r1929096503
PR Review Comment: https://git.openjdk.org/jdk/pull/23303#discussion_r1929099310

From jlu at openjdk.org  Fri Jan 24 21:46:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Jan 2025 21:46:51 GMT
Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2]
In-Reply-To: <pSXVsoAUQ03Lyqg2eUggTO9JV584xgqgVZz5Kz_Bzig=.b10a7565-7677-4559-9c6c-354442b33de8@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
 <pSXVsoAUQ03Lyqg2eUggTO9JV584xgqgVZz5Kz_Bzig=.b10a7565-7677-4559-9c6c-354442b33de8@github.com>
Message-ID: <JbZ1-y9brysoPpAo7fThELNQ0wsiEcKFVnBeU0G_9Rg=.713fe611-2329-445e-bce7-2f41aca1561c@github.com>

On Wed, 22 Jan 2025 18:39:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
>> 
>> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
>> 
>> Once this pull request is integrated, it will be back-ported to the jdk24 branch.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect jlink review

Thank you all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2613427519

From jlu at openjdk.org  Fri Jan 24 21:46:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Jan 2025 21:46:52 GMT
Subject: Integrated: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
References: <TWmIY3oFZC60iNmPNXVtEz2kNzW4KQOrdFrqi6rqx64=.50834b6b-5cf3-41d8-8c0d-fb303a435f61@github.com>
Message-ID: <WoV1bTj4SCLjFqNIzjT8fE0r9TY7LIyofT0VreBU_Ik=.68c71df5-f802-4c14-9e9a-52f41b9d339c@github.com>

On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch.
> 
> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements.
> 
> Once this pull request is integrated, it will be back-ported to the jdk24 branch.

This pull request has now been integrated.

Changeset: dec93675
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea
Stats:     93 lines in 26 files changed: 33 ins; 15 del; 45 mod

8347498: JDK 24 RDP2 L10n resource files update

Reviewed-by: sgehwolf, dnguyen, naoto, joehw, asemenyuk

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

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

From jlu at openjdk.org  Fri Jan 24 21:57:24 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 24 Jan 2025 21:57:24 GMT
Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update
Message-ID: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>

Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24.

The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk.

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

Commit messages:
 - Backport dec93675ab3e4c271b14a254df75dc838f1346ea

Changes: https://git.openjdk.org/jdk/pull/23307/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23307&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347498
  Stats: 93 lines in 26 files changed: 33 ins; 15 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/23307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23307/head:pull/23307

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

From dnguyen at openjdk.org  Fri Jan 24 22:31:46 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 24 Jan 2025 22:31:46 GMT
Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
Message-ID: <-BBvNQbrAoMMC_FayqUfV3YMlvRVWXOHVnpI6yhcuQ4=.dad22090-982f-4546-8f69-b5aef9178355@github.com>

On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24.
> 
> The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk.

Backport looks fine and normal to me.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23307#pullrequestreview-2573707535

From acobbs at openjdk.org  Fri Jan 24 23:05:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 23:05:51 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash
In-Reply-To: <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
Message-ID: <AusnuufwdmfCmCw0sVcmmVPVHrNtOHBOUa2s--blmNQ=.24b93a33-0ead-42b5-9000-02937057fe35@github.com>

On Fri, 24 Jan 2025 18:40:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JEP 455 adds support for `switch`'ing on `long`, `float`, `double`, and `boolean`. Since this feature is still in preview, the `--enable-preview` flag is required. The compiler was properly checking that when the expressions had primitive type, but not when the expression a corresponding boxed type (i.e., `Long`, `Float`, `Double`, and `Boolean`). This resulted in `BootstrapMethodError` failures at runtime. This PR closes that loophole.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1706:
> 
>> 1704:             boolean intSwitch = types.isAssignable(seltype, syms.intType);
>> 1705:             boolean patternSwitch;
>> 1706:             if (seltypeUnboxed.isPrimitive() && !intSwitch) {
> 
> Sorry, but this seems wrong. Having a selector type of type `Boolean` is not a preview feature (since JDK 21). I.e. this is completely valid:
> 
> public class Test {
>     public static void main(String... args) {
>         Boolean b = true;
>         System.err.println(switch (b) { case Boolean bb -> bb; });
>     }
> }
> 
> 
> I think there needs to be a preview check in the section that handles constant labels, probably somewhere here:
> https://github.com/openjdk/jdk/blob/76f792b55263faf883e54cb879d8609f87164e51/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1808

Ah! My apologies, I totally misunderstood the cause of this issue.

Since this is more complicated than I thought I will defer back to Angelos who is the expert.

Thanks. Closing this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23303#discussion_r1929342090

From acobbs at openjdk.org  Fri Jan 24 23:05:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 23:05:51 GMT
Subject: Withdrawn: 8348410: Preview flag not checked during compilation
 resulting in runtime crash
In-Reply-To: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
Message-ID: <KaLRGVTeRJbLB43tyrXanL2MJXCacyrDQIMa39RycDI=.e052a6b4-8b4a-4b55-9c5f-aa4a000dc46f@github.com>

On Fri, 24 Jan 2025 17:12:00 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> JEP 455 adds support for `switch`'ing on `long`, `float`, `double`, and `boolean`. Since this feature is still in preview, the `--enable-preview` flag is required. The compiler was properly checking that when the expressions had primitive type, but not when the expression a corresponding boxed type (i.e., `Long`, `Float`, `Double`, and `Boolean`). This resulted in `BootstrapMethodError` failures at runtime. This PR closes that loophole.

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Fri Jan 24 23:08:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Jan 2025 23:08:47 GMT
Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
Message-ID: <dzoRtSHj4OleHt32NbcYarG6pP4fo0j-4KfG1zruD08=.c1a55334-84a1-4c41-a5ce-743179ccbc48@github.com>

On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24.
> 
> The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23307#pullrequestreview-2573755873

From acobbs at openjdk.org  Fri Jan 24 23:34:28 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 23:34:28 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition [v2]
In-Reply-To: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
Message-ID: <_n7hsThMGaGZhlj2DiHBN63oeiajVON_Qmn_gSdPpjM=.d075b726-061d-4054-850b-8d52bcf7ab37@github.com>

> The purpose of `DeferredLintHandler` is to allow `@SuppressWarnings` to be applied to warnings that are generated before `@SuppressWarnings` annotations themselves have been processed. The way this currently works is that warning callbacks are kept in a `HashMap` keyed by the innermost containing module, package, class, method, or variable declarations (in the form of a `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`). Later, when the compiler executes the attribution phase and the lint categories suppressed at each declaration are known, the corresponding warning callbacks are provided with an appropriately configured `Lint` instance and "flushed".
> 
> However, the `DeferredLintHandler` API uses `DiagnosticPosition` instead of `JCTree` for registering and flushing deferred warnings. This opens the door for bugs where warnings are registered to an object which is not a declaration, and therefore ignored.
> 
> In fact, this occurs once in the code ([here](https://github.com/openjdk/jdk/blob/48ece0721489c1b357aaa81e89fe59f486079d15/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L679)) where a `JCExpression` is being passed, although in this case the bug appears to be harmless (because annotation values can't contain any type of declaration).
> 
> The API should be tighted up, and furthermore an assertion should be added to verify that the JCTree being passed is actually a declaration supporting `@SuppressWarnings`.
> 
> In addition, there is a design flaw in the API: it's not possible to obtain the current immediate mode `Lint` object, so if an immediate mode `Lint` object is pushed/popped more than once, the second `Lint` object will overwrite the first.
> 
> To fix this, the API should be adjusted so the stack of current declarations and/or immediate mode `Lint` objects is managed by the `DeferredLintHandler` itself, by providing a `push()` and `pop()` methods in the API.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8348427 to fix conflict.
 - Refactor the DeferredLintHandler API to maintain the "stack" itself.
 - Add Javadoc to document a subtley in the API.
 - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition.

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

Changes: https://git.openjdk.org/jdk/pull/23281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23281&range=01
  Stats: 211 lines in 9 files changed: 52 ins; 29 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/23281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23281/head:pull/23281

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

From acobbs at openjdk.org  Fri Jan 24 23:34:28 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 24 Jan 2025 23:34:28 GMT
Subject: RFR: 8348427: DeferredLintHandler API should use JCTree instead of
 DiagnosticPosition
In-Reply-To: <5h1q3QVhdhAR7agyKX_JmImu4ef57LT830RUYuvXcY0=.2075f449-ab8c-4eb8-95cb-8aec0ab22fd5@github.com>
References: <Douo6vtVARp-pjv29VwN4tuiaX6G5lzJ3ckWWp9aLnI=.4a36d5be-e495-40fe-9e6d-0adff4c18cec@github.com>
 <YIbEbBT8EqlviE0Hzoq8A0thmtSi__yAOCmpOn4Momg=.b6bc6425-29c2-4de9-8c1d-65a3b26c5114@github.com>
 <aVnBjfdWOP5Zqnx07hDKh4PrCs10uzG-hPcIfHWv47U=.582c06ad-1fde-4129-8cdb-5a7faa6baac4@github.com>
 <5h1q3QVhdhAR7agyKX_JmImu4ef57LT830RUYuvXcY0=.2075f449-ab8c-4eb8-95cb-8aec0ab22fd5@github.com>
Message-ID: <h6eqmsVcl1KP3L6BX0sy089y86VPLqpcQt_5UK2wDRg=.825a5a70-d7b4-48d6-9247-f4be3666cf0d@github.com>

On Fri, 24 Jan 2025 18:42:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This seems like a great plan. We don't have to get there in one step (and this PR can proceed separately). I just want to make sure that we end up somewhere around there :-)

Sounds good. I created [JDK-8348611](https://bugs.openjdk.org/browse/JDK-8348611) to capture the idea.

> I believe that in `flow` we still see all the classes in the same source as belonging to the same toplevel unit. It's after desugar that things start to get messier. So, I believe that the warning visitor can assume that it's called once per compilation unit, and call flush on all the stuff that belongs to that unit.

Thanks - that makes life simpler.

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

PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2613589887

From iris at openjdk.org  Sat Jan 25 01:20:59 2025
From: iris at openjdk.org (Iris Clark)
Date: Sat, 25 Jan 2025 01:20:59 GMT
Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
Message-ID: <7HHGVvdg10IEwU0ntbgYFeXJ5L3btQgva7Ey3pmD83Y=.f5442616-24c2-422d-a090-9f46086b98ba@github.com>

On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24.
> 
> The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23307#pullrequestreview-2573871901

From acobbs at openjdk.org  Sat Jan 25 18:05:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 25 Jan 2025 18:05:52 GMT
Subject: Integrated: 8348212: Need to add warn() step to JavacTaskImpl after
 JDK-8344148
In-Reply-To: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
References: <R2ZyTBArkoDpABfC26JILqcpWaexpKljV4Hkwp0AlZk=.dabb2b17-48aa-4dc9-b161-315946cafb03@github.com>
Message-ID: <6k8_zkUY7ND0efJnBtpXXH2GNvle-NZD0ZEzdGfs0yg=.f977bd8f-33fd-45a4-8695-baa48073b35c@github.com>

On Tue, 21 Jan 2025 23:42:29 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> In [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) a new `warn()` compiler phase was added and `JavaCompiler.java` was updated accordingly.
> 
> However, the class `JavacTaskImpl` also walks through the compiler phases step-by-step, but the new `warn()` step was never added there. This will cause some warnings to not be emitted when that API is used.
> 
> This PR adds the missing `warn()` calls.

This pull request has now been integrated.

Changeset: 5431668c
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5431668cb92a8ef2ccfe1059db1cde0e5d98adce
Stats:     90 lines in 2 files changed: 88 ins; 0 del; 2 mod

8348212: Need to add warn() step to JavacTaskImpl after JDK-8344148

Reviewed-by: mcimadamore

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

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

From acobbs at openjdk.org  Sat Jan 25 23:01:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 25 Jan 2025 23:01:38 GMT
Subject: RFR: 8347958: Minor compiler cleanups relating to
 MandatoryWarningHandler [v2]
In-Reply-To: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com>
References: <-8kPXPXKm9itoPQw509dc7-qVsaGQoItWUdfjsdm2Bo=.fdb56031-0392-44d7-b190-e30fc25b17ca@github.com>
Message-ID: <FzRGQ5bEfOwZHTNzkUCxWbBMR-zDZ83tlgvm3GOzJxY=.d8f11d31-884a-40f3-91b1-e019d77de4d7@github.com>

> After recent improvements to Lint-related classes, there are now a few minor cleanup opportunities relating to `MandatoryWarningHandler`.
> 
> 1. The new `LintWarning` class provides access to the associated `LintCategory`. This means that the `LintCategory` parameter being passed to the `MandatoryWarningHandler` constructor is no longer needed.
> 1. The `prefix` string being passed to the `MandatoryWarningHandler` constructor can (in most cases) be inferred as well.
> 1. The field `Check.sunApiHandler` (which has type `MandatoryWarningHandler`) is no longer used and can be removed.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8347958 to fix conflict.
 - Some cleanups relating to MandatoryWarningHandler.

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

Changes: https://git.openjdk.org/jdk/pull/23167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23167&range=01
  Stats: 61 lines in 3 files changed: 28 ins; 22 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23167/head:pull/23167

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

From acobbs at openjdk.org  Sun Jan 26 20:10:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 26 Jan 2025 20:10:38 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v4]
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <JDVbYeGzOGDuNJQGgMNPpIMSVqvh5OelNfhM8a_QFB8=.73b44655-0b48-4025-a433-37a2210e6782@github.com>

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.

Archie Cobbs 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 branch 'master' into JDK-8224228 to fix conflict.
 - Put back required flushing of binding pattern variable declaration.
 - Remove Attr.flushDeferredLintHandler() which doesn't appear necessary.
 - Merge branch 'JDK-8348427' into JDK-8224228
 - Refactor the DeferredLintHandler API to maintain the "stack" itself.
 - Add Javadoc to document a subtley in the API.
 - Update DeferredLintHandler API to use JCTree instead of DiagnosticPosition.
 - Fixes and cleanups.
 - Merge branch 'master' into JDK-8224228
 - Bug fixes.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/907350e9...03f08d96

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

Changes: https://git.openjdk.org/jdk/pull/23237/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23237&range=03
  Stats: 727 lines in 22 files changed: 503 ins; 41 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/23237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237

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

From acobbs at openjdk.org  Sun Jan 26 20:27:41 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 26 Jan 2025 20:27:41 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v5]
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <zYf27KopVlg6scy3llay3lD2nswhMolotN0FrVNWtao=.41b86c6d-fccd-4d5d-9057-569075ed1b23@github.com>

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
> 
> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's:
> * #23167
> * #23281

Archie Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'JDK-8347958' into JDK-8224228
 - Merge branch 'master' into JDK-8347958 to fix conflict.
 - Some cleanups relating to MandatoryWarningHandler.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23237/files
  - new: https://git.openjdk.org/jdk/pull/23237/files/03f08d96..6cc1eae5

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

  Stats: 65 lines in 3 files changed: 33 ins; 22 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237

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

From jlu at openjdk.org  Mon Jan 27 17:27:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Jan 2025 17:27:53 GMT
Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
Message-ID: <GQiZ7sXE7F2byYWtIN5sWm_mUzMwD_eRemjJfYPJVk0=.154e98cb-001b-4741-a08b-116c735082d6@github.com>

On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24.
> 
> The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23307#issuecomment-2616430340

From jlu at openjdk.org  Mon Jan 27 17:27:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Jan 2025 17:27:54 GMT
Subject: [jdk24] Integrated: 8347498: JDK 24 RDP2 L10n resource files update
In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com>
Message-ID: <9auIj0WRflyzVXt6UFfMaOa8CzlSwgPYww5cJ13905Q=.2fa6a88b-514e-4ac6-b814-f29f58bb7005@github.com>

On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24.
> 
> The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk.

This pull request has now been integrated.

Changeset: a315b932
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a315b9326b07a6241858c55d15e4cbec4ab3773b
Stats:     93 lines in 26 files changed: 33 ins; 15 del; 45 mod

8347498: JDK 24 RDP2 L10n resource files update

Reviewed-by: dnguyen, naoto, iris
Backport-of: dec93675ab3e4c271b14a254df75dc838f1346ea

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

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

From stephan.herrmann at berlin.de  Tue Jan 28 14:24:59 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 28 Jan 2025 15:24:59 +0100
Subject: Is the null type a reference type?
Message-ID: <12de8425-344f-4e89-980d-0d2d166ba39b@berlin.de>

Assume this (nonsense) program, which is accepted by javac and ecj:

public class X {
	public static void main(String[] args) {
		switch (null) {
			case null -> System.out.println("Null");
			default-> System.out.println("Default");
		}
	}
}

14.1.1 Switch Blocks requires (T is the type of the selector expression):
* If a null literal is associated with the switch block, then T is a reference type.

In our case the selector expression has the null type, which can be assigned to 
any reference type, but it doesn't seem to be a reference type itself.

 From this I would conclude that the program is illegal.


Next, lets remove the default case from the same program. Now compilers 
complain, here's how javac puts it:

X.java:3: error: the switch statement does not cover all possible input values
                 switch (null) {
                 ^
1 error

In previous discussions I learned that requiring a default label may be 
justified by requirements of future changes, but here for this reasoning to hold 
the null type would need to acquire new values, which seems very unlikely :). 
So, if the initial program would get the blessing from JLS, then also this case 
(without default) deserves a second look.

thanks,
Stephan

From davidalayachew at gmail.com  Tue Jan 28 16:40:36 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 28 Jan 2025 11:40:36 -0500
Subject: Is the null type a reference type?
In-Reply-To: <12de8425-344f-4e89-980d-0d2d166ba39b@berlin.de>
References: <12de8425-344f-4e89-980d-0d2d166ba39b@berlin.de>
Message-ID: <CAA9v-_MTmZr__azO7g0nsftQGYUsviSkLVOhTDhw6dPk9V6qTA@mail.gmail.com>

Isn't null a value and not a type?

On Tue, Jan 28, 2025, 9:25?AM Stephan Herrmann <stephan.herrmann at berlin.de>
wrote:

> Assume this (nonsense) program, which is accepted by javac and ecj:
>
> public class X {
>         public static void main(String[] args) {
>                 switch (null) {
>                         case null -> System.out.println("Null");
>                         default-> System.out.println("Default");
>                 }
>         }
> }
>
> 14.1.1 Switch Blocks requires (T is the type of the selector expression):
> * If a null literal is associated with the switch block, then T is a
> reference type.
>
> In our case the selector expression has the null type, which can be
> assigned to
> any reference type, but it doesn't seem to be a reference type itself.
>
>  From this I would conclude that the program is illegal.
>
>
> Next, lets remove the default case from the same program. Now compilers
> complain, here's how javac puts it:
>
> X.java:3: error: the switch statement does not cover all possible input
> values
>                  switch (null) {
>                  ^
> 1 error
>
> In previous discussions I learned that requiring a default label may be
> justified by requirements of future changes, but here for this reasoning
> to hold
> the null type would need to acquire new values, which seems very unlikely
> :).
> So, if the initial program would get the blessing from JLS, then also this
> case
> (without default) deserves a second look.
>
> thanks,
> Stephan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/04bc1e33/attachment-0001.htm>

From stephan.herrmann at berlin.de  Tue Jan 28 16:58:11 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 28 Jan 2025 17:58:11 +0100
Subject: Is the null type a reference type?
In-Reply-To: <CAA9v-_MTmZr__azO7g0nsftQGYUsviSkLVOhTDhw6dPk9V6qTA@mail.gmail.com>
References: <12de8425-344f-4e89-980d-0d2d166ba39b@berlin.de>
 <CAA9v-_MTmZr__azO7g0nsftQGYUsviSkLVOhTDhw6dPk9V6qTA@mail.gmail.com>
Message-ID: <4241cb86-709a-4bb4-b01f-f41514ef6928@berlin.de>

Am 28.01.25 um 17:40 schrieb David Alayachew:
> Isn't null a value and not a type?

null is a value, and null type is a type,
  see https://docs.oracle.com/javase/specs/jls/se23/html/jls-4.html#jls-4.1

> 
> On Tue, Jan 28, 2025, 9:25?AM Stephan Herrmann <stephan.herrmann at berlin.de 
> <mailto:stephan.herrmann at berlin.de>> wrote:
> 
>     Assume this (nonsense) program, which is accepted by javac and ecj:
> 
>     public class X {
>      ? ? ? ? public static void main(String[] args) {
>      ? ? ? ? ? ? ? ? switch (null) {
>      ? ? ? ? ? ? ? ? ? ? ? ? case null -> System.out.println("Null");
>      ? ? ? ? ? ? ? ? ? ? ? ? default-> System.out.println("Default");
>      ? ? ? ? ? ? ? ? }
>      ? ? ? ? }
>     }
> 
>     14.1.1 Switch Blocks requires (T is the type of the selector expression):
>     * If a null literal is associated with the switch block, then T is a
>     reference type.
> 
>     In our case the selector expression has the null type, which can be assigned to
>     any reference type, but it doesn't seem to be a reference type itself.
> 
>      ?From this I would conclude that the program is illegal.
> 
> 
>     Next, lets remove the default case from the same program. Now compilers
>     complain, here's how javac puts it:
> 
>     X.java:3: error: the switch statement does not cover all possible input values
>      ? ? ? ? ? ? ? ? ?switch (null) {
>      ? ? ? ? ? ? ? ? ?^
>     1 error
> 
>     In previous discussions I learned that requiring a default label may be
>     justified by requirements of future changes, but here for this reasoning to
>     hold
>     the null type would need to acquire new values, which seems very unlikely :).
>     So, if the initial program would get the blessing from JLS, then also this case
>     (without default) deserves a second look.
> 
>     thanks,
>     Stephan
> 


From stephan.herrmann at berlin.de  Tue Jan 28 17:49:15 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Tue, 28 Jan 2025 18:49:15 +0100
Subject: named pattern variable in pattern list
Message-ID: <d332432f-49eb-410e-88fd-5176f2afd376@berlin.de>

Our tests reveal a difference between compilers regarding this program:

	public class X {
		record Point (int x, int y) {}
		static void foo(Object o) {
		switch (o) {
			case Integer _, Point(int x, int _), String _  :
			    System.out.println("Integer");
			default:
			    System.out.println("Object");
		}
		}
		public static void main(String [] args) {
			foo("");
		}
	}

We expect an error to be raised against x in the record pattern, because it 
seems to violate this from JLS ?14.11.1:

"It is a compile-time error for a case label to have more than one case pattern 
and declare any pattern variables (other than those declared by a guard 
associated with the case label)."

This program is accepted by javac. Am I right to assume that this is a bug in javac?

thanks,
Stephan

From cushon at google.com  Tue Jan 28 18:51:22 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 28 Jan 2025 10:51:22 -0800
Subject: Capture conversion and switch selectors
Message-ID: <CAL4QsgvhGvq419=5a78HDFkRWv8d55KTf05mmhXhSqDtQMYdYg@mail.gmail.com>

Hi,

Chris Povirk and I were trying to understand why examples like the
following are rejected:

sealed interface A<T> {
  enum B implements A<String> {
    C;
  }

  static void d(A<?> a) {
    switch (a) {
      case B.C:
    }
  }
}

A.java:8: error: incompatible types: B cannot be converted to A<CAP#1>
      case B.C:
            ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object from capture of ?

I think this is a consequence of JLS 6.5.6.1, which says that the type of
the switch selector expression is subject to capture conversion, and then
the captured type is not convertible.

In the implementation, this is happening here [1], where attribExpr uses
KindSelector.VAL, which causes the capture to happen.

Has consideration been given to treating selector expressions differently,
to avoid the capture conversion, and allow examples like this to compile? I
couldn't find test coverage for this specific combination of features,
which made me wonder if this was a corner case that hadn't been explored,
rather than something that had definitely been ruled out.

Liam

[1]
https://github.com/openjdk/jdk/blob/a224f12cb701b45df4706a403a05c66de2d623af/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1702
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/1b497948/attachment.htm>

From davidalayachew at gmail.com  Tue Jan 28 19:07:55 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 28 Jan 2025 14:07:55 -0500
Subject: Would it make sense to make missing/incorrect method errors be above
 generics errors?
Message-ID: <CAA9v-_PujkH28Mvv7NNiPOdUJEXq9j0kFxWduypqTTBD4Q2Lsw@mail.gmail.com>

Hello Compiler Dev Team,

I am coming in entirely ignorant of how the compiler works under the hood.
I am trying to correct this ignorance, but I hope you'll forgive an
ignorant question in the meantime.

Would it make sense to have missing method errors (can't find symbol) be
above errors like invalid method references (trying to use non-static
method in static context)?

Basically, I am just asking to alter the output order of compile time
errors. We all have run into situations where we get this nightmarish
generics error, and the actual error is that we mispelled a method name or
something. However, the misspelled error is usually beneath the ugly
generics error.

If the top of the list was a "can't find symbol", that would make it much
more obvious what the problem is. Then, when the problem actually is our
generics, then it will be unambiguous as opposed to trying to parse the
many errors in compile time.

Of course, if altering error output order is a pandora's box that we don't
want to open, then I understand. From my ignorant opinion, altering the
output order of an already compiled list seems easy, but maybe there are
rules in place that prevent that, or we don't want to mess with people's
mental model. Or maybe we are expected to have read the entire list of
errors and parse the best next steps only after having read the whole thing
lol. I don't know.

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/1d3c3d5e/attachment-0001.htm>

From davidalayachew at gmail.com  Tue Jan 28 19:08:28 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 28 Jan 2025 14:08:28 -0500
Subject: Is the null type a reference type?
In-Reply-To: <4241cb86-709a-4bb4-b01f-f41514ef6928@berlin.de>
References: <12de8425-344f-4e89-980d-0d2d166ba39b@berlin.de>
 <CAA9v-_MTmZr__azO7g0nsftQGYUsviSkLVOhTDhw6dPk9V6qTA@mail.gmail.com>
 <4241cb86-709a-4bb4-b01f-f41514ef6928@berlin.de>
Message-ID: <CAA9v-_NCS9g+dqUCUUWPJTVv4z0iwU4BuagMNm5Sk=NE+45W1g@mail.gmail.com>

Ty vm.

On Tue, Jan 28, 2025, 11:58?AM Stephan Herrmann <stephan.herrmann at berlin.de>
wrote:

> Am 28.01.25 um 17:40 schrieb David Alayachew:
> > Isn't null a value and not a type?
>
> null is a value, and null type is a type,
>   see
> https://docs.oracle.com/javase/specs/jls/se23/html/jls-4.html#jls-4.1
>
> >
> > On Tue, Jan 28, 2025, 9:25?AM Stephan Herrmann <
> stephan.herrmann at berlin.de
> > <mailto:stephan.herrmann at berlin.de>> wrote:
> >
> >     Assume this (nonsense) program, which is accepted by javac and ecj:
> >
> >     public class X {
> >              public static void main(String[] args) {
> >                      switch (null) {
> >                              case null -> System.out.println("Null");
> >                              default-> System.out.println("Default");
> >                      }
> >              }
> >     }
> >
> >     14.1.1 Switch Blocks requires (T is the type of the selector
> expression):
> >     * If a null literal is associated with the switch block, then T is a
> >     reference type.
> >
> >     In our case the selector expression has the null type, which can be
> assigned to
> >     any reference type, but it doesn't seem to be a reference type
> itself.
> >
> >       From this I would conclude that the program is illegal.
> >
> >
> >     Next, lets remove the default case from the same program. Now
> compilers
> >     complain, here's how javac puts it:
> >
> >     X.java:3: error: the switch statement does not cover all possible
> input values
> >                       switch (null) {
> >                       ^
> >     1 error
> >
> >     In previous discussions I learned that requiring a default label may
> be
> >     justified by requirements of future changes, but here for this
> reasoning to
> >     hold
> >     the null type would need to acquire new values, which seems very
> unlikely :).
> >     So, if the initial program would get the blessing from JLS, then
> also this case
> >     (without default) deserves a second look.
> >
> >     thanks,
> >     Stephan
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/e392abba/attachment.htm>

From cushon at google.com  Tue Jan 28 20:00:28 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 28 Jan 2025 12:00:28 -0800
Subject: History of using -parameters for JDK builds
Message-ID: <CAL4Qsgu+7CLqONy0NmPVtPpUS4HsriRiz1WWYvmgwvfDfsLNxQ@mail.gmail.com>

Hi,

I was wondering if anyone on the list knows of prior discussions about
using -parameters when building the JDK itself. (compiler-dev@ isn't
exactly the right list but I'm not sure where else to ask,
enhanced-metadata-spec-discuss@ is archived.)

JEP 118 added support for -parameters and the corresponding model APIs to
read parameter names. I understand why the change is opt-in, and there's
some related discussion about that on the lists:

https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html
https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000202.html

I was curious if there's been any discussion about enabling the feature
specifically when building the JDK itself? All of the general concerns
would apply there as well (class file size, compatibility surface).

I understand this isn't a small change, and am not making an argument for
doing it, but I'm curious if this has already been considered and there's
history on the lists I can read up on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/15db4286/attachment.htm>

From chen.l.liang at oracle.com  Tue Jan 28 20:17:26 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 28 Jan 2025 20:17:26 +0000
Subject: History of using -parameters for JDK builds
In-Reply-To: <CAL4Qsgu+7CLqONy0NmPVtPpUS4HsriRiz1WWYvmgwvfDfsLNxQ@mail.gmail.com>
References: <CAL4Qsgu+7CLqONy0NmPVtPpUS4HsriRiz1WWYvmgwvfDfsLNxQ@mail.gmail.com>
Message-ID: <SJ2PR10MB766917368CA56EC81E76C470A2EF2@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Liam,
I believe turning on -parameters is no longer as necessary with the introduction of JDK-8292275<https://bugs.openjdk.org/browse/JDK-8292275>, which enforces emission of relevant access flags for parameters that can affect core reflection behavior.
In addition, parameter name changes are not considered in the CSR process; relying on them would be risky.
Another event of note is that due to JDK-8058322<https://bugs.openjdk.org/browse/JDK-8058322>, such emitted parameters fail core reflection in JDK 8. A fix has since been backported by me.

I believe the main value of parameter is not to reflect on them, but to interpret the contents of signatures and annotations.  They omit some synthetic or mandated parameters, and only MethodParameters inform users which parameters exactly should be omitted.

Regards,
Chen Liang
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Liam Miller-Cushon <cushon at google.com>
Sent: Tuesday, January 28, 2025 2:00 PM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: History of using -parameters for JDK builds

Hi,

I was wondering if anyone on the list knows of prior discussions about using -parameters when building the JDK itself. (compiler-dev@ isn't exactly the right list but I'm not sure where else to ask, enhanced-metadata-spec-discuss@ is archived.)

JEP 118 added support for -parameters and the corresponding model APIs to read parameter names. I understand why the change is opt-in, and there's some related discussion about that on the lists:

https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html
https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000202.html

I was curious if there's been any discussion about enabling the feature specifically when building the JDK itself? All of the general concerns would apply there as well (class file size, compatibility surface).

I understand this isn't a small change, and am not making an argument for doing it, but I'm curious if this has already been considered and there's history on the lists I can read up on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/2742c425/attachment-0001.htm>

From cushon at google.com  Tue Jan 28 20:29:36 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 28 Jan 2025 12:29:36 -0800
Subject: History of using -parameters for JDK builds
In-Reply-To: <SJ2PR10MB766917368CA56EC81E76C470A2EF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAL4Qsgu+7CLqONy0NmPVtPpUS4HsriRiz1WWYvmgwvfDfsLNxQ@mail.gmail.com>
 <SJ2PR10MB766917368CA56EC81E76C470A2EF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAL4QsgsT8sdv-vZ9FNFm_t-Ti5x22fs8UxVSpNJcDEWzS6fkaA@mail.gmail.com>

Thanks Chen,

Another concrete use case for parameter names is for static analysis. For
example an analyzer might want to use parameter names as a signal to detect
cases where arguments are passed to a particular API in the wrong order, to
detect mistakes like:

int index = s.indexOf(fromIndex, '/'); // whoops, fromIndex should be the
second argument

(This hypothetical analyzer would find a bunch of interesting cases where
arguments were deliberately 'swapped' relative to the formal parameter
names, the general point here is just that parameter names are sometimes
interesting to static analyzers.)

Currently the parameter names can sometimes be retrieved from the LVT, but
-parameters would be more reliable.

I think your point about CSRs gets at one of the main challenges with this.
It might require either carefully reviewing existing parameter names and
committing to making them stable, and considering them as part of CSR
reviews; or else trying to set expectations that the names were not part of
the supported interface and people shouldn't rely on them, but they would
anyway, and it would lead to complaints when they changed. So none of this
is something that I'd expect to be done lightly.

On Tue, Jan 28, 2025 at 12:17?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Liam,
> I believe turning on -parameters is no longer as necessary with the
> introduction of JDK-8292275 <https://bugs.openjdk.org/browse/JDK-8292275>,
> which enforces emission of relevant access flags for parameters that can
> affect core reflection behavior.
> In addition, parameter name changes are not considered in the CSR process;
> relying on them would be risky.
> Another event of note is that due to JDK-8058322
> <https://bugs.openjdk.org/browse/JDK-8058322>, such emitted parameters
> fail core reflection in JDK 8. A fix has since been backported by me.
>
> I believe the main value of parameter is not to reflect on them, but to
> interpret the contents of signatures and annotations.  They omit some
> synthetic or mandated parameters, and only MethodParameters inform users
> which parameters exactly should be omitted.
>
> Regards,
> Chen Liang
> ------------------------------
> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Liam
> Miller-Cushon <cushon at google.com>
> *Sent:* Tuesday, January 28, 2025 2:00 PM
> *To:* compiler-dev at openjdk.org <compiler-dev at openjdk.org>
> *Subject:* History of using -parameters for JDK builds
>
> Hi,
>
> I was wondering if anyone on the list knows of prior discussions about
> using -parameters when building the JDK itself. (compiler-dev@ isn't
> exactly the right list but I'm not sure where else to ask,
> enhanced-metadata-spec-discuss@ is archived.)
>
> JEP 118 added support for -parameters and the corresponding model APIs to
> read parameter names. I understand why the change is opt-in, and there's
> some related discussion about that on the lists:
>
>
> https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html
>
> https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000202.html
>
> I was curious if there's been any discussion about enabling the feature
> specifically when building the JDK itself? All of the general concerns
> would apply there as well (class file size, compatibility surface).
>
> I understand this isn't a small change, and am not making an argument for
> doing it, but I'm curious if this has already been considered and there's
> history on the lists I can read up on.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/be304564/attachment.htm>

From alex.buckley at oracle.com  Tue Jan 28 22:37:56 2025
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 28 Jan 2025 14:37:56 -0800
Subject: History of using -parameters for JDK builds
In-Reply-To: <SJ2PR10MB766917368CA56EC81E76C470A2EF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAL4Qsgu+7CLqONy0NmPVtPpUS4HsriRiz1WWYvmgwvfDfsLNxQ@mail.gmail.com>
 <SJ2PR10MB766917368CA56EC81E76C470A2EF2@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <c891d29b-854a-4d96-9c7b-5b7248716c38@oracle.com>

Chen,

Specifically on this JBS item:

On 1/28/2025 12:17 PM, Chen Liang wrote:
> I believe turning on -parameters is no longer as necessary with the 
> introduction of JDK-8292275 ...

This bug, and the corresponding CSR which authorized automatic 
generation of MethodParameters (JDK-8292467), would be much easier to 
comprehend if they stated clearly that:

   Parameter names are _not_ included in the generated attribute.
   It continues to be necessary to specify -parameters at compile time
   to generate MethodParameters attributes with parameter names.

Alex

From acobbs at openjdk.org  Tue Jan 28 22:44:01 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 28 Jan 2025 22:44:01 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v6]
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <RDNGBJhRU8v81IzNBvlQMWxb79g6ylg1UO7r1uKwz_g=.1cfa1574-0c14-4e31-9c76-ebde032b225a@github.com>

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
> 
> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's:
> * #23167
> * #23281

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

  Instead of using EndPosTable, track ending positions of declarations explicitly.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23237/files
  - new: https://git.openjdk.org/jdk/pull/23237/files/6cc1eae5..7ad56bb5

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

  Stats: 121 lines in 10 files changed: 54 ins; 22 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/23237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237

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

From daniel.smith at oracle.com  Tue Jan 28 22:54:46 2025
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 28 Jan 2025 22:54:46 +0000
Subject: Is the null type a reference type?
In-Reply-To: <12de8425-344f-4e89-980d-0d2d166ba39b@berlin.de>
References: <12de8425-344f-4e89-980d-0d2d166ba39b@berlin.de>
Message-ID: <42204179-3EB5-4EDF-95A8-BD38950529CE@oracle.com>

> On Jan 28, 2025, at 6:24?AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
> 
> 14.1.1 Switch Blocks requires (T is the type of the selector expression):
> * If a null literal is associated with the switch block, then T is a reference type.
> 
> In our case the selector expression has the null type, which can be assigned to any reference type, but it doesn't seem to be a reference type itself.
> 
> From this I would conclude that the program is illegal.

See also this assertion from 14.19 about 'synchronized' statements:

"The type of Expression must be a reference type, or a compile-time error occurs."

In this case, 'synchronized (null) { ... }' gets a compiler error.

So, yes, to be consistent, 14.11.1 should explicitly allow 'T' to be a null type.

(I *don't* think it is the intent to reject the switch expression, as evidenced by the reference implementation behavior, and the fact that no rule rejects a switch that leaves out the 'case null'.)

I filed a bug: https://bugs.openjdk.org/browse/JDK-8348901

> Next, lets remove the default case from the same program. Now compilers complain, here's how javac puts it:
> 
> X.java:3: error: the switch statement does not cover all possible input values
>                switch (null) {
>                ^
> 1 error

> So, if the initial program would get the blessing from JLS, then also this case (without default) deserves a second look.

The rules about what counts as exhaustive are laid out in 14.11.1.1. This case is not mentioned, so the spec and implementation are consistent in rejecting it.

I agree it could be worth thinking about this case more, though. (It's not practically useful, but it can be used to explore the underlying rules/intuitions.) JEP 488 enhances exhaustiveness to cover 'case true -> ...; case false -> ...;'. It might make sense to treat this as an additional exhaustiveness refinement to consider.

I actually think that, since exhaustiveness is happy to ignore 'null' in other cases, it might want to treat this switch as exhaustive even if there are *no* case labels.

On the other hand, we typically report a compile-time error if a null literal will trigger a guaranteed NPE (see the 'synchronized' rule above). So maybe it's worth having a special rule that *mandates* a null-handling case?


From alex.buckley at oracle.com  Tue Jan 28 23:06:33 2025
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 28 Jan 2025 15:06:33 -0800
Subject: History of using -parameters for JDK builds
In-Reply-To: <CAL4Qsgu+7CLqONy0NmPVtPpUS4HsriRiz1WWYvmgwvfDfsLNxQ@mail.gmail.com>
References: <CAL4Qsgu+7CLqONy0NmPVtPpUS4HsriRiz1WWYvmgwvfDfsLNxQ@mail.gmail.com>
Message-ID: <e4dd2fc6-03be-4cb5-844b-7d4b000d4d5c@oracle.com>

On 1/28/2025 12:00 PM, Liam Miller-Cushon wrote:
> I was curious if there's been any discussion about enabling the feature 
> specifically when building the JDK itself? All of the general concerns 
> would apply there as well (class file size, compatibility?surface).
> 
> I understand this isn't a small change, and am not making an argument 
> for doing it, but I'm curious if this has already been considered?and 
> there's history on the lists I can read up on.

It was considered internally in the years leading up to Java 8. We 
considered the high utility to IDEs, the increased complexity of the 
build, the larger amount of "debug" information in the image (by some 
viewpoints), and the general lack of consistency of parameter names in 
JDK code. I don't really see anything that has changed in the ensuing 
decade+ that would cause a different decision today.

Alex

From jan.lahoda at oracle.com  Wed Jan 29 07:44:54 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 29 Jan 2025 08:44:54 +0100
Subject: named pattern variable in pattern list
In-Reply-To: <d332432f-49eb-410e-88fd-5176f2afd376@berlin.de>
References: <d332432f-49eb-410e-88fd-5176f2afd376@berlin.de>
Message-ID: <fb9c9cfd-c300-41aa-8588-378688437ab9@oracle.com>

Hello Stephan,


I've filled:

https://bugs.openjdk.org/browse/JDK-8348928


Thanks for the report!


Jan


On 28. 01. 25 18:49, Stephan Herrmann wrote:
> Our tests reveal a difference between compilers regarding this program:
>
> ????public class X {
> ??????? record Point (int x, int y) {}
> ??????? static void foo(Object o) {
> ??????? switch (o) {
> ??????????? case Integer _, Point(int x, int _), String _? :
> ??????????????? System.out.println("Integer");
> ??????????? default:
> ??????????????? System.out.println("Object");
> ??????? }
> ??????? }
> ??????? public static void main(String [] args) {
> ??????????? foo("");
> ??????? }
> ????}
>
> We expect an error to be raised against x in the record pattern, 
> because it seems to violate this from JLS ?14.11.1:
>
> "It is a compile-time error for a case label to have more than one 
> case pattern and declare any pattern variables (other than those 
> declared by a guard associated with the case label)."
>
> This program is accepted by javac. Am I right to assume that this is a 
> bug in javac?
>
> thanks,
> Stephan

From davidalayachew at gmail.com  Wed Jan 29 20:25:46 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 29 Jan 2025 15:25:46 -0500
Subject: Ran into trouble with JEP-458 -- Launch Multi-File Source-Code
 Programs
Message-ID: <CAA9v-_Piz0Z9p6x4=aDrQR4gw3TaW-hmLv54LxbUvgGVYgnLkg@mail.gmail.com>

Hello Compiler Dev Team,

I have been using JEP 458 to great effect, but I ran into an issue today. I
made a StackOverflow post about it.

https://stackoverflow.com/questions/79398053/why-cant-i-use-the-same-class-path-for-my-compile-command-versus-my-run-command

Long story short, it appears that all my source files must be contained
under a single root. This differs in behaviour from javac, which permits as
many root folders as you want, as long as all of them are listed in your
class path option.

Is there any chance that we could add this functionality in?

Long story short, I found that JEP 458 is actually great for testing
pre-existing classes. Classes that are nested deep in a pre-existing
hierarchy, and therefore, may sometimes be within different root
hierarchies. Being able to have both of these source files on the class
path greatly facilitates testing because I can isolate the individual files
I need,  and test the functionality simply by adding a main method to one
of the classes.

This ended up being super super super useful to me until I finally landed
on an example that has 2 different roots, as I found out in the SO post.

Would it make sense to add the ability to have multiple roots?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250129/518e6e25/attachment.htm>

From acobbs at openjdk.org  Wed Jan 29 21:53:44 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 29 Jan 2025 21:53:44 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v7]
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <dTjBMSKUXBxG2WmKj86KP_yhKFu3bsAi8Ppo-fnrAz4=.051b5184-b2a9-4320-aead-6ba99d55246b@github.com>

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
> 
> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's:
> * #23167
> * #23281

Archie Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - Refactor "dangling-doc-comments" logic to utilize new DeferredLintHandler.
 - Fix bugs when mapping lexical deferrals to declarations.
 - Refactor to eliminate the unnecessary MandatoryWarningHandler "verbose" field.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23237/files
  - new: https://git.openjdk.org/jdk/pull/23237/files/7ad56bb5..ebb6544e

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

  Stats: 131 lines in 5 files changed: 14 ins; 74 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/23237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237

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

From jlahoda at openjdk.org  Thu Jan 30 15:07:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 30 Jan 2025 15:07:54 GMT
Subject: RFR: 8326485: Assertion due to Type.addMetadata adding annotations
 to already-annotated type
In-Reply-To: <8gvMozOrqmReKzLdGSWhQOiVUIZNi7_W6PxXdwfOYD8=.bf2f67ca-4b17-4506-bec2-c1738865b123@github.com>
References: <8gvMozOrqmReKzLdGSWhQOiVUIZNi7_W6PxXdwfOYD8=.bf2f67ca-4b17-4506-bec2-c1738865b123@github.com>
Message-ID: <9b9GWNAX5lcMcNoOAEYFnfR-5P4hv6wE3NYxB9R1F0U=.3d669695-1fa5-4726-8430-a7c0c3e3f0e2@github.com>

On Thu, 23 Jan 2025 16:17:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> We end up with an errorType having annotation metadata (which subsequently results in this assertion getting invalidated after `Type ret = typeWithAnnotations(type, enclTy, annotations);` is executed).
> 
> What if we continue to try to define the `enclTy` (iteratively)? The error can still be reported appropriately. If this PR is merged it reproduces the original test case by running as expected: many errors without a crash:
> 
> 
> javac src/main/java/net/ccbluex/liquidbounce/injection/mixins/minecraft/gui/MixinChatInputSuggestor.java -cp /tmp/jars/annotations-20.1.0.jar:/tmp/jars/kotlin-compiler-embeddable-1.9.0.jar
> 
> 
> WDYT?

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23272#pullrequestreview-2584169163

From asotona at openjdk.org  Thu Jan 30 16:07:52 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 30 Jan 2025 16:07:52 GMT
Subject: RFR: 8347989: Trees.getScope may crash for not-yet attributed
 source
In-Reply-To: <YKrhqZxANO20M1DXIF-2MwPKIAFbOeMBJ6ruvKuZjP8=.eb266810-cb9f-4a80-b194-49856a3a4d3b@github.com>
References: <YKrhqZxANO20M1DXIF-2MwPKIAFbOeMBJ6ruvKuZjP8=.eb266810-cb9f-4a80-b194-49856a3a4d3b@github.com>
Message-ID: <7WE87HxadqWG43-I-8dctSH4bgBggm1lOQzkXKga5lw=.ed1cf158-900c-44f2-aae2-2e025114997b@github.com>

On Fri, 17 Jan 2025 18:21:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
> class Test {
>     private int test(boolean b) {
>         int v = b ? test(!b) : 0;
>         return v;
>     }
> }
> 
> 
> and consider `Trees.getScope` being called for a `TreePath` corresponding to "return" after the "enter" phase, but before `Attr`. E.g. from an annotation processor. This will lead to an exception like:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.accept(com.sun.tools.javac.code.Type$Visitor, Object)" because "t" is null
> at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4936)
> at jdk.compiler/com.sun.tools.javac.code.Types.memberType(Types.java:2306)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.isBooleanOrNumeric(Attr.java:2133)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.isBooleanOrNumeric(Attr.java:2122)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitConditional(Attr.java:2060)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCConditional.accept(JCTree.java:1580)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:723)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitVarDef(Attr.java:1320)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1066)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:751)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:770)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1454)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1136)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
> at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:515)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribToTree(Attr.java:428)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStatToTree(Attr.java:421)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.attribStatToTree(JavacTrees.java:882)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getAttrContext(JavacTrees.java:857)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:723)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:159)
> 
> 
> The reason is that the `Attr.isBooleanOrNumeric` in this case will refer to `env.encClass.type`, but the type of the enclosing class is filled at the end of `Attr.visitCl...

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23179#pullrequestreview-2584348395

From archie.cobbs at gmail.com  Thu Jan 30 16:18:26 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 30 Jan 2025 10:18:26 -0600
Subject: Question about "sourcefile"
Message-ID: <CANSoFxsRJ1HGKaufh8bfLom4tLQYpQMnUp4KFQNumUW2fM3pmQ@mail.gmail.com>

In JavaCompiler.java, there is code that looks like this:

        JavaFileObject prev = log.useSource(

*env.enclClass.sym.sourcefile != null ?
        env.enclClass.sym.sourcefile :
      env.toplevel.sourcefile*);
        try {
            ... do something ...
        } finally {
            log.useSource(prev);
        }

I don't understand why the boldface part is needed. How would it ever be
possible for a class A to have an enclosing class B that exists in a
different source file?

Put another way, isn't env.toplevel.sourcefile always the source file that
corresponds to any class being compiled?

Thanks for any clarifications.

-Archie

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

From jlahoda at openjdk.org  Fri Jan 31 07:58:50 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 31 Jan 2025 07:58:50 GMT
Subject: Integrated: 8347989: Trees.getScope may crash for not-yet attributed
 source
In-Reply-To: <YKrhqZxANO20M1DXIF-2MwPKIAFbOeMBJ6ruvKuZjP8=.eb266810-cb9f-4a80-b194-49856a3a4d3b@github.com>
References: <YKrhqZxANO20M1DXIF-2MwPKIAFbOeMBJ6ruvKuZjP8=.eb266810-cb9f-4a80-b194-49856a3a4d3b@github.com>
Message-ID: <2_y9x7catW06Rqd60ioN7GEF8OHJiCYLSTqPWnkf9G4=.5345f53f-c89a-48fd-a45b-740c0414470f@github.com>

On Fri, 17 Jan 2025 18:21:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
> class Test {
>     private int test(boolean b) {
>         int v = b ? test(!b) : 0;
>         return v;
>     }
> }
> 
> 
> and consider `Trees.getScope` being called for a `TreePath` corresponding to "return" after the "enter" phase, but before `Attr`. E.g. from an annotation processor. This will lead to an exception like:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.accept(com.sun.tools.javac.code.Type$Visitor, Object)" because "t" is null
> at jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4936)
> at jdk.compiler/com.sun.tools.javac.code.Types.memberType(Types.java:2306)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.isBooleanOrNumeric(Attr.java:2133)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.isBooleanOrNumeric(Attr.java:2122)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitConditional(Attr.java:2060)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCConditional.accept(JCTree.java:1580)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:723)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitVarDef(Attr.java:1320)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1066)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:751)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStats(Attr.java:770)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1454)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1136)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:677)
> at jdk.compiler/com.sun.tools.javac.comp.DeferredAttr.attribSpeculative(DeferredAttr.java:515)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribToTree(Attr.java:428)
> at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStatToTree(Attr.java:421)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.attribStatToTree(JavacTrees.java:882)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getAttrContext(JavacTrees.java:857)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:723)
> at jdk.compiler/com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:159)
> 
> 
> The reason is that the `Attr.isBooleanOrNumeric` in this case will refer to `env.encClass.type`, but the type of the enclosing class is filled at the end of `Attr.visitCl...

This pull request has now been integrated.

Changeset: 5a45de5e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a45de5e1ec5ab3e6ed1f5cefa7b320353bb523f
Stats:     91 lines in 2 files changed: 87 ins; 0 del; 4 mod

8347989: Trees.getScope may crash for not-yet attributed source

Reviewed-by: asotona

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

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

From jlahoda at openjdk.org  Fri Jan 31 12:49:24 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 31 Jan 2025 12:49:24 GMT
Subject: RFR: 8349132: javac Analyzers should handle non-deferrable errors
Message-ID: <y8daWq4x2w1OatMgfgJI0Q2sH35lDDnsOgQ9bvFWOjo=.78b43e30-b755-4b70-9387-da8f7ec4b589@github.com>

Consider this test script:

$ cat JDK8349132.sh 
mkdir -p JDK-8349132
cd JDK-8349132
cat >Utils.java <<EOF
package test;
public class Utils {
    public static void run(Task<Param> uat) {}
}
interface Task<T> {
    public void run(T t) throws Exception;
}
class Param {}
EOF
cat >Test.java <<EOF
package test;
public class Test {
    private static void test() {
        Utils.run(new Task<Param>() {
            @Override
            public void run(Param parameter) throws Exception {
            }
        });
    }
}
EOF

javac -d out Utils.java
rm out/test/Param.class
javac -XDfind=diamond -XDshould-stop.at=FLOW -classpath out Test.java


It fails with:

$ bash JDK8349132.sh 
Test.java:4: error: cannot find symbol
        Utils.run(new Task<Param>() {
                           ^
  symbol:   class Param
  location: class Test
Test.java:6: error: cannot find symbol
            public void run(Param parameter) throws Exception {
                            ^
  symbol: class Param
Test.java:4: error: cannot access Param
        Utils.run(new Task<Param>() {
             ^
  class file for test.Param not found
3 errors
An exception has occurred in the compiler (21.0.5). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError: Analyzer error when processing: Utils.run(new Task<Param>(){
    
    () {
        super();
    }
    
    @Override
    public void run(Param parameter) throws Exception {
    }
});:java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.getTypeArguments()" because "com.sun.tools.javac.util.List.get(int).type" is null
jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:258)
jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:228)
jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:577)
jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:547)
jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:591)
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1425)
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1393)
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:976)
jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
        at jdk.compiler/com.sun.tools.javac.comp.Analyzer.doAnalysis(Analyzer.java:579)
        at jdk.compiler/com.sun.tools.javac.comp.Analyzer$2.flush(Analyzer.java:547)
        at jdk.compiler/com.sun.tools.javac.comp.Analyzer.flush(Analyzer.java:591)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1425)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1393)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:976)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)
printing javac parameters to: /tmp/JDK-8349132/javac.20250131_133856.args


The reason for this is as follows: Some errors reported by javac have the "NON_DEFERRABLE" flag, which means the error should not be stored in `DeferredDiagnosticHandler`, but rather should be reported immediately.

This is particularly the case when e.g. entering the sources before annotation processing - the errors found during this enter run may be resolved by the AP. So, ordinary errors are stored in `DeferredDiagnosticHandler` and reported later if needed. Non-deferrable errors are not stored, but reported immediately, as those are typically serious errors that cannot be fixed by AP.

javac also has an `Analyzer`, which looks for code simplifications by speculatively simplifying the code, and re-attributing it to see if it would still compile. It is using `DeferredDiagnosticHandler`, so that if any errors are found during the speculative attribution, the code simplification is rejected.

But, if a non-deferrable error is reported during the speculative attribution, it is passed through `DeferredDiagnosticHandler` undetected, and the `Analyzer` may try to do further evaluations - which may crash the compiler.

The proposal in the PR is to catch all errors while doing this speculative attribution for the `Analyzer`. As a consequence, the speculative code rewrite is found to be problematic, is rejected, and there's no crash.

Note this will also avoid the third error reported in the above case - that error comes directly from the speculative attribution, and it seems incorrect to report it.

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

Commit messages:
 - 8349132: javac Analyzers should handle non-deferrable errors

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

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

From acobbs at openjdk.org  Fri Jan 31 18:17:19 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 31 Jan 2025 18:17:19 GMT
Subject: RFR: 8349155: The "log" parameter to Lint.logIfEnabled() is not needed
Message-ID: <Y02pzkGA5sa0cK1amP1OrDLvQenvyh_aBJte7CXG8qk=.e65b12cc-a3d8-4a6b-904b-034a31435ef6@github.com>

In [JDK-8345263](https://bugs.openjdk.org/browse/JDK-8345263), a new method `Lint.logIfEnabled(Log log, DiagnosticPosition pos, LintWarning warning)` was added. It was decided at the time to pass a `log` parameter explicitly instead of having `Lint` keep its own reference to the `Log` singleton. This was done to keep a conservative approach with the refactoring and to avoid possible initialization ordering issues.

After other recent changes ([JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079), [JDK-8347474](https://bugs.openjdk.org/browse/JDK-8347474)) the initialization ordering issues have been alleviated. It's also the case that there is only ever one `Log` instance per compiler `Context`. So the `log` parameter can be removed and `Lint` can just keep its own reference, as is the normal custom in the compiler code. This results in a minor code cleanup.

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

Commit messages:
 - Refactor to remove the "log" parameter from Lint.logIfEnabled().

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

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

From acobbs at openjdk.org  Fri Jan 31 18:38:04 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 31 Jan 2025 18:38:04 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features [v8]
In-Reply-To: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
Message-ID: <tgMTtBOP7ePWv9XMNfrwTiN1BnYAchrLjl9mzL-pBcI=.eb443947-e95f-427d-8e3d-6410f4e2dfd0@github.com>

> This PR updates the `DeferredLintHandler` so that deferred warnings can be registered during parsing, before any `JCTree` nodes have been created, and it uses this new capability to update the `"preview"` and `"text-blocks"` Lint warnings so that they can be suppressed via `@SuppressWarnings` annotations. More details are provided in additional comments.
> 
> Note: This PR depends on (i.e., includes and extends) these other "cleanup" PR's:
> * #23167
> * #23281
> * #23400

Archie Cobbs has updated the pull request incrementally with four additional commits since the last revision:

 - Revert gratuituous whitespace change.
 - Merge branch 'JDK-8349155' into JDK-8224228
 - Refactor to remove the "log" parameter from Lint.logIfEnabled().
 - Fix an inaccurate comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23237/files
  - new: https://git.openjdk.org/jdk/pull/23237/files/ebb6544e..44f5bedc

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

  Stats: 54 lines in 11 files changed: 3 ins; 3 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/23237.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23237/head:pull/23237

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

From acobbs at openjdk.org  Fri Jan 31 18:40:48 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 31 Jan 2025 18:40:48 GMT
Subject: RFR: 8224228: No way to locally suppress lint warnings in
 parser/tokenizer or preview features
In-Reply-To: <cjb2rz15eQCHM9SEdyKiVtFml-GOwO_We4Wx4o9o1zU=.10acf611-3055-41e4-bac3-baa74f097183@github.com>
References: <gtzkQyDKR26df2zgcE60ByseZM1Zbg6OREQ3cHbFtbA=.3dce2562-48db-4e0d-a802-6e0df4aad35c@github.com>
 <6ze6J8aLTzJmsjgT23_ByUNvaqYNuVYLPd7P9TnPB8k=.eb4aa472-1a33-4b1b-8227-179d7e6777a4@github.com>
 <cjb2rz15eQCHM9SEdyKiVtFml-GOwO_We4Wx4o9o1zU=.10acf611-3055-41e4-bac3-baa74f097183@github.com>
Message-ID: <IrliGcqaasnOY9JRn7lv_MJD1Pxh8SpfnJA_01iCH7I=.6b6de977-4dfb-455f-9f2a-daa422c9ead6@github.com>

On Thu, 23 Jan 2025 22:02:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Question: the change looks beneficial, but there's a lot going on in the PR. Would it be possible, do you think, to break it down into simpler parts? For instance, the push/pop logic seems something that we could review and integrate separately (and it's adding quite a bit of noise to the PR). Same for missing flushes etc.
>
>> Hi @mcimadamore,
>> 
>> Thanks for taking a look.
>> 
>> > Would it be possible, do you think, to break it down into simpler parts?
>> 
>> Absolutely, I will work on that.
> 
> Thanks!!

@mcimadamore,

> Would it be possible, do you think, to break it down into simpler parts?

I've split this into three precursor "cleanup" PR's (although the third one is new and wasn't part of the original change).

So this PR depends on (i.e., includes and extends) these others. Obviously they would need to be adjudicated first:
* #23167
* #23281
* #23400

Let me know if this looks like a reasonable approach. I'm happy to split things up differently if needed. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23237#issuecomment-2628054367