From haosun at openjdk.org  Fri Aug  1 00:04:02 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 1 Aug 2025 00:04:02 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <q2sYANTiDxR1R_UP_6R21fzUeWoB1D0rYVZE0k1HSOA=.d6778ae4-878d-48df-84ea-0fa1f05dfb1d@github.com>
Message-ID: <6CRZBpGwS69ZgWKLmIG7UOj9jPqVxvieJKEAT9lao-Y=.af3bdd20-0a45-4928-8c5b-197b377e8ba3@github.com>

On Wed, 30 Jul 2025 16:26:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Hao,
> 
> > Hi, I encountered two jtreg failures with this new version `8` on both AArch64 and x86_64 platforms.
> > Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.
> 
> Thank you for bringing this up. I'm able to reproduce this issue with this newer version of jtreg. I'll take a look to see what's going on.

Thanks for your confirm, Jaikiran.
Forgot to mention that I tested `jdk_all, hotspot_all, langtools_all` with jtreg `8` and only found these two test failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3141675024

From kcr at openjdk.org  Fri Aug  1 11:00:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 11:00:55 GMT
Subject: RFR: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown
In-Reply-To: <B7A9xBhQ8UziMHT_3quGGOHSItdrpARKQrlEPtifEKg=.6996ba63-0fff-489a-bc18-926701ebe897@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
 <B7A9xBhQ8UziMHT_3quGGOHSItdrpARKQrlEPtifEKg=.6996ba63-0fff-489a-bc18-926701ebe897@github.com>
Message-ID: <nQvM3b0LTx4rSkB84NM4mGbdUpuzzH-NX469rfnPvnQ=.23ec9636-c3d7-4285-898f-3e4304d07e94@github.com>

On Tue, 15 Jul 2025 12:46:27 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change introducing a range check before pruning
>> stacktrace elements in source launch mode. Additional `null`-checks
>> are also added to this change set.
>
> I wonder when and why the exception-handling code moved from `InvocationTargetException::getTargetException` to `InvocationTargetException::getCause`? ?
> 
> Ah, API documentation of [InvocationTargetException](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/InvocationTargetException.html#getTargetException()) to the rescue:
> 
>> API Note:
> This method predates the general-purpose exception chaining facility. The [Throwable.getCause()](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Throwable.html#getCause()) method is now the preferred means of obtaining this information.

@sormuras Do you intend to integrate this?

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

PR Comment: https://git.openjdk.org/jdk/pull/26315#issuecomment-3114668209

From cstein at openjdk.org  Fri Aug  1 11:07:00 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 1 Aug 2025 11:07:00 GMT
Subject: Integrated: 8362237: IllegalArgumentException in the launcher when
 exception without stack trace is thrown
In-Reply-To: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
References: <wu0K27KAuaBDFsFneiG6pL2jYCJv5eJUdtBouf-KHPk=.5ea1be8d-55e3-4e3a-9aca-4b102d54efb4@github.com>
Message-ID: <djPOw-WRPmWbPbTvk1tm0LYXvgkbyduAHmgJYucfJeE=.cdb68347-71f0-4976-b8a4-1844a80fb8ba@github.com>

On Tue, 15 Jul 2025 12:20:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change introducing a range check before pruning
> stacktrace elements in source launch mode. Additional `null`-checks
> are also added to this change set.

This pull request has now been integrated.

Changeset: 8ac4a88f
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ac4a88f3c5ad57824dd192cb3f0af5e71cbceeb
Stats:     49 lines in 2 files changed: 43 ins; 0 del; 6 mod

8362237: IllegalArgumentException in the launcher when exception without stack trace is thrown

Reviewed-by: kcr, vromero

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

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

From liach at openjdk.org  Fri Aug  1 16:41:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 16:41:37 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v9]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <GbdAr9fWbrVloxGW5nYqprt4WsQaXoHPYjjDVg810mY=.9752922a-3a0c-42ec-8163-a5eea78b2749@github.com>

> Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Fixes
 - Fix sourceversion test
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java
 - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
   
   Co-authored-by: Luca Kellermann <lukellmann at gmail.com>
 - Don't need to update latestSupported later
   
 - ... and 4 more: https://git.openjdk.org/jdk/compare/ee3665bc...ce9cf84b

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=08
  Stats: 1284 lines in 6 files changed: 1138 ins; 87 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017

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

From liach at openjdk.org  Fri Aug  1 17:31:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 17:31:46 GMT
Subject: RFR: 8364545: tools/javac/launcher/SourceLauncherTest.java fails
 frequently
Message-ID: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>

SourceLauncherTest is placing arbitrary assumptions on the hotspot compiler. Since this test is running the source launcher in the same JVM, we have to create separate jtreg tests to allow running the test and the in-JVM source launcher with another set of VM flags.

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

Commit messages:
 - 8364545: tools/javac/launcher/SourceLauncherTest.java fails frequently

Changes: https://git.openjdk.org/jdk/pull/26601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26601&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364545
  Stats: 122 lines in 2 files changed: 84 ins; 37 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26601/head:pull/26601

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

From liach at openjdk.org  Fri Aug  1 17:31:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 17:31:46 GMT
Subject: RFR: 8364545: tools/javac/launcher/SourceLauncherTest.java fails
 frequently
In-Reply-To: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
References: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
Message-ID: <TcTja5w3_U4naY49ljDJJU6eCr-CJHjRu9mzOrtqgPg=.ee45d464-cc79-483e-a47d-b4214d9f78f8@github.com>

On Fri, 1 Aug 2025 17:23:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> SourceLauncherTest is placing arbitrary assumptions on the hotspot compiler. Since this test is running the source launcher in the same JVM, we have to create separate jtreg tests to allow running the test and the in-JVM source launcher with another set of VM flags.

Testing: Ran the newly split test 100 times in repeat in jtreg

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

PR Comment: https://git.openjdk.org/jdk/pull/26601#issuecomment-3145282345

From liach at openjdk.org  Fri Aug  1 17:38:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Aug 2025 17:38:55 GMT
Subject: RFR: 8364545: tools/javac/launcher/SourceLauncherTest.java fails
 frequently
In-Reply-To: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
References: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
Message-ID: <mxN2MioRhk2Jtsd9exm_BCVrzpHVHrYG2wBf7LSPs_k=.26079f4d-6982-4ceb-9719-f2375e135939@github.com>

On Fri, 1 Aug 2025 17:23:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> SourceLauncherTest is placing arbitrary assumptions on the hotspot compiler. Since this test is running the source launcher in the same JVM, we have to create separate jtreg tests to allow running the test and the in-JVM source launcher with another set of VM flags.

Will be unavailable soon. If the fix looks good, other committers may integrate once someone approves.

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

PR Comment: https://git.openjdk.org/jdk/pull/26601#issuecomment-3145301135

From erikj at openjdk.org  Fri Aug  1 18:17:55 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:17:55 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
Message-ID: <7-OHL7cQf8cKDTulwBLVf1DD6gIkSuX12P-TvbMvPa4=.736c0d91-a0cd-4cac-8d8c-251967742250@github.com>

On Mon, 28 Jul 2025 06:50:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting runtime checks, as suggested.

Marked as reviewed by erikj (Reviewer).

make/modules/jdk.compiler/Gensrc.gmk line 79:

> 77: 
> 78: ################################################################################
> 79: 

Can remove one of these comment delimiter lines.

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

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3080147875
PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2248577111

From erikj at openjdk.org  Fri Aug  1 18:29:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:29:57 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <MYOxu1Y0X-cadUHNUOGHl-bo3zq3NFHzqr77RCG8i8g=.536325df-4118-449a-9fc1-b7a63673b25b@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3080178709

From cstein at openjdk.org  Sat Aug  2 06:11:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 2 Aug 2025 06:11:53 GMT
Subject: RFR: 8364545: tools/javac/launcher/SourceLauncherTest.java fails
 frequently
In-Reply-To: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
References: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
Message-ID: <72HO3jsv6n1_HgGX41GpDmKl_B0gmcXoFhkTcsfETyY=.d814ba6d-5a21-4d3b-ac14-257a3415bc3a@github.com>

On Fri, 1 Aug 2025 17:23:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> SourceLauncherTest is placing arbitrary assumptions on the hotspot compiler. Since this test is running the source launcher in the same JVM, we have to create separate jtreg tests to allow running the test and the in-JVM source launcher with another set of VM flags.

Moving the new test with _assumptions on the hotspot compiler_ into a dedicated unit makes sense.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26601#pullrequestreview-3080933062

From jpai at openjdk.org  Sun Aug  3 09:25:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 3 Aug 2025 09:25:53 GMT
Subject: RFR: 8364545: tools/javac/launcher/SourceLauncherTest.java fails
 frequently
In-Reply-To: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
References: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
Message-ID: <jBJT-SILJfXsrgs0kYQF15ZuRGoFT8YZMzNe8TZ7RSU=.46b99778-af59-42cb-82ab-c00627c2213d@github.com>

On Fri, 1 Aug 2025 17:23:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> SourceLauncherTest is placing arbitrary assumptions on the hotspot compiler. Since this test is running the source launcher in the same JVM, we have to create separate jtreg tests to allow running the test and the in-JVM source launcher with another set of VM flags.

Marked as reviewed by jpai (Reviewer).

In context of the current failure reported in https://bugs.openjdk.org/browse/JDK-8364545, this change looks OK to me.

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

PR Review: https://git.openjdk.org/jdk/pull/26601#pullrequestreview-3082062872
PR Comment: https://git.openjdk.org/jdk/pull/26601#issuecomment-3148287878

From liach at openjdk.org  Sun Aug  3 13:27:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 3 Aug 2025 13:27:00 GMT
Subject: RFR: 8364545: tools/javac/launcher/SourceLauncherTest.java fails
 frequently
In-Reply-To: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
References: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
Message-ID: <2EZjNYCOA8eIqpEa4rHoUVnaCrKr9XtQ2myJSrbL4lM=.59965333-6676-4f99-a699-f2183274e440@github.com>

On Fri, 1 Aug 2025 17:23:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> SourceLauncherTest is placing arbitrary assumptions on the hotspot compiler. Since this test is running the source launcher in the same JVM, we have to create separate jtreg tests to allow running the test and the in-JVM source launcher with another set of VM flags.

Thanks Jaikiran for this approval. Let's integrate this to stop the spam in CI pipelines.

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

PR Comment: https://git.openjdk.org/jdk/pull/26601#issuecomment-3148421653

From liach at openjdk.org  Sun Aug  3 13:27:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 3 Aug 2025 13:27:01 GMT
Subject: Integrated: 8364545: tools/javac/launcher/SourceLauncherTest.java
 fails frequently
In-Reply-To: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
References: <DJt9ah9YRfCzDtSkgA0MUiwJXbXpXMFtSOF0MZKdeNo=.4ae4e897-6e45-450d-9240-3c66b4f2f149@github.com>
Message-ID: <auWyId1q9hRb-eSAI_uuE4aVV5wGWI-LcmRtrm6V78g=.5791d676-77be-4d06-9d3f-1ffeaafaed71@github.com>

On Fri, 1 Aug 2025 17:23:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> SourceLauncherTest is placing arbitrary assumptions on the hotspot compiler. Since this test is running the source launcher in the same JVM, we have to create separate jtreg tests to allow running the test and the in-JVM source launcher with another set of VM flags.

This pull request has now been integrated.

Changeset: 1a206d2a
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a206d2a6cade07249f6922072ac9d29aa56bc43
Stats:     122 lines in 2 files changed: 84 ins; 37 del; 1 mod

8364545: tools/javac/launcher/SourceLauncherTest.java fails frequently

Reviewed-by: cstein, jpai

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

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

From duke at openjdk.org  Sun Aug  3 13:37:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 3 Aug 2025 13:37:54 GMT
Subject: RFR: 8364007: Add no-argument codePointCount method to
 CharSequence and String [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <7_hGRPSddpEvGRJxCGREDYZjqQ68_0rIPzHVV-NOjFA=.63974cf2-8f61-451d-a509-60727d065e29@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

Its author may have prioritized the versatility of the APIs.

> `codePointCount(0, length())`

This workaround is only effective if the instance expression is sufficiently short or can afford to be stored to a new temporary variable once. It can be a pain in the neck that you have to write the expression even twice to get the number of code points in the entire string instance.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3148429115

From jlahoda at openjdk.org  Mon Aug  4 18:39:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Aug 2025 18:39:09 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v10]
In-Reply-To: <w1aIR8J8hyKGWhr1310DQyxe8iKl-bUT4jE2ecWaOuM=.bbfe3c01-f00b-49b5-a66e-0443ab3ff643@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <w1aIR8J8hyKGWhr1310DQyxe8iKl-bUT4jE2ecWaOuM=.bbfe3c01-f00b-49b5-a66e-0443ab3ff643@github.com>
Message-ID: <k7dVpIQgoTWVWOtfF0ZwgISDE4BNBnEJmUw58tV6cLs=.bace17ef-e235-48c0-89ab-7a70bc9fe236@github.com>

On Thu, 31 Jul 2025 09:09:57 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable assertion until JDK 25 is bootstrap JRE.

Marked as reviewed by jlahoda (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25639#pullrequestreview-3085344695

From duke at openjdk.org  Mon Aug  4 19:21:05 2025
From: duke at openjdk.org (duke)
Date: Mon, 4 Aug 2025 19:21:05 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v10]
In-Reply-To: <w1aIR8J8hyKGWhr1310DQyxe8iKl-bUT4jE2ecWaOuM=.bbfe3c01-f00b-49b5-a66e-0443ab3ff643@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <w1aIR8J8hyKGWhr1310DQyxe8iKl-bUT4jE2ecWaOuM=.bbfe3c01-f00b-49b5-a66e-0443ab3ff643@github.com>
Message-ID: <J4y45i6_yX8JmtSKd7rup_N7cJSPBknfO_wIUHzHb3M=.819079e7-f90d-43c9-a5a0-e46e7f2e6c72@github.com>

On Thu, 31 Jul 2025 09:09:57 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable assertion until JDK 25 is bootstrap JRE.

@david-beaumont 
Your change (at version 5d73c3271f2698024d4bd5b65d7a676dde8edac0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25639#issuecomment-3152051500

From cstein at openjdk.org  Tue Aug  5 16:03:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 5 Aug 2025 16:03:07 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <1XRUup7RXkUWm_2yscYV2M-m4ooHr70QdwcVVB7zxDI=.d641c6f9-9dd9-4da7-8599-a164274b9d93@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Both tests seem to make hard assumptions on where binary files of `@library` classes are stored.

- [TestSPISigned.java#L60-L62](https://github.com/openjdk/jdk/blob/master/test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java#L60-L62)
- [resexhausted003.java#L83-L96](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003.java#L83-L96)

The storage location changed due to https://bugs.openjdk.org/browse/CODETOOLS-7902847 - it might change again in the near future. Thus, both tests need to be updated to work correctly without relying on a specific location of compiled library classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3155714592

From duke at openjdk.org  Wed Aug  6 08:59:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 6 Aug 2025 08:59:12 GMT
Subject: Integrated: 8356645: Javac should utilize new ZIP file system
 read-only access mode
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <lRvMYkWPFS-wunIEXBnxEmyhZFVD-J9U1yhhW4cTsl0=.5ef14557-2bf2-4204-83c0-a71cefdf13f8@github.com>

On Wed, 4 Jun 2025 12:08:38 GMT, David Beaumont <duke at openjdk.org> wrote:

> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
> 
> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
> This will, of course, be thoroughly tested before integration.
> 
> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
> 
> I'm also happy to update the original bug description to include the timestamp related changes as necessary.

This pull request has now been integrated.

Changeset: 0ceb366d
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ceb366dc26e2e4f6252da9dd8930b016a5d46ba
Stats:     88 lines in 6 files changed: 57 ins; 15 del; 16 mod

8356645: Javac should utilize new ZIP file system read-only access mode

Reviewed-by: jlahoda

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

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

From mistria at redhat.com  Wed Aug  6 09:02:16 2025
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 6 Aug 2025 11:02:16 +0200
Subject: Fully discarded annotations if repeated but not repeatable
Message-ID: <CAFr6BZRzz++9-Se2tiENqqKYCL0rUVY7UVsxX4UZM4JKZXTRcw@mail.gmail.com>

Hi all,

I'm seeing what we interpret as a limitation with Javac when comparing with
ECJ, which has impact on things like semantic search in the downstream
Eclipse IDE when Javac is used as backend for code-analysis.
I'm not sure it would qualify as a bug though, I would let people who are
more expert judge of the best way to consider this case, or not.

So from a bit of code in Test.java file
```
package pack;

@Ann
@Ann
class Test {
}

@interface Ann  {
}
```

Run the various compilation stage up to Analyze. This report an error thant
Ann is not repeatable; all good.
Then from the JCTree element, navigate to Test and read the typeSymbol that
is attached to it, and then inspect the value of
`typeSymbol.getAnnotationMirrors()`.
EXPECTED: 2 annotation mirrors anyway (maybe with ErrorType or whatever)
GOT: 0 annotaiton mirror
So in later analysis, those annotations are simply non-existant at all,
making it impossible eg to reliably report that Ann has a (faulty) consumer.

Cheers
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
<https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250806/5cde254d/attachment.htm>

From jlahoda at openjdk.org  Thu Aug  7 11:28:50 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Aug 2025 11:28:50 GMT
Subject: RFR: 8364987: javac fails with an exception when looking for diamond
 creation
Message-ID: <640xOln0A_76CYjq_umbakwx4bdtJulwzUoxBn1yAyE=.0d89d893-33f1-41ad-bfd9-251c8a417c50@github.com>

Consider code like:

$ cat /tmp/Test.java
public class Test {
    void t() {
        L<Object> l = new L<Test>();
    }
    static class L<T> {}
}


Note the code is invalid - `L<Test>` is not assignable to `L<Object>`. The type of `L<Test>` is erroneous in the AST. This may crash with an exception when searching for diamond rewrites:

$ javac -XDfind=diamond -XDshould-stop.at=FLOW -XDdev /tmp/Test.java
/tmp/Test.java:3: error: incompatible types: L<Test> cannot be converted to L<Object>
        L<Object> l = new L<Test>();
                      ^
1 error
An exception has occurred in the compiler (25-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError: Analyzer error when processing: L<Object> l = new L<Test>():java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.isPartial()" because "s" is null
jdk.compiler/com.sun.tools.javac.code.Types$5.visitClassType(Types.java:1399)
jdk.compiler/com.sun.tools.javac.code.Types$5.visitClassType(Types.java:1351)
jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1052)
jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4936)
jdk.compiler/com.sun.tools.javac.code.Types.isSameType(Types.java:1343)
jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:268)
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:1412)
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380)
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:968)
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:66)
jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
        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:1412)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:968)
        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:66)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
