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

From davidalayachew at gmail.com  Mon Aug 18 02:39:51 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 17 Aug 2025 22:39:51 -0400
Subject: JShell EditPad is cutoff by default
Message-ID: <CAA9v-_PzVH80+_KRzAaTvk4A-f6qfy2odNDxZj26D9mndXrnRQ@mail.gmail.com>

Hello @compiler-dev <compiler-dev at openjdk.org>,

On my Windows 11 laptop, when I open up jshell and type /edit, the edit pad
that pops up is ALWAYS cutoff at the bottom right of my screen. Please
note, I have a 1920x1080 monitor and a computer set to that resolution.

It's annoying, and a bad user experience. Wouldn't it make more sense to do
something similar to Swing's setLocationByPlatform()? Or better yet, just
pick a sensible default?

This should be incredibly easy to recreate. I have tested this on 4
different computers, and all have the same behaviour.

Thank you for your time and attention.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250817/ff1219ee/attachment.htm>

From chen.l.liang at oracle.com  Mon Aug 18 03:46:47 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 18 Aug 2025 03:46:47 +0000
Subject: JShell EditPad is cutoff by default
In-Reply-To: <CAA9v-_PzVH80+_KRzAaTvk4A-f6qfy2odNDxZj26D9mndXrnRQ@mail.gmail.com>
References: <CAA9v-_PzVH80+_KRzAaTvk4A-f6qfy2odNDxZj26D9mndXrnRQ@mail.gmail.com>
Message-ID: <SJ2PR10MB76699F75700A08C381D5E689A231A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi David, thank you so much for your report!

Indeed, I can reproduce this issue on my windows device with a different resolution - the 3 bottom buttons are out of the screen. I have created https://bugs.openjdk.org/browse/JDK-8365643 to track this issue. (Meanwhile it doesn't happen on Ubuntu)

I think the problem lies in this line - https://github.com/openjdk/jdk/blob/bd65d483df4742bb7ce79b613f10f70a45117f84/src/jdk.editpad/share/classes/jdk/editpad/EditPad.java#L92
Since you suggested the solution, can you try replacing that call with setLocationByPlatform and see if this fixes your problem on Windows?

If this works for you, feel free to contribute a patch to OpenJDK upstream.

Kind regards, Chen Liang


________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Sunday, August 17, 2025 9:39 PM
To: compiler-dev <compiler-dev at openjdk.org>
Subject: JShell EditPad is cutoff by default

Hello @compiler-dev<mailto:compiler-dev at openjdk.org>,

On my Windows 11 laptop, when I open up jshell and type /edit, the edit pad that pops up is ALWAYS cutoff at the bottom right of my screen. Please note, I have a 1920x1080 monitor and a computer set to that resolution.

It's annoying, and a bad user experience. Wouldn't it make more sense to do something similar to Swing's setLocationByPlatform()? Or better yet, just pick a sensible default?

This should be incredibly easy to recreate. I have tested this on 4 different computers, and all have the same behaviour.

Thank you for your time and attention.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250818/ba6be107/attachment-0001.htm>

From davidalayachew at gmail.com  Mon Aug 18 04:22:56 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 18 Aug 2025 00:22:56 -0400
Subject: JShell EditPad is cutoff by default
In-Reply-To: <SJ2PR10MB76699F75700A08C381D5E689A231A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAA9v-_PzVH80+_KRzAaTvk4A-f6qfy2odNDxZj26D9mndXrnRQ@mail.gmail.com>
 <SJ2PR10MB76699F75700A08C381D5E689A231A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_PWRA8y9-e00_1ujwyJq2xqQkum-Mv9KQiDMjEFO=kfww@mail.gmail.com>

Woah, I found something even deeper.

Look at the order of the commands. First, we set location, THEN we set the
size.

Reverse the 2, and then it works!

I am 99.999999% sure that, what is happening is Swing tries to center the
window when the size defaults to (0, 0), which would be the center of the
screen. And then, when we set the size, it keeps its location, but expands
down and right, causing the problem we see.

So, I think a cleaner solution would instead be to change the order of the
2 commands. Is that ok with you? Can you test it locally?