printing javac parameters to: /tmp/javac.20250807_090036.args


The reason is that while the inferred type (`L<Object>`) has one type argument, the actual type in the AST (error/`<any>`) has no type arguments, leading to getting a `null` from the list, and failing with the NPE.

The proposal is to improve the error resilience by not trying to search for diamond rewrites for erroneous types.

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

Commit messages:
 - Re-enabling accidentally disabled test.
 - 8364987: javac fails with an exception when looking for diamond creation

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

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

From davidalayachew at gmail.com  Thu Aug  7 18:39:13 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 7 Aug 2025 14:39:13 -0400
Subject: Fwd: jshell has unreadable javadoc on Git Bash
In-Reply-To: <CAA9v-_OABhfYKb2j+CQAbhFUXgUx=W0j_pN+U9f7=1sEnQ3pVA@mail.gmail.com>
References: <CAA9v-_OUknzCp0KsytMfT51jAJYswWOPDT2-N_W_N12gTYuMDg@mail.gmail.com>
 <CAA9v-_OABhfYKb2j+CQAbhFUXgUx=W0j_pN+U9f7=1sEnQ3pVA@mail.gmail.com>
Message-ID: <CAA9v-_NmJ3yLQ4GaBoJo6_bDBZ4dXUwKxPov9ciQcK_PYT-hpQ@mail.gmail.com>

Hello,

Since the kulla dev chat has just been retired, moving my unanswered
question here instead. Please see the below thread, or let me know if I
should copy paste it for easier reading.


---------- Forwarded message ---------
From: David Alayachew <davidalayachew at gmail.com>
Date: Mon, Jun 2, 2025, 8:57?PM
Subject: Re: jshell has unreadable javadoc on Git Bash
To: <kulla-dev at openjdk.org>


Side note -- the same problem occurs in Commandline too for Windows 10. The
only difference is that I can't use Shift+Enter to create the new lines.
Instead, I did a .map(somePath -> {, and then pressed enter. The opening
curly brace then allowed my enter to create a new line. After making a few
new lines, then trying to press tab on a half-typed method, I got the same,
garbled text.


And to be clear, they are garbled/interspersed, even on the same line.

On Mon, Jun 2, 2025, 8:52?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello @kulla-dev at openjdk.org <kulla-dev at openjdk.org> ,
>
> I was using jshell to write some stream code today, and I was doing this
> in Git Bash on Windows 10.
>
> I did list.stream(), then used Shift+Enter to create a new line for each
> method on my stream. Typical builder-style code formatting.
>
> Then, I pressed Tab in order to see javadoc for one of the methods, and
> the resulting javadoc was basically illegible. It was a mix of the
> multi-line stream and the javadoc, jumbled together.
>
> I think this is a bug? Can something be done to resolve this? Let me know
> if more information is needed.
>
> 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/20250807/ad6ca7a7/attachment.htm>

From jlahoda at openjdk.org  Fri Aug  8 12:39:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Aug 2025 12:39:03 GMT
Subject: RFR: 8341342: Elements.getAllModuleElements() does not work properly
 before JavacTask.analyze()
Message-ID: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>

When calling `Elements.getTypeElement(...)` or `Elements.getPackageElement(...)`, javac itself ensures that the enter phase is already done. That is, sadly, not done for `Elements.getAllModuleElements()`. This PR fixes that.

See:
https://github.com/openjdk/jdk/pull/18934/files#r1767657515
for a practical case.

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

Commit messages:
 - Removing trailing whitespace.
 - 8341342: Elements.getAllModuleElements() does not work properly before JavacTask.analyze()

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

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

From liach at openjdk.org  Fri Aug  8 17:28:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Aug 2025 17:28:11 GMT
Subject: RFR: 8341342: Elements.getAllModuleElements() does not work
 properly before JavacTask.analyze()
In-Reply-To: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
References: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
Message-ID: <xmLpeU-xk7cRWKjhvmGpaK2lHWaBqIYzpXzvQv2Hscw=.59d1c7a5-e1a0-40d2-8ba5-d9982ff3c7c0@github.com>

On Fri, 8 Aug 2025 12:03:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When calling `Elements.getTypeElement(...)` or `Elements.getPackageElement(...)`, javac itself ensures that the enter phase is already done. That is, sadly, not done for `Elements.getAllModuleElements()`. This PR fixes that.
> 
> See:
> https://github.com/openjdk/jdk/pull/18934/files#r1767657515
> for a practical case.

I remember this from the APIDiff: https://github.com/openjdk/apidiff/blob/1dbbcb5b87f75edcbdf9caf7314c56bce1a110df/src/share/classes/jdk/codetools/apidiff/model/API.java#L460

test/langtools/tools/javac/processing/model/util/elements/TestElementsProgrammatic.java line 55:

> 53:     public void automaticallyEnter() {
> 54:         //make sure the get{All,}{Module,Package,Type}Element{s,} methods will automatically enter:
> 55:         List<Consumer<JavacTask>> testCases = List.of(

You can use `@ParameterizedTest @MethodSource("taskFactory")` for each test case, and `static JavacTask taskFactory() { /* ... */}` for junit to call to create the task argument for each test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26694#issuecomment-3168791855
PR Review Comment: https://git.openjdk.org/jdk/pull/26694#discussion_r2263634347

From chen.l.liang at oracle.com  Fri Aug  8 19:24:47 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 8 Aug 2025 19:24:47 +0000
Subject: jshell has unreadable javadoc on Git Bash
In-Reply-To: <CAA9v-_NmJ3yLQ4GaBoJo6_bDBZ4dXUwKxPov9ciQcK_PYT-hpQ@mail.gmail.com>
References: <CAA9v-_OUknzCp0KsytMfT51jAJYswWOPDT2-N_W_N12gTYuMDg@mail.gmail.com>
 <CAA9v-_OABhfYKb2j+CQAbhFUXgUx=W0j_pN+U9f7=1sEnQ3pVA@mail.gmail.com>
 <CAA9v-_NmJ3yLQ4GaBoJo6_bDBZ4dXUwKxPov9ciQcK_PYT-hpQ@mail.gmail.com>
Message-ID: <SJ2PR10MB7669628370D6970ECE516543A22FA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Thanks for this report. I can reproduce this with the suggestions, it does print something that is hidden by user code. I created https://bugs.openjdk.org/browse/JDK-8365177 with the steps of reproduction, which I can reproduce on a linux machine too.



________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Thursday, August 7, 2025 1:39 PM
To: compiler-dev <compiler-dev at openjdk.org>
Subject: Fwd: jshell has unreadable javadoc on Git Bash

Hello,

Since the kulla dev chat has just been retired, moving my unanswered question here instead. Please see the below thread, or let me know if I should copy paste it for easier reading.


---------- Forwarded message ---------
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Date: Mon, Jun 2, 2025, 8:57?PM
Subject: Re: jshell has unreadable javadoc on Git Bash
To: <kulla-dev at openjdk.org<mailto:kulla-dev at openjdk.org>>



Side note -- the same problem occurs in Commandline too for Windows 10. The only difference is that I can't use Shift+Enter to create the new lines. Instead, I did a .map(somePath -> {, and then pressed enter. The opening curly brace then allowed my enter to create a new line. After making a few new lines, then trying to press tab on a half-typed method, I got the same, garbled text.


And to be clear, they are garbled/interspersed, even on the same line.

On Mon, Jun 2, 2025, 8:52?PM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Hello @kulla-dev at openjdk.org<mailto:kulla-dev at openjdk.org> ,

I was using jshell to write some stream code today, and I was doing this in Git Bash on Windows 10.

I did list.stream(), then used Shift+Enter to create a new line for each method on my stream. Typical builder-style code formatting.

Then, I pressed Tab in order to see javadoc for one of the methods, and the resulting javadoc was basically illegible. It was a mix of the multi-line stream and the javadoc, jumbled together.

I think this is a bug? Can something be done to resolve this? Let me know if more information is needed.

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/20250808/b8dd2d38/attachment.htm>

From vromero at openjdk.org  Fri Aug  8 19:29:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Aug 2025 19:29:12 GMT
Subject: RFR: 8364987: javac fails with an exception when looking for
 diamond creation
In-Reply-To: <640xOln0A_76CYjq_umbakwx4bdtJulwzUoxBn1yAyE=.0d89d893-33f1-41ad-bfd9-251c8a417c50@github.com>
References: <640xOln0A_76CYjq_umbakwx4bdtJulwzUoxBn1yAyE=.0d89d893-33f1-41ad-bfd9-251c8a417c50@github.com>
Message-ID: <kiyEfXmwHKigPq5H3-oOhRVGWpZimKBZU39NzMlSmes=.ade1cb31-9ded-4ae0-aed0-6f9a172e1f5c@github.com>

On Thu, 7 Aug 2025 11:23:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> $ cat /tmp/Test.java
> public class Test {
>     void t() {
>         L<Object> l = new L<Test>();
>     }
>     static class L<T> {}
> }
> 
> 
> Note the code is invalid - `L<Test>` is not assignable to `L<Object>`. The type of `L<Test>` is erroneous in the AST. This may crash with an exception when searching for diamond rewrites:
> 
> $ javac -XDfind=diamond -XDshould-stop.at=FLOW -XDdev /tmp/Test.java
> /tmp/Test.java:3: error: incompatible types: L<Test> cannot be converted to L<Object>
>         L<Object> l = new L<Test>();
>                       ^
> 1 error
> An exception has occurred in the compiler (25-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: Analyzer error when processing: L<Object> l = new L<Test>():java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.isPartial()" because "s" is null
> jdk.compiler/com.sun.tools.javac.code.Types$5.visitClassType(Types.java:1399)
> jdk.compiler/com.sun.tools.javac.code.Types$5.visitClassType(Types.java:1351)
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1052)
> jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4936)
> jdk.compiler/com.sun.tools.javac.code.Types.isSameType(Types.java:1343)
> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:268)
> 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:1412)
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380)
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:968)
> 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:66)
> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>         at jdk....

yes, makes sense

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26675#pullrequestreview-3101954862

From ihse at openjdk.org  Mon Aug 11 09:22:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:22:17 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
Message-ID: <JHtigp6K2FNIdF1cOwhOI7rWdYzIf-1djjiHDBxzAkY=.f7c95c26-ec49-4683-8967-b59281c0c8a3@github.com>

On Mon, 28 Jul 2025 06:50:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting runtime checks, as suggested.

make/modules/jdk.compiler/Gensrc.gmk line 82:

> 80: ################################################################################
> 81: #
> 82: # Generate FlagsEnum from Flags constants:

Suggestion:

# Generate FlagsEnum from Flags constants

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2266118863

From ihse at openjdk.org  Mon Aug 11 09:39:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 09:39:21 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <gk7J2fluyshhY0YHFZDnWaXMOdnMtH42y1z7FGthfwU=.498019c5-643c-46fb-b744-c3c0bb1b8140@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3104868381

From jlahoda at openjdk.org  Mon Aug 11 09:43:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Aug 2025 09:43:36 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v4]
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <2N2f71azV7x8Cn2gSeFUrOkNomSD7mIDqGcxcd53C00=.d819e69b-0950-4a50-b1ad-eed88df5251e@github.com>

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

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

  Update make/modules/jdk.compiler/Gensrc.gmk as suggested.
  
  Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26452/files
  - new: https://git.openjdk.org/jdk/pull/26452/files/f1d6def8..019d0061

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

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

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

From jlahoda at openjdk.org  Mon Aug 11 09:43:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Aug 2025 09:43:36 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v3]
In-Reply-To: <z7mfCWZR-naeyRqaV4Nax0eoWGxfXxipQtzRmjd9828=.229922da-dc67-41d2-96ad-0748b50ccb99@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <yp8LbJz1X0CKEU_AANsFc0wCyhhMgc3FVTr-CXEK8ZA=.82c68c26-9a88-4ce1-87d0-a557d767e5b4@github.com>
 <z7mfCWZR-naeyRqaV4Nax0eoWGxfXxipQtzRmjd9828=.229922da-dc67-41d2-96ad-0748b50ccb99@github.com>
Message-ID: <1Hf1LjcgBDhCfj8Y6pvfRZXuEEpiBbUMNpvDLZ5_P9c=.135b2884-ea85-471e-816f-330e22f233cb@github.com>

On Mon, 28 Jul 2025 21:10:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverting runtime checks, as suggested.
>
> make/langtools/tools/flagsgenerator/FlagsGenerator.java line 84:
> 
>> 82:                                            .forEach(target -> target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>())
>> 83:                                                                                    .computeIfAbsent(flagBit, _ -> new ArrayList<>())
>> 84:                                                                                    .add(flagName));
> 
> Instead of a dedicated loop to verify no overlaps, we can make the nested map `Map<Integer, String>` and fail fast whenever we detect a conflict, like:
> 
> var oldFlagName = target2FlagBit2Fields.computeIfAbsent(target, _ -> new HashMap<>()).put(flagBit, flagName);
> if (oldFlagName != null) {
>     // Fail fast code
> }
> 
> I personally don't see a reason to collect all conflicting fields for a flag if any of these conflicts already causes a failure.

Its unlikely to be common in the long run, but there may be conflicts among more than two fields. Reporting all at once (rather than reporting one conflict, and after resolving reporting another) seems nicer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26452#discussion_r2266167613

From jlahoda at openjdk.org  Mon Aug 11 09:57:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Aug 2025 09:57:03 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
 - Using EnumMap, as suggested.
 - Removing unnecessary delimited, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26452/files
  - new: https://git.openjdk.org/jdk/pull/26452/files/019d0061..2095f574

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

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

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

From jlahoda at openjdk.org  Mon Aug 11 10:32:15 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Aug 2025 10:32:15 GMT
Subject: Integrated: 8364987: javac fails with an exception when looking for
 diamond creation
In-Reply-To: <640xOln0A_76CYjq_umbakwx4bdtJulwzUoxBn1yAyE=.0d89d893-33f1-41ad-bfd9-251c8a417c50@github.com>
References: <640xOln0A_76CYjq_umbakwx4bdtJulwzUoxBn1yAyE=.0d89d893-33f1-41ad-bfd9-251c8a417c50@github.com>
Message-ID: <h2gWevdZARjq15qBAwYr6dYXxua9N4k9PWVbe5mOPvg=.fbb6be45-019e-4baf-a918-dcd78ae52075@github.com>

On Thu, 7 Aug 2025 11:23:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> $ cat /tmp/Test.java
> public class Test {
>     void t() {
>         L<Object> l = new L<Test>();
>     }
>     static class L<T> {}
> }
> 
> 
> Note the code is invalid - `L<Test>` is not assignable to `L<Object>`. The type of `L<Test>` is erroneous in the AST. This may crash with an exception when searching for diamond rewrites:
> 
> $ javac -XDfind=diamond -XDshould-stop.at=FLOW -XDdev /tmp/Test.java
> /tmp/Test.java:3: error: incompatible types: L<Test> cannot be converted to L<Object>
>         L<Object> l = new L<Test>();
>                       ^
> 1 error
> An exception has occurred in the compiler (25-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: Analyzer error when processing: L<Object> l = new L<Test>():java.lang.NullPointerException: Cannot invoke "com.sun.tools.javac.code.Type.isPartial()" because "s" is null
> jdk.compiler/com.sun.tools.javac.code.Types$5.visitClassType(Types.java:1399)
> jdk.compiler/com.sun.tools.javac.code.Types$5.visitClassType(Types.java:1351)
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1052)
> jdk.compiler/com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4936)
> jdk.compiler/com.sun.tools.javac.code.Types.isSameType(Types.java:1343)
> jdk.compiler/com.sun.tools.javac.comp.Analyzer$DiamondInitializer.process(Analyzer.java:268)
> 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:1412)
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380)
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:968)
> 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:66)
> jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>         at jdk....

This pull request has now been integrated.

Changeset: 8b5bb013
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b5bb013557478c9ceb49f94f22600d5901f4eee
Stats:     41 lines in 2 files changed: 39 ins; 0 del; 2 mod

8364987: javac fails with an exception when looking for diamond creation

Reviewed-by: vromero

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

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

From ihse at openjdk.org  Mon Aug 11 11:34:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Aug 2025 11:34:16 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
Message-ID: <yptCke03-RgYbRaCn3QGhoAnT6SRCAd6FL5GhEOExZE=.b1122a1c-a425-4ece-93a8-2adf8159e084@github.com>

On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
>  - Using EnumMap, as suggested.
>  - Removing unnecessary delimited, as suggested.

Build changes look fine now

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3105399551

From cstein at openjdk.org  Mon Aug 11 11:35:12 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 11 Aug 2025 11:35:12 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v2]
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

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

  Update to use correct library directories
  
  See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26261/files
  - new: https://git.openjdk.org/jdk/pull/26261/files/bf7b033b..b5112c32

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

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

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

From cstein at openjdk.org  Mon Aug 11 11:35:13 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 11 Aug 2025 11:35:13 GMT
Subject: RFR: 8361950: Update to use jtreg 8
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <45gc5UsWc5d6aePWF_7SSX0ERJTTvklTXBukRdjqhCc=.1cf0046e-b697-4fce-9751-e8eade48a49e@github.com>

On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.

I updated both tests to be agnostic about the location to where `jtreg` puts library classes into. See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files

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

PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3174373256

From iris at openjdk.org  Mon Aug 11 17:38:12 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 11 Aug 2025 17:38:12 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v2]
In-Reply-To: <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <J5fF6P9MhXKy2H2Xb4CDVdpED-zOGHHHrehDggSdsUs=.0d938d3d-cfcb-465b-bfdf-a13575113eb7@github.com>
Message-ID: <3cVhuiuq1cW-XgONMnkCje3LI6yOMIxTmmiH5AStlTY=.e6a50bf3-0a7e-437b-bd66-3f6b59353b74@github.com>

On Mon, 11 Aug 2025 11:35:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review the change to update to using jtreg 8.
>> 
>> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to use correct library directories
>   
>   See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3106980594

From acobbs at openjdk.org  Mon Aug 11 18:17:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 11 Aug 2025 18:17:35 GMT
Subject: RFR: 8359383: Incorrect starting positions for implicitly typed
 variables [v2]
In-Reply-To: <DalHVpmhVqCE8vn2ePdsP0P5mPsL6mflttjK0NkG7nY=.b2ee068c-e4e5-4549-b519-b53112167969@github.com>
References: <DalHVpmhVqCE8vn2ePdsP0P5mPsL6mflttjK0NkG7nY=.b2ee068c-e4e5-4549-b519-b53112167969@github.com>
Message-ID: <gEppGku1f3EpnjY6Piqhh0gsgCdP_MesIZn48yG97SE=.9bf2810c-10a6-462b-9a5c-b82e82c8ab21@github.com>

> This fixes starting position bugs relating to implicitly typed variables; see the linked issue for details.
> 
> This also makes it possible to recover the declaration type (explicit, implicit, or `var`) from a `JCVariableDecl` and, in the case of `var` declarations, the starting position of the `var`; previously this wasn't possible.
> 
> Finally, as a minor drive-by improvement, we can now pretty print `var` as `var` instead of `/*missing*/`.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Add back regression test case that got removed somehow.
 - Merge branch 'master' into JDK-8359383
 - Fix various starting position bugs relating to implicitly typed variables.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25786/files
  - new: https://git.openjdk.org/jdk/pull/25786/files/1272b52d..af4ef40b

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

  Stats: 96928 lines in 2468 files changed: 54412 ins; 28080 del; 14436 mod
  Patch: https://git.openjdk.org/jdk/pull/25786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25786/head:pull/25786

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

From archie.cobbs at gmail.com  Mon Aug 11 18:57:33 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 11 Aug 2025 13:57:33 -0500
Subject: Compiler PR review requests
Message-ID: <CANSoFxuNZ8FcE3c=-8Jj8_xUgpz+T0LqtSmhMRHQc_ARUNU=oA@mail.gmail.com>

Dear compiler-dev reviewers,

I have a few small PR's and one big PR that need reviewers and would
appreciate your help in getting these resolved.

The big one...

JDK-8348611: Eliminate DeferredLintHandler and emit warnings after
attribution <https://github.com/openjdk/jdk/pull/24584>

This is a refactoring/cleanup that simplifies how warnings are logged, so
that regardless of compiler phase, lint configuration, etc., you can always
just invoke log.warning() to log a warning and the right thing happens
automatically.

Already reviewed by Maurizio but needs a second reviewer.

The small ones...

JDK-8349847: Support configuring individual lint categories as errors
<https://github.com/openjdk/jdk/pull/23622>

Adds the capability for more precise control of which warnings cause an
error. For example, -Werror:all,-serial.

This one has been sitting out there with a CSR since February. The code is
fairly straightforward; I think the main question is whether this is
something we want to add or not.

Any strong opinions one way or the other?

JDK-8353487: JShell LocalExecutionControl should allow decorating the
execution task <https://github.com/openjdk/jdk/pull/24398>

This is a simple API addition, but there is unresolved discussion about the
best way to augment the API.

Need someone in a position of authority (Jan) to weigh in.

JDK-8359383 <https://bugs.openjdk.org/browse/JDK-8359383>: Incorrect
starting positions for implicitly typed variables
<https://github.com/openjdk/jdk/pull/25786>

This fixes a few minor and obscure glitches in computed lexical starting
positions. Not the most important problem in the world right now, but it
would be nice to fix these corner cases.

Thanks,
-Archie

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

From acobbs at openjdk.org  Mon Aug 11 19:23:59 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 11 Aug 2025 19:23:59 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:

 - Merge branch 'master' into JDK-8348611 to fix conflict.
 - Remove an unnecessary field.
 - More simplification of LintMapper per review suggestions.
 - More simplification of LintMapper per review suggestions.
 - More refactoring to simplify LintMapper per review.
 - Refactor LintMapper to clean up internal type hierarchy per review.
 - Address a couple of review comments.
 - Merge branch 'master' into JDK-8348611
 - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
 - Merge branch 'master' into JDK-8348611 to fix conflicts.
 - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

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

Changes: https://git.openjdk.org/jdk/pull/24584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24584&range=09
  Stats: 1925 lines in 56 files changed: 981 ins; 584 del; 360 mod
  Patch: https://git.openjdk.org/jdk/pull/24584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24584/head:pull/24584

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

From liach at openjdk.org  Mon Aug 11 20:59:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Aug 2025 20:59:15 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
Message-ID: <KXtn3WXVuz86ZcGPq8IiAnqIPk1wHjdaJaNrOhftCJs=.6141fba9-5a2b-4a5e-87a4-369f237efd30@github.com>

On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
>  - Using EnumMap, as suggested.
>  - Removing unnecessary delimited, as suggested.

Looks good. This should have minimal impact to javac performance.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3107758710

From vromero at openjdk.org  Mon Aug 11 21:06:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Aug 2025 21:06:14 GMT
Subject: RFR: 8362885: A more formal way to mark javac's Flags that belong
 to a specific Symbol type only [v5]
In-Reply-To: <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
 <bHb26PXJJU6Yhoj7_BiJTdOHMc5r8wPQi7W47vAGHZY=.256bc633-e474-4db4-a92b-460e082bf640@github.com>
Message-ID: <qVMlP3tdXgMt-C0xyUrl7s_ImSwWXJS9cTO67G9BzK4=.067244e8-0950-413a-b1b5-81d14d8313ff@github.com>

On Mon, 11 Aug 2025 09:57:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR proposes to improve handling of javac's `Flags` in two ways:
>> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
>> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
>> 
>> This is inspired by:
>> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
>> 
>> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
>> 
>> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
>> 
>> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8362885' into JDK-8362885
>  - Using EnumMap, as suggested.
>  - Removing unnecessary delimited, as suggested.

very nice!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26452#pullrequestreview-3107774416

From jlahoda at openjdk.org  Tue Aug 12 09:23:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Aug 2025 09:23:03 GMT
Subject: RFR: 8341342: Elements.getAllModuleElements() does not work
 properly before JavacTask.analyze() [v2]
In-Reply-To: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
References: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
Message-ID: <aOrhUP0ILuURdndcXB1QbuTEMDJf6RBLaEECsqEFXQs=.3fedc631-c476-417c-ada8-fe35920013b4@github.com>

> When calling `Elements.getTypeElement(...)` or `Elements.getPackageElement(...)`, javac itself ensures that the enter phase is already done. That is, sadly, not done for `Elements.getAllModuleElements()`. This PR fixes that.
> 
> See:
> https://github.com/openjdk/jdk/pull/18934/files#r1767657515
> for a practical case.

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

  Using parameterized test as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26694/files
  - new: https://git.openjdk.org/jdk/pull/26694/files/358378db..8651514c

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

  Stats: 30 lines in 1 file changed: 12 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26694/head:pull/26694

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