On Sun, Aug 17, 2025 at 11:46?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi David, thank you so much for your report!
>
> Indeed, I can reproduce this issue on my windows device with a different
> resolution - the 3 bottom buttons are out of the screen. I have created
> https://bugs.openjdk.org/browse/JDK-8365643 to track this issue.
> (Meanwhile it doesn't happen on Ubuntu)
>
> I think the problem lies in this line -
> https://github.com/openjdk/jdk/blob/bd65d483df4742bb7ce79b613f10f70a45117f84/src/jdk.editpad/share/classes/jdk/editpad/EditPad.java#L92
> Since you suggested the solution, can you try replacing that call with
> setLocationByPlatform and see if this fixes your problem on Windows?
>
> If this works for you, feel free to contribute a patch to OpenJDK upstream.
>
> Kind regards, Chen Liang
>
>
> ------------------------------
> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Sunday, August 17, 2025 9:39 PM
> *To:* compiler-dev <compiler-dev at openjdk.org>
> *Subject:* JShell EditPad is cutoff by default
>
> Hello @compiler-dev <compiler-dev at openjdk.org>,
>
> On my Windows 11 laptop, when I open up jshell and type /edit, the edit
> pad that pops up is ALWAYS cutoff at the bottom right of my screen. Please
> note, I have a 1920x1080 monitor and a computer set to that resolution.
>
> It's annoying, and a bad user experience. Wouldn't it make more sense to
> do something similar to Swing's setLocationByPlatform()? Or better yet,
> just pick a sensible default?
>
> This should be incredibly easy to recreate. I have tested this on 4
> different computers, and all have the same behaviour.
>
> Thank you for your time and attention.
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250818/e49cf3c0/attachment.htm>

From davidalayachew at gmail.com  Mon Aug 18 04:48:47 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 18 Aug 2025 00:48:47 -0400
Subject: JShell EditPad is cutoff by default
In-Reply-To: <CAA9v-_PWRA8y9-e00_1ujwyJq2xqQkum-Mv9KQiDMjEFO=kfww@mail.gmail.com>
References: <CAA9v-_PzVH80+_KRzAaTvk4A-f6qfy2odNDxZj26D9mndXrnRQ@mail.gmail.com>
 <SJ2PR10MB76699F75700A08C381D5E689A231A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_PWRA8y9-e00_1ujwyJq2xqQkum-Mv9KQiDMjEFO=kfww@mail.gmail.com>
Message-ID: <CAA9v-_O9iGtqip=tFfZFuoPDn0y8WjAemSwnkmAWwO2RxC+6Xg@mail.gmail.com>

And look at the documentation --
https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Window.html#setLocationRelativeTo(java.awt.Component)

It says this.

> If the component is null, or the GraphicsConfiguration
> associated with this component is null, the window is
> placed in the center of the screen. The center point
> can be obtained with the
> GraphicsEnvironment.getCenterPoint
<https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/GraphicsEnvironment.html#getCenterPoint()>
method.

This confirms what I am saying -- that it normally sets it in the center of
the screen.

As for which solution is better, the developer in question probably did
intend for it to be centered, considering the function and parameter used.
So probably better to stick with their original intent for now, until given
reason not to.

Here is my pull request -- https://github.com/openjdk/jdk/pull/26814


On Mon, Aug 18, 2025 at 12:22?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Woah, I found something even deeper.
>
> Look at the order of the commands. First, we set location, THEN we set the
> size.
>
> Reverse the 2, and then it works!
>
> I am 99.999999% sure that, what is happening is Swing tries to center the
> window when the size defaults to (0, 0), which would be the center of the
> screen. And then, when we set the size, it keeps its location, but expands
> down and right, causing the problem we see.
>
> So, I think a cleaner solution would instead be to change the order of the
> 2 commands. Is that ok with you? Can you test it locally?
>
>
> On Sun, Aug 17, 2025 at 11:46?PM Chen Liang <chen.l.liang at oracle.com>
> wrote:
>
>> Hi David, thank you so much for your report!
>>
>> Indeed, I can reproduce this issue on my windows device with a different
>> resolution - the 3 bottom buttons are out of the screen. I have created
>> https://bugs.openjdk.org/browse/JDK-8365643 to track this issue.
>> (Meanwhile it doesn't happen on Ubuntu)
>>
>> I think the problem lies in this line -
>> https://github.com/openjdk/jdk/blob/bd65d483df4742bb7ce79b613f10f70a45117f84/src/jdk.editpad/share/classes/jdk/editpad/EditPad.java#L92
>> Since you suggested the solution, can you try replacing that call with
>> setLocationByPlatform and see if this fixes your problem on Windows?
>>
>> If this works for you, feel free to contribute a patch to OpenJDK
>> upstream.
>>
>> Kind regards, Chen Liang
>>
>>
>> ------------------------------
>> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David
>> Alayachew <davidalayachew at gmail.com>
>> *Sent:* Sunday, August 17, 2025 9:39 PM
>> *To:* compiler-dev <compiler-dev at openjdk.org>
>> *Subject:* JShell EditPad is cutoff by default
>>
>> Hello @compiler-dev <compiler-dev at openjdk.org>,
>>
>> On my Windows 11 laptop, when I open up jshell and type /edit, the edit
>> pad that pops up is ALWAYS cutoff at the bottom right of my screen. Please
>> note, I have a 1920x1080 monitor and a computer set to that resolution.
>>
>> It's annoying, and a bad user experience. Wouldn't it make more sense to
>> do something similar to Swing's setLocationByPlatform()? Or better yet,
>> just pick a sensible default?
>>
>> This should be incredibly easy to recreate. I have tested this on 4
>> different computers, and all have the same behaviour.
>>
>> Thank you for your time and attention.
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250818/80ab8f8e/attachment-0001.htm>

From jpai at openjdk.org  Mon Aug 18 04:49:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 04:49:28 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
Message-ID: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@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.

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

 - merge latest from master branch
 - 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=01
  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  Mon Aug 18 04:58:43 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 04:58:43 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
Message-ID: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>

When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

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

Commit messages:
 - Fixing incorrect centering of EditPad window.

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

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

From alanb at openjdk.org  Mon Aug 18 06:04:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Aug 2025 06:04:14 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
Message-ID: <H_tMMP8u5UzbkC9lwzvo4NTkFdDGg0x_baZZ07tg5Ig=.12c19630-073e-46aa-bf94-cb26b566f87a@github.com>

On Mon, 18 Aug 2025 04:49:28 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.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge latest from master branch
>  - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26776#pullrequestreview-3126883742

From jpai at openjdk.org  Mon Aug 18 06:48:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 06:48:19 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
Message-ID: <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>

On Mon, 18 Aug 2025 04:49:28 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.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - merge latest from master branch
>  - 8365533: Remove outdated jdk.internal.javac package export to several modules from java.base

Thank you Alan and Chen for the reviews.

tier1, tier2 and tier3 testing with this change completed without any related issues.

> In addition, `PreviewFeature.Feature` enum has a few obsolete entries ... Now the boot JDK is min 24, and a few of the features are already permanent in 24.

I'll file a separate issue to clean those up.

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

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

From sormuras at gmail.com  Mon Aug 18 07:50:28 2025
From: sormuras at gmail.com (Christian Stein)
Date: Mon, 18 Aug 2025 09:50:28 +0200
Subject: JShell EditPad is cutoff by default
In-Reply-To: <CAA9v-_PWRA8y9-e00_1ujwyJq2xqQkum-Mv9KQiDMjEFO=kfww@mail.gmail.com>
References: <CAA9v-_PzVH80+_KRzAaTvk4A-f6qfy2odNDxZj26D9mndXrnRQ@mail.gmail.com>
 <SJ2PR10MB76699F75700A08C381D5E689A231A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_PWRA8y9-e00_1ujwyJq2xqQkum-Mv9KQiDMjEFO=kfww@mail.gmail.com>
Message-ID: <CAJi8+g79JhskMRwasLNK4w=FfHf5T=DDA3JysRyrxz0gby4VBg@mail.gmail.com>

I approved PR https://github.com/openjdk/jdk/pull/26814 because I can
confirm that the current order of commands results in a centered upper-left
corner of the edit window. (Only Windows?)

Moving the `jframe.setLocationRelativeTo(null);` after the
`jframe.setSize(800, 600);` (and still before `jframe.setVisible(true);`)
solves the problem.

On Mon, Aug 18, 2025 at 6:23?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Woah, I found something even deeper.
>
> Look at the order of the commands. First, we set location, THEN we set the
> size.
>
> Reverse the 2, and then it works!
>
> I am 99.999999% sure that, what is happening is Swing tries to center the
> window when the size defaults to (0, 0), which would be the center of the
> screen. And then, when we set the size, it keeps its location, but expands
> down and right, causing the problem we see.
>
> So, I think a cleaner solution would instead be to change the order of the
> 2 commands. Is that ok with you? Can you test it locally?
>
>
> On Sun, Aug 17, 2025 at 11:46?PM Chen Liang <chen.l.liang at oracle.com>
> wrote:
>
>> Hi David, thank you so much for your report!
>>
>> Indeed, I can reproduce this issue on my windows device with a different
>> resolution - the 3 bottom buttons are out of the screen. I have created
>> https://bugs.openjdk.org/browse/JDK-8365643 to track this issue.
>> (Meanwhile it doesn't happen on Ubuntu)
>>
>> I think the problem lies in this line -
>> https://github.com/openjdk/jdk/blob/bd65d483df4742bb7ce79b613f10f70a45117f84/src/jdk.editpad/share/classes/jdk/editpad/EditPad.java#L92
>> Since you suggested the solution, can you try replacing that call with
>> setLocationByPlatform and see if this fixes your problem on Windows?
>>
>> If this works for you, feel free to contribute a patch to OpenJDK
>> upstream.
>>
>> Kind regards, Chen Liang
>>
>>
>> ------------------------------
>> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David
>> Alayachew <davidalayachew at gmail.com>
>> *Sent:* Sunday, August 17, 2025 9:39 PM
>> *To:* compiler-dev <compiler-dev at openjdk.org>
>> *Subject:* JShell EditPad is cutoff by default
>>
>> Hello @compiler-dev <compiler-dev at openjdk.org>,
>>
>> On my Windows 11 laptop, when I open up jshell and type /edit, the edit
>> pad that pops up is ALWAYS cutoff at the bottom right of my screen. Please
>> note, I have a 1920x1080 monitor and a computer set to that resolution.
>>
>> It's annoying, and a bad user experience. Wouldn't it make more sense to
>> do something similar to Swing's setLocationByPlatform()? Or better yet,
>> just pick a sensible default?
>>
>> This should be incredibly easy to recreate. I have tested this on 4
>> different computers, and all have the same behaviour.
>>
>> Thank you for your time and attention.
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250818/e0f96182/attachment.htm>

From cstein at openjdk.org  Mon Aug 18 07:51:11 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 18 Aug 2025 07:51:11 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <c5q07JWbDrdWpVAMtjzIX07aZzP5brhSEf46R0_EBaU=.266c5ebc-1cfe-4309-9e89-f97ee83c5ea6@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

I can confirm that the current order of commands results in a screen-centered upper-left corner of the edit window:


  |
--+--
  |[#]


Moving the `jframe.setLocationRelativeTo(null);` after the `jframe.setSize(800, 600);` (and still before `jframe.setVisible(true);`) solves the problem.



  |
-[+]-
  |

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3127191363

From jlahoda at openjdk.org  Mon Aug 18 08:08:13 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Aug 2025 08:08:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <w5mM7o4To5iNA8C5fHaGNho8NiqL6zIzCgItC2fDchk=.271b34b1-cd37-4732-b8a7-dfef7b3c9c06@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3127243559

From lkorinth at openjdk.org  Mon Aug 18 09:10:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:10:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
Message-ID: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>

On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan <syan at openjdk.org> wrote:

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

It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:18:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:18:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
Message-ID: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>

On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> 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()
>
> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

It is also something that can be changed later, in a follow up fix.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
 <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com>

On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

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

I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list).

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

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

From jlahoda at openjdk.org  Mon Aug 18 09:36:29 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Aug 2025 09:36:29 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package
Message-ID: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>

In JDK 8, the package `jdk.net` was exported and part of `rt.jar`, and hence should have been part of the historical data for `--release`, but it is not. The primary goal of this PR is to add historical data for `jdk.net` for JDK 8.

The changes herein are based on JDK 8u462. I used the Probe running on JDK 8 to dump the classfiles, along these lines:

$ java -classpath .../make/langtools/src/classes/ build.tools.symbolgenerator.Probe /tmp/jdk8-classfiles


and then the up-to-date `CreateSymbols` to generate the `sym.txt` files, along these lines:

java --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED  CreateSymbols.java build-description-incremental-file .../src/jdk.compiler/share/data/symbols/symbols .../src/jdk.compiler/share/data/symbols/include.list 8 /tmp/jdk8-classfiles '<none>' --normalize-method-flags


There are a few APIs that have been added for this release, and a few representational changes.

Most notably - the ordering of "removal" entries (i.e. those that start with `-`) and "add" entries is much more strict in the current `CreateSymbols`, and so there are some changes where the removal entries are moved to the front. I went through those, and they seem OK to me.

I'll add specific comments to the other updates to the files.

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

Commit messages:
 - Merge branch 'master' into JDK-8365060
 - Fixing test.
 - 8365060: Historical data for JDK 8 should include the jdk.net package

Changes: https://git.openjdk.org/jdk/pull/26817/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26817&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365060
  Stats: 289 lines in 13 files changed: 205 ins; 67 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26817.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26817/head:pull/26817

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

From jlahoda at openjdk.org  Mon Aug 18 09:36:32 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Aug 2025 09:36:32 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package
In-Reply-To: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
References: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
Message-ID: <YBkfIApmgFjX8zvIWE0p_TLDf_1VI8VeieB8gxaioMg=.21394432-adbf-4c86-a559-2127ea9d2076@github.com>

On Mon, 18 Aug 2025 08:18:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> In JDK 8, the package `jdk.net` was exported and part of `rt.jar`, and hence should have been part of the historical data for `--release`, but it is not. The primary goal of this PR is to add historical data for `jdk.net` for JDK 8.
> 
> The changes herein are based on JDK 8u462. I used the Probe running on JDK 8 to dump the classfiles, along these lines:
> 
> $ java -classpath .../make/langtools/src/classes/ build.tools.symbolgenerator.Probe /tmp/jdk8-classfiles
> 
> 
> and then the up-to-date `CreateSymbols` to generate the `sym.txt` files, along these lines:
> 
> java --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED  CreateSymbols.java build-description-incremental-file .../src/jdk.compiler/share/data/symbols/symbols .../src/jdk.compiler/share/data/symbols/include.list 8 /tmp/jdk8-classfiles '<none>' --normalize-method-flags
> 
> 
> There are a few APIs that have been added for this release, and a few representational changes.
> 
> Most notably - the ordering of "removal" entries (i.e. those that start with `-`) and "add" entries is much more strict in the current `CreateSymbols`, and so there are some changes where the removal entries are moved to the front. I went through those, and they seem OK to me.
> 
> I'll add specific comments to the other updates to the files.

src/jdk.compiler/share/data/symbols/include.list line 270:

> 268: +com/sun/nio/sctp/
> 269: +jdk/
> 270: +jdk/net/

This is one of the main changes - whitelisting `jdk.net` for JDK 8.

src/jdk.compiler/share/data/symbols/java.base-8.sym.txt line 1714:

> 1712: field name MIAO descriptor Ljava/lang/Character$UnicodeBlock; flags 19
> 1713: field name ARABIC_MATHEMATICAL_ALPHABETIC_SYMBOLS descriptor Ljava/lang/Character$UnicodeBlock; flags 19
> 1714: field name CJK_UNIFIED_IDEOGRAPHS_EXTENSION_E descriptor Ljava/lang/Character$UnicodeBlock; flags 19

This field has been added as part of Java SE 8, MR 5.

src/jdk.compiler/share/data/symbols/java.base-8.sym.txt line 2082:

> 2080: field name NaN descriptor F constantValue NaN flags 19
> 2081: field name MAX_VALUE descriptor F constantValue 3.4028235E38 flags 19
> 2082: field name MIN_NORMAL descriptor F constantValue 1.1754944E-38 flags 19

I believe this is only a representational difference, without any real change to the value. Using:

public class Rep {
    public static void main(String... args) {
        System.out.println(Float.floatToIntBits(Float.parseFloat("1.17549435E-38")));
        System.out.println(Float.floatToIntBits(Float.parseFloat("1.1754944E-38")));
        if (Float.floatToIntBits(Float.parseFloat("1.17549435E-38")) ==
            Float.floatToIntBits(Float.parseFloat("1.1754944E-38"))) {
            System.out.println("The same.");
        } else {
            System.out.println("Not the same.");
        }
    }
}


I get the same on both JDK 8 and JDK 25:

8388608
8388608
The same.


Probably related to [JDK-4511638](https://bugs.openjdk.org/browse/JDK-4511638).

src/jdk.compiler/share/data/symbols/java.base-8.sym.txt line 3578:

> 3576: method name isEnqueued descriptor ()Z flags 1
> 3577: method name enqueue descriptor ()Z flags 1
> 3578: method name clone descriptor ()Ljava/lang/Object; thrownTypes java/lang/CloneNotSupportedException flags 4

This method has been added as part of Java SE 8, MR 4 (although I don't think it should have a real effect on compilation, as it is an override of the `j.l.Object` method).

src/jdk.compiler/share/data/symbols/java.base-9.sym.txt line 232:

> 230: field name SUTTON_SIGNWRITING descriptor Ljava/lang/Character$UnicodeBlock; flags 19
> 231: field name SUPPLEMENTAL_SYMBOLS_AND_PICTOGRAPHS descriptor Ljava/lang/Character$UnicodeBlock; flags 19
> 232: field name CJK_UNIFIED_IDEOGRAPHS_EXTENSION_E descriptor Ljava/lang/Character$UnicodeBlock; flags 19

The field is now part of JDK 8's data, but was not part of JDK 9, so it is removed.

src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt line 15617:

> 15615: method name getFormat descriptor ()Ljava/text/DecimalFormat; flags 1
> 15616: method name getModel descriptor ()Ljavax/swing/SpinnerNumberModel; flags 1
> 15617: method name setComponentOrientation descriptor (Ljava/awt/ComponentOrientation;)V flags 1

I believe this is only a new override of an existing method in the parent class.

src/jdk.compiler/share/data/symbols/jdk.management-8.sym.txt line 94:

> 92: method name isThreadAllocatedMemoryEnabled descriptor ()Z flags 401
> 93: method name setThreadAllocatedMemoryEnabled descriptor (Z)V flags 401
> 94: method name getCurrentThreadAllocatedBytes descriptor ()J flags 1

There's a handful of methods added in u282 (`getThreadInfo`, `dumpAllThreads` and `getCurrentThreadAllocatedBytes`) and in u412 (`getTotalThreadAllocatedBytes`). Given the other updates, it seems OK to keep those here.

src/jdk.compiler/share/data/symbols/jdk.management-9.sym.txt line 51:

> 49: class name com/sun/management/ThreadMXBean
> 50: header extends java/lang/Object implements java/lang/management/ThreadMXBean flags 601
> 51: -method name getCurrentThreadAllocatedBytes descriptor ()J

The methods were not part of JDK 9, so are removed here.

src/jdk.compiler/share/data/symbols/jdk.net-8.sym.txt line 1:

> 1: #

This is the main change here - adding `jdk.net` package for JDK 8 data.

src/jdk.compiler/share/data/symbols/jdk.net-8.sym.txt line 32:

> 30: header extends java/lang/Object flags 31 classAnnotations @Ljdk/Profile+Annotation;(value=I1) runtimeAnnotations @Ljdk/Exported;
> 31: field name SO_FLOW_SLA descriptor Ljava/net/SocketOption; flags 19 signature Ljava/net/SocketOption<Ljdk/net/SocketFlow;>;
> 32: field name TCP_KEEPIDLE descriptor Ljava/net/SocketOption; flags 19 signature Ljava/net/SocketOption<Ljava/lang/Integer;>;

The `TCP_*` have been added in u272.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281642046
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281643586
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281666588
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281646775
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281667864
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281670866
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281834580
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281835318
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281839054
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2281838225

From lkorinth at openjdk.org  Mon Aug 18 09:43:14 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:43:14 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: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@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

If there are no mayor objections, I will update the copyrights before I leave work today.

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

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

From duke at openjdk.org  Mon Aug 18 09:44:14 2025
From: duke at openjdk.org (duke)
Date: Mon, 18 Aug 2025 09:44:14 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <oosFgDdNrvyluyuCujPwwlEwNppGu7Mv9vg0KxrLNag=.2c278374-87fe-4bbe-9db6-1ab7b5d1eb7b@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3195929616

From dfuchs at openjdk.org  Mon Aug 18 11:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 11:38:14 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: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@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

Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:


	java/net/httpclient/CancelledResponse.java
	java/net/httpclient/whitebox/FlowTestDriver.java


The	first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

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

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

From liach at openjdk.org  Mon Aug 18 13:09:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 13:09:12 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Marked as reviewed by liach (Reviewer).

Do we need a update to `EditPadTest` to ensure all parts of that JFrame is rendered on the screen?

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

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3128297469
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3196742832

From rriggs at openjdk.org  Mon Aug 18 13:15:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 13:15:11 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: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@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

Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings.  The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

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

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

From jpai at openjdk.org  Mon Aug 18 13:43:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 13:43:23 GMT
Subject: Integrated: 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: <rGcu60RTmmtT0IhftuIgwKa33UyYiopBA9D4Oal7op0=.b4692860-d62b-426b-a248-63030d11fa6f@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.

This pull request has now been integrated.

Changeset: 81c6ed38
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81c6ed38828940d51c872c354c29dc13ed62a5ac
Stats:     27 lines in 7 files changed: 0 ins; 22 del; 5 mod

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

Reviewed-by: alanb, liach

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

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

From liach at openjdk.org  Mon Aug 18 13:45:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 13:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <opdfOPyKKszYq-pDpA0Wpc2Jr0SUJ3INrYZO9u-JrOQ=.c5bc2321-d9d9-44d3-8958-c4d60bd10483@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Hi @davidalayachew, can you update the copyright year at top from `2015, 2016,` to `2015, 2025,`?

In addition, according to https://openjdk.org/guide, we usually leave 24 hours for sufficient review. This applies so you should type `/integrate` later in the future.

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

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3128437299

From cstein at openjdk.org  Mon Aug 18 13:54:10 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 18 Aug 2025 13:54:10 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>
Message-ID: <dx4tj2Ea92bkxySR9HGda6Gug112NfCzkfdOB3J4AdM=.084fb73d-1394-4fbd-b9b8-74b3c4ff3683@github.com>

On Mon, 18 Aug 2025 13:04:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> Do we need a update to EditPadTest to ensure all parts of that JFrame is rendered on the screen?

I think such a test, if deemed necessary, should be added to the "core" Swing tests instead. Here, it would be an implementation detail that only applies to screens equal or larger than 800x600 in dimension ... on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3197031599

From jpai at openjdk.org  Mon Aug 18 14:23:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Aug 2025 14:23:16 GMT
Subject: RFR: 8365533: Remove outdated jdk.internal.javac package export to
 several modules from java.base [v2]
In-Reply-To: <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>
References: <btnD0YSUlGsXgghpFzJJ0KsYZiWs-oJdo2SkOLPHG7c=.617bd59e-d2d5-4ef7-ba82-847b3f8d4e43@github.com>
 <lGkUeDaSiAA6MmWLVn8iHxAk8W1LZ0IPSvnRoClIt2w=.caa81507-da03-4329-bc40-ddbd92fbf83a@github.com>
 <s6oGXOyF-XsFhvS6dqVXvNZ0OScyeuTwolxjCYzYvr0=.89d24294-775a-4d26-ac51-c09c5d29b955@github.com>
Message-ID: <GyH3rTfRAPhV2t0UQNd3v5tucgnj1GlhkNTLz30emJ4=.075a85a3-06ad-40ef-8cfc-94be7c608801@github.com>

On Mon, 18 Aug 2025 06:45:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > In addition, `PreviewFeature.Feature` enum has a few obsolete entries ... Now the boot JDK is min 24, and a few of the features are already permanent in 24.
> 
> I'll file a separate issue to clean those up.

I've now filed https://bugs.openjdk.org/browse/JDK-8365699 to track this.

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

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

From lkorinth at openjdk.org  Mon Aug 18 14:34:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 14:34:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
Message-ID: <lSUzoh2lhdmeEPYY2eAAGIycS8QSm5_9BLFy7FgOfFw=.f7a8acc4-ead5-4625-9d3c-83a345212193@github.com>

On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change!

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

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

From aivanov at openjdk.org  Mon Aug 18 14:38:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 14:38:11 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <y43eYR60e2f3eeiBKwwWRv8CjHqRnSw2p5nzOrinjm0=.bd36d275-26a9-465c-87e6-ae0dff7a48d3@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Looks good to me.

I agree the copyright year should be updated in `EditPad.java`.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3128658090

From aivanov at openjdk.org  Mon Aug 18 14:41:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 14:41:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <dx4tj2Ea92bkxySR9HGda6Gug112NfCzkfdOB3J4AdM=.084fb73d-1394-4fbd-b9b8-74b3c4ff3683@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>
 <dx4tj2Ea92bkxySR9HGda6Gug112NfCzkfdOB3J4AdM=.084fb73d-1394-4fbd-b9b8-74b3c4ff3683@github.com>
Message-ID: <IYZMQiwcRkqvzI4vt_ZjzbI5mtp4jW4C7LraXMdJMtw=.6703656a-aa84-49bd-9489-04f65250b6b6@github.com>

On Mon, 18 Aug 2025 13:51:07 GMT, Christian Stein <cstein at openjdk.org> wrote:

> > Do we need a update to EditPadTest to ensure all parts of that JFrame is rendered on the screen?
> 
> I think such a test, if deemed necessary, should be added to the "core" Swing tests instead. Here, it would be an implementation detail that only applies to screens equal or larger than 800x600 in dimension ... on Windows.

If the screen resolution is 800?600, the frame with the same size can't fit because the screen usually has other elements, such a taskbar, covering portion of the screen.

If it's assumed that no screen is less than 800?600, then the fix is fine; yet if a screen resolution happens to be less than that, the edit pad frame won't fit on the screen.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3197210945

From lmesnik at openjdk.org  Mon Aug 18 15:01:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 18 Aug 2025 15:01: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: <O_WRSR2Q7KM1CWMYPxfXyFQI3lU9AjTOklWNVYAxvUk=.387e933f-0eed-43d8-a2eb-dbe2dd98cc75@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

Thank you for fixing this! I think the changes are good.

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

Marked as reviewed by lmesnik (Reviewer).

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

From liach at openjdk.org  Mon Aug 18 15:53:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 15:53:11 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package
In-Reply-To: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
References: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
Message-ID: <3hyHQIS4KBcCFkSzqfd_8uYbTLL4Hh6dsXO5KLA8iJ4=.358c70fc-031e-483c-9bd4-56f79e1c8641@github.com>

On Mon, 18 Aug 2025 08:18:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> In JDK 8, the package `jdk.net` was exported and part of `rt.jar`, and hence should have been part of the historical data for `--release`, but it is not. The primary goal of this PR is to add historical data for `jdk.net` for JDK 8.
> 
> The changes herein are based on JDK 8u462. I used the Probe running on JDK 8 to dump the classfiles, along these lines:
> 
> $ java -classpath .../make/langtools/src/classes/ build.tools.symbolgenerator.Probe /tmp/jdk8-classfiles
> 
> 
> and then the up-to-date `CreateSymbols` to generate the `sym.txt` files, along these lines:
> 
> java --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED  CreateSymbols.java build-description-incremental-file .../src/jdk.compiler/share/data/symbols/symbols .../src/jdk.compiler/share/data/symbols/include.list 8 /tmp/jdk8-classfiles '<none>' --normalize-method-flags
> 
> 
> There are a few APIs that have been added for this release, and a few representational changes.
> 
> Most notably - the ordering of "removal" entries (i.e. those that start with `-`) and "add" entries is much more strict in the current `CreateSymbols`, and so there are some changes where the removal entries are moved to the front. I went through those, and they seem OK to me.
> 
> I'll add specific comments to the other updates to the files.

Marked as reviewed by liach (Reviewer).

test/langtools/tools/javac/sym/ElementStructureTest.java line 286:

> 284:                 JavaFileObject file = new ByteArrayJavaFileObject(data.toByteArray());
> 285:                 try (InputStream in = new ByteArrayInputStream(data.toByteArray())) {
> 286:                     String name = ClassFile.of().parse(in.readAllBytes()).thisClass().name().stringValue().replace("/", ".");

Good fix for `lastIndexOf('.')` below ?

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

PR Review: https://git.openjdk.org/jdk/pull/26817#pullrequestreview-3128945581
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2282796156

From lkorinth at openjdk.org  Mon Aug 18 16:34:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:21 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@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 suggestion from Daniel

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

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

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

  Stats: 3 lines in 2 files 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  Mon Aug 18 16:34:22 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:22 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
Message-ID: <KNNxBq11P7lT_D16Mzwx-_VHkNITiw5wQbuYCf58yQI=.cdcf7871-b20c-4e44-b10e-c6108e647afb@github.com>

On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:
> 
> ```
> 	java/net/httpclient/CancelledResponse.java
> 	java/net/httpclient/whitebox/FlowTestDriver.java
> ```
> 
> The first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

Fixed! Thanks for helping!

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

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

From dfuchs at openjdk.org  Mon Aug 18 16:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 16:46:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <a3CwlSQwHYj_F3fC30zoiDhXf9G-cn5xK8ZwVFmxBd0=.afdaf352-e494-4bc6-adf2-dc5afa0dd4b9@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

Thanks! Changes to JNDI / net / httpclient LGTM.

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

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

From duke at openjdk.org  Mon Aug 18 19:17:38 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:17:38 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

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

 - Merge branch 'openjdk:master' into patch-1
 - Fixing incorrect centering of EditPad window.
   
   When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26814/files
  - new: https://git.openjdk.org/jdk/pull/26814/files/b82d1300..409f392d

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

  Stats: 464 lines in 32 files changed: 252 ins; 84 del; 128 mod
  Patch: https://git.openjdk.org/jdk/pull/26814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26814/head:pull/26814

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

From duke at openjdk.org  Mon Aug 18 19:17:39 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:17:39 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <opdfOPyKKszYq-pDpA0Wpc2Jr0SUJ3INrYZO9u-JrOQ=.c5bc2321-d9d9-44d3-8958-c4d60bd10483@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <opdfOPyKKszYq-pDpA0Wpc2Jr0SUJ3INrYZO9u-JrOQ=.c5bc2321-d9d9-44d3-8958-c4d60bd10483@github.com>
Message-ID: <6q24O2zyCeuIOqj-LQ53gMWY4hUZ7BVDG7KBdpOc9CA=.148f470b-6c3e-40c1-95dd-364859efacfb@github.com>

On Mon, 18 Aug 2025 13:42:45 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi @davidalayachew, can you update the copyright year at top from `2015, 2016,` to `2015, 2025,`?
> 
> In addition, according to https://openjdk.org/guide, we usually leave 24 hours for sufficient review. This applies so you should type `/integrate` later in the future.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198087322

From duke at openjdk.org  Mon Aug 18 19:17:40 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:17:40 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

And yes, in future pull requests, I will try and remember to wait before trying to do an integrate command.

Is there any outstanding tasks? Or are we just waiting the 24 hours before merging?

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198092377

From liach at openjdk.org  Mon Aug 18 19:33:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 19:33:46 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
Message-ID: <c4J3vodR7fUa-eK2BcUKcw6wYsQdrY3g6kk2G8nhtU8=.184d0204-99a4-4c6e-abfa-41529d4aa11a@github.com>

On Mon, 18 Aug 2025 19:12:30 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> And yes, in future pull requests, I will try and remember to wait before trying to do an integrate command.
> 
> Is there any outstanding tasks? Or are we just waiting the 24 hours before merging?

@davidalayachew I don't see the copyright year update committed. Did you accidentally forget to push?

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198130706

From duke at openjdk.org  Mon Aug 18 19:33:48 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:33:48 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
Message-ID: <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>

On Mon, 18 Aug 2025 19:17:38 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-1
>  - Fixing incorrect centering of EditPad window.
>    
>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Man, I messed up the commit. It asked me if I wanted to grab upstream changes, now there's all this gunk. Let me try recreating the pull request.

I clicked the button to grab upstream changes, now the file changelist is all garbled. Let me reattempt this pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198138249
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198142558

From aivanov at openjdk.org  Mon Aug 18 19:33:48 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:33:48 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
Message-ID: <h5pg3Lld19ZHY7a2uYNU_EMvNYGlP5U7UfRfCUYD-Og=.df2edf97-2ebb-4956-a3e0-f65f0e28c158@github.com>

On Mon, 18 Aug 2025 19:29:11 GMT, David Alayachew <duke at openjdk.org> wrote:

> Man, I messed up the commit. It asked me if I wanted to grab upstream changes, now there's all this gunk. Let me try recreating the pull request.

@davidalayachew Why do you need to re-create the PR?

Just pull the changes from your personal fork if you used GitHub interface to sync your remote branch with upstream.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198143898

From duke at openjdk.org  Mon Aug 18 19:33:49 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:33:49 GMT
Subject: Withdrawn: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <F0hKVRBeWcQ9U39Sm4qcnbcD1VGY4zP8OK_2lxIc2RQ=.40b5070b-2bb2-45ef-b90e-d03b4dd40355@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

This pull request has been closed without being integrated.

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

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

From aivanov at openjdk.org  Mon Aug 18 19:45:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:45:12 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <avvU2FskaBqejYIPZjvL0SNs1nk-hePJZtr95LoBuTk=.ff972fe5-2bd8-4d8e-a3d6-216efc5ffe75@github.com>

On Mon, 18 Aug 2025 19:40:06 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3129643076

From aivanov at openjdk.org  Mon Aug 18 19:45:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
Message-ID: <aMQTn3DxefrGynlpTfvU0hx2_TS59lYAgbRfQTmkxAQ=.ccc7df26-888c-40fd-a742-0a763800bb37@github.com>

On Mon, 18 Aug 2025 19:30:42 GMT, David Alayachew <duke at openjdk.org> wrote:

>> David Alayachew has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-1
>>  - Fixing incorrect centering of EditPad window.
>>    
>>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> I clicked the button to grab upstream changes, now the file changelist is all garbled. Let me reattempt this pull request.

@davidalayachew If you already created a commit in your local branch, you can reset your branch to its previous state before that commit with


git reset HEAD~1


Then pull the updates from `origin`:


git pull origin patch-1


Both commands above imply that your current branch is `patch-1`.

Then update the copyright year again, commit the change, and push the update to your fork.

> Ok, does that look better?

> Hi @davidalayachew, you can continue with the PR with all "redundant" commits. Our bot just looks at the diff at https://github.com/openjdk/jdk/pull/26814.diff and automatically squashes it.

@liach I believe the problem is that the remote and local branches diverged. Pushing from local isn't allowed because of that; pulling from remote directly would create a merge commit, which isn't that bad.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198152910
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198163607

From duke at openjdk.org  Mon Aug 18 19:45:13 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
Message-ID: <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>

On Mon, 18 Aug 2025 19:17:38 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-1
>  - Fixing incorrect centering of EditPad window.
>    
>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Ok, let me try. I am not too familiar with this.

Ok, does that look better?

Thanks for approving. I see that the sponsor tag is gone. I will wait until the 24 hours to do the integrate command. Thanks for the help.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198154086
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198157915
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198172582

From liach at openjdk.org  Mon Aug 18 19:45:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 19:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
Message-ID: <2-IHhc2eWon7YxYm-H7R6CVW_WChfP1luUN3GsBjLi0=.638e4f16-7451-4771-bdf4-182586666fe2@github.com>

On Mon, 18 Aug 2025 19:34:14 GMT, David Alayachew <duke at openjdk.org> wrote:

>> David Alayachew has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-1
>>  - Fixing incorrect centering of EditPad window.
>>    
>>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> Ok, let me try. I am not too familiar with this.

Hi @davidalayachew, you can continue with the PR with all "redundant" commits. Our bot just looks at the diff at https://github.com/openjdk/jdk/pull/26814.diff and automatically squashes it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198154273

From duke at openjdk.org  Mon Aug 18 19:45:12 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:45:12 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

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

  Forgot to update the copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26814/files
  - new: https://git.openjdk.org/jdk/pull/26814/files/409f392d..1a7f9952

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

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

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

From aivanov at openjdk.org  Mon Aug 18 19:49:37 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:49:37 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
Message-ID: <ByjjNlKEGGXttatV3PCG2Ogeh8JlugoTCLtuvbvGtMw=.54de6d4e-5eac-43f6-83e0-d12e6e9b6d0d@github.com>

On Mon, 18 Aug 2025 19:35:12 GMT, David Alayachew <duke at openjdk.org> wrote:

> Ok, does that look better?

Yes, it looks good to me now, and you learnt some Git magic. (Thanks for not force-pushing.)
 
> Thanks for approving. I see that the sponsor tag is gone. I will wait until the 24 hours to do the integrate command. Thanks for the help.

Yes, it's gone because you added another commit which requires re-approval.

You should still wait for other reviewers from core libs, although copyright update is trivial. @liach has been actively participating, so I expect he'll re-approve the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198194409

From liach at openjdk.org  Mon Aug 18 20:04:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:04:46 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <oy8h1oWxEc5y7WnWnau5XXdMaFw3avn0A8gwVQumJCY=.86116c2a-8fab-476d-bb50-496f6708dad8@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Thanks for this copyright year update.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3129715539

From liach at openjdk.org  Mon Aug 18 20:04:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:04:47 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
Message-ID: <KUtsmAmMKKCNq88St8mmo-bMd1VKCgs6dwKI8pDJvkI=.91d8a983-6b25-447b-b370-890a4b541796@github.com>

On Mon, 18 Aug 2025 19:12:30 GMT, David Alayachew <duke at openjdk.org> wrote:

> Is there any outstanding tasks? Or are we just waiting the 24 hours before merging?

The 24-hour rule is usually to ensure all involved areas can have a reviewer to take a look at the changes, given people live in different time zones. For this contribution we already have people from langtools (compiler-dev) and client, so this is sufficiently reviewed. Thanks for the report and contribution again!

> I see that the sponsor tag is gone. 

It will be restored when you type `/integrate` command again.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198241760

From duke at openjdk.org  Mon Aug 18 20:04:47 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:04:47 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <FJcWSbWPho167r5jnYq-oo8U4_fZl0cnk6sYOBo26ko=.c6a22a6e-193a-44ad-b4f0-8c7fff6057bd@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Then here I go.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198243439

From duke at openjdk.org  Mon Aug 18 20:04:47 2025
From: duke at openjdk.org (duke)
Date: Mon, 18 Aug 2025 20:04:47 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <b5Ukf3I4ESF6GUZXMYhJK-iVEuYGCCZ-R3WfHvzJ86k=.82c1ad8f-24e4-468e-865a-feb03da17131@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

@davidalayachew 
Your change (at version 1a7f99524d0841e5f3600abf933c32851af0742a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198244614

From liach at openjdk.org  Mon Aug 18 20:07:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:07:45 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <ZqQ5W8j0OttOjX8sKDuR87uXneuy7iRPHy_rckOvHtA=.d41a3315-7940-4728-ad31-cdbb7a8df476@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Thank you again, and thanks to all reviewers!

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198251588

From duke at openjdk.org  Mon Aug 18 20:27:45 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:27:45 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <uifzcBNI69VHsn5fmi2rw_taB-_bURuKqDAGpRmuwDc=.7070c9a2-4497-48d4-9bee-6e68b9c36f4a@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Did I do it wrong?

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198313072

From liach at openjdk.org  Mon Aug 18 20:46:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:46:43 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <iMFO5cgVQBl_s5c_xDFfGx0fPT2mgK7UwNovbmgO-VQ=.ab9ef996-545f-4c36-beb5-00f895dfcf1c@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

I think I will sponsor again given the status. The skara bots are undergoing mass restarts, and some other patches suddenly have new replies or unexpected status updates too.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198361168

From duke at openjdk.org  Mon Aug 18 20:51:44 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:51:44 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <edam26eDU0jNy_TdOw0bPlMrylLgnHlLh7UZRDOw3hw=.77f1c1e4-1b85-44d9-8795-481746b2637b@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Ty all for the help!

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198376598

From duke at openjdk.org  Mon Aug 18 20:51:45 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:51:45 GMT
Subject: Integrated: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <U5VLfOhyhYLxP8fCaBOnM1uJ1Rm4A-ty-9PpwVqmxrU=.3a73ec61-ae07-495b-993c-203ab37f8acd@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

This pull request has now been integrated.

Changeset: bad38a0f
Author:    David Alayachew <davidalayachew at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bad38a0f928589be62cabcc48df8a4651c615b3c
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8365643: JShell EditPad out of bounds on Windows

Reviewed-by: liach, aivanov, cstein, jlahoda

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

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

From syan at openjdk.org  Tue Aug 19 03:34:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 03:34:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
Message-ID: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>

On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.
>
> It is also something that can be changed later, in a follow up fix.

Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable.

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

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

From dholmes at openjdk.org  Tue Aug 19 05:25:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:25:40 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
Message-ID: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> It is also something that can be changed later, in a follow up fix.
>
> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.

> It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. 

What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources.

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

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

From dholmes at openjdk.org  Tue Aug 19 05:49:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:49:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

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

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

From dholmes at openjdk.org  Tue Aug 19 06:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:07:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
Message-ID: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
>> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.
>
> DELETED - I confused the timeout with the timeout-factor. New comment below.

No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 

However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

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

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

From syan at openjdk.org  Tue Aug 19 06:40:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 06:40:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>

On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
> 
> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.

The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

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

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

From jlahoda at openjdk.org  Tue Aug 19 07:44:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 19 Aug 2025 07:44:09 GMT
Subject: RFR: 8365689: Elements.getFileObjectOf fails with a
 NullPointerException when an erroneous Element is passed in
Message-ID: <vzDmf4lCyd3nLj79OHJu_LiFxiV8NaUwhKVWr2pz7bw=.d63a68fe-760c-4de8-b564-800dca2f212f@github.com>

If an erroneous/unresolvable `Element` is passed to `Elements.getFileObjectOf`, it fails with an NPE like:

Caused by: java.lang.NullPointerException: Cannot read field "classfile" because the return value of "com.sun.tools.javac.code.Symbol.enclClass()" is null
at jdk.compiler/com.sun.tools.javac.model.JavacElements.getFileObjectOf(JavacElements.java:803)
at TestFileObjectOf$PrintFiles.handleDeclaration(TestFileObjectOf.java:329)
at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2718)


The reason is the `Symbol.enclClass()` will return `null` for the erroneous `Element`. The proposed solution herein is to return `null` for erroneous/unresolvable `Element`s.

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

Commit messages:
 - Updating copyright year.
 - Improving test
 - 8365689: Elements.getFileObjectOf fails with a NullPointerException when an erroneous Element is passed in

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

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

From mbaesken at openjdk.org  Tue Aug 19 07:59:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Aug 2025 07:59:16 GMT
Subject: RFR: 8365700: jar --validate without any --file option leaves around a
 temporary file /tmp/tmpJar<number>.jar
Message-ID: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>

The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
This has been observed at least on Linux and AIX .

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

Commit messages:
 - JDK-8365700

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

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

From lkorinth at openjdk.org  Tue Aug 19 09:02:36 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:02:36 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
Message-ID: <uOH12UfZUHixcxSAx8lP66zvzxKr50yUj8x4_x22Su0=.31769f01-81c4-48b0-9050-f642c562deb5@github.com>

On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while.

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

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

From jpai at openjdk.org  Tue Aug 19 09:14:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Aug 2025 09:14:37 GMT
Subject: RFR: 8365700: jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <tuvDk9cVhKei8XR0Os70JKiB3nTTqrrul0YiPrfsfYE=.c868b140-ae1a-4f50-93a7-629b99201e16@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

Thank you Matthias for this fix. Although it was the `JarNoFileArgOperations` test which showed up this issue, the actual bug resides in the `jar` tool which is where your fix resides. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26837#pullrequestreview-3131432807

From lkorinth at openjdk.org  Tue Aug 19 09:19:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:19:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <BM1P_203-vMLbBYxbzigREy0NuHWoZqfgQvmGV0SH7I=.bf66ee89-19a9-4212-b800-08e7c835f4de@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.

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

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

From hannesw at openjdk.org  Tue Aug 19 12:04:43 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 19 Aug 2025 12:04:43 GMT
Subject: RFR: 8356411: Comment tree not reporting correct position for label
Message-ID: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>

Please review a change to fix the reported position of the label in `@see` tags in Markdown doc comments. When `MarkdownTransformer` would process the label of a `@see` tag together with the leading reference, it would set the position of the label to the position immediately following the reference, losing the actual source position of the label. The solution is to process the label without the leading reference. 

I have looked for other standard tags that may be affected by similar problems, but the `@see` tag is the only tag that [supports multiple forms](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#see) where Markdown text is stored in a list together with non-Markdown arguments.

The two tests are slightly redundant, but they test slightly different aspects of the fix and they were easy to implement in their respective frameworks.

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

Commit messages:
 - 8356411: Comment tree not reporting correct position for label

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

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

From asteiner at openjdk.org  Tue Aug 19 14:01:39 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Tue, 19 Aug 2025 14:01:39 GMT
Subject: RFR: 8365700: Jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <CQhQs0m1sya-KqImvL-qmKI6kup71_98ISrKP-BaqkQ=.9a38b4ce-7fd4-4c13-ba9a-6cc68edd9b43@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

LGTM

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

Marked as reviewed by asteiner (Author).

PR Review: https://git.openjdk.org/jdk/pull/26837#pullrequestreview-3132480856

From aturbanov at openjdk.org  Tue Aug 19 14:18:38 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Aug 2025 14:18:38 GMT
Subject: RFR: 8356411: Comment tree not reporting correct position for
 label
In-Reply-To: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>
References: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>
Message-ID: <J08rZGva3M9E8su60ilXHZgq4A-7dpb11FwNQW1LP6s=.9a7c1b65-7a91-4590-9fed-9a9a570e1863@github.com>

On Tue, 19 Aug 2025 11:57:45 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to fix the reported position of the label in `@see` tags in Markdown doc comments. When `MarkdownTransformer` would process the label of a `@see` tag together with the leading reference, it would set the position of the label to the position immediately following the reference, losing the actual source position of the label. The solution is to process the label without the leading reference. 
> 
> I have looked for other standard tags that may be affected by similar problems, but the `@see` tag is the only tag that [supports multiple forms](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#see) where Markdown text is stored in a list together with non-Markdown arguments.
> 
> The two tests are slightly redundant, but they test slightly different aspects of the fix and they were easy to implement in their respective frameworks.

src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java line 365:

> 363:             var ref = tree.reference;
> 364:             var hasReference = !ref.isEmpty() && ref.getFirst().getKind() == DocTree.Kind.REFERENCE;
> 365:             List<DCTree> transformed  = new ArrayList<>();

Suggestion:

            List<DCTree> transformed = new ArrayList<>();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26842#discussion_r2285420587

From hannesw at openjdk.org  Tue Aug 19 14:46:22 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 19 Aug 2025 14:46:22 GMT
Subject: RFR: 8356411: Comment tree not reporting correct position for
 label [v2]
In-Reply-To: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>
References: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>
Message-ID: <8NYQI5ZqETOqjfnBDXbYQNybJIJEAv4wns3EOvUJyE8=.77300259-7c98-4dd4-8c38-2e95b56b3232@github.com>

> Please review a change to fix the reported position of the label in `@see` tags in Markdown doc comments. When `MarkdownTransformer` would process the label of a `@see` tag together with the leading reference, it would set the position of the label to the position immediately following the reference, losing the actual source position of the label. The solution is to process the label without the leading reference. 
> 
> I have looked for other standard tags that may be affected by similar problems, but the `@see` tag is the only tag that [supports multiple forms](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#see) where Markdown text is stored in a list together with non-Markdown arguments.
> 
> The two tests are slightly redundant, but they test slightly different aspects of the fix and they were easy to implement in their respective frameworks.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Remove duplicate whitespace
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26842/files
  - new: https://git.openjdk.org/jdk/pull/26842/files/f0788bd1..dddfdc05

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

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

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

From liach at openjdk.org  Tue Aug 19 15:57:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Aug 2025 15:57:37 GMT
Subject: RFR: 8356411: Comment tree not reporting correct position for
 label [v2]
In-Reply-To: <8NYQI5ZqETOqjfnBDXbYQNybJIJEAv4wns3EOvUJyE8=.77300259-7c98-4dd4-8c38-2e95b56b3232@github.com>
References: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>
 <8NYQI5ZqETOqjfnBDXbYQNybJIJEAv4wns3EOvUJyE8=.77300259-7c98-4dd4-8c38-2e95b56b3232@github.com>
Message-ID: <XTJKAFsSJLQMhntukmkBjuCYGe9IIHkoSWmJxVC-qBA=.071d8957-6f8c-4e65-a2af-97e69ca7524e@github.com>

On Tue, 19 Aug 2025 14:46:22 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to fix the reported position of the label in `@see` tags in Markdown doc comments. When `MarkdownTransformer` would process the label of a `@see` tag together with the leading reference, it would set the position of the label to the position immediately following the reference, losing the actual source position of the label. The solution is to process the label without the leading reference. 
>> 
>> I have looked for other standard tags that may be affected by similar problems, but the `@see` tag is the only tag that [supports multiple forms](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#see) where Markdown text is stored in a list together with non-Markdown arguments.
>> 
>> The two tests are slightly redundant, but they test slightly different aspects of the fix and they were easy to implement in their respective frameworks.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate whitespace
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26842#pullrequestreview-3132937808

From mbaesken at openjdk.org  Wed Aug 20 06:50:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 06:50:42 GMT
Subject: RFR: 8365700: Jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <j2HEUTaMvz79n0ADjD0U9mtugwSlJhyZlrS-erxIGio=.7af09a9e-01fb-475e-9704-335bb74dd3c3@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26837#issuecomment-3204413561

From mbaesken at openjdk.org  Wed Aug 20 06:50:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Aug 2025 06:50:43 GMT
Subject: Integrated: 8365700: Jar --validate without any --file option leaves
 around a temporary file /tmp/tmpJar<number>.jar
In-Reply-To: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
References: <rTfGrZRml6wWmB8N4oipU8DBy1-6Kmph-c0c_j9KfMs=.82fb48ba-2a61-46fd-879b-b78d6689b561@github.com>
Message-ID: <fEzhZLegB_ayNUXsTPRhpRkDWBNVs4sMXzoYE9sKkXs=.ca6a4b1d-ffd8-4625-84b4-d7e270caa888@github.com>

On Tue, 19 Aug 2025 07:51:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jtreg test tools/jar/JarNoFileArgOperations.java seems to create files like /tmp/tmpJar12065714313154611400.jar in the file system and keeps them there after the test finishes (also in case of SUCCESS) .
> This has been observed at least on Linux and AIX .

This pull request has now been integrated.

Changeset: 320235cc
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/320235ccb88b4b554cd5756b7e6a34ce97aabd53
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8365700: Jar --validate without any --file option leaves around a temporary file /tmp/tmpJar<number>.jar

Reviewed-by: jpai, asteiner

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

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

From hannesw at openjdk.org  Wed Aug 20 08:40:42 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 20 Aug 2025 08:40:42 GMT
Subject: Integrated: 8356411: Comment tree not reporting correct position for
 label
In-Reply-To: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>
References: <HX9_XSHs1W9cM7fJrAhiaXGg2dxHC0UZ3ldTa3eV36U=.837aa5ad-0f6a-4834-978c-4a78789e4c40@github.com>
Message-ID: <ytUhyiE5rBMEeM7NfPI7gF1cGqlO2-mtr-ZBx39BKa8=.0a3658d5-a4f3-4a3b-b865-e75e92d395b4@github.com>

On Tue, 19 Aug 2025 11:57:45 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to fix the reported position of the label in `@see` tags in Markdown doc comments. When `MarkdownTransformer` would process the label of a `@see` tag together with the leading reference, it would set the position of the label to the position immediately following the reference, losing the actual source position of the label. The solution is to process the label without the leading reference. 
> 
> I have looked for other standard tags that may be affected by similar problems, but the `@see` tag is the only tag that [supports multiple forms](https://docs.oracle.com/en/java/javase/24/docs/specs/javadoc/doc-comment-spec.html#see) where Markdown text is stored in a list together with non-Markdown arguments.
> 
> The two tests are slightly redundant, but they test slightly different aspects of the fix and they were easy to implement in their respective frameworks.

This pull request has now been integrated.

Changeset: 908f3c96
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/908f3c96978bfa031414e576f444ec8f4dcc6925
Stats:     59 lines in 4 files changed: 48 ins; 0 del; 11 mod

8356411: Comment tree not reporting correct position for label

Reviewed-by: liach

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

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

From mcimadamore at openjdk.org  Wed Aug 20 12:54:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 20 Aug 2025 12:54:48 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: <6EdDbdhTX9yB2tpmy-jLjs4b5UG5fAOKjHvx6WKgi4Q=.bd4dd5ee-bdff-4a6a-b63c-dcb3f089e173@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.

Still looks good to me :-)

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

Marked as reviewed by mcimadamore (Reviewer).

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

From dholmes at openjdk.org  Wed Aug 20 12:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:55:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

@sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

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

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

From jlahoda at openjdk.org  Wed Aug 20 12:59:49 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 20 Aug 2025 12:59:49 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: <GxVU67BQodUS3zj1momREaeyCrM7ODP1YSL9a-XjoZ0=.b4484581-0b73-4eb4-a840-03bb0a775145@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 jlahoda (Reviewer).

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

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

From syan at openjdk.org  Wed Aug 20 14:28:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 14:28:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
Message-ID: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>

On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
>> 
>> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.

So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).

I do agree this change, what I mean is this change has some side effect.

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

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

From acobbs at openjdk.org  Wed Aug 20 15:08:01 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 20 Aug 2025 15:08:01 GMT
Subject: Integrated: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution
In-Reply-To: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
References: <08zj2WBmFFeEQbGegExwyGLIDLQV71_TmkqDA4lYad8=.50f5befe-7d49-4865-92e8-fcbbf1f5ea32@github.com>
Message-ID: <JM0DTQC9KkcXRvePBRdi6wGmmPh70ukPVNt7lut5DnE=.c1234cc6-265a-425c-903f-a113947d7a26@github.com>

On Thu, 10 Apr 2025 20:23:15 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.

This pull request has now been integrated.

Changeset: 3e60ab51
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e60ab51fea17098d852931a06f4f5a827ae0e78
Stats:     1924 lines in 56 files changed: 980 ins; 584 del; 360 mod

8348611: Eliminate DeferredLintHandler and emit warnings after attribution
8224228: No way to locally suppress lint warnings in parser/tokenizer or preview features
8353758: Missing calls to Log.useSource() in JavacTrees

Reviewed-by: mcimadamore, vromero, jlahoda

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

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

From ihse at openjdk.org  Wed Aug 20 15:19:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:19:42 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

I don't think there is any point linking to the build source code. 

Suggestion:

certain amount of time will apply this factor. If you run in
forced compilation mode (`-Xcomp`) using `make test`, it
will automatically adjust this factor to compensate for the
interpreter not being as fast as JITed code. Defaults to 1.

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

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

From ihse at openjdk.org  Wed Aug 20 15:24:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:24:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>

On Mon, 18 Aug 2025 16:34:21 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 suggestion from Daniel

It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.

I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 

Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

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

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

From daniel.smith at oracle.com  Wed Aug 20 15:52:20 2025
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 20 Aug 2025 15:52:20 +0000
Subject: Possible bug with multiple generic bounds
In-Reply-To: <CA+0ynh9pO_S7Kn0z_KQ2HzSG1xoki2Ge4nbAzaBAiXrM0-W=fQ@mail.gmail.com>
References: <CA+0ynh82cdGH7+K=gXmh3USm2Z_5gVzPAgOHb9ckWFQe3-i5tw@mail.gmail.com>
 <CA+0ynh9pO_S7Kn0z_KQ2HzSG1xoki2Ge4nbAzaBAiXrM0-W=fQ@mail.gmail.com>
Message-ID: <B1295F5C-C81F-4D54-815D-6DB0C2BEBF86@oracle.com>

For some context, there's a longstanding known issue that the interaction between intersections and wildcards is under-specified. Deciding which intersections are well-formed, and if so what are the types of their members, is a deep problem without easy answers.

JDK-7034922 captures some of the issues, and I see this bug has been linked to it.

So yes, this is intuitively a bug, but the problem is we don't have a specification to conform to, and it's not clear what that specification should say.

I've done some work in the past to try to make sense of the intended type system, but that work hasn't gotten to the point of actionable changes. In the mean time I think this is just one more test case for these features that we can keep track of.


From lkorinth at openjdk.org  Wed Aug 20 16:27:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 16:27:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
Message-ID: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>

On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> I don't think there is any point linking to the build source code. 
> 
> Suggestion:
> 
> certain amount of time will apply this factor. If you run in
> forced compilation mode (`-Xcomp`) using `make test`, it
> will automatically adjust this factor to compensate for the
> interpreter not being as fast as JITed code. Defaults to 1.

I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

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

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

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@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:

  update testing.md, remove makefile link, fix bad text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72

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

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 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 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
 <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com>

On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> I don't think there is any point linking to the build source code. 
>> 
>> Suggestion:
>> 
>> certain amount of time will apply this factor. If you run in
>> forced compilation mode (`-Xcomp`) using `make test`, it
>> will automatically adjust this factor to compensate for the
>> interpreter not being as fast as JITed code. Defaults to 1.
>
> I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

fixed

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

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

From mcimadamore at openjdk.org  Wed Aug 20 17:09:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 20 Aug 2025 17:09:51 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v11]
In-Reply-To: <oDTXZPuDC75ZjBewjnY4mZX4FklJM1Eh9JTZUrmDBWs=.b0b8fab5-ecd8-4c5c-afae-47f4f0ee90cb@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>
 <oDTXZPuDC75ZjBewjnY4mZX4FklJM1Eh9JTZUrmDBWs=.b0b8fab5-ecd8-4c5c-afae-47f4f0ee90cb@github.com>
Message-ID: <G3HEh6HHpQFFBWUb-yfoLGDDNuT-mox5jVW5C7O_0mU=.c21d826f-042d-4787-90c2-d401dc2e6dbe@github.com>

On Fri, 15 Aug 2025 16:19:13 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Marked as reviewed by vromero (Reviewer).
>
> @vicente-romero-oracle thanks for the re-review.
> 
> @lahodaj @mcimadamore please re-review after 1f1247bc5c whenever convenient.
> 
> Thanks!

Thanks @archiecobbs for all your hard work on this issue. I'm glad to see this integrated!

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

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

From acobbs at openjdk.org  Wed Aug 20 17:23:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 20 Aug 2025 17:23:52 GMT
Subject: RFR: 8348611: Eliminate DeferredLintHandler and emit warnings
 after attribution [v11]
In-Reply-To: <G3HEh6HHpQFFBWUb-yfoLGDDNuT-mox5jVW5C7O_0mU=.c21d826f-042d-4787-90c2-d401dc2e6dbe@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>
 <oDTXZPuDC75ZjBewjnY4mZX4FklJM1Eh9JTZUrmDBWs=.b0b8fab5-ecd8-4c5c-afae-47f4f0ee90cb@github.com>
 <G3HEh6HHpQFFBWUb-yfoLGDDNuT-mox5jVW5C7O_0mU=.c21d826f-042d-4787-90c2-d401dc2e6dbe@github.com>
Message-ID: <lY97m_m5TXCfR0IkFX6virmY9xhT6MEZES0hoZCGhEI=.9f6d45c4-d46d-4410-a1df-c2014390b54d@github.com>

On Wed, 20 Aug 2025 17:06:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> @vicente-romero-oracle thanks for the re-review.
>> 
>> @lahodaj @mcimadamore please re-review after 1f1247bc5c whenever convenient.
>> 
>> Thanks!
>
> Thanks @archiecobbs for all your hard work on this issue. I'm glad to see this integrated!

@mcimadamore thanks very much for your reviews and helpful discussions. "Cleanups" like this are sometimes tedious to review so I appreciate your time on it!

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

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

From ihse at openjdk.org  Wed Aug 20 19:36:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 19:36:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <Pw1uYaqAPK95BsoZ0xgNA1c3rsXjxHCiz-xACzocwqA=.e6cb7fcf-4438-4e4a-aeef-7d9c707c87c8@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

Build changes look good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

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

From nlisker at gmail.com  Wed Aug 20 20:47:18 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 20 Aug 2025 23:47:18 +0300
Subject: Possible bug with multiple generic bounds
In-Reply-To: <B1295F5C-C81F-4D54-815D-6DB0C2BEBF86@oracle.com>
References: <CA+0ynh82cdGH7+K=gXmh3USm2Z_5gVzPAgOHb9ckWFQe3-i5tw@mail.gmail.com>
 <CA+0ynh9pO_S7Kn0z_KQ2HzSG1xoki2Ge4nbAzaBAiXrM0-W=fQ@mail.gmail.com>
 <B1295F5C-C81F-4D54-815D-6DB0C2BEBF86@oracle.com>
Message-ID: <CA+0ynh90fNUeDwggVzKaAgSrXwoEAUg_C5GXLf2QzRoJL_SvYw@mail.gmail.com>

ECJ doesn't have this "bug" yet still conforms to the specs. Is it possible
to get javac to do the same thing here?

On Wed, Aug 20, 2025 at 6:52?PM Dan Smith <daniel.smith at oracle.com> wrote:

> For some context, there's a longstanding known issue that the interaction
> between intersections and wildcards is under-specified. Deciding which
> intersections are well-formed, and if so what are the types of their
> members, is a deep problem without easy answers.
>
> JDK-7034922 captures some of the issues, and I see this bug has been
> linked to it.
>
> So yes, this is intuitively a bug, but the problem is we don't have a
> specification to conform to, and it's not clear what that specification
> should say.
>
> I've done some work in the past to try to make sense of the intended type
> system, but that work hasn't gotten to the point of actionable changes. In
> the mean time I think this is just one more test case for these features
> that we can keep track of.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250820/b297950f/attachment-0001.htm>

From dholmes at openjdk.org  Wed Aug 20 21:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 21:32:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <j5ndr4sR6OHgBGlCY-e1I-VdfMKpG2GS98Wv2qbshtU=.d5aad200-1bc2-4080-ad71-218c59a7e491@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, 

@magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally).

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

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

From smarks at openjdk.org  Wed Aug 20 23:13:57 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 20 Aug 2025 23:13:57 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <rJ3QSq3t7ltPQFZT29uxH40dxr2vaIkJcE1ZZTZohv8=.9c51b9cb-b71c-4483-89a7-0f7cf8e274df@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26273#pullrequestreview-3138508798

From vicente.romero at oracle.com  Thu Aug 21 02:13:08 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 20 Aug 2025 22:13:08 -0400
Subject: Possible bug with multiple generic bounds
In-Reply-To: <CA+0ynh90fNUeDwggVzKaAgSrXwoEAUg_C5GXLf2QzRoJL_SvYw@mail.gmail.com>
References: <CA+0ynh82cdGH7+K=gXmh3USm2Z_5gVzPAgOHb9ckWFQe3-i5tw@mail.gmail.com>
 <CA+0ynh9pO_S7Kn0z_KQ2HzSG1xoki2Ge4nbAzaBAiXrM0-W=fQ@mail.gmail.com>
 <B1295F5C-C81F-4D54-815D-6DB0C2BEBF86@oracle.com>
 <CA+0ynh90fNUeDwggVzKaAgSrXwoEAUg_C5GXLf2QzRoJL_SvYw@mail.gmail.com>
Message-ID: <3fddb81a-b9ab-4989-8761-a02eecb0a780@oracle.com>

Hi Nir,

On 8/20/25 16:47, Nir Lisker wrote:
> ECJ doesn't have this "bug" yet still conforms to the specs. Is it 
> possible to get javac to do the same thing here?

to start with it could be argue that it could be a bug that ECJ is 
accepting this code. But considering only the javac side, what you are 
suggesting would imply implementing non-specified behavior. Which will 
imply accepting programs that once the specification settles on this 
issue could be rejected thus having a future compatibility issue. javac 
is not supposed to accept the same universe of programs as ECJ. This is 
desirable for all users but there are differences. Sometimes due to 
bugs, sometimes because the compilers cover some gaps or gray areas that 
are under specified. IMO this case represents a gap wide enough to 
consider waiting for specification clarity before jumping over it

>
> On Wed, Aug 20, 2025 at 6:52?PM Dan Smith <daniel.smith at oracle.com> wrote:
>
>     For some context, there's a longstanding known issue that the
>     interaction between intersections and wildcards is
>     under-specified. Deciding which intersections are well-formed, and
>     if so what are the types of their members, is a deep problem
>     without easy answers.
>
>     JDK-7034922 captures some of the issues, and I see this bug has
>     been linked to it.
>
>     So yes, this is intuitively a bug, but the problem is we don't
>     have a specification to conform to, and it's not clear what that
>     specification should say.
>
>     I've done some work in the past to try to make sense of the
>     intended type system, but that work hasn't gotten to the point of
>     actionable changes. In the mean time I think this is just one more
>     test case for these features that we can keep track of.
>

Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250820/ba0bd981/attachment-0001.htm>

From alanb at openjdk.org  Thu Aug 21 05:48:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Aug 2025 05:48:54 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <Ib7EzYAmRZKpHeZaXrb9hHcELvId036W2qDQX7sYI9o=.a6aa2d75-d72d-41b6-adb1-e37f5a164be7@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26273#pullrequestreview-3139104718

From alanb at openjdk.org  Thu Aug 21 05:48:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Aug 2025 05:48:54 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <2tLfcUvYvIIVvxNIZPUkRT-hVw9a4Ew1J-Vf4jNEmhQ=.23dd367a-2b1d-4934-8381-c38313ed097f@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
 <cO1zXItkW-dfgISgig8mEe1Aos_urlRS11MWAGXIHzw=.972adca9-cc58-4e4c-a0c4-1f884137e268@github.com>
 <u4iqIEvR6AlBXRLAOXLl3W0zHxzF9-jkFbODhznu6oo=.af6bf899-7526-4920-b8e8-92ee35bcf1cb@github.com>
 <Ugc0-PSaFEgTqbvkKWniZ1WHULGyCLmUpqSa8VIHEaQ=.67317723-f459-43ca-a03b-52984a0fa9d2@github.com>
 <2tLfcUvYvIIVvxNIZPUkRT-hVw9a4Ew1J-Vf4jNEmhQ=.23dd367a-2b1d-4934-8381-c38313ed097f@github.com>
Message-ID: <t0AyaL_RbuQr7WQpEd8p67Fs9lsIY0jL_EhCoC9m4sc=.0b0ab1eb-bc89-44f9-a3fb-695bcdd01887@github.com>

On Tue, 15 Jul 2025 16:26:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> we do have wordings like " If the virtual machine is started from an interactive command line without redirecting the standard input AND output streams then its console will exist ..." and "If no console device is
>> available then an invocation of that method will return <tt>null</tt>" from the very beginning. not very "straightforward" but i think it's clear enough?
>
> I think adding `@see` tag would be more helpful.
> 
> As to the spec wording wrt stdin/out, there is another issue filed to make it clearer: JDK-8361972. This PR addresses the implementation part only so that it can be backported to prior LTSes without spec change.

It already links to Console so I don't think think the additional `@see` is needed. Look at the generated javadoc and see what you think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26273#discussion_r2289917231

From lkorinth at openjdk.org  Thu Aug 21 09:12:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 21 Aug 2025 09:12:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
Message-ID: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>

On Wed, 20 Aug 2025 14:25:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.
>
> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
> 
> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
> 
> I do agree this change, what I mean is this change has some side effect.
> 
>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
> 
> I think I can try it in a new PR.

I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.

I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

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

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

From syan at openjdk.org  Thu Aug 21 09:52:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 21 Aug 2025 09:52:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
 <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
Message-ID: <N_1V36WztAVi1O6SdDaGQXa4b8TGB7xGpz5T1TbxL9I=.ea0293e3-eb0b-4d96-bd40-d5c9c4e3fd1d@github.com>

On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
>> 
>> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
>> 
>> I do agree this change, what I mean is this change has some side effect.
>> 
>>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
>> 
>> I think I can try it in a new PR.
>
> I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.
> 
> I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

@lkorinth Thanks for your advice sincerely. I think you are right, we need more evaluate cautiously before start to change the timeoutFactor for -Xcomp.

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

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

From ihse at openjdk.org  Thu Aug 21 12:21:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Aug 2025 12:21:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <zgu5mLb1mA-ca4wxmJJjLNmmq3sJFwWtfjY4yRnmYFQ=.81a024ea-41ce-42cc-9038-3ef40e483793@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.
> 
> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 
> 
> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

> @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

That is surprising and a bit disappointing. I guess it is not worth the effort to try and figure out why this is the case; it could probably vary from test to test and be difficult to track for little gain. Still, it makes you wonder.

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

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

From jlahoda at openjdk.org  Thu Aug 21 12:48:15 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 21 Aug 2025 12:48:15 GMT
Subject: RFR: 8285150: Improve tab completion for annotations [v2]
In-Reply-To: <vJvgdnek_UV2Ed0BKYBAKuFVoeAuhm5yJveWCBdr10k=.a7e2f89f-e4be-445d-b532-1710313de064@github.com>
References: <vJvgdnek_UV2Ed0BKYBAKuFVoeAuhm5yJveWCBdr10k=.a7e2f89f-e4be-445d-b532-1710313de064@github.com>
Message-ID: <7Kf2DP33mHnr8xDKHCMyQumRA2Oaa2TBIqoq08N5lTA=.acd42389-a3d2-4fc8-a2ae-f4bd58c8aec0@github.com>

> When using types code like:
> 
> @Deprecated(
> 
> 
> and presses `<tab>`, there should be a sensible completion, but currently there is nothing. This PR proposes to add code completion for annotation attributes.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Fixing completion prefix behavior
 - Merge branch 'master' into JDK-8285150-dev2
 - Improving the handling of annotation attributes that are annotations and enum constants.
 - Merge branch 'master' into JDK-8285150
 - Merge branch 'master' into JDK-8285150
 - 8285150: Improve tab completion for annotations

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

Changes: https://git.openjdk.org/jdk/pull/22840/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22840&range=01
  Stats: 321 lines in 4 files changed: 300 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/22840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22840/head:pull/22840

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

From duke at openjdk.org  Thu Aug 21 15:19:32 2025
From: duke at openjdk.org (altrisi)
Date: Thu, 21 Aug 2025 15:19:32 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names
Message-ID: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>

This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.

Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.

The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.

This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.

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

Commit messages:
 - Hoist supported check and change message from review comments
 - Remove builtin anonymous class test
 - Fix whitespace error
 - Fix test not using anonymous class
 - Support anonymous, local and inner classes in TOOLING.jsh

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

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

From liach at openjdk.org  Thu Aug 21 15:19:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Aug 2025 15:19:33 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names
In-Reply-To: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
Message-ID: <lDtA72-m4Zpxc37lo2XF8EEpJgNcIjLVl0x05DulsZ8=.124d50c5-0db9-40bc-8ad3-ba405fb5cf12@github.com>

On Wed, 20 Aug 2025 15:37:09 GMT, altrisi <duke at openjdk.org> wrote:

> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
> 
> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
> 
> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
> 
> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.

Created https://bugs.openjdk.org/browse/JDK-8365878 for you.

src/jdk.jshell/share/classes/jdk/jshell/tool/resources/TOOLING.jsh line 12:

> 10: void javap(Class<?> type) throws Exception {
> 11:     try {
> 12:         if (type.isPrimitive() || type.isHidden() || type.isArray()) throw new IllegalArgumentException("Type not supported: " + type);

The message should say the given class has no class file. And this check should be hoisted out of the try-catch.

test/langtools/jdk/jshell/ToolingTest.java line 100:

> 98:             a -> assertCommand(a, "/open TOOLING",
> 99:                         ""),
> 100:             a -> assertCommandUserOutputContains(a, "javap(Class.forName(\"sun.util.PreHashedMap$1\"))", // arbitrary built-in anonymous class

I recommend the case to test against a generic class without a canonical name, such as `java.lang.invoke.DirectMethodHandle$Holder` generated by jlink; arbitrary javac artifacts is subject to renames because they have no linkage exposure, and these generic packages with antique code may be removed in a future maintenance and cause unexpected failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/26864#issuecomment-3207681627
PR Review Comment: https://git.openjdk.org/jdk/pull/26864#discussion_r2288782092
PR Review Comment: https://git.openjdk.org/jdk/pull/26864#discussion_r2288654271

From duke at openjdk.org  Thu Aug 21 15:19:33 2025
From: duke at openjdk.org (altrisi)
Date: Thu, 21 Aug 2025 15:19:33 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names
In-Reply-To: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
Message-ID: <WM1wR4smW4AATz-71BiYrX67IEIY5KEu0sE46D2-jcw=.20c96658-30ab-47cd-acef-36aa03c7f221@github.com>

On Wed, 20 Aug 2025 15:37:09 GMT, altrisi <duke at openjdk.org> wrote:

> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
> 
> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
> 
> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
> 
> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.

> Created [bugs.openjdk.org/browse/JDK-8365878](https://bugs.openjdk.org/browse/JDK-8365878) for you.

Thanks! I had actually opened a bug via webbug and was waiting on it, not sure how to handle now having two. I'll use yours for now.

Also about the issue name, I think it's fair for an utility like this to start with a broad check like "has canonical name" to check if supported, even though it caused the issue of nested built-in classes failing to use the proper path. It only used the canonical for that anyway, when retrieving the class file it'd use the binary name. I'd say the most important part of this patch is support for more types of classes.

But I'm fine with that one too if you think it's better.

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

PR Comment: https://git.openjdk.org/jdk/pull/26864#issuecomment-3211058592

From duke at openjdk.org  Thu Aug 21 15:19:33 2025
From: duke at openjdk.org (altrisi)
Date: Thu, 21 Aug 2025 15:19:33 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names
In-Reply-To: <lDtA72-m4Zpxc37lo2XF8EEpJgNcIjLVl0x05DulsZ8=.124d50c5-0db9-40bc-8ad3-ba405fb5cf12@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <lDtA72-m4Zpxc37lo2XF8EEpJgNcIjLVl0x05DulsZ8=.124d50c5-0db9-40bc-8ad3-ba405fb5cf12@github.com>
Message-ID: <8qgCRmTFBgat3LOuAaJih-vDRnnwF7ZI8JF-oSKgzFQ=.4e082b3a-1e28-4bda-8820-6116ebc4ddac@github.com>

On Wed, 20 Aug 2025 16:14:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
>> 
>> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
>> 
>> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
>> 
>> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.
>
> test/langtools/jdk/jshell/ToolingTest.java line 100:
> 
>> 98:             a -> assertCommand(a, "/open TOOLING",
>> 99:                         ""),
>> 100:             a -> assertCommandUserOutputContains(a, "javap(Class.forName(\"sun.util.PreHashedMap$1\"))", // arbitrary built-in anonymous class
> 
> I recommend the case to test against a generic class without a canonical name, such as `java.lang.invoke.DirectMethodHandle$Holder` generated by jlink; arbitrary javac artifacts is subject to renames because they have no linkage exposure, and these generic packages with antique code may be removed in a future maintenance and cause unexpected failures.

`java.lang.invoke.DirectMethodHandle$Holder` seems to have a canonical name, it's not anonymous:


jshell> Class.forName("java.lang.invoke.DirectMethodHandle$Holder").getCanonicalName()
$13 ==> "java.lang.invoke.DirectMethodHandle$Holder"
jshell> Class.forName("java.lang.invoke.DirectMethodHandle$Holder").isAnonymousClass()
$14 ==> false


Wasn't too sure on this test either way, considering I also added a test for user created anonymous classes, I think I'll just remove it instead. Any anonymous class can be refactored anytime and would have the same problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26864#discussion_r2288746130

From liach at openjdk.org  Thu Aug 21 15:19:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Aug 2025 15:19:33 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names
In-Reply-To: <8qgCRmTFBgat3LOuAaJih-vDRnnwF7ZI8JF-oSKgzFQ=.4e082b3a-1e28-4bda-8820-6116ebc4ddac@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <lDtA72-m4Zpxc37lo2XF8EEpJgNcIjLVl0x05DulsZ8=.124d50c5-0db9-40bc-8ad3-ba405fb5cf12@github.com>
 <8qgCRmTFBgat3LOuAaJih-vDRnnwF7ZI8JF-oSKgzFQ=.4e082b3a-1e28-4bda-8820-6116ebc4ddac@github.com>
Message-ID: <THKPJGixjF2yfb6Mcx405DqqWBwcnkrEMShuFGX6Itc=.beb95f68-0015-42f2-a5b3-794675164ecb@github.com>

On Wed, 20 Aug 2025 16:43:32 GMT, altrisi <duke at openjdk.org> wrote:

>> test/langtools/jdk/jshell/ToolingTest.java line 100:
>> 
>>> 98:             a -> assertCommand(a, "/open TOOLING",
>>> 99:                         ""),
>>> 100:             a -> assertCommandUserOutputContains(a, "javap(Class.forName(\"sun.util.PreHashedMap$1\"))", // arbitrary built-in anonymous class
>> 
>> I recommend the case to test against a generic class without a canonical name, such as `java.lang.invoke.DirectMethodHandle$Holder` generated by jlink; arbitrary javac artifacts is subject to renames because they have no linkage exposure, and these generic packages with antique code may be removed in a future maintenance and cause unexpected failures.
>
> `java.lang.invoke.DirectMethodHandle$Holder` seems to have a canonical name, it's not anonymous:
> 
> 
> jshell> Class.forName("java.lang.invoke.DirectMethodHandle$Holder").getCanonicalName()
> $13 ==> "java.lang.invoke.DirectMethodHandle$Holder"
> jshell> Class.forName("java.lang.invoke.DirectMethodHandle$Holder").isAnonymousClass()
> $14 ==> false
> 
> 
> Wasn't too sure on this test either way, considering I also added a test for user created anonymous classes, I think I'll just remove it instead. Any anonymous class can be refactored anytime and would have the same problem.

Essentially the problem is the name from `getCanonicalName` is wrong. javap accepts both dot and slash notations, so `getName` is sufficient. Also the `type.getClassLoader().getResourceAsStream(name)` is wrong if the type is loaded by the bootstrap class loader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26864#discussion_r2288781037

From liach at openjdk.org  Thu Aug 21 17:20:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Aug 2025 17:20:52 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names
In-Reply-To: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
Message-ID: <LviDipweqmD59xufnXCRKrY0g00Osi5FpWaP24i3VcM=.0a207d43-5b40-4332-ac49-c2f95ad76f01@github.com>

On Wed, 20 Aug 2025 15:37:09 GMT, altrisi <duke at openjdk.org> wrote:

> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
> 
> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
> 
> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
> 
> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.

Looks good to me, thanks! @sormuras may be interested in this too since he initially added this script.

test/langtools/jdk/jshell/ToolingTest.java line 1:

> 1: /*

Can you update:
On line 2, `(c) 2023, Oracle` to `(c) 2023, 2025, Oracle`
On line 26 `@bug 8306560` to `@bug 8306560 8365878`

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

PR Review: https://git.openjdk.org/jdk/pull/26864#pullrequestreview-3141643171
PR Review Comment: https://git.openjdk.org/jdk/pull/26864#discussion_r2291696567

From duke at openjdk.org  Thu Aug 21 17:30:46 2025
From: duke at openjdk.org (altrisi)
Date: Thu, 21 Aug 2025 17:30:46 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names [v2]
In-Reply-To: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
Message-ID: <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>

> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
> 
> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
> 
> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
> 
> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.

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

  Update copyright and add this bug id to ToolingTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26864/files
  - new: https://git.openjdk.org/jdk/pull/26864/files/977c73cb..4077f403

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

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

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

From duke at openjdk.org  Thu Aug 21 17:37:53 2025
From: duke at openjdk.org (altrisi)
Date: Thu, 21 Aug 2025 17:37:53 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names [v2]
In-Reply-To: <LviDipweqmD59xufnXCRKrY0g00Osi5FpWaP24i3VcM=.0a207d43-5b40-4332-ac49-c2f95ad76f01@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <LviDipweqmD59xufnXCRKrY0g00Osi5FpWaP24i3VcM=.0a207d43-5b40-4332-ac49-c2f95ad76f01@github.com>
Message-ID: <S06yjovXOPNHSJpvP4ZzQqPmcg4NFp20Zfj2Ct2GyQI=.1e5e52f5-a2b6-491e-b6e6-e0ad27e7d55a@github.com>

On Thu, 21 Aug 2025 17:18:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> altrisi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright and add this bug id to ToolingTest
>
> test/langtools/jdk/jshell/ToolingTest.java line 1:
> 
>> 1: /*
> 
> Can you update:
> On line 2, `(c) 2023, Oracle` to `(c) 2023, 2025, Oracle`
> On line 26 `@bug 8306560` to `@bug 8306560 8365878`

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26864#discussion_r2291730517

From liach at openjdk.org  Thu Aug 21 17:37:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Aug 2025 17:37:51 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names [v2]
In-Reply-To: <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
Message-ID: <vz9d0s1hgvHvYvM1-uctjMZKNyN5fish3DPqaG11Zl0=.cdc52541-7b3d-448e-a2c5-0a04d6655c18@github.com>

On Thu, 21 Aug 2025 17:30:46 GMT, altrisi <duke at openjdk.org> wrote:

>> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
>> 
>> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
>> 
>> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
>> 
>> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.
>
> altrisi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and add this bug id to ToolingTest

Looks good. Let's wait for @sormuras for another verification.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26864#pullrequestreview-3141701665

From smarks at openjdk.org  Thu Aug 21 18:46:56 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 21 Aug 2025 18:46:56 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <mbX3kLCnSoigRDhV6L5YAwJErnsEXVx8m0hxxmJR_iU=.6b250bdf-2cbc-4972-a672-75722b34a8e3@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

ecki wrote:

> I know my View of console is always a bit controversial, but having access to /dev/tty despite a program have redirected stdout and stderr would be a feature, not something you actively need to disable.
But I guess writing system tools it not something Java ever was made for :)

[extracted from HTML and edited slightly by me]

There is as usual a bunch of history here. The Java `Console` class doesn't use /dev/tty at all. In retrospect it might have been preferable for it to have used `/dev/tty` from the beginning, at least on Unix. However, that's not the case; it's always been a wrapper around the combination of stdin and stdout. Having to support equivalent functions on Windows might have played a part in this design. In any case, since its introduction in JDK 1.6, `Console` has been based on stdin and stdout and not /dev/tty.

The question then arises as to what should happen if one or both of stdin or stdout have been redirected. Historically, if either were redirected, `System.console()` would return null, meaning that "the console does not exist." More recently, we introduced the JLine console provider in order to provide line editing. Unfortunately this confused the situation, as it would provide a non-null `Console` instance in certain cases even if stdin or stdout were redirected, leading to confused and inconsistent behavior. That's what this PR is fixing.

There's still a broader question of, could `Console` use /dev/tty? Calling `System.console()` to obtain a `Console` instance might open /dev/tty directly. This could work even if all of stdin, stdout, and stderr are redirected. And it could provide a full set of features (including no-echo when reading passwords, and line editing) even in this case. This could be quite useful. However, this would be an incompatbile behavior change. Given the history of `Console`, there are programs out there that assume that it is based around stdin and stdout and mix operations on them. However, it might be possible to create a `Console` based on /dev/tty, and applications that are prepared for this change could opt into using this implementation. There are also questions about how this would work on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/26273#issuecomment-3211704997

From cstein at openjdk.org  Thu Aug 21 19:14:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 21 Aug 2025 19:14:51 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names [v2]
In-Reply-To: <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
Message-ID: <UIOIbRVqwh1JfZH_8Hr4HkqHVrAAwvbUNq2Aq_ERK0I=.f19d5e7e-b696-445b-b19e-a568fc55009f@github.com>

On Thu, 21 Aug 2025 17:30:46 GMT, altrisi <duke at openjdk.org> wrote:

>> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
>> 
>> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
>> 
>> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
>> 
>> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.
>
> altrisi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and add this bug id to ToolingTest

Implementation and new tests look good to me, too. Thanks for improving this feature of the tooling script.

Seems like two of the pre-submit checks ran into timeouts ? thus, not related to this change.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26864#pullrequestreview-3141970637
PR Comment: https://git.openjdk.org/jdk/pull/26864#issuecomment-3211783251

From prr at openjdk.org  Fri Aug 22 05:54:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 05:54:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:

> 48:  * @summary URL.getContent() should return SoundClip for supported formats
> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
> 50:  */

I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

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

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

From dholmes at openjdk.org  Fri Aug 22 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 06:38:56 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <GGszb14v2jX1mI4BbHtgkXQDlgFehKYtLl3yUr0zX40=.1952e76e-0a5c-4be9-944a-505f84d89624@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

@prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

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

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

From duke at openjdk.org  Fri Aug 22 15:21:52 2025
From: duke at openjdk.org (altrisi)
Date: Fri, 22 Aug 2025 15:21:52 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names [v2]
In-Reply-To: <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
Message-ID: <lz19p8hK6mV_yfgbhJ_yR7niy4dXAfpJXOyS46ZhOVw=.1aaaf504-c153-4fc4-8750-29c8fc24b531@github.com>

On Thu, 21 Aug 2025 17:30:46 GMT, altrisi <duke at openjdk.org> wrote:

>> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
>> 
>> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
>> 
>> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
>> 
>> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.
>
> altrisi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and add this bug id to ToolingTest

Thanks for the reviews! Reran the failed GHA and now completed successfully.

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

PR Comment: https://git.openjdk.org/jdk/pull/26864#issuecomment-3214749181

From duke at openjdk.org  Fri Aug 22 15:21:53 2025
From: duke at openjdk.org (duke)
Date: Fri, 22 Aug 2025 15:21:53 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names [v2]
In-Reply-To: <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
Message-ID: <ByAUgsncbPRjyIu88FXF2Naec_LncTIB2RnBS18ca28=.e594070a-af0f-4237-8fd5-9385ad77b75c@github.com>

On Thu, 21 Aug 2025 17:30:46 GMT, altrisi <duke at openjdk.org> wrote:

>> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
>> 
>> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
>> 
>> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
>> 
>> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.
>
> altrisi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and add this bug id to ToolingTest

@altrisi 
Your change (at version 4077f4037c4238335a8b5be57a04645959c8a03b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26864#issuecomment-3214752624

From ayang at openjdk.org  Fri Aug 22 16:10:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 16:10:58 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

> Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480.

I identified some cases that doesn't follow this. Unclear whether they are intentional.

test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:

> 34:  * @build jdk.test.whitebox.WhiteBox
> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation

Why not `480` in this case?

test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:

> 38:  * @requires vm.cds
> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses

I was expecting `500 * 4 = 2000`, instead of `8000` here.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31:

> 29:  * @compile SuspendResume2.java
> 30:  * @run driver jdk.test.lib.FileInstaller . .
> 31:  * @run main/othervm/native/timeout=700

Why `700` instead of `480` in this file?

test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:

> 57: public class DGCDeadLock implements Runnable {
> 58:     final static public int HOLD_TARGET_TIME = 25000;
> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);

Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:

> 58:  * @comment skip running this test on 32 bit VM
> 59:  * @requires vm.bits == "64"
> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest

Why not `480`?

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:

> 32:  * @build com.foobar.Utils
> 33:  *        com.bar.*
> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest

Why not `480`?

test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:

> 47:  * @library /test/lib /test/jdk
> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription

Why not `480`?

test/jdk/tools/jpackage/share/InstallDirTest.java line 69:

> 67:  * @compile -Xlint:all -Werror InstallDirTest.java
> 68:  * @requires (jpackage.test.SQETest != null)
> 69:  * @run main/othervm/timeout=4000 -Xmx512m jdk.jpackage.test.Main

Why more than `4x` in this file?

test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:

> 36: class HangingRemoteAgent extends RemoteExecutionControl {
> 37: 
> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

why not `Utils.TIMEOUT_FACTOR`?

test/langtools/jdk/jshell/UITesting.java line 148:

> 146:     }
> 147: 
> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

Why not `Utils.TIMEOUT_FACTOR`?

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

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3144985957
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294077875
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294085201
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294089550
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294108202
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294110136
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294113670
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294116148
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294119800
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294128741
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294129243

From liach at openjdk.org  Fri Aug 22 17:13:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Aug 2025 17:13:57 GMT
Subject: RFR: 8365878: jshell TOOLING's javap should use binary names [v2]
In-Reply-To: <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
 <DAtWRTxKKsh_wZJDD06_vCjYBGI5Pk10CmsutcaY04Q=.9728dd66-97b8-484d-8b13-dad6036ffe21@github.com>
Message-ID: <z9yFm_Ky9-rmM_EjGNsO_0OtnazAzJ4HcZcdg7GnMdE=.d9af3072-8540-4a93-9849-5f5dff6e3dc9@github.com>

On Thu, 21 Aug 2025 17:30:46 GMT, altrisi <duke at openjdk.org> wrote:

>> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
>> 
>> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
>> 
>> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
>> 
>> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.
>
> altrisi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and add this bug id to ToolingTest

Verified again locally. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26864#issuecomment-3215045169

From duke at openjdk.org  Fri Aug 22 17:13:57 2025
From: duke at openjdk.org (altrisi)
Date: Fri, 22 Aug 2025 17:13:57 GMT
Subject: Integrated: 8365878: jshell TOOLING's javap should use binary names
In-Reply-To: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
References: <0UPtq4IIEofnn52UmreqpdFoFt1Fi5onBSP0LEavGdI=.ebe00815-b59b-455a-8b6c-61d09e69418a@github.com>
Message-ID: <eaM4w5nbQ7IFgB01VluwDT2f1y4hlm50VYNSRO7uEi4=.45763a5f-da71-44a9-aab0-e264491a03a9@github.com>

On Wed, 20 Aug 2025 15:37:09 GMT, altrisi <duke at openjdk.org> wrote:

> This PR makes TOOLING.jsh's `javap` function support anonymous, local and built-in nested classes.
> 
> Note that nested classes created in jshell would previously work, but not JDK ones as they'd miss the is built-in check (wrong name for `Class.forName`) and later throw an exception because of a null classloader.
> 
> The rest of classes would fail the canonical name check, which wouldn't allow them to be disassembled.
> 
> This change makes them work by changing the check from canonicalName != null to specific checks for unsupported types of classes, and doing Class.forName using the result of getName(), not the canonical name, for the built-in check.

This pull request has now been integrated.

Changeset: e916ce8c
Author:    altrisi <altrisi.trillosierra at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e916ce8ce9af906cf86f1801fcb43e08f8188665
Stats:     32 lines in 2 files changed: 28 ins; 1 del; 3 mod

8365878: jshell TOOLING's javap should use binary names

Reviewed-by: liach, cstein

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

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

From prr at openjdk.org  Fri Aug 22 17:20:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 17:20:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

I don't agree.
If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

I am also questioning whether such a time out was demonstrated for this test.
I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
I can send you my query off-line so you can check it. Maybe it is incomplete.

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

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

From naoto at openjdk.org  Fri Aug 22 17:53:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Aug 2025 17:53:04 GMT
Subject: Integrated: 8361613: System.console() should only be available for
 interactive terminal
In-Reply-To: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
Message-ID: <r_95_t4wZ_a_KI8Ilwj56xPEZ4IaW_o5FwZDNl_zfKc=.3579fcbf-6036-437f-8942-f9de9bd804f8@github.com>

On Fri, 11 Jul 2025 18:46:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: ae0dac43
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae0dac43c09377c87e9b0452618a5b32c8568150
Stats:     566 lines in 12 files changed: 223 ins; 237 del; 106 mod

8361613: System.console() should only be available for interactive terminal

Reviewed-by: jlahoda, smarks, alanb

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

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

From naoto at openjdk.org  Fri Aug 22 17:53:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Aug 2025 17:53:03 GMT
Subject: RFR: 8361613: System.console() should only be available for
 interactive terminal [v3]
In-Reply-To: <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
References: <v-yKxsyIuH5tW0kSc3RTn2o2nAwgWAcGlOkny4-nSSM=.d698ff44-bf0f-40ed-801e-5dc00d6e5d99@github.com>
 <b5pWZ3i9NMGU4rLu-mlxvq_tzhzo022LHrER9z9d5e4=.27d447ba-83b5-4b54-b997-b7b4ae4d87ae@github.com>
Message-ID: <R40FmBIBFV48CzQTELeTdzm-uie3OikROe7pqqIoVJ0=.30ab59ae-15ab-4d7c-955c-e54abf97deb6@github.com>

On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> In prior JDK releases, `System.console()` could return a `Console` instance even when the JVM was not attached to an interactive terminal. This could lead to confusion, particularly when input was not from a keyboard or output was redirected, such as to or from a file or pipe, especially when using methods like `readPassword()`. Starting with JDK 25, the default behavior has changed: `System.console()` now returns `null` if standard input and/or output is redirected. However, if a JLine-based Console implementation is explicitly specified via the system property `-Djdk.console=jdk.internal.le`, the previous behavior may still occur.
>> This PR aims to align the behavior of the JLine-based `Console` implementation with the default `System.console()` behavior. The actual code change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the changes are adjustments to test cases to reflect the updated behavior. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26273#issuecomment-3215147434

From ayang at openjdk.org  Fri Aug 22 18:45:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 18:45:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> or don't do it.

Adding `/timeout=480` is more or less don't do anything.

The default timeout (if omitting `/timeout=...`) is 120, so:

master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

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

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

From alanb at openjdk.org  Sun Aug 24 09:58:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 24 Aug 2025 09:58:52 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
 <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
Message-ID: <VveE9LwNHbACMKjKW97dxBek0d1JtVSmaLzxJ1d_gKg=.ebe2da86-b1c5-4ca5-890b-693ddbb1dac7@github.com>

On Fri, 22 Aug 2025 18:43:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
>> 
>> I don't agree.
>> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
>> 
>> I am also questioning whether such a time out was demonstrated for this test.
>> I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
>> I can send you my query off-line so you can check it. Maybe it is incomplete.
>
>> or don't do it.
> 
> Adding `/timeout=480` is more or less don't do anything.
> 
> The default timeout (if omitting `/timeout=...`) is 120, so:
> 
> master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
> patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

There are several comments in this PR pointing out again and again that adding "/timeout=480" doesn't change anything with the new proposed default timeout and timeoutFactor. I was initially puzzled as to why these were being added to a lot of tests but I think Leo's runs with a timeoutFactor of 0.7 explains it. If the timeoutFactor is reduced then we risk timeouts from tests that are run close to the limit today. The method used to find these tests seems reasonable. So I think the approach is good and we should try to help him get this change integrated to avoid needing to keep it up to date while tests change in main line.

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

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

From dholmes at openjdk.org  Sun Aug 24 22:54:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 24 Aug 2025 22:54:03 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>

On Fri, 22 Aug 2025 15:41:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
> 
>> 34:  * @build jdk.test.whitebox.WhiteBox
>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
> 
> Why not `480` in this case?

Leo also states in the description:

> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

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

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

From jlahoda at openjdk.org  Mon Aug 25 07:18:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 25 Aug 2025 07:18:57 GMT
Subject: Integrated: 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: <gvykKdaSelXoMnel6p4WpcdP5lWWUe_qu1QF2DYrzTM=.33201352-a012-48c1-a54b-24cd94b7f706@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).

This pull request has now been integrated.

Changeset: d99fb09a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d99fb09a20df2639af23d1083afd14247abb991e
Stats:     13 lines in 2 files changed: 11 ins; 0 del; 2 mod

8359497: IllegalArgumentException thrown by SourceCodeAnalysisImpl.highlights()

Reviewed-by: vromero

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

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

From lkorinth at openjdk.org  Mon Aug 25 10:52:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:01 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>
Message-ID: <AFdpOMl_1ooSkxayT06rLAB2YAqOdpOVArSwLFhr5RI=.9ad37969-d90c-44e8-8839-2efb60f9f0a0@github.com>

On Sun, 24 Aug 2025 22:51:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
>> 
>>> 34:  * @build jdk.test.whitebox.WhiteBox
>>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
>> 
>> Why not `480` in this case?
>
> Leo also states in the description:
> 
>> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

In a few places, I have got timeouts after adjusting the timeout value. This is most likely because I have used a timeout factor of 0.7 to minimise "flickering" behaviour before finally changing to a timeout factor of 1. One consequence of this is that a few test cases will have double the original timeout (those test that would not pass a reduction to 0.7). So in all the instances when the timeout factor is exactly two times the size, the reason is that I have realised that I have already adjusted the timeout and I do not want to quad it again.

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

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

From lkorinth at openjdk.org  Mon Aug 25 10:52:09 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 10:52:09 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <vSDcN6CwSbjugZPSWSankLFy31FA2rVoSuJidKO-yLQ=.e2955c07-efad-498c-9606-cb9ab46ed327@github.com>

On Fri, 22 Aug 2025 15:44:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:
> 
>> 38:  * @requires vm.cds
>> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
>> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses
> 
> I was expecting `500 * 4 = 2000`, instead of `8000` here.

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:
> 
>> 58:  * @comment skip running this test on 32 bit VM
>> 59:  * @requires vm.bits == "64"
>> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:
> 
>> 32:  * @build com.foobar.Utils
>> 33:  *        com.bar.*
>> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

> test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:
> 
>> 47:  * @library /test/lib /test/jdk
>> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
>> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription
> 
> Why not `480`?

This is another instance of ([double after quad ](https://github.com/openjdk/jdk/pull/26749#discussion_r2297765975)).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297768577
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773391
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297773648
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2297774209

From lkorinth at openjdk.org  Mon Aug 25 11:04:00 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:04:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <nlwJNUKGatY6Irnw2NlsOMfSpPv_kE_dY8mY_cggDy8=.5136bc97-670f-4b23-bbf5-6277ddd7de3d@github.com>

On Fri, 22 Aug 2025 16:06:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:
> 
>> 36: class HangingRemoteAgent extends RemoteExecutionControl {
>> 37: 
>> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> why not `Utils.TIMEOUT_FACTOR`?

There are a few places where I have changed java files that are not jtreg tests themself. The code is used by a jtreg test, but is not the "entry" into a test. Those files have no way to specify `@library` annotations, as no "test annotations" are parsed. It is a pity that a jtreg "library" can not specify dependencies to other "libraries".

> test/langtools/jdk/jshell/UITesting.java line 148:
> 
>> 146:     }
>> 147: 
>> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));
> 
> Why not `Utils.TIMEOUT_FACTOR`?

[see above](https://github.com/openjdk/jdk/pull/26749#discussion_r2297800775)

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

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

From lkorinth at openjdk.org  Mon Aug 25 11:19:53 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:19:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <cORbSIzlWv8wgHca57OZ7Mm1wGDOGrYFEoUvNKLjcU0=.00ee4953-8c94-4812-89a5-f710dbe570d1@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

I am awaiting Oracle internal feedback if you wonder why I have still not updated copyright and integrated.  Target date for integration is second of September.

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

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

From lkorinth at openjdk.org  Mon Aug 25 11:43:54 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 25 Aug 2025 11:43:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>

On Fri, 22 Aug 2025 15:55:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:
> 
>> 57: public class DGCDeadLock implements Runnable {
>> 58:     final static public int HOLD_TARGET_TIME = 25000;
>> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);
> 
> Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4).

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

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

From ayang at openjdk.org  Mon Aug 25 13:50:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 25 Aug 2025 13:50:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
 <OrUszFbCpRlysBX8qVV7WF_Zx7Yli6voniXFlh_Zl9s=.a83cd99b-d003-4e8c-99bf-6cedfef51226@github.com>
Message-ID: <plR6IBqt_CP-kbXrzVRQ-ZHQcmVAxFFHDkeXOA-fM5M=.0facc4e4-3564-42d5-978e-8173723f8d07@github.com>

On Mon, 25 Aug 2025 11:40:56 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> while not multiplying a 10x factor with four resulting in a 40x factor.

Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000)  * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO.

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

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

From darcy at openjdk.org  Tue Aug 26 01:57:34 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 26 Aug 2025 01:57:34 GMT
Subject: RFR: 8365689: Elements.getFileObjectOf fails with a
 NullPointerException when an erroneous Element is passed in
In-Reply-To: <vzDmf4lCyd3nLj79OHJu_LiFxiV8NaUwhKVWr2pz7bw=.d63a68fe-760c-4de8-b564-800dca2f212f@github.com>
References: <vzDmf4lCyd3nLj79OHJu_LiFxiV8NaUwhKVWr2pz7bw=.d63a68fe-760c-4de8-b564-800dca2f212f@github.com>
Message-ID: <UZEEJmUFtVEeuOZt9r3WVTZ-V7KBwTV7qtOfyNN1RDQ=.397eee42-1b26-4ce9-a23c-9d3e42a4b42d@github.com>

On Tue, 19 Aug 2025 07:35:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> If an erroneous/unresolvable `Element` is passed to `Elements.getFileObjectOf`, it fails with an NPE like:
> 
> Caused by: java.lang.NullPointerException: Cannot read field "classfile" because the return value of "com.sun.tools.javac.code.Symbol.enclClass()" is null
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getFileObjectOf(JavacElements.java:803)
> at TestFileObjectOf$PrintFiles.handleDeclaration(TestFileObjectOf.java:329)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2718)
> 
> 
> The reason is the `Symbol.enclClass()` will return `null` for the erroneous `Element`. The proposed solution herein is to return `null` for erroneous/unresolvable `Element`s.

The updated behavior is consistent with the specification of the method.

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

PR Comment: https://git.openjdk.org/jdk/pull/26836#issuecomment-3222287944

From darcy at openjdk.org  Tue Aug 26 02:00:36 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 26 Aug 2025 02:00:36 GMT
Subject: RFR: 8365689: Elements.getFileObjectOf fails with a
 NullPointerException when an erroneous Element is passed in
In-Reply-To: <vzDmf4lCyd3nLj79OHJu_LiFxiV8NaUwhKVWr2pz7bw=.d63a68fe-760c-4de8-b564-800dca2f212f@github.com>
References: <vzDmf4lCyd3nLj79OHJu_LiFxiV8NaUwhKVWr2pz7bw=.d63a68fe-760c-4de8-b564-800dca2f212f@github.com>
Message-ID: <scPR6VuOZEcO6pqLETt8fl6YSVJwpcsJK3yzKqNOLII=.983db751-cb2f-49ca-8a96-afb934995b3a@github.com>

On Tue, 19 Aug 2025 07:35:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> If an erroneous/unresolvable `Element` is passed to `Elements.getFileObjectOf`, it fails with an NPE like:
> 
> Caused by: java.lang.NullPointerException: Cannot read field "classfile" because the return value of "com.sun.tools.javac.code.Symbol.enclClass()" is null
> at jdk.compiler/com.sun.tools.javac.model.JavacElements.getFileObjectOf(JavacElements.java:803)
> at TestFileObjectOf$PrintFiles.handleDeclaration(TestFileObjectOf.java:329)
> at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2718)
> 
> 
> The reason is the `Symbol.enclClass()` will return `null` for the erroneous `Element`. The proposed solution herein is to return `null` for erroneous/unresolvable `Element`s.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26836#pullrequestreview-3153577025

From asotona at openjdk.org  Tue Aug 26 12:06:39 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Aug 2025 12:06:39 GMT
Subject: RFR: 8177650: JShell tool: packages in classpath don't appear in
 completions [v3]
In-Reply-To: <FSx-BVzGU_Uvjcx0Bhx0AugDLyXOmfBqTz7ZAUXtLPk=.cbd88d51-4e90-4bda-b0c6-06be7da160ed@github.com>
References: <UFeNCm6oJg8l6tOyvY0kFAZbkXM_SSGRiYCSnz-jY3U=.2bb4af49-276e-40cb-9685-e51151055209@github.com>
 <FSx-BVzGU_Uvjcx0Bhx0AugDLyXOmfBqTz7ZAUXtLPk=.cbd88d51-4e90-4bda-b0c6-06be7da160ed@github.com>
Message-ID: <CiOzQkqtp5O2bWvuW8rYaQA4BHifL3VpkLWPeu3ldSA=.f83135ba-f963-4a26-882a-da786848f18a@github.com>

On Thu, 14 Aug 2025 08:31:08 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 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

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26137#pullrequestreview-3155330016

From cstein at openjdk.org  Tue Aug 26 14:44:29 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 26 Aug 2025 14:44:29 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v3]
In-Reply-To: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
Message-ID: <z7DScwjz2IqprdOifMQdM2IXKhV22kMDaEXw5v4raHM=.fa14cb05-e6b5-4502-830b-14f361042598@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
 - 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
 - 8361950: Set required version to 8+2
 - 8361950: Update to use jtreg 8

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

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

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

  Stats: 79727 lines in 2045 files changed: 46139 ins; 24474 del; 9114 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  Tue Aug 26 15:16:39 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 26 Aug 2025 15:16:39 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v3]
In-Reply-To: <z7DScwjz2IqprdOifMQdM2IXKhV22kMDaEXw5v4raHM=.fa14cb05-e6b5-4502-830b-14f361042598@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <z7DScwjz2IqprdOifMQdM2IXKhV22kMDaEXw5v4raHM=.fa14cb05-e6b5-4502-830b-14f361042598@github.com>
Message-ID: <xxn-RV5wCLWvRRm8DdELWD2UCYb5ds_RUfGTwEamts0=.5068622a-5d2a-431c-98c0-a8625b957d5b@github.com>

On Tue, 26 Aug 2025 14:44:29 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - 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
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

test/jdk/java/security/SignedJar/spi-calendar-provider/TestSPISigned.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2025, Red Hat, Inc.

Restore original line and insert an additional one.

Suggestion:

 * Copyright (c) 2022, Red Hat, Inc.
 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2301330477

From mdonovan at openjdk.org  Tue Aug 26 17:08:38 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 26 Aug 2025 17:08:38 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/sun/security/krb5/name/Constructors.java line 28:

> 26:  * @summary Make PrincipalName and Realm immutable
> 27:  * @modules java.security.jgss/sun.security.krb5
> 28:  * @run main/othervm Constructors

Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

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

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

From shade at openjdk.org  Thu Aug 28 11:49:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Aug 2025 11:49:46 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package
In-Reply-To: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
References: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
Message-ID: <xAbWYdvBURkQtz-DcW8Ep0ZUj68BAidTm7kbu0GlHsU=.efdd4752-ff4f-4524-9802-6dd5561ed048@github.com>

On Mon, 18 Aug 2025 08:18:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> In JDK 8, the package `jdk.net` was exported and part of `rt.jar`, and hence should have been part of the historical data for `--release`, but it is not. The primary goal of this PR is to add historical data for `jdk.net` for JDK 8.
> 
> The changes herein are based on JDK 8u462. I used the Probe running on JDK 8 to dump the classfiles, along these lines:
> 
> $ java -classpath .../make/langtools/src/classes/ build.tools.symbolgenerator.Probe /tmp/jdk8-classfiles
> 
> 
> and then the up-to-date `CreateSymbols` to generate the `sym.txt` files, along these lines:
> 
> java --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED  CreateSymbols.java build-description-incremental-file .../src/jdk.compiler/share/data/symbols/symbols .../src/jdk.compiler/share/data/symbols/include.list 8 /tmp/jdk8-classfiles '<none>' --normalize-method-flags
> 
> 
> There are a few APIs that have been added for this release, and a few representational changes.
> 
> Most notably - the ordering of "removal" entries (i.e. those that start with `-`) and "add" entries is much more strict in the current `CreateSymbols`, and so there are some changes where the removal entries are moved to the front. I went through those, and they seem OK to me.
> 
> I'll add specific comments to the other updates to the files.

(not an expert in this area at all, drive-by review)

Feels a bit awkward that lines jump within the single file, looks like the order is not stable? Can it be stabilized, or would it incur even more change in the symbol files?

test/langtools/tools/javac/sym/ElementStructureTest.java line 518:

> 516:                 out.write(Float.toHexString((Float) value));
> 517:             } else {
> 518:                 if (value instanceof Character ch && Character.isSurrogate(ch)) {

Looks like one would want to match the style, and of `else if`, joining the if-chain above?

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

PR Review: https://git.openjdk.org/jdk/pull/26817#pullrequestreview-3164479947
PR Review Comment: https://git.openjdk.org/jdk/pull/26817#discussion_r2307129846

From jlahoda at openjdk.org  Thu Aug 28 12:32:43 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Aug 2025 12:32:43 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package
In-Reply-To: <xAbWYdvBURkQtz-DcW8Ep0ZUj68BAidTm7kbu0GlHsU=.efdd4752-ff4f-4524-9802-6dd5561ed048@github.com>
References: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
 <xAbWYdvBURkQtz-DcW8Ep0ZUj68BAidTm7kbu0GlHsU=.efdd4752-ff4f-4524-9802-6dd5561ed048@github.com>
Message-ID: <2fs7XwVJtXduN0ofpA94xJkHEfRigNazkGve1pbNu7U=.0e3d1d91-b4fa-4ab0-94f0-6b045e42f954@github.com>

On Thu, 28 Aug 2025 11:47:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> (not an expert in this area at all, drive-by review)
> 
> Feels a bit awkward that lines jump within the single file, looks like the order is not stable? Can it be stabilized, or would it incur even more change in the symbol files?

The problem is that these files are generated by a version of the tool that (lets say) more lenient in ordering. More specifically, it was willing to mix removals and additions, as long as the order of removals and additions for the same signature was correct (i.e. first removal and then addition). At some point, I think, it was causing unwelcome diffs, so we changed the tool to first do all removals, and then all additions. But, we didn't update existing files, as that would be unnecessary churn.

I.e., I'm afraid there are not too many sensible options.

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

PR Comment: https://git.openjdk.org/jdk/pull/26817#issuecomment-3233308409

From lkorinth at openjdk.org  Thu Aug 28 13:05:51 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:05:51 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <EJdxiot32oUpUVtRSTMTXFSFI9pOkmb17vwLGEKmuK0=.a14f9df8-b05a-4a59-a5c0-039070d059ff@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> > @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
> 
> I don't agree. If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
> 
> I am also questioning whether such a time out was demonstrated for this test. I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test. I can send you my query off-line so you can check it. Maybe it is incomplete.

I will revert this change. Thanks for finding it. I think the timeout was found in a local run with a timeout factor of 0.5 and a local fix to "CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE". CI history tells me that the run time of the test is stable and that we have a margin.

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

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

From lkorinth at openjdk.org  Thu Aug 28 13:12:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <mygrl66-jtLOCitZE1y7w005QUUFmtZ0QDWPO5FD8pQ=.9558b892-2b3a-4c1e-b898-51b86d61beb0@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 two additional commits since the last revision:

 - revert added timeout, it is not needed
 - feedback from Mark Sheppard

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/f24a1e72..365454d2

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

  Stats: 62 lines in 41 files changed: 3 ins; 0 del; 59 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  Thu Aug 28 13:12:46 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 28 Aug 2025 13:12:46 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <O2hQ5ow7drkJOD-QiVkoDFa9ChZmv3WEOTqLgH3r8lQ=.b12f1c30-cfe8-4797-a964-67429193f9d9@github.com>

On Wed, 20 Aug 2025 17:05:59 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:
> 
>   update testing.md, remove makefile link, fix bad text

I have added some updates. I will try to merge latest, update copyrights and run tests over the weekend.

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

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

From jlahoda at openjdk.org  Thu Aug 28 14:04:02 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 28 Aug 2025 14:04:02 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package [v2]
In-Reply-To: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
References: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
Message-ID: <okAWRqRcBInT0JbuQX28sfahxxrVnmyAtmr91fnPQUw=.f0eb4fd6-99d5-47a7-8327-dd52b833cf58@github.com>

> In JDK 8, the package `jdk.net` was exported and part of `rt.jar`, and hence should have been part of the historical data for `--release`, but it is not. The primary goal of this PR is to add historical data for `jdk.net` for JDK 8.
> 
> The changes herein are based on JDK 8u462. I used the Probe running on JDK 8 to dump the classfiles, along these lines:
> 
> $ java -classpath .../make/langtools/src/classes/ build.tools.symbolgenerator.Probe /tmp/jdk8-classfiles
> 
> 
> and then the up-to-date `CreateSymbols` to generate the `sym.txt` files, along these lines:
> 
> java --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED  CreateSymbols.java build-description-incremental-file .../src/jdk.compiler/share/data/symbols/symbols .../src/jdk.compiler/share/data/symbols/include.list 8 /tmp/jdk8-classfiles '<none>' --normalize-method-flags
> 
> 
> There are a few APIs that have been added for this release, and a few representational changes.
> 
> Most notably - the ordering of "removal" entries (i.e. those that start with `-`) and "add" entries is much more strict in the current `CreateSymbols`, and so there are some changes where the removal entries are moved to the front. I went through those, and they seem OK to me.
> 
> I'll add specific comments to the other updates to the files.

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

  Adjusting formatting as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26817/files
  - new: https://git.openjdk.org/jdk/pull/26817/files/2fb1fd8f..8b718cdd

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

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

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

From shade at openjdk.org  Thu Aug 28 15:30:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Aug 2025 15:30:44 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package [v2]
In-Reply-To: <2fs7XwVJtXduN0ofpA94xJkHEfRigNazkGve1pbNu7U=.0e3d1d91-b4fa-4ab0-94f0-6b045e42f954@github.com>
References: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
 <xAbWYdvBURkQtz-DcW8Ep0ZUj68BAidTm7kbu0GlHsU=.efdd4752-ff4f-4524-9802-6dd5561ed048@github.com>
 <2fs7XwVJtXduN0ofpA94xJkHEfRigNazkGve1pbNu7U=.0e3d1d91-b4fa-4ab0-94f0-6b045e42f954@github.com>
Message-ID: <Qrp02r_3Itz1NAW3IHEvGI_yL7hUDW6PEq4__By72kk=.3036b207-044d-472e-8ed4-1870cbb4d95c@github.com>

On Thu, 28 Aug 2025 12:29:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I.e., I'm afraid there are not too many sensible options.

Yeah. Just checking if anything easy was on the table, because this patch is going to be backported to at least some LTSes. I tried to `patch --dry-run` the current diff, and this was the result:
 - JDK 25u: Applies cleanly
  - JDK 21u: Applies with minor conflicts in `src/jdk.compiler/share/data/symbols/symbols` and `test/langtools/tools/javac/sym/ElementStructureTest.java`
 - JDK 17u: All the hunks fail, because [JDK-8257733](https://bugs.openjdk.org/browse/JDK-8257733) moved stuff around
 - JDK 11u: Have not tried, I assume it is at least as bad as JDK 17u

So "superfluous" changes in `data/symbols` do not look like the practical problem, AFAICS.

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

PR Comment: https://git.openjdk.org/jdk/pull/26817#issuecomment-3233974430

From shade at openjdk.org  Thu Aug 28 16:44:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Aug 2025 16:44:44 GMT
Subject: RFR: 8365060: Historical data for JDK 8 should include the jdk.net
 package [v2]
In-Reply-To: <okAWRqRcBInT0JbuQX28sfahxxrVnmyAtmr91fnPQUw=.f0eb4fd6-99d5-47a7-8327-dd52b833cf58@github.com>
References: <7EA7TV3a3aPdhvDV0Jd1zD_xHqUNVakc2KtgQ62_C_c=.7136a250-dfaf-454d-aa13-3499addd6762@github.com>
 <okAWRqRcBInT0JbuQX28sfahxxrVnmyAtmr91fnPQUw=.f0eb4fd6-99d5-47a7-8327-dd52b833cf58@github.com>
Message-ID: <_Xa90K7Q3B1T7Ivs_lNTSocjAIT2-Fmvm05ePOBAKgA=.cfaa9f40-90cb-4a5d-8263-eb1cf6b6aaa8@github.com>

On Thu, 28 Aug 2025 14:04:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> In JDK 8, the package `jdk.net` was exported and part of `rt.jar`, and hence should have been part of the historical data for `--release`, but it is not. The primary goal of this PR is to add historical data for `jdk.net` for JDK 8.
>> 
>> The changes herein are based on JDK 8u462. I used the Probe running on JDK 8 to dump the classfiles, along these lines:
>> 
>> $ java -classpath .../make/langtools/src/classes/ build.tools.symbolgenerator.Probe /tmp/jdk8-classfiles
>> 
>> 
>> and then the up-to-date `CreateSymbols` to generate the `sym.txt` files, along these lines:
>> 
>> java --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED  CreateSymbols.java build-description-incremental-file .../src/jdk.compiler/share/data/symbols/symbols .../src/jdk.compiler/share/data/symbols/include.list 8 /tmp/jdk8-classfiles '<none>' --normalize-method-flags
>> 
>> 
>> There are a few APIs that have been added for this release, and a few representational changes.
>> 
>> Most notably - the ordering of "removal" entries (i.e. those that start with `-`) and "add" entries is much more strict in the current `CreateSymbols`, and so there are some changes where the removal entries are moved to the front. I went through those, and they seem OK to me.
>> 
>> I'll add specific comments to the other updates to the files.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting formatting as suggested.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26817#pullrequestreview-3165680733

From liach at openjdk.org  Thu Aug 28 17:39:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Aug 2025 17:39:53 GMT
Subject: RFR: 8366264: tools/javac/launcher/SourceLauncherStackTraceTest.java
 does not cover the scenario for 8362237
Message-ID: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>

In #26601, I moved a test case to create a traceless exception for the source launcher that depended on C2 behaviors to a separate test with compiler flags. However, that move is incorrect: to reproduce the issue, the cause exception must have no trace while the InvocationTargetException does. My migrated test blindly turned off stack traces for all exceptions, which is not the intended scenario.

I found that in Java 7, Throwable, Exception, Error, and RuntimeException get new constructors that allow specifying suppression and trace filling behaviors. We can use that constructor to prohibit stack traces for the cause while preserving the trace for the InvocationTargetException.

Testing: Running the single source file on Java 24 and getting the AIOOBE (ensure it is a valid reproducer), and running the test to ensure the new case passes.

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

Commit messages:
 - 8366264: tools/javac/launcher/SourceLauncherStackTraceTest.java does not cover the scenario for 8362237

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

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

From cstein at openjdk.org  Fri Aug 29 08:06:42 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 29 Aug 2025 08:06:42 GMT
Subject: RFR: 8366264:
 tools/javac/launcher/SourceLauncherStackTraceTest.java does not cover the
 scenario for 8362237
In-Reply-To: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
References: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
Message-ID: <q2X12NOhbeFLm9p6U7k2AZLzYUv2SO3wfVNCPL2mkIs=.24321525-1ef0-4c07-b3b2-24c1baf37437@github.com>

On Thu, 28 Aug 2025 17:34:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #26601, I moved a test case to create a traceless exception for the source launcher that depended on C2 behaviors to a separate test with compiler flags. However, that move is incorrect: to reproduce the issue, the cause exception must have no trace while the InvocationTargetException does. My migrated test blindly turned off stack traces for all exceptions, which is not the intended scenario.
> 
> I found that in Java 7, Throwable, Exception, Error, and RuntimeException get new constructors that allow specifying suppression and trace filling behaviors. We can use that constructor to prohibit stack traces for the cause while preserving the trace for the InvocationTargetException.
> 
> Testing: Running the single source file on Java 24 and getting the array copy IAE (ensure it is a valid reproducer), and running the test to ensure the new case passes.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26993#pullrequestreview-3167793035

From lkorinth at openjdk.org  Fri Aug 29 14:41:48 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 14:41:48 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v6]
In-Reply-To: <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <QGduFIVDL1GhGaPhP8KkFjowyEYbUP8FALCUil62La4=.a0da78f8-d9c5-48b9-a054-6649997d3f71@github.com>
Message-ID: <U44eId1pfiGjDkIlPM5vo-4Y_Oq-QdjIdCTFbD5O94E=.0f31a90c-9106-4cf5-a50f-4e7551eb14ff@github.com>

On Tue, 26 Aug 2025 17:06:08 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert added timeout, it is not needed
>>  - feedback from Mark Sheppard
>
> test/jdk/sun/security/krb5/name/Constructors.java line 28:
> 
>> 26:  * @summary Make PrincipalName and Realm immutable
>> 27:  * @modules java.security.jgss/sun.security.krb5
>> 28:  * @run main/othervm Constructors
> 
> Do you know why this test needs the change? It's not doing much (no blocking calls) and on my system runs in about a tenth of a second.

I have not analysed why. I can see 1013 occurrences in our test history where the test takes 2 minutes or more. On different CPU platforms.

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

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

From jlahoda at openjdk.org  Fri Aug 29 18:26:40 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 29 Aug 2025 18:26:40 GMT
Subject: RFR: 8366264:
 tools/javac/launcher/SourceLauncherStackTraceTest.java does not cover the
 scenario for 8362237
In-Reply-To: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
References: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
Message-ID: <w_vyV_dYMxSkuZXp8qCPeddzQ02-de6TSewRWp_b6-o=.e9aa908d-4b98-4491-841a-eaa23d4907a9@github.com>

On Thu, 28 Aug 2025 17:34:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #26601, I moved a test case to create a traceless exception for the source launcher that depended on C2 behaviors to a separate test with compiler flags. However, that move is incorrect: to reproduce the issue, the cause exception must have no trace while the InvocationTargetException does. My migrated test blindly turned off stack traces for all exceptions, which is not the intended scenario.
> 
> I found that in Java 7, Throwable, Exception, Error, and RuntimeException get new constructors that allow specifying suppression and trace filling behaviors. We can use that constructor to prohibit stack traces for the cause while preserving the trace for the InvocationTargetException.
> 
> Testing: Running the single source file on Java 24 and getting the array copy IAE (ensure it is a valid reproducer), and running the test to ensure the new case passes.

Looks sensible to me. Please be sure to run tests before integrating.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26993#pullrequestreview-3169666463

From matsaave at openjdk.org  Fri Aug 29 18:46:48 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 29 Aug 2025 18:46:48 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v3]
In-Reply-To: <z7DScwjz2IqprdOifMQdM2IXKhV22kMDaEXw5v4raHM=.fa14cb05-e6b5-4502-830b-14f361042598@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <z7DScwjz2IqprdOifMQdM2IXKhV22kMDaEXw5v4raHM=.fa14cb05-e6b5-4502-830b-14f361042598@github.com>
Message-ID: <B6laPuStn_vifGSu59efTIt8rxfIr6oiBSehgOMrsy4=.94529b8c-ad4d-4deb-b801-15e5abeac366@github.com>

On Tue, 26 Aug 2025 14:44:29 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8
>  - 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
>  - 8361950: Set required version to 8+2
>  - 8361950: Update to use jtreg 8

Is there an ETA for integration? There are new tests for Valhalla that are disabled because they rely on some of the new features in JTREG 8. We are working to reinforce testing and are really looking forward to this patch so we can merge it from mainline to lworld.

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

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

From lkorinth at openjdk.org  Fri Aug 29 18:45:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 29 Aug 2025 18:45:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v7]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <2IfOGWu0Kfw8qdRmYLkMEdF5kvlC5lcuc-USAovOTFM=.f6d2a6c9-160d-478e-aa5c-1086b40e52bd@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:

  update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/365454d2..4b33904a

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

  Stats: 233 lines in 233 files changed: 0 ins; 0 del; 233 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 liach at openjdk.org  Fri Aug 29 19:16:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 29 Aug 2025 19:16:43 GMT
Subject: RFR: 8366264:
 tools/javac/launcher/SourceLauncherStackTraceTest.java does not cover the
 scenario for 8362237
In-Reply-To: <w_vyV_dYMxSkuZXp8qCPeddzQ02-de6TSewRWp_b6-o=.e9aa908d-4b98-4491-841a-eaa23d4907a9@github.com>
References: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
 <w_vyV_dYMxSkuZXp8qCPeddzQ02-de6TSewRWp_b6-o=.e9aa908d-4b98-4491-841a-eaa23d4907a9@github.com>
Message-ID: <EHZQboMVHq4S3eNOFLeCwM2qw2T-fk-bIVwRjhPF5f8=.ec013b1d-0c00-4967-a143-2805498b5068@github.com>

On Fri, 29 Aug 2025 18:23:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>Please be sure to run tests before integrating.

Is there any test I should run besides the `tools/javac/launcher/SourceLauncherTest.java`?

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

PR Comment: https://git.openjdk.org/jdk/pull/26993#issuecomment-3237968536

From liach at openjdk.org  Sat Aug 30 00:44:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 30 Aug 2025 00:44:21 GMT
Subject: RFR: 8365676: javac incorrectly allows calling interface static method
 via type variable
Message-ID: <x0Vq5K27bz-wj0sKw9q88epmDdTD9B-ocrruiDtU3c4=.a18d6742-8922-402c-bcb5-4cec440d96ef@github.com>

The interface static methods added in Java 8 are never inherited in method resolution. However, javac incorrectly allowed them to be resolved against type variables with an interface as its only upper bound, which violates JLS 4.9:

> The members of an intersection type are the members of the class or interface it induces.

Combined with JLS 4.4:

> The members of a type variable X with bound T & I1 & ... & In are the members of the intersection type ([?4.9](https://docs.oracle.com/javase/specs/jls/se24/html/jls-4.html#jls-4.9)) T & I1 & ... & In appearing at the point where the type variable is declared

Last time this piece of code in Attr was updated was around Java 7, so this was probably missed in Java 8.

The test cases added showcases wrong ways to refer to interface static methods: `Collator`, a subtype of `Comparator`, cannot use `reverseOrder`, so shouldn't type variable `T` bounded by `Comparator<Integer>` be able to do so.

In addition, the error for private member access on type variables should probably have been symbol not found instead of access errors - we might revisit that later. I made the new error symbol not found for parity with interface static reference on classes, as showcased in the compiler output in this new test.

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

Commit messages:
 - 8365676: javac incorrectly allows calling interface static method via type variable

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

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

From cstein at openjdk.org  Sat Aug 30 05:30:43 2025
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 30 Aug 2025 05:30:43 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v3]
In-Reply-To: <B6laPuStn_vifGSu59efTIt8rxfIr6oiBSehgOMrsy4=.94529b8c-ad4d-4deb-b801-15e5abeac366@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <z7DScwjz2IqprdOifMQdM2IXKhV22kMDaEXw5v4raHM=.fa14cb05-e6b5-4502-830b-14f361042598@github.com>
 <B6laPuStn_vifGSu59efTIt8rxfIr6oiBSehgOMrsy4=.94529b8c-ad4d-4deb-b801-15e5abeac366@github.com>
Message-ID: <zTDx7F-vu3G-Aq9i8voP_9EBqXMmxoVaXtzW_NtYnPw=.2382765d-d107-44aa-bd69-49af0f1d8231@github.com>

On Fri, 29 Aug 2025 18:44:04 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Is there an ETA for integration?

On September, 1st.

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

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

From liach at openjdk.org  Sat Aug 30 14:06:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 30 Aug 2025 14:06:46 GMT
Subject: RFR: 8366264:
 tools/javac/launcher/SourceLauncherStackTraceTest.java does not cover the
 scenario for 8362237
In-Reply-To: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
References: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
Message-ID: <d3bTxQbiUXho1qybAg8wlJU0Cl5SuN5qJp8Ir9s3pYw=.e08f3517-de74-4356-be80-2f73adfcd545@github.com>

On Thu, 28 Aug 2025 17:34:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #26601, I moved a test case to create a traceless exception for the source launcher that depended on C2 behaviors to a separate test with compiler flags. However, that move is incorrect: to reproduce the issue, the cause exception must have no trace while the InvocationTargetException does. My migrated test blindly turned off stack traces for all exceptions, which is not the intended scenario.
> 
> I found that in Java 7, Throwable, Exception, Error, and RuntimeException get new constructors that allow specifying suppression and trace filling behaviors. We can use that constructor to prohibit stack traces for the cause while preserving the trace for the InvocationTargetException.
> 
> Testing: Running the single source file on Java 24 and getting the array copy IAE (ensure it is a valid reproducer), and running the test to ensure the new case passes.

Since I cannot think of other tests to run and the revised SourceLauncherTest passes on CI against 26 build 13, I think we are fine. Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26993#issuecomment-3239286389

From liach at openjdk.org  Sat Aug 30 14:06:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 30 Aug 2025 14:06:46 GMT
Subject: Integrated: 8366264:
 tools/javac/launcher/SourceLauncherStackTraceTest.java does not cover the
 scenario for 8362237
In-Reply-To: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
References: <PDJBj-9VFE_H5LfZzzQWELqV8vwKh9axq5o2X2lSEHk=.3fafbf3e-d107-42e7-b99e-b7e2b1fc2ac6@github.com>
Message-ID: <yvuVdrtdaX_GH9pUh2dl3l2lKrRkbv4wgPO5sdqtIb4=.20e292e2-98e5-4f1b-9196-4255049dbe0d@github.com>

On Thu, 28 Aug 2025 17:34:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #26601, I moved a test case to create a traceless exception for the source launcher that depended on C2 behaviors to a separate test with compiler flags. However, that move is incorrect: to reproduce the issue, the cause exception must have no trace while the InvocationTargetException does. My migrated test blindly turned off stack traces for all exceptions, which is not the intended scenario.
> 
> I found that in Java 7, Throwable, Exception, Error, and RuntimeException get new constructors that allow specifying suppression and trace filling behaviors. We can use that constructor to prohibit stack traces for the cause while preserving the trace for the InvocationTargetException.
> 
> Testing: Running the single source file on Java 24 and getting the array copy IAE (ensure it is a valid reproducer), and running the test to ensure the new case passes.

This pull request has now been integrated.

Changeset: 0e739931
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e7399318b6c33c03a72ed1fdfb671f8cd9342a3
Stats:     108 lines in 2 files changed: 24 ins; 84 del; 0 mod

8366264: tools/javac/launcher/SourceLauncherStackTraceTest.java does not cover the scenario for 8362237

Reviewed-by: cstein, jlahoda

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

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

From alanb at openjdk.org  Sat Aug 30 15:15:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Aug 2025 15:15:42 GMT
Subject: RFR: 8361950: Update to use jtreg 8 [v3]
In-Reply-To: <zTDx7F-vu3G-Aq9i8voP_9EBqXMmxoVaXtzW_NtYnPw=.2382765d-d107-44aa-bd69-49af0f1d8231@github.com>
References: <JCK6WEz9s0f6a0LllzB9ax0t71Hex7Au2Kli2NPG3hQ=.32459968-5598-494c-90b2-f12438309a90@github.com>
 <z7DScwjz2IqprdOifMQdM2IXKhV22kMDaEXw5v4raHM=.fa14cb05-e6b5-4502-830b-14f361042598@github.com>
 <B6laPuStn_vifGSu59efTIt8rxfIr6oiBSehgOMrsy4=.94529b8c-ad4d-4deb-b801-15e5abeac366@github.com>
 <zTDx7F-vu3G-Aq9i8voP_9EBqXMmxoVaXtzW_NtYnPw=.2382765d-d107-44aa-bd69-49af0f1d8231@github.com>
Message-ID: <Xay4E8uXOKV6RwY0YSQrQNOoAlCCn1YMUm846t2tbw4=.57eef424-7dbf-4367-a5ad-de9c6fbbe1a8@github.com>

On Sat, 30 Aug 2025 05:27:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> > Is there an ETA for integration?
> 
> On September, 1st.

I had a brief discussion with Christian about maybe holding off until the TIMEOUT_FACTOR changes (pull/26749) is integrated.

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

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

From acobbs at openjdk.org  Sun Aug 31 22:55:44 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 31 Aug 2025 22:55:44 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: <fSDU-d6gKtVHWrwwT9qDGHkQjKLk7BClNiW2S9BXnbg=.f3860cac-fd08-433b-b3c4-aea35144a08f@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.

The only change that should be visible is in the case of a `final var` lambda parameter, e.g.:

Consumer<String> c = (final var testVar) -> {};

Before: the `JCVariableDecl` for `testVar` starts at `var`
After: the `JCVariableDecl` for `testVar` starts at `final`

But note that change is just making the lambda case consistent with how all these other cases already behave:

(a) final var testVar = 0;
(b) switch (x) { case Rec(final var testVar) -> {} }
(c) for (final var testVar : List.of(0, 1)) {}

Before: the `JCVariableDecl` for `testVar` starts at `final`
After: the `JCVariableDecl` for `testVar` starts at `final`

So I think this is really just a bug fix rather than a behavioral change.

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

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