From jlahoda at openjdk.org  Tue Aug 12 12:54:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Aug 2025 12:54:57 GMT
Subject: RFR: 8341342: Elements.getAllModuleElements() does not work
 properly before JavacTask.analyze() [v3]
In-Reply-To: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
References: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
Message-ID: <6v25uaSO91zq5XAL34o3Sl_4eKSGaLvvbqjy2vpVbW8=.29409787-087b-4358-bf75-f9902a78d54f@github.com>

> When calling `Elements.getTypeElement(...)` or `Elements.getPackageElement(...)`, javac itself ensures that the enter phase is already done. That is, sadly, not done for `Elements.getAllModuleElements()`. This PR fixes that.
> 
> See:
> https://github.com/openjdk/jdk/pull/18934/files#r1767657515
> for a practical case.

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

  Removing unnecessary explicit module initialization.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26694/files
  - new: https://git.openjdk.org/jdk/pull/26694/files/8651514c..5462926c

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

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

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

From vromero at openjdk.org  Tue Aug 12 14:38:11 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Aug 2025 14:38:11 GMT
Subject: RFR: 8341342: Elements.getAllModuleElements() does not work
 properly before JavacTask.analyze() [v3]
In-Reply-To: <6v25uaSO91zq5XAL34o3Sl_4eKSGaLvvbqjy2vpVbW8=.29409787-087b-4358-bf75-f9902a78d54f@github.com>
References: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
 <6v25uaSO91zq5XAL34o3Sl_4eKSGaLvvbqjy2vpVbW8=.29409787-087b-4358-bf75-f9902a78d54f@github.com>
Message-ID: <fmdksAhlSp5Xv8uD_ZRVzCW4vIg6GC0CydMeB1pbPtM=.36345764-0934-4d48-9d86-c1e27203f50e@github.com>

On Tue, 12 Aug 2025 12:54:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When calling `Elements.getTypeElement(...)` or `Elements.getPackageElement(...)`, javac itself ensures that the enter phase is already done. That is, sadly, not done for `Elements.getAllModuleElements()`. This PR fixes that.
>> 
>> See:
>> https://github.com/openjdk/jdk/pull/18934/files#r1767657515
>> for a practical case.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary explicit module initialization.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26694#pullrequestreview-3111025142

From liach at openjdk.org  Tue Aug 12 14:49:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Aug 2025 14:49:12 GMT
Subject: RFR: 8341342: Elements.getAllModuleElements() does not work
 properly before JavacTask.analyze() [v3]
In-Reply-To: <6v25uaSO91zq5XAL34o3Sl_4eKSGaLvvbqjy2vpVbW8=.29409787-087b-4358-bf75-f9902a78d54f@github.com>
References: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
 <6v25uaSO91zq5XAL34o3Sl_4eKSGaLvvbqjy2vpVbW8=.29409787-087b-4358-bf75-f9902a78d54f@github.com>
Message-ID: <1h3IzBAe0LSatjLEEPKYvfWjm9Ndq4hGUN1qtLc715I=.12bf977d-0973-4501-aa1f-54d7b749e6dc@github.com>

On Tue, 12 Aug 2025 12:54:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When calling `Elements.getTypeElement(...)` or `Elements.getPackageElement(...)`, javac itself ensures that the enter phase is already done. That is, sadly, not done for `Elements.getAllModuleElements()`. This PR fixes that.
>> 
>> See:
>> https://github.com/openjdk/jdk/pull/18934/files#r1767657515
>> for a practical case.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary explicit module initialization.

Thanks. This test is indeed a bit hard to organize due to being stateful. We can reorganize it if we need later.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26694#pullrequestreview-3111121499

From chen.l.liang at oracle.com  Tue Aug 12 15:13:40 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 12 Aug 2025 15:13:40 +0000
Subject: Compiler PR review requests
In-Reply-To: <CANSoFxuNZ8FcE3c=-8Jj8_xUgpz+T0LqtSmhMRHQc_ARUNU=oA@mail.gmail.com>
References: <CANSoFxuNZ8FcE3c=-8Jj8_xUgpz+T0LqtSmhMRHQc_ARUNU=oA@mail.gmail.com>
Message-ID: <SJ2PR10MB7669A583E49CA9A542216506A22BA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Archie, FYI people are coming back from JVMLS so it may take some time. In addition, most of our new development are focused on experimental projects like Babylon, Valhalla, and Amber, and javac is mainly just routine bugfixes, so these did not catch people's attention. So I think 8359383 is the most likely to be prioritized being a fix, while 8353487 is less because it involves API additions that has not seen a usage request.

Thanks, Chen
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Archie Cobbs <archie.cobbs at gmail.com>
Sent: Monday, August 11, 2025 11:57 AM
To: compiler-dev <compiler-dev at openjdk.org>
Subject: Compiler PR review requests

Dear compiler-dev reviewers,

I have a few small PR's and one big PR that need reviewers and would appreciate your help in getting these resolved.

The big one...

JDK-8348611: Eliminate DeferredLintHandler and emit warnings after attribution<https://github.com/openjdk/jdk/pull/24584>

This is a refactoring/cleanup that simplifies how warnings are logged, so that regardless of compiler phase, lint configuration, etc., you can always just invoke log.warning() to log a warning and the right thing happens automatically.

Already reviewed by Maurizio but needs a second reviewer.

The small ones...

JDK-8349847: Support configuring individual lint categories as errors<https://github.com/openjdk/jdk/pull/23622>

Adds the capability for more precise control of which warnings cause an error. For example, -Werror:all,-serial.

This one has been sitting out there with a CSR since February. The code is fairly straightforward; I think the main question is whether this is something we want to add or not.

Any strong opinions one way or the other?

JDK-8353487: JShell LocalExecutionControl should allow decorating the execution task<https://github.com/openjdk/jdk/pull/24398>

This is a simple API addition, but there is unresolved discussion about the best way to augment the API.

Need someone in a position of authority (Jan) to weigh in.

JDK-8359383<https://bugs.openjdk.org/browse/JDK-8359383>: Incorrect starting positions for implicitly typed variables<https://github.com/openjdk/jdk/pull/25786>

This fixes a few minor and obscure glitches in computed lexical starting positions. Not the most important problem in the world right now, but it would be nice to fix these corner cases.

Thanks,
-Archie

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

From archie.cobbs at gmail.com  Tue Aug 12 15:34:21 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 12 Aug 2025 10:34:21 -0500
Subject: Compiler PR review requests
In-Reply-To: <SJ2PR10MB7669A583E49CA9A542216506A22BA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANSoFxuNZ8FcE3c=-8Jj8_xUgpz+T0LqtSmhMRHQc_ARUNU=oA@mail.gmail.com>
 <SJ2PR10MB7669A583E49CA9A542216506A22BA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CANSoFxtrPj+zu-pYWj2jVTtgQnpL_ApAJbGAE8A5-N7V7h_-Gg@mail.gmail.com>

Hi Chen,

Thanks for responding. I understand, and there's absolutely no hurry on
these. I'm just trying to keep them from falling into the "lost forever"
bucket.

I'm targeting smaller, lower priority fixes, minor improvements, and
cleanups that other people are too busy to deal with ("code janitor"), so
it's understood that these PR's are going to be inherently less exciting
and lower priority in general. That also means sending out occasional (and
hopefully non-annoying) pings for review, which I don't mind doing, but let
me know if the ping rate needs to be adjusted :)

-Archie

On Tue, Aug 12, 2025 at 10:13?AM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Archie, FYI people are coming back from JVMLS so it may take some time.
> In addition, most of our new development are focused on experimental
> projects like Babylon, Valhalla, and Amber, and javac is mainly just
> routine bugfixes, so these did not catch people's attention. So I think
> 8359383 is the most likely to be prioritized being a fix, while 8353487 is
> less because it involves API additions that has not seen a usage request.
>
> Thanks, Chen
> ------------------------------
> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Archie
> Cobbs <archie.cobbs at gmail.com>
> *Sent:* Monday, August 11, 2025 11:57 AM
> *To:* compiler-dev <compiler-dev at openjdk.org>
> *Subject:* Compiler PR review requests
>
> Dear compiler-dev reviewers,
>
> I have a few small PR's and one big PR that need reviewers and would
> appreciate your help in getting these resolved.
>
> The big one...
>
> JDK-8348611: Eliminate DeferredLintHandler and emit warnings after
> attribution <https://github.com/openjdk/jdk/pull/24584>
>
> This is a refactoring/cleanup that simplifies how warnings are logged, so
> that regardless of compiler phase, lint configuration, etc., you can always
> just invoke log.warning() to log a warning and the right thing happens
> automatically.
>
> Already reviewed by Maurizio but needs a second reviewer.
>
> The small ones...
>
> JDK-8349847: Support configuring individual lint categories as errors
> <https://github.com/openjdk/jdk/pull/23622>
>
> Adds the capability for more precise control of which warnings cause an
> error. For example, -Werror:all,-serial.
>
> This one has been sitting out there with a CSR since February. The code is
> fairly straightforward; I think the main question is whether this is
> something we want to add or not.
>
> Any strong opinions one way or the other?
>
> JDK-8353487: JShell LocalExecutionControl should allow decorating the
> execution task <https://github.com/openjdk/jdk/pull/24398>
>
> This is a simple API addition, but there is unresolved discussion about
> the best way to augment the API.
>
> Need someone in a position of authority (Jan) to weigh in.
>
> JDK-8359383 <https://bugs.openjdk.org/browse/JDK-8359383>: Incorrect
> starting positions for implicitly typed variables
> <https://github.com/openjdk/jdk/pull/25786>
>
> This fixes a few minor and obscure glitches in computed lexical starting
> positions. Not the most important problem in the world right now, but it
> would be nice to fix these corner cases.
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>


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

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>

This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).

My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have ploughed through test cases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

After the review, I will update the copyrights.

I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

I got 4 timing related faults:
1) runtime/Thread/TestThreadDumpMonitorContention.java
   This is probably: https://bugs.openjdk.org/browse/JDK-8361370
2) sun/tools/jhsdb/BasicLauncherTest.java
   I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
3) gc/stress/TestReclaimStringsLeaksMemory.java
   I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
4) sun/security/ssl/X509KeyManager/CertChecking.java
   This is a new test that I got on last rebase. I have added a timeout of 480 to it.

In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.

>From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

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

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

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

From cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> sun/tools/jhsdb/BasicLauncherTest.java
> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.

@lkorinth Can you send me a link to the failure?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From vromero at openjdk.org  Tue Aug 12 18:35:17 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Aug 2025 18:35:17 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
Message-ID: <2l891gFnDGSFtpxiZNb7mGOzVKNpB05NHzwIXqwCihI=.48a2b2b4-6fe5-4df5-b53e-0566cba2aeb9@github.com>

On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>  - Remove an unnecessary field.
>  - More simplification of LintMapper per review suggestions.
>  - More simplification of LintMapper per review suggestions.
>  - More refactoring to simplify LintMapper per review.
>  - Refactor LintMapper to clean up internal type hierarchy per review.
>  - Address a couple of review comments.
>  - Merge branch 'master' into JDK-8348611
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

wow, very nice!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3112215380

From vicente.romero at oracle.com  Tue Aug 12 18:37:06 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 12 Aug 2025 14:37:06 -0400
Subject: Compiler PR review requests
In-Reply-To: <CANSoFxuNZ8FcE3c=-8Jj8_xUgpz+T0LqtSmhMRHQc_ARUNU=oA@mail.gmail.com>
References: <CANSoFxuNZ8FcE3c=-8Jj8_xUgpz+T0LqtSmhMRHQc_ARUNU=oA@mail.gmail.com>
Message-ID: <434df3a9-44e6-456c-aee3-2e5dff8fe1bb@oracle.com>

Hi Archie,

On 8/11/25 14:57, Archie Cobbs wrote:
> Dear compiler-dev reviewers,
>
> I have a few small PR's and one big PR that need reviewers and would 
> appreciate your help in getting these resolved.
>
> The big one...
>
> JDK-8348611: Eliminate DeferredLintHandler and emit warnings after 
> attribution <https://github.com/openjdk/jdk/pull/24584>
>
> This is a refactoring/cleanup that?simplifies how warnings are logged, 
> so that regardless of compiler phase, lint configuration,?etc., you 
> can always just invoke |log.warning()| to log a warning and the right 
> thing happens automatically.
>
> Already reviewed by Maurizio but needs a second reviewer.

really nice one, great simplification, I have been following the 
discussion. I was out for a few days, nice to see the final result. 
Really good

>
> -Archie
>
> -- 
> Archie L. Cobbs

Thanks,
Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250812/d7b97a60/attachment.htm>

From acobbs at openjdk.org  Tue Aug 12 19:26:21 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 12 Aug 2025 19:26:21 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <2l891gFnDGSFtpxiZNb7mGOzVKNpB05NHzwIXqwCihI=.48a2b2b4-6fe5-4df5-b53e-0566cba2aeb9@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <2l891gFnDGSFtpxiZNb7mGOzVKNpB05NHzwIXqwCihI=.48a2b2b4-6fe5-4df5-b53e-0566cba2aeb9@github.com>
Message-ID: <NhdMPZ8paUjKY-Uv-GAHz6NMFBIL1ZMRuc7X1HnQMDo=.0deb0168-5c49-4423-a411-8651be733158@github.com>

On Tue, 12 Aug 2025 18:32:44 GMT, Vicente Romero <vromero 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 97 commits:
>> 
>>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>>  - Remove an unnecessary field.
>>  - More simplification of LintMapper per review suggestions.
>>  - More simplification of LintMapper per review suggestions.
>>  - More refactoring to simplify LintMapper per review.
>>  - Refactor LintMapper to clean up internal type hierarchy per review.
>>  - Address a couple of review comments.
>>  - Merge branch 'master' into JDK-8348611
>>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef
>
> wow, very nice!

Hi @vicente-romero-oracle, thanks for the review, much appreciated!

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

PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3180703198

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271883564

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271888024

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3114280042

From jlahoda at openjdk.org  Wed Aug 13 08:11:26 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Aug 2025 08:11:26 GMT
Subject: Integrated: 8362885: A more formal way to mark javac's Flags that
 belong to a specific Symbol type only
In-Reply-To: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
References: <8B8_WIT1TzNgILQss3jwRNRWunfzR2NTBL4hIPIUfDw=.534128fd-533a-4356-9e15-b3065d92dd16@github.com>
Message-ID: <xJV57e7yqzyoMEeWxkCRZ_7k7D3Yuj9o0vSNrb6w7bs=.f6b90449-8b93-4351-895a-80a8d79ce8e7@github.com>

On Thu, 24 Jul 2025 07:21:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This PR proposes to improve handling of javac's `Flags` in two ways:
> - for each flag, there's now an informational annotation specifying what is the target Symbol type. Only targets right now are `TypeSymbol`s, `MethodSymbol`s and `VarSymbol`s. If we ran out of flags for `TypeSymbol`s, we could split those to module/package/class/type variable, but it does not seem to be quite necessary yet. There's an auxiliary special `BLOCK`, which is for `JCBlock`.
> - the manually handled `Flags.Flag` enum is replaced with autogenerated `FlagsEnum`
> 
> This is inspired by:
> https://github.com/openjdk/jdk/pull/26181#pullrequestreview-2997428662
> 
> There may be some better to handle `Flags` eventually, but this hopefully improves the current situation at least somewhat, by providing more formal way to say the flags' target, and restricting the need to read comments and search for free flags.
> 
> As a side-effect of this annotation, the `test/langtools/tools/javac/flags/FlagsTest.java` now also prints which flags are free, for each Symbol type.
> 
> (I will remove the `build` label for now, until discussion on javac level is done, and will re-add it if we decide the goal to autogenerate the FlagsEnum makes sense.)

This pull request has now been integrated.

Changeset: 72e22b4d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72e22b4de59a18f83c75be9a51fd99726f77f6f6
Stats:     495 lines in 8 files changed: 362 ins; 80 del; 53 mod

8362885: A more formal way to mark javac's Flags that belong to a specific Symbol type only

Reviewed-by: ihse, liach, vromero, mcimadamore, erikj

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

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

From jlahoda at openjdk.org  Wed Aug 13 08:14:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Aug 2025 08:14:22 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
Message-ID: <x0DnRLf764osC7P1gLwqVFPeTTpLHjXoNSYNru61Xko=.bda203c9-12af-449a-82fd-77dd04814bb8@github.com>

On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>  - Remove an unnecessary field.
>  - More simplification of LintMapper per review suggestions.
>  - More simplification of LintMapper per review suggestions.
>  - More refactoring to simplify LintMapper per review.
>  - Refactor LintMapper to clean up internal type hierarchy per review.
>  - Address a couple of review comments.
>  - Merge branch 'master' into JDK-8348611
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

Looks good to me.

Two overall comments:
- nice to see `ThisEscapeAnalyzer` is short-circuited, we'll see if there are more than needs to be short-circuited, but probably good to do it when there's a need, rather than pro-actively.
- the semantics for `BaseFileManager`/`Locations` is slightly complex (the `Context` there may be a different `Context` than used by the rest of javac, e.g. when created through `javax.tools.JavaCompiler.getStandardFileManager`). I *think* the current code is OK with that - the warnings should be reported using the root Lint, but I am not sure if there are any tests for that. I'll see if I can add a test, but it may be done separately.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 198:

> 196:             lintWaitersMap.entrySet().removeIf(entry -> {
> 197: 
> 198:                 // Is the source file no longer recognized? If so, discard warnings (e.g., this can happen with JShell)

Just for information, do you know/recall what's the exact path to get here with JShell?

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3114447229
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2272448421

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2272745651

From jlahoda at openjdk.org  Wed Aug 13 12:35:23 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Aug 2025 12:35:23 GMT
Subject: RFR: 8365314: javac fails with an exception for erroneous source
Message-ID: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>

For very broken code like:

$ cat /tmp/BrokenSuppressWarnings.java
@SuppressWarnings
public class BrokenSuppressWarnings {}


javac may fail with an exception:

$ javac -XDdev /tmp/BrokenSuppressWarnings.java
/tmp/BrokenSuppressWarnings.java:1: error: annotation @SuppressWarnings is missing a default value for the element 'value'
@SuppressWarnings
^
1 error
An exception has occurred in the compiler (26-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NullPointerException: Cannot read field "values" because "values" is null
        at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:532)
...
printing javac parameters to: /tmp/javac.20250812_114830.args


This is because the `Attribute` for `value` is missing. The proposed solution here is to ignore the missing attribute/`null`, by using `instanceof`.

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

Commit messages:
 - 8365314: javac fails with an exception for erroneous source

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

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

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273410872

From liach at openjdk.org  Wed Aug 13 13:13:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Aug 2025 13:13:16 GMT
Subject: RFR: 8365314: javac fails with an exception for erroneous source
In-Reply-To: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>
References: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>
Message-ID: <p8a9HrjeJZ-dOoqxxYAdCgYnwWiJJKnbnbgX8lJKjvE=.bd296eda-0209-46d1-8d3b-0f8c0eeecae8@github.com>

On Wed, 13 Aug 2025 12:28:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For very broken code like:
> 
> $ cat /tmp/BrokenSuppressWarnings.java
> @SuppressWarnings
> public class BrokenSuppressWarnings {}
> 
> 
> javac may fail with an exception:
> 
> $ javac -XDdev /tmp/BrokenSuppressWarnings.java
> /tmp/BrokenSuppressWarnings.java:1: error: annotation @SuppressWarnings is missing a default value for the element 'value'
> @SuppressWarnings
> ^
> 1 error
> An exception has occurred in the compiler (26-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "values" because "values" is null
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:532)
> ...
> printing javac parameters to: /tmp/javac.20250812_114830.args
> 
> 
> This is because the `Attribute` for `value` is missing. The proposed solution here is to ignore the missing attribute/`null`, by using `instanceof`.

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

> 532:             for (Attribute value : values.values) {
> 533:                 Optional.of(value)
> 534:                   .filter(val -> val instanceof Attribute.Constant)

Should we filter the .value field in this Attribute.Constant is indeed a String too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26758#discussion_r2273422638

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > sun/tools/jhsdb/BasicLauncherTest.java
> > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273468852

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  After suggestions from Erik and Andrey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

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

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

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

From lkorinth at openjdk.org  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273621868

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273614076

From acobbs at openjdk.org  Wed Aug 13 15:11:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Aug 2025 15:11:22 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
Message-ID: <l99A6XVYdHSmd31FZAZY6E6qJBooGxulMmFcp_vS274=.76e52865-1534-44be-a8a0-d7fbe06214e8@github.com>

On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>  - Remove an unnecessary field.
>  - More simplification of LintMapper per review suggestions.
>  - More simplification of LintMapper per review suggestions.
>  - More refactoring to simplify LintMapper per review.
>  - Refactor LintMapper to clean up internal type hierarchy per review.
>  - Address a couple of review comments.
>  - Merge branch 'master' into JDK-8348611
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

Hi Jan, thanks for taking a look.

> nice to see `ThisEscapeAnalyzer` is short-circuited, we'll see if there are more than needs to be short-circuited, but probably good to do it when there's a need, rather than pro-actively.

Right - and to elaborate on this a bit: We added the new `WARN` phase a while back as a comfortable home for `ThisEscapeAnalyzer` and any other future non-trivial warning calculators. Since `WARN` comes after `ATTR`, all attribution and `Lint` calculations are complete, and so you can always ask, "Is Lint category X enabled here... or here... or over there...?" without worry.

> the semantics for `BaseFileManager`/`Locations` is slightly complex (the `Context` there may be a different `Context` than used by the rest of javac, e.g. when created through `javax.tools.JavaCompiler.getStandardFileManager`). I _think_ the current code is OK with that - the warnings should be reported using the root Lint, but I am not sure if there are any tests for that. I'll see if I can add a test, but it may be done separately.

Ah, I didn't realize that. In any case it should have the same semantics as before, because in both cases (before and after this change), the `Lint` and the `Log` singletons derive from the same `Context`.

> Just for information, do you know/recall what's the exact path to get here with JShell?

If you throw an `AssertionError` in that particular case, you get a failure in `ToolEnablePreviewTest.java` that looks like this (but I haven't investigated it any further):

test ToolEnablePreviewTest.testCompilerTestFlag(): failure [406ms]
java.lang.AssertionError: unknown source file: WrappedJavaFileObject[jdk.jshell.MemoryFileManager$SourceMemoryJavaFileObject[string:///$NeverUsedName$.java]]
	at jdk.compiler/com.sun.tools.javac.util.Log$DiagnosticHandler.lambda$flushLintWaiters$0(Log.java:201)
	at java.base/java.util.Collection.removeIf(Collection.java:581)
	at jdk.compiler/com.sun.tools.javac.util.Log$DiagnosticHandler.flushLintWaiters(Log.java:196)
	at jdk.compiler/com.sun.tools.javac.util.Log.reportOutstandingWarnings(Log.java:832)
	at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.errorCount(JavaCompiler.java:583)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:177)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.parse(JavacTaskImpl.java:248)
	at jdk.jshell/jdk.jshell.TaskFactory$ParseTask.parse(TaskFactory.java:384)
	at jdk.jshell/jdk.jshell.TaskFactory$ParseTask.<init>(TaskFactory.java:373)
	at jdk.jshell/jdk.jshell.TaskFactory.lambda$parse$0(TaskFactory.java:149)
	at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218)
	at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:194)
	at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211)
	at jdk.jshell/jdk.jshell.TaskFactory.parse(TaskFactory.java:145)
	at jdk.jshell/jdk.jshell.TaskFactory.parse(TaskFactory.java:245)
	at jdk.jshell/jdk.jshell.CompletenessAnalyzer.lambda$scan$1(CompletenessAnalyzer.java:96)
	at jdk.jshell/jdk.jshell.CompletenessAnalyzer$Parser.disambiguateDeclarationVsExpression(CompletenessAnalyzer.java:769)
	at jdk.jshell/jdk.jshell.CompletenessAnalyzer$Parser.parseUnit(CompletenessAnalyzer.java:669)
	at jdk.jshell/jdk.jshell.CompletenessAnalyzer.scan(CompletenessAnalyzer.java:97)
	at jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.analyzeCompletion(SourceCodeAnalysisImpl.java:199)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.isComplete(JShellTool.java:1356)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1297)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1246)
	at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1031)
	at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:259)
	at ReplToolTesting.testRawRun(ReplToolTesting.java:319)
	at ReplToolTesting.testRaw(ReplToolTesting.java:302)
	at ReplToolTesting.test(ReplToolTesting.java:254)
	at ReplToolTesting.test(ReplToolTesting.java:241)
	at ReplToolTesting.test(ReplToolTesting.java:233)
	at ReplToolTesting.test(ReplToolTesting.java:224)
	at ToolEnablePreviewTest.testCompilerTestFlag(ToolEnablePreviewTest.java:97)

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

PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3184318491

From jlahoda at openjdk.org  Wed Aug 13 15:21:12 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Aug 2025 15:21:12 GMT
Subject: RFR: 8365314: javac fails with an exception for erroneous source
In-Reply-To: <p8a9HrjeJZ-dOoqxxYAdCgYnwWiJJKnbnbgX8lJKjvE=.bd296eda-0209-46d1-8d3b-0f8c0eeecae8@github.com>
References: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>
 <p8a9HrjeJZ-dOoqxxYAdCgYnwWiJJKnbnbgX8lJKjvE=.bd296eda-0209-46d1-8d3b-0f8c0eeecae8@github.com>
Message-ID: <7xVvFUb3Mrq2Pf9tCkqbFsQU1cgvaWKyFzmXZgH4KMQ=.d98a82a4-4b2b-418c-9922-2be0048e5194@github.com>

On Wed, 13 Aug 2025 13:10:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> For very broken code like:
>> 
>> $ cat /tmp/BrokenSuppressWarnings.java
>> @SuppressWarnings
>> public class BrokenSuppressWarnings {}
>> 
>> 
>> javac may fail with an exception:
>> 
>> $ javac -XDdev /tmp/BrokenSuppressWarnings.java
>> /tmp/BrokenSuppressWarnings.java:1: error: annotation @SuppressWarnings is missing a default value for the element 'value'
>> @SuppressWarnings
>> ^
>> 1 error
>> An exception has occurred in the compiler (26-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
>> java.lang.NullPointerException: Cannot read field "values" because "values" is null
>>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:532)
>> ...
>> printing javac parameters to: /tmp/javac.20250812_114830.args
>> 
>> 
>> This is because the `Attribute` for `value` is missing. The proposed solution here is to ignore the missing attribute/`null`, by using `instanceof`.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 534:
> 
>> 532:             for (Attribute value : values.values) {
>> 533:                 Optional.of(value)
>> 534:                   .filter(val -> val instanceof Attribute.Constant)
> 
> Should we filter the .value field in this Attribute.Constant is indeed a String too?

There's a fairly comprehensive test checking the behavior for non-String constants:
https://github.com/openjdk/jdk/blob/001aaa1e49f2692061cad44d68c9e81a27ea3b98/test/langtools/tools/javac/recovery/AnnotationRecovery.java#L167

I am not generally opposed to adding the check, but if I would be adding a check without a test, I think we need an extraordinary good reason to add it. So, do you have an example where the check is needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26758#discussion_r2273800302

From vromero at openjdk.org  Wed Aug 13 15:39:10 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 15:39:10 GMT
Subject: RFR: 8365314: javac fails with an exception for erroneous source
In-Reply-To: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>
References: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>
Message-ID: <w1l6rN7_bul9Ep1M1KVrB0JRtjoE9-CbjsgQSChDkYU=.52669ee2-3d88-4d1c-9fab-b84d2eff5e5b@github.com>

On Wed, 13 Aug 2025 12:28:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For very broken code like:
> 
> $ cat /tmp/BrokenSuppressWarnings.java
> @SuppressWarnings
> public class BrokenSuppressWarnings {}
> 
> 
> javac may fail with an exception:
> 
> $ javac -XDdev /tmp/BrokenSuppressWarnings.java
> /tmp/BrokenSuppressWarnings.java:1: error: annotation @SuppressWarnings is missing a default value for the element 'value'
> @SuppressWarnings
> ^
> 1 error
> An exception has occurred in the compiler (26-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "values" because "values" is null
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:532)
> ...
> printing javac parameters to: /tmp/javac.20250812_114830.args
> 
> 
> This is because the `Attribute` for `value` is missing. The proposed solution here is to ignore the missing attribute/`null`, by using `instanceof`.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26758#pullrequestreview-3116581273

From vromero at openjdk.org  Wed Aug 13 16:59:22 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 16:59:22 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
Message-ID: <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>

On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>  - Remove an unnecessary field.
>  - More simplification of LintMapper per review suggestions.
>  - More simplification of LintMapper per review suggestions.
>  - More refactoring to simplify LintMapper per review.
>  - Refactor LintMapper to clean up internal type hierarchy per review.
>  - Address a couple of review comments.
>  - Merge branch 'master' into JDK-8348611
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 75:

> 73: 
> 74:     // Per-source file information. Note: during the parsing of a file, an entry exists but the FileInfo value is null
> 75:     private final Map<JavaFileObject, FileInfo> fileInfoMap = new HashMap<>();

would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274068210

From vromero at openjdk.org  Wed Aug 13 17:57:17 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 17:57:17 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
Message-ID: <Z05e4YpEntnpJnxD0I4fOgKmGm_VqaGUAlKBmTjpZ7k=.2c7ecffe-f99f-452e-8fd2-8269623c5cbc@github.com>

On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>  - Remove an unnecessary field.
>  - More simplification of LintMapper per review suggestions.
>  - More simplification of LintMapper per review suggestions.
>  - More refactoring to simplify LintMapper per review.
>  - Refactor LintMapper to clean up internal type hierarchy per review.
>  - Address a couple of review comments.
>  - Merge branch 'master' into JDK-8348611
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 250:

> 248:         Span span,                                      // declaration's lexical range
> 249:         Lint lint,                                      // the Lint configuration that applies at this declaration
> 250:         Symbol symbol,                                  // declaration symbol (for debug purposes only; null for root)

nit: should we keep this field in the final version? we can add it while debugging if needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274219819

From acobbs at openjdk.org  Wed Aug 13 18:13:16 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Aug 2025 18:13:16 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>
Message-ID: <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>

On Wed, 13 Aug 2025 16:56:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared.

Frankly I'm a little fuzzy on that. If there were an issue with `LintMapper.fileInfoMap`, then wouldn't the same issue exist with `AbstractLog.sourceMap`? Note `LintMapper.clear()` and `Log.clear()` are called at the same time, so it seems in any given scenario, they are going to either both be cleared or both not be cleared.

> nit: should we keep this field in the final version? we can add it while debugging if needed

I can remove it. Besides, this symbol is always the same object as the one that the `Lint` instance was created with, so if debugging were a concern, a better place to store it would be with the `Lint` instance anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274249547
PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274250193

From vromero at openjdk.org  Wed Aug 13 19:02:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 19:02:16 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>
 <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>
Message-ID: <LqiAbd3PPd8tVK8-9F0oXh4ckvWVPO-CDciqc7tD5xI=.37112a85-e844-4804-821f-dd888e7a2cfd@github.com>

On Wed, 13 Aug 2025 18:10:14 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 75:
>> 
>>> 73: 
>>> 74:     // Per-source file information. Note: during the parsing of a file, an entry exists but the FileInfo value is null
>>> 75:     private final Map<JavaFileObject, FileInfo> fileInfoMap = new HashMap<>();
>> 
>> would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared.
>
>> would it makes sense to make this map a WeakHashMap? I'm thinking about cases where we are not using a ReusableContext and thus this map wont be cleared.
> 
> Frankly I'm a little fuzzy on that. If there were an issue with `LintMapper.fileInfoMap`, then wouldn't the same issue exist with `AbstractLog.sourceMap`? Note `LintMapper.clear()` and `Log.clear()` are called at the same time, so it seems in any given scenario, they are going to either both be cleared or both not be cleared.

yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274354834

From acobbs at openjdk.org  Wed Aug 13 19:41:15 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Aug 2025 19:41:15 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <LqiAbd3PPd8tVK8-9F0oXh4ckvWVPO-CDciqc7tD5xI=.37112a85-e844-4804-821f-dd888e7a2cfd@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>
 <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>
 <LqiAbd3PPd8tVK8-9F0oXh4ckvWVPO-CDciqc7tD5xI=.37112a85-e844-4804-821f-dd888e7a2cfd@github.com>
Message-ID: <z_BHBxwi0oWoU4lB5JWP8chh_J1rwAC2HBb20uTfmso=.df6fc99d-21d6-4f1f-9bde-e94edcc5ad69@github.com>

On Wed, 13 Aug 2025 18:59:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue

I'm not familiar with all of the various compiler life-cycle variants, but I guess it would boil down to the question, "In what scenarios would a `Context` that's not a `ReusableContext` be reused for multiple compilations?"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274432201

From jlahoda at openjdk.org  Wed Aug 13 19:41:16 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Aug 2025 19:41:16 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <z_BHBxwi0oWoU4lB5JWP8chh_J1rwAC2HBb20uTfmso=.df6fc99d-21d6-4f1f-9bde-e94edcc5ad69@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>
 <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>
 <LqiAbd3PPd8tVK8-9F0oXh4ckvWVPO-CDciqc7tD5xI=.37112a85-e844-4804-821f-dd888e7a2cfd@github.com>
 <z_BHBxwi0oWoU4lB5JWP8chh_J1rwAC2HBb20uTfmso=.df6fc99d-21d6-4f1f-9bde-e94edcc5ad69@github.com>
Message-ID: <qpFwhtasNLFN6sjiE800C6-tR1zYqD_61aJPmB-xWBE=.3ffad3d0-48c7-4229-92d5-d959dbcf8104@github.com>

On Wed, 13 Aug 2025 19:36:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue
>
>> yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue
> 
> I'm not familiar with all of the various compiler life-cycle variants, but I guess it would boil down to the question, "In what scenarios would a `Context` that's not a `ReusableContext` be reused for multiple compilations?"

FWIW, this is an instance field on a `Context` service - it will be GCed when the given javac instance is GCed. I think in most cases, use of weak maps is not necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274438431

From vromero at openjdk.org  Wed Aug 13 19:49:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 19:49:14 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <qpFwhtasNLFN6sjiE800C6-tR1zYqD_61aJPmB-xWBE=.3ffad3d0-48c7-4229-92d5-d959dbcf8104@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>
 <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>
 <LqiAbd3PPd8tVK8-9F0oXh4ckvWVPO-CDciqc7tD5xI=.37112a85-e844-4804-821f-dd888e7a2cfd@github.com>
 <z_BHBxwi0oWoU4lB5JWP8chh_J1rwAC2HBb20uTfmso=.df6fc99d-21d6-4f1f-9bde-e94edcc5ad69@github.com>
 <qpFwhtasNLFN6sjiE800C6-tR1zYqD_61aJPmB-xWBE=.3ffad3d0-48c7-4229-92d5-d959dbcf8104@github.com>
Message-ID: <PKsqHlswNgQH3FbCz4HPDiR2z4olr8Fh4Nd1XJaunx0=.ae986a12-51b8-45fa-a38b-2259c087486e@github.com>

On Wed, 13 Aug 2025 19:38:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> yes you are right we have other DSs with the same `issue` if any. I guess discuss and address it as a separate issue
>> 
>> I'm not familiar with all of the various compiler life-cycle variants, but I guess it would boil down to the question, "In what scenarios would a `Context` that's not a `ReusableContext` be reused for multiple compilations?"
>
> FWIW, this is an instance field on a `Context` service - it will be GCed when the given javac instance is GCed. I think in most cases, use of weak maps is not necessary.

I was worried about holding unnecessary memory withing one javac instance

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274464640

From vromero at openjdk.org  Wed Aug 13 20:46:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 20:46:18 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
Message-ID: <wR8zBD3uuoy0mLQ5bgIn6fmbufays0SbgqiTP_uFrkI=.44048733-6f8e-4cd0-9b70-d503450ce09c@github.com>

On Mon, 11 Aug 2025 19:23:59 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>  - Remove an unnecessary field.
>  - More simplification of LintMapper per review suggestions.
>  - More simplification of LintMapper per review suggestions.
>  - More refactoring to simplify LintMapper per review.
>  - Refactor LintMapper to clean up internal type hierarchy per review.
>  - Address a couple of review comments.
>  - Merge branch 'master' into JDK-8348611
>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef

src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251:

> 249:         Lint lint,                                      // the Lint configuration that applies at this declaration
> 250:         Symbol symbol,                                  // declaration symbol (for debug purposes only; null for root)
> 251:         List<LintRange> children                        // the nested declarations one level below this node

not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274581943

From vromero at openjdk.org  Wed Aug 13 21:27:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 21:27:18 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v8]
In-Reply-To: <4rKKMZp7x3LHh-20459LtyTWbOVYbnBGTogg4YDJacM=.4e065c76-7f5d-4ad9-ac8d-c8870b680f5a@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
 <4rKKMZp7x3LHh-20459LtyTWbOVYbnBGTogg4YDJacM=.4e065c76-7f5d-4ad9-ac8d-c8870b680f5a@github.com>
Message-ID: <E1lmQwmmAYFjSsX6rZZxvQ5gbq-nVG7tokgTwcVpzIY=.fe60ada3-dce7-4945-b98f-537e1aa344cf@github.com>

On Thu, 31 Jul 2025 14:24:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR enhances the `-Werror` flag to support lint categories just like `-Xlint` does. For example `-Werror:all,-preview` would cause an error if any warning not in the `preview` lint category occurred.
>> 
>> The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` is equivalent to `-Xlint:all`). This behavior has been factored out and Javadocumented so that both `-Xlint` and `-Werror` can have this same "parsing" logic.
>> 
>> See the CSR [JDK-8350044](https://bugs.openjdk.org/browse/JDK-8350044) for details on how the new flag behaves in certain corner cases.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into JDK-8349847 to fix cross-compiling build problem.
>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>  - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
>  - Ensure that "-Xlint:none" still works for the affected warnings.
>    
>    The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>    which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>    which allowed the affected warnings to get away with skipping that check.
>  - Minor naming and Javadoc tweaks.
>  - Merge branch 'JDK-8359596' into JDK-8349847
>  - No need for /nodynamiccopyright/ with this test.
>  - Restore behavior when both -Xlint:options and -Xlint:-options are given.
>  - Merge branch 'master' into JDK-8349847
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/5f357fa2...2bdc2ab0

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java line 176:

> 174:     /**
> 175:      * Determine if a specific {@link LintCategory} is enabled via a custom
> 176:      * option flag of the form {@code -Flag}, {@code -Flag:all}, or {@code -Flag:key}.

nit: `Flag` seems to imply that any flag is acceptable when only two are

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java line 248:

> 246:      *
> 247:      * <p>
> 248:      * The set of categories is calculated as folllows. First, an initial set is created:

typo: `folllows`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23622#discussion_r2274650854
PR Review Comment: https://git.openjdk.org/jdk/pull/23622#discussion_r2274657381

From vromero at openjdk.org  Wed Aug 13 21:50:10 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 21:50:10 GMT
Subject: RFR: 8359497: IllegalArgumentException thrown by
 SourceCodeAnalysisImpl.highlights()
In-Reply-To: <FGgeVak7OLd0F3KE_n6y8nSdb0oIXIX5LW7yhPC18k4=.485d5b87-6269-4a29-a5e3-5c2b24928a77@github.com>
References: <FGgeVak7OLd0F3KE_n6y8nSdb0oIXIX5LW7yhPC18k4=.485d5b87-6269-4a29-a5e3-5c2b24928a77@github.com>
Message-ID: <q7TPghXLufPVWCilPpUU8eBcoahTRBdNpNy6o5I4HdA=.ebd68149-2612-449a-ac68-6021a8f006f8@github.com>

On Wed, 23 Jul 2025 14:56:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JShell computes highlights, it uses the javac' lexer to detect keywords. But, if there's a lexical error in the input, the lexer will try to report an error, but that will with an exception, as there's no input file set. This PR:
> - sets a source to `Log` so that the attempt to report the error will not fail
> - sets a `DiagnosticListener` so that the error is ignored (as the error is not important, this lexer is only used to detect keyword).

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26446#pullrequestreview-3117823048

From vromero at openjdk.org  Wed Aug 13 21:54:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Aug 2025 21:54:18 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v8]
In-Reply-To: <4rKKMZp7x3LHh-20459LtyTWbOVYbnBGTogg4YDJacM=.4e065c76-7f5d-4ad9-ac8d-c8870b680f5a@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
 <4rKKMZp7x3LHh-20459LtyTWbOVYbnBGTogg4YDJacM=.4e065c76-7f5d-4ad9-ac8d-c8870b680f5a@github.com>
Message-ID: <2bhwjXGpw6JAdMMUpvMKbtBgUq6j9y9UM0tQQBN0EFs=.771362e7-bfb6-4274-a626-9291e87b7cd0@github.com>

On Thu, 31 Jul 2025 14:24:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR enhances the `-Werror` flag to support lint categories just like `-Xlint` does. For example `-Werror:all,-preview` would cause an error if any warning not in the `preview` lint category occurred.
>> 
>> The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` is equivalent to `-Xlint:all`). This behavior has been factored out and Javadocumented so that both `-Xlint` and `-Werror` can have this same "parsing" logic.
>> 
>> See the CSR [JDK-8350044](https://bugs.openjdk.org/browse/JDK-8350044) for details on how the new flag behaves in certain corner cases.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into JDK-8349847 to fix cross-compiling build problem.
>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>  - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
>  - Ensure that "-Xlint:none" still works for the affected warnings.
>    
>    The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>    which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>    which allowed the affected warnings to get away with skipping that check.
>  - Minor naming and Javadoc tweaks.
>  - Merge branch 'JDK-8359596' into JDK-8349847
>  - No need for /nodynamiccopyright/ with this test.
>  - Restore behavior when both -Xlint:options and -Xlint:-options are given.
>  - Merge branch 'master' into JDK-8349847
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/5f357fa2...2bdc2ab0

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java line 268:

> 266: 
> 267:         // Create the initial set
> 268:         EnumSet<LintCategory> categories;

should we check that the option parameter is either `Xlint` or `Werror`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23622#discussion_r2274730323

From acobbs at openjdk.org  Wed Aug 13 22:44:16 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Aug 2025 22:44:16 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <wR8zBD3uuoy0mLQ5bgIn6fmbufays0SbgqiTP_uFrkI=.44048733-6f8e-4cd0-9b70-d503450ce09c@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <wR8zBD3uuoy0mLQ5bgIn6fmbufays0SbgqiTP_uFrkI=.44048733-6f8e-4cd0-9b70-d503450ce09c@github.com>
Message-ID: <1Yhf56lsX7-JRw2sM9E3E0zb0R6sjqvEZlvSRX28EYI=.3b02f424-b25a-4dad-a216-fe033fb1e8f3@github.com>

On Wed, 13 Aug 2025 20:42:44 GMT, Vicente Romero <vromero 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 97 commits:
>> 
>>  - Merge branch 'master' into JDK-8348611 to fix conflict.
>>  - Remove an unnecessary field.
>>  - More simplification of LintMapper per review suggestions.
>>  - More simplification of LintMapper per review suggestions.
>>  - More refactoring to simplify LintMapper per review.
>>  - Refactor LintMapper to clean up internal type hierarchy per review.
>>  - Address a couple of review comments.
>>  - Merge branch 'master' into JDK-8348611
>>  - Add DEFAULT_ENABLED flags to fix some mandatory warnings.
>>  - Merge branch 'master' into JDK-8348611 to fix conflicts.
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/8cd79752...18eaa8ef
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251:
> 
>> 249:         Lint lint,                                      // the Lint configuration that applies at this declaration
>> 250:         Symbol symbol,                                  // declaration symbol (for debug purposes only; null for root)
>> 251:         List<LintRange> children                        // the nested declarations one level below this node
> 
> not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future

I think at one point I had something like that, but it made things more complicated. Plain binary search doesn't work when you are searching in a list of (possibly nested) intervals instead of a list of points, because there can be multiple matches (arbitrarily many in fact). I think it would require an [Interval tree](https://en.wikipedia.org/wiki/Interval_tree).

There is also another annoying detail, which is that the nesting is not always proper: in some oddball cases (none of which I can specifically remember) there can be an AST node whose starting position is before the starting position of its parent AST node (or ending position after its parent). These instances could cause an Interval tree type of algorithm to glitch out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2274793914

From acobbs at openjdk.org  Thu Aug 14 03:50:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Aug 2025 03:50:29 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v8]
In-Reply-To: <E1lmQwmmAYFjSsX6rZZxvQ5gbq-nVG7tokgTwcVpzIY=.fe60ada3-dce7-4945-b98f-537e1aa344cf@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
 <4rKKMZp7x3LHh-20459LtyTWbOVYbnBGTogg4YDJacM=.4e065c76-7f5d-4ad9-ac8d-c8870b680f5a@github.com>
 <E1lmQwmmAYFjSsX6rZZxvQ5gbq-nVG7tokgTwcVpzIY=.fe60ada3-dce7-4945-b98f-537e1aa344cf@github.com>
Message-ID: <EUJ_5y9DcHliCcTUv9OgN7-mpnFxYFuT8U99PPMD7N0=.cb9f9dc9-eb13-4dff-bbda-e606c0c5c4e8@github.com>

On Wed, 13 Aug 2025 21:11:04 GMT, Vicente Romero <vromero 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 14 commits:
>> 
>>  - Merge branch 'master' into JDK-8349847 to fix cross-compiling build problem.
>>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>>  - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
>>  - Ensure that "-Xlint:none" still works for the affected warnings.
>>    
>>    The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>>    which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>>    which allowed the affected warnings to get away with skipping that check.
>>  - Minor naming and Javadoc tweaks.
>>  - Merge branch 'JDK-8359596' into JDK-8349847
>>  - No need for /nodynamiccopyright/ with this test.
>>  - Restore behavior when both -Xlint:options and -Xlint:-options are given.
>>  - Merge branch 'master' into JDK-8349847
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/5f357fa2...2bdc2ab0
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java line 176:
> 
>> 174:     /**
>> 175:      * Determine if a specific {@link LintCategory} is enabled via a custom
>> 176:      * option flag of the form {@code -Flag}, {@code -Flag:all}, or {@code -Flag:key}.
> 
> nit: `Flag` seems to imply that any flag is acceptable when only two are

Thanks - should be fixed in e8f5539f3a1.

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java line 248:
> 
>> 246:      *
>> 247:      * <p>
>> 248:      * The set of categories is calculated as folllows. First, an initial set is created:
> 
> typo: `folllows`

Thanks - should be fixed in e8f5539f3a1.

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java line 268:
> 
>> 266: 
>> 267:         // Create the initial set
>> 268:         EnumSet<LintCategory> categories;
> 
> should we check that the option parameter is either `Xlint` or `Werror`?

Good point - it happens by virtue of the call to `Option.getCustom()` which throws an exception if no custom option exists, but not perfectly - that method only checks for the existence of a matching enum value ending in `_CUSTOM`, and such values also exist for `-g` and `-Xdoclint`. That has been tightened up in e8f5539f3a1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23622#discussion_r2275264827
PR Review Comment: https://git.openjdk.org/jdk/pull/23622#discussion_r2275264879
PR Review Comment: https://git.openjdk.org/jdk/pull/23622#discussion_r2275264992

From acobbs at openjdk.org  Thu Aug 14 03:50:27 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Aug 2025 03:50:27 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v9]
In-Reply-To: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
Message-ID: <BxVQJlCn6ggfIwCQBTNObtVDepfwKbgVB-mrzLl3N7w=.87eaa86e-05d1-4772-8c50-006eee9241db@github.com>

> This PR enhances the `-Werror` flag to support lint categories just like `-Xlint` does. For example `-Werror:all,-preview` would cause an error if any warning not in the `preview` lint category occurred.
> 
> The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` is equivalent to `-Xlint:all`). This behavior has been factored out and Javadocumented so that both `-Xlint` and `-Werror` can have this same "parsing" logic.
> 
> See the CSR [JDK-8350044](https://bugs.openjdk.org/browse/JDK-8350044) for details on how the new flag behaves in certain corner cases.

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

 - Address review comments.
 - Merge branch 'master' into JDK-8349847
 - Merge branch 'master' into JDK-8349847 to fix cross-compiling build problem.
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
 - Ensure that "-Xlint:none" still works for the affected warnings.
   
   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
   which allowed the affected warnings to get away with skipping that check.
 - Minor naming and Javadoc tweaks.
 - Merge branch 'JDK-8359596' into JDK-8349847
 - No need for /nodynamiccopyright/ with this test.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/8cd79752...e8f5539f

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

Changes: https://git.openjdk.org/jdk/pull/23622/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23622&range=08
  Stats: 268 lines in 15 files changed: 188 ins; 35 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/23622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23622/head:pull/23622

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

From acobbs at openjdk.org  Thu Aug 14 04:00:12 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Aug 2025 04:00:12 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v11]
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <kL8PQBWUxtmozBzmQRc67aiM1Fp-567gROp3spOjN9U=.6a8d72f2-8def-4b9b-8977-cb54b520d871@github.com>

> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
> 
> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
> 
> In addition, several other factors complicate things:
> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
> 
> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
> 
> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.

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

  Remove unused field from "LintRange" record.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24584/files
  - new: https://git.openjdk.org/jdk/pull/24584/files/18eaa8ef..1f1247bc

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

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

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

From acobbs at openjdk.org  Thu Aug 14 04:00:13 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Aug 2025 04:00:13 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <8hd3w_O3ZkXfrfaKlt4tO7xaMNqMwDsq9nO326Sfaso=.f7ee7ff4-8326-47cb-85da-904582db31d7@github.com>
 <Bo4WRx7l8NGg0wAUH_-fiCUoo39drLdeADO2RPNS3vw=.12634712-ad2c-4330-9356-5f50f788eeca@github.com>
Message-ID: <cBvZuEbmV7cUw6KbXAmbbEsm-YDMWA8fHDcslk4jbH0=.edd7849c-21b8-4567-87b6-9a4d8aa1e402@github.com>

On Wed, 13 Aug 2025 18:10:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 250:
>> 
>>> 248:         Span span,                                      // declaration's lexical range
>>> 249:         Lint lint,                                      // the Lint configuration that applies at this declaration
>>> 250:         Symbol symbol,                                  // declaration symbol (for debug purposes only; null for root)
>> 
>> nit: should we keep this field in the final version? we can add it while debugging if needed
>
>> nit: should we keep this field in the final version? we can add it while debugging if needed
> 
> I can remove it. Besides, this symbol is always the same object as the one that the `Lint` instance was created with, so if debugging were a concern, a better place to store it would be with the `Lint` instance anyway.

Unused field removed in 1f1247bc5cf.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2275275487

From jlahoda at openjdk.org  Thu Aug 14 07:05:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Aug 2025 07:05:22 GMT
Subject: Integrated: 8341342: Elements.getAllModuleElements() does not work
 properly before JavacTask.analyze()
In-Reply-To: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
References: <fQThYW5ovyf5g_a0-HWmqDS-5_wpcgfv0uOn5zdpp8o=.98f96b28-4a05-4043-bf5b-157260732324@github.com>
Message-ID: <dPJmU8JNMjrTwLtciRr16Ypj_NOmnkVrQTxsHHbdqyw=.5f1b528d-1dfc-41b9-a59e-2ab42db35c22@github.com>

On Fri, 8 Aug 2025 12:03:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When calling `Elements.getTypeElement(...)` or `Elements.getPackageElement(...)`, javac itself ensures that the enter phase is already done. That is, sadly, not done for `Elements.getAllModuleElements()`. This PR fixes that.
> 
> See:
> https://github.com/openjdk/jdk/pull/18934/files#r1767657515
> for a practical case.

This pull request has now been integrated.

Changeset: c22e01d7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c22e01d77648036db4ed640521e82c49f8791ca1
Stats:     76 lines in 3 files changed: 75 ins; 1 del; 0 mod

8341342: Elements.getAllModuleElements() does not work properly before JavacTask.analyze()

Reviewed-by: vromero, liach

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

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

From jlahoda at openjdk.org  Thu Aug 14 07:08:17 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Aug 2025 07:08:17 GMT
Subject: Integrated: 8365314: javac fails with an exception for erroneous
 source
In-Reply-To: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>
References: <bKbh5Yvi0eYTZPkpUjCRHTt3GydrzwqjjGTCigrk3os=.43943a89-9ba4-450a-957f-f79ab5545898@github.com>
Message-ID: <kDqQ-m3cdSfy8XSmw-diMadgqb8zkmLlXgiAv4sWuqU=.2c96404b-6064-45ec-995b-23cb632ff094@github.com>

On Wed, 13 Aug 2025 12:28:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For very broken code like:
> 
> $ cat /tmp/BrokenSuppressWarnings.java
> @SuppressWarnings
> public class BrokenSuppressWarnings {}
> 
> 
> javac may fail with an exception:
> 
> $ javac -XDdev /tmp/BrokenSuppressWarnings.java
> /tmp/BrokenSuppressWarnings.java:1: error: annotation @SuppressWarnings is missing a default value for the element 'value'
> @SuppressWarnings
> ^
> 1 error
> An exception has occurred in the compiler (26-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "values" because "values" is null
>         at jdk.compiler/com.sun.tools.javac.code.Lint.suppressionsFrom(Lint.java:532)
> ...
> printing javac parameters to: /tmp/javac.20250812_114830.args
> 
> 
> This is because the `Attribute` for `value` is missing. The proposed solution here is to ignore the missing attribute/`null`, by using `instanceof`.

This pull request has now been integrated.

Changeset: a6be2286
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6be2286421e069a292c749eecd6bdc38a8deaf2
Stats:     34 lines in 2 files changed: 25 ins; 0 del; 9 mod

8365314: javac fails with an exception for erroneous source

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Thu Aug 14 08:31:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Aug 2025 08:31:08 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions [v3]
In-Reply-To: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
Message-ID: <FSx-BVzGU_Uvjcx0Bhx0AugDLyXOmfBqTz7ZAUXtLPk=.cbd88d51-4e90-4bda-b0c6-06be7da160ed@github.com>

> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them.
> 
> There are two problems with this background task:
> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet,
> - the module path is not included in the list of paths to paths to search
> 
> This PR proposes to:
> - use FileManager configured by passing the compile options through javac
> - include the module path in the search path

Jan Lahoda 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:

 - Reading module paths directly from the FileManager, to avoid playing with JRT FS.
 - Merge branch 'master' into JDK-8177650
 - Avoiding problems with locked files on Windows.
 - Correcting handling of modular paths.
 - Improving test reliability.
 - 8177650: JShell tool: packages in classpath don't appear in completions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26137/files
  - new: https://git.openjdk.org/jdk/pull/26137/files/54eed125..b4e0b0f0

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

  Stats: 69596 lines in 1762 files changed: 41124 ins; 19092 del; 9380 mod
  Patch: https://git.openjdk.org/jdk/pull/26137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26137/head:pull/26137

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

From jlahoda at openjdk.org  Thu Aug 14 08:31:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Aug 2025 08:31:09 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions [v2]
In-Reply-To: <mmpaUfANdsNA7aAEhRD60pGMonEDxKxcAGlByNOW9us=.c447420e-8f21-4d55-8b8c-fda1e6ba6fb7@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
 <mmpaUfANdsNA7aAEhRD60pGMonEDxKxcAGlByNOW9us=.c447420e-8f21-4d55-8b8c-fda1e6ba6fb7@github.com>
Message-ID: <mRjmGQ_LGTPT2z-QTDya2TJ8012FA7YyfqRr4iZDk_w=.a2b2ce2f-4904-48f5-8cde-f9237462875a@github.com>

On Mon, 7 Jul 2025 13:05:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell provides the code completion feature, where it suggests possible follow ups for a given snippet prefix. To allow completion for packages, JShell uses a background task to go through known classes and create an index for them.
>> 
>> There are two problems with this background task:
>> - the classpath is read from the JShell's FileManager, but the FileManager may not be configured with the compile options yet, so the classpath may not be filled yet,
>> - the module path is not included in the list of paths to paths to search
>> 
>> This PR proposes to:
>> - use FileManager configured by passing the compile options through javac
>> - include the module path in the search path
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoiding problems with locked files on Windows.

During discussion with @david-beaumont, it turned out it might be better to read module content directly from the `JavaFileManager`, using methods like `listLocationsForModules`, rather than manually try to inspect the JRT FileSystem from JShell. So that is what:
https://github.com/openjdk/jdk/pull/26137/commits/b4e0b0f0efc1f263dc775d2447b4b531d82badfa
is trying to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/26137#issuecomment-3187468393

From jpai at openjdk.org  Thu Aug 14 10:42:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 10:42:26 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
Message-ID: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>

Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.

These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.

tier1, tier2 and tier3 testing of this change completed without any related failures.

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

Commit messages:
 - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

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

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

From duke at openjdk.org  Thu Aug 14 12:04:14 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 14 Aug 2025 12:04:14 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <RwfKP5KO_jRS4HxRMRu_pfbiNJahmrRc9q8qMybEaiU=.8319ef07-772d-4817-8e5f-b88fd887afa1@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

See?also <https://github.com/openjdk/jdk/pull/26765> ([JDK?8365416])

[JDK?8365416]: https://bugs.openjdk.org/browse/JDK-8365416 "[JDK?8365416] java.desktop no?longer?needs preview?feature?access"

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

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3188202824

From jpai at openjdk.org  Thu Aug 14 12:23:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 12:23:12 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <R-Hw3-g5SjEVgWmyAGyXJ2HrKh9MyDgcfuMvU9erYsk=.65b03c56-5e97-4de4-a3fc-639ffb8195e5@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

> See also #26765 ([JDK?8365416](https://bugs.openjdk.org/browse/JDK-8365416))

Right, that's what prompted me to start looking into this. The java.desktop change for which that other PR is open can go ahead independently.

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

PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3188258941

From vromero at openjdk.org  Thu Aug 14 13:26:25 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Aug 2025 13:26:25 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v10]
In-Reply-To: <1Yhf56lsX7-JRw2sM9E3E0zb0R6sjqvEZlvSRX28EYI=.3b02f424-b25a-4dad-a216-fe033fb1e8f3@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <X9lVb_n863mZwiJWYC7aIXbrROoQ3SQeCvO21p6-VO0=.ac8623fb-85bc-4095-9007-e049d2fa4e13@github.com>
 <wR8zBD3uuoy0mLQ5bgIn6fmbufays0SbgqiTP_uFrkI=.44048733-6f8e-4cd0-9b70-d503450ce09c@github.com>
 <1Yhf56lsX7-JRw2sM9E3E0zb0R6sjqvEZlvSRX28EYI=.3b02f424-b25a-4dad-a216-fe033fb1e8f3@github.com>
Message-ID: <NrEswKYrGB2rA-H_UiHeqzt8Q-AhP_ZqLzMLOnmOwTQ=.cae5e0a3-bcfb-40aa-86ac-5c2e68e995d1@github.com>

On Wed, 13 Aug 2025 22:40:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java line 251:
>> 
>>> 249:         Lint lint,                                      // the Lint configuration that applies at this declaration
>>> 250:         Symbol symbol,                                  // declaration symbol (for debug purposes only; null for root)
>>> 251:         List<LintRange> children                        // the nested declarations one level below this node
>> 
>> not a proposal to do any change, but I think that if instead of having a tree-like structure in which each range has, potentially, a number of children, we had one list of ranges sorted by its starting point. I think that we could find the right range doing a binary search. We could actually have both: the current tree and a flat list of lint ranges for searches. Again probably not necessary for general cases but there could be corner cases as in machine generated code for which having a faster retrieval could make the difference. But again we can do that if needed in the future
>
> I think at one point I had something like that, but it made things more complicated. Plain binary search doesn't work when you are searching in a list of (possibly nested) intervals instead of a list of points, because there can be multiple matches (arbitrarily many in fact). I think it would require an [Interval tree](https://en.wikipedia.org/wiki/Interval_tree).
> 
> There is also another annoying detail, which is that the nesting is not always proper: in some oddball cases (none of which I can specifically remember) there can be an AST node whose starting position is before the starting position of its parent AST node (or ending position after its parent). These instances could cause an Interval tree type of algorithm to glitch out.

I see, interesting that you explored those options. Yes I also saw the interval tree solution but that seemed like an overkill, at least as an starting point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24584#discussion_r2276627752

From vromero at openjdk.org  Thu Aug 14 14:50:22 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Aug 2025 14:50:22 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v9]
In-Reply-To: <BxVQJlCn6ggfIwCQBTNObtVDepfwKbgVB-mrzLl3N7w=.87eaa86e-05d1-4772-8c50-006eee9241db@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
 <BxVQJlCn6ggfIwCQBTNObtVDepfwKbgVB-mrzLl3N7w=.87eaa86e-05d1-4772-8c50-006eee9241db@github.com>
Message-ID: <4UGbe12zQMY7CNHPdrXeDGrDUz0bC50XiYmDQwajqbA=.36683b3c-b036-41e9-b50c-64a692d64f0e@github.com>

On Thu, 14 Aug 2025 03:50:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR enhances the `-Werror` flag to support lint categories just like `-Xlint` does. For example `-Werror:all,-preview` would cause an error if any warning not in the `preview` lint category occurred.
>> 
>> The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` is equivalent to `-Xlint:all`). This behavior has been factored out and Javadocumented so that both `-Xlint` and `-Werror` can have this same "parsing" logic.
>> 
>> See the CSR [JDK-8350044](https://bugs.openjdk.org/browse/JDK-8350044) for details on how the new flag behaves in certain corner cases.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Address review comments.
>  - Merge branch 'master' into JDK-8349847
>  - Merge branch 'master' into JDK-8349847 to fix cross-compiling build problem.
>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>  - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
>  - Ensure that "-Xlint:none" still works for the affected warnings.
>    
>    The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>    which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>    which allowed the affected warnings to get away with skipping that check.
>  - Minor naming and Javadoc tweaks.
>  - Merge branch 'JDK-8359596' into JDK-8349847
>  - No need for /nodynamiccopyright/ with this test.
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8cd79752...e8f5539f

I'm OK with the last version. It could be said that more tests could be added but at the same time given that we are reusing code paths already tested for `Xlint`, then we should be fine. Kind of on the fence here

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23622#pullrequestreview-3120898825

From vromero at openjdk.org  Thu Aug 14 15:15:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 14 Aug 2025 15:15:18 GMT
Subject: RFR: 8359383: Incorrect starting positions for implicitly typed
 variables [v2]
In-Reply-To: <gEppGku1f3EpnjY6Piqhh0gsgCdP_MesIZn48yG97SE=.9bf2810c-10a6-462b-9a5c-b82e82c8ab21@github.com>
References: <DalHVpmhVqCE8vn2ePdsP0P5mPsL6mflttjK0NkG7nY=.b2ee068c-e4e5-4549-b519-b53112167969@github.com>
 <gEppGku1f3EpnjY6Piqhh0gsgCdP_MesIZn48yG97SE=.9bf2810c-10a6-462b-9a5c-b82e82c8ab21@github.com>
Message-ID: <YhbQiPFbWtljCazcY7wk9GSF-oWBkpn2C8ib9Zd5Rpg=.f66ecd54-d94c-4250-877c-f8d11b37dacc@github.com>

On Mon, 11 Aug 2025 18:17:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This fixes starting position bugs relating to implicitly typed variables; see the linked issue for details.
>> 
>> This also makes it possible to recover the declaration type (explicit, implicit, or `var`) from a `JCVariableDecl` and, in the case of `var` declarations, the starting position of the `var`; previously this wasn't possible.
>> 
>> Finally, as a minor drive-by improvement, we can now pretty print `var` as `var` instead of `/*missing*/`.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add back regression test case that got removed somehow.
>  - Merge branch 'master' into JDK-8359383
>  - Fix various starting position bugs relating to implicitly typed variables.

I believe that this one will need a CSR as some tools could observe a difference. @jddarcy what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/25786#issuecomment-3188818281

From dnsimon at openjdk.org  Thu Aug 14 19:33:15 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Aug 2025 19:33:15 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
Message-ID: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>

On Wed, 13 Aug 2025 14:22:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   After suggestions from Erik and Andrey

> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

Would you mind also running tier9 to avoid surprises there.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422

From acobbs at openjdk.org  Thu Aug 14 20:58:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Aug 2025 20:58:22 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v9]
In-Reply-To: <4UGbe12zQMY7CNHPdrXeDGrDUz0bC50XiYmDQwajqbA=.36683b3c-b036-41e9-b50c-64a692d64f0e@github.com>
References: <ZQoX3Wlaw5_cHkLdXJNy-jfDO7MZ-3pJMPOck-QSin8=.c55f0e45-a29e-45ab-81f2-5184fdc28d35@github.com>
 <BxVQJlCn6ggfIwCQBTNObtVDepfwKbgVB-mrzLl3N7w=.87eaa86e-05d1-4772-8c50-006eee9241db@github.com>
 <4UGbe12zQMY7CNHPdrXeDGrDUz0bC50XiYmDQwajqbA=.36683b3c-b036-41e9-b50c-64a692d64f0e@github.com>
Message-ID: <szh-_s_HhwfjVYLuX7jfpmzRFXOATYReGcdOEg84GcI=.de1c537f-fba0-4ed4-b880-af3c6d0adeae@github.com>

On Thu, 14 Aug 2025 14:47:53 GMT, Vicente Romero <vromero 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 16 commits:
>> 
>>  - Address review comments.
>>  - Merge branch 'master' into JDK-8349847
>>  - Merge branch 'master' into JDK-8349847 to fix cross-compiling build problem.
>>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>>  - Merge branch 'master' into JDK-8349847 to fix conflicts.
>>  - Merge branch 'JDK-8359596' into JDK-8349847 to add "-Xlint:none" fix.
>>  - Ensure that "-Xlint:none" still works for the affected warnings.
>>    
>>    The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>>    which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>>    which allowed the affected warnings to get away with skipping that check.
>>  - Minor naming and Javadoc tweaks.
>>  - Merge branch 'JDK-8359596' into JDK-8349847
>>  - No need for /nodynamiccopyright/ with this test.
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8cd79752...e8f5539f
>
> I'm OK with the last version. It could be said that more tests could be added but at the same time given that we are reusing code paths already tested for `Xlint`, then we should be fine. Kind of on the fence here

@vicente-romero-oracle thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23622#issuecomment-3189847960

From liach at openjdk.org  Fri Aug 15 04:29:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Aug 2025 04:29:15 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <kmngnozEmlS3-dfo_xmzpW84PLGX-yrXavmBAGO_7Ys=.4600fb69-1c42-4132-9cce-1077fbdc7ae4@github.com>

On Thu, 14 Aug 2025 10:34:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these change which removes the outdated use of `jdk.internal.javac.ParticipatesInPreview` and the qualified export of `jdk.internal.javac` package? This addresses https://bugs.openjdk.org/browse/JDK-8365533.
> 
> These qualified exports in `java.base` were added in https://bugs.openjdk.org/browse/JDK-8308753 when ClassFile API was in preview. Starting Java 24, ClassFile API is now a part of Java SE. These affected modules don't use any other preview feature, so there's no longer a need to export the `jdk.internal.javac` package to these modules.
> 
> tier1, tier2 and tier3 testing of this change completed without any related failures.

Looks right to me. However since your changed lines is directly by the java.desktop changed line, there's a conflict and you must resolve it.

In addition, `PreviewFeature.Feature` enum has a few obsolete entries - they should be kept until the preview feature is not in the minimum boot JDK. Now the boot JDK is min 24, and a few of the features are already permanent in 24.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26776#pullrequestreview-3122788756
PR Comment: https://git.openjdk.org/jdk/pull/26776#issuecomment-3190566237

From lkorinth at openjdk.org  Fri Aug 15 11:43:33 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:43:33 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d

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

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

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

From lkorinth at openjdk.org  Fri Aug 15 11:59:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:59:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <iWlp9Azqc_MsGBnk-PK8OYZqpcnhSASRJmnz8IgzTQI=.965cedce-3e5a-40e5-9e86-9b1f5c2d2021@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Added three new `/timeout=480` after the last run.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090

From syan at openjdk.org  Fri Aug 15 14:08:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 14:08:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2279056261

From vromero at openjdk.org  Fri Aug 15 14:53:17 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Aug 2025 14:53:17 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v11]
In-Reply-To: <kL8PQBWUxtmozBzmQRc67aiM1Fp-567gROp3spOjN9U=.6a8d72f2-8def-4b9b-8977-cb54b520d871@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <kL8PQBWUxtmozBzmQRc67aiM1Fp-567gROp3spOjN9U=.6a8d72f2-8def-4b9b-8977-cb54b520d871@github.com>
Message-ID: <jO1XEv8DIp9MgeRuFoL35sg9I_brbJptbGndZxfbwp4=.510c8521-0422-490f-9062-7a2595872ced@github.com>

On Thu, 14 Aug 2025 04:00:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a cleanup/refactoring of how lint warnings are logged and `@SuppressWarnings` annotations applied.
>> 
>> A central challenge with lint warnings is that warnings can be generated during any compiler phase, but whether a particular lint warning is suppressed via `@SuppressWarnings` can't be known until after attribution. For example, the parser doesn't have enough information to interpret and apply `@SuppressWarnings("text-blocks")` to text blocks, or `@SuppressWarnings("preview")` to preview lexical features; instead, the `DeferredLintHandler` is used to workaround this limitation.
>> 
>> In addition, several other factors complicate things:
>> * Knowing the current applicable `Lint` instance requires manually tracking it with each declaration visited and applying/removing the `@SuppressWarnings` annotation there, if any
>> * Some warnings are "suppressibly mandatory" (i.e., they are _emitted if not suppressed_ instead of _emitted if enabled_)
>> * Some warnings are "unsuppressibly mandatory" (e.g., the "internal proprietary API" warning)
>> * Some mandatory warnings are _aggregated_ into notes that are emitted at the end of compilation when not enabled
>> * Some warnings are _lint_ warnings, with a corresponding lint category, while others are just "plain" warnings
>> * Some lint warnings are suppressible via `@SuppressWarnings`, while others are only suppressible via `-Xlint:-foo` flags
>> * Speculative compilation requires holding log messages in purgatory until the speculation resolves, after which they are then either discarded or emitted. But this creates a tricky interaction with `DeferredLintHandler` because even after speculation is complete, we may still not yet know whether a warning should be suppressed.
>> 
>> Previously the logic to get all of this right was non-obviously woven around the code base. In particular, you needed to know somehow whether or not to use `DeferredLintHandler`, and in what "mode".
>> 
>> The overall goal of this PR is to simplify usage so that **no matter where you are in the compiler, you can just invoke `log.warning()` to log a warning** and (mostly) forget about all of the details listed above.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused field from "LintRange" record.

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24584#pullrequestreview-3124046040

From acobbs at openjdk.org  Fri Aug 15 16:22:16 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 15 Aug 2025 16:22:16 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v11]
In-Reply-To: <jO1XEv8DIp9MgeRuFoL35sg9I_brbJptbGndZxfbwp4=.510c8521-0422-490f-9062-7a2595872ced@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
 <kL8PQBWUxtmozBzmQRc67aiM1Fp-567gROp3spOjN9U=.6a8d72f2-8def-4b9b-8977-cb54b520d871@github.com>
 <jO1XEv8DIp9MgeRuFoL35sg9I_brbJptbGndZxfbwp4=.510c8521-0422-490f-9062-7a2595872ced@github.com>
Message-ID: <oDTXZPuDC75ZjBewjnY4mZX4FklJM1Eh9JTZUrmDBWs=.b0b8fab5-ecd8-4c5c-afae-47f4f0ee90cb@github.com>

On Fri, 15 Aug 2025 14:50:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused field from "LintRange" record.
>
> Marked as reviewed by vromero (Reviewer).

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

@lahodaj @mcimadamore please re-review after 1f1247bc5c whenever convenient.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24584#issuecomment-3192072246