From jlahoda at openjdk.org  Thu May  1 07:45:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 07:45:55 GMT
Subject: Integrated: 8344708: Implement JEP 511: Module Import Declarations
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <gYaNiDs5PL4NDmpOy9etPHh86GsmJWu_Z_QkubL-OXI=.998a58dc-7470-4204-8f89-23bba1191d55@github.com>

On Wed, 26 Feb 2025 13:50:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

This pull request has now been integrated.

Changeset: 0a697f6f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a697f6ff4c2f8254e95519e04708cf406009dc3
Stats:     484 lines in 32 files changed: 268 ins; 136 del; 80 mod

8344708: Implement JEP 511: Module Import Declarations

Reviewed-by: mcimadamore, vromero, alanb

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

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

From duke at openjdk.org  Thu May  1 09:55:49 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 1 May 2025 09:55:49 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
Message-ID: <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>

On Sun, 27 Apr 2025 14:23:50 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> I misunderstood that I have tested `stdin.encoding`.
>> I cannot confirm that `stdin.encoding` is changed in Windows to proper ones because it has not been included in the latest EA build (20) and I cannot build master for Windows. However, it is changed to `US-ASCII` in Ubuntu when I change `LANG`. I will believe its author until the latest EA build is updated.
>
> Anyway you need to merge master first to test `stdin.encoding`.

`stdin.encoding` seems to work as intended in Windows for Japanese. No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070108439

From weijun at openjdk.org  Thu May  1 14:50:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 May 2025 14:50:31 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>

> Finalize the KDF API.

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

 - merge
 - add a positive debug log and update exception message
 - enhancing exception messages and debug outputs
 - update @since tags as required by JEP 12
 - add enum back
 - the change

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

Changes: https://git.openjdk.org/jdk/pull/24520/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24520&range=04
  Stats: 206 lines in 17 files changed: 158 ins; 29 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24520.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24520/head:pull/24520

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

From vromero at openjdk.org  Thu May  1 15:33:47 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 15:33:47 GMT
Subject: RFR: 8354908: javac mishandles supplementary character in
 character literal
In-Reply-To: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
References: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
Message-ID: <K4FZLoEi4IntOA0EZdFLvEYqPlVueTzGo50pRZn-fG0=.173bb4cd-4543-40ba-8b6d-354c5a2db16d@github.com>

On Wed, 30 Apr 2025 13:05:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Some Unicode characters consist of two surrogates, i.e. two `char`s. And, such Unicode characters cannot be part of a char literal, as there's no way to represent them as a character literal. But, javac currently accepts code with such characters, and only puts the char, the high surrogate, into the literal, ignoring the second one.
> 
> For example, the JDK 24 behavior is:
> 
> $ cat /tmp/T.java 
> public class T {
>     public static void main(String... args) {
>        char c = '?';
>        System.err.println(Integer.toHexString((int) c));
>        System.err.println(Character.isHighSurrogate(c));
>     }
> }
> $ java /tmp/T.java
> d83d
> true
> 
> 
> But, in JDK 11, such literals have been rejected:
> 
> $ java /tmp/T.java
> /tmp/T.java:3: error: unclosed character literal
>        char c = '?';
>                 ^
> /tmp/T.java:3: error: illegal character: '\ude0a'
>        char c = '?';
>                   ^
> /tmp/T.java:3: error: unclosed character literal
>        char c = '?';
>                    ^
> 3 errors
> error: compilation failed
> 
> 
> The proposal in this PR is to explicitly check for this case when scanning character literal, and produce explicit error when a multi-surrogate character is used. javac will produce an error like:
> 
> $ java /tmp/T.java
> /tmp/T.java:3: error: character literal contains more than one UTF-16 code point
>        char c = '?';
>                 ^
> 1 error
> error: compilation failed

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24964#pullrequestreview-2810043824

From liach at openjdk.org  Thu May  1 15:06:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 15:06:05 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>

On Fri, 18 Apr 2025 00:06:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1:

> 1: /*

Need to add handling of `RequiresIdentity` in `createAnnotation`

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253:

> 4251: 
> 4252: # lint: identity
> 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\

How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049917728
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049921677

From vromero at openjdk.org  Thu May  1 15:06:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 15:06:06 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API
In-Reply-To: <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <k0YoPCbK1q_hpxN0e023-_Nk5rpvRjywcuthI9uzAPg=.82a77a31-ff44-413c-8596-da9b2da03f19@github.com>
Message-ID: <IolGhIMvxlSQSJ0b75BiQIMhywgGm3StuvVOCYOZMXU=.532de416-445c-4a29-bcb2-b8141f5c1056@github.com>

On Fri, 18 Apr 2025 02:32:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253:
> 
>> 4251: 
>> 4252: # lint: identity
>> 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\
> 
> How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint?

the requirement is for the identity lint warning to be an alias of the synchronization warning

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2053222093

From smarks at openjdk.org  Thu May  1 16:57:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 1 May 2025 16:57:53 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
Message-ID: <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>

On Thu, 1 May 2025 09:51:41 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Anyway you need to merge master first to test `stdin.encoding`.
>
> `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.

Hello @tats-u , there is no bother, I appreciate you looking at this.

The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.

Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.

In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070508985

From jlahoda at openjdk.org  Thu May  1 17:44:47 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 17:44:47 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v7]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <79mjbgCz8a1HC6r0_an5GwcY6lWssji50XWSoV1lrlM=.5fea494d-0bad-4e73-a482-090f47663302@github.com>

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

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

 - Merge branch 'master' into finalize-concise-source-files
 - Merge branch 'master' into finalize-concise-source-files
 - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
 - Add clause about handling of malformed/unmappable bytes.
 - Rewrite bits about charset decoding, removing mention of "internal objects."
 - Use local variable for System.out in print().
 - Reverting test commit.
   
   This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
 - Fixing tests.
 - Updating copyright year.
 - Adding bug number to tests.
 - ... and 28 more: https://git.openjdk.org/jdk/compare/6b553acb...3868019e

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

Changes: https://git.openjdk.org/jdk/pull/24438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=06
  Stats: 1060 lines in 59 files changed: 336 ins; 585 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

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

From naoto at openjdk.org  Thu May  1 17:44:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 May 2025 17:44:48 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
Message-ID: <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>

On Thu, 1 May 2025 16:55:06 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.
>
> Hello @tats-u , there is no bother, I appreciate you looking at this.
> 
> The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.
> 
> Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.
> 
> In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.

`InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070569424

From jlahoda at openjdk.org  Thu May  1 17:48:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 17:48:22 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

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

  Updating copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/3868019e..5d0a867f

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

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

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

From a.silichenko at gmail.com  Thu May  1 18:29:38 2025
From: a.silichenko at gmail.com (Oleksii Sylichenko)
Date: Thu, 1 May 2025 21:29:38 +0300
Subject: 8353489: Increase timeout and improve Windows compatibility in
 test/jdk/java/lang/ProcessBuilder/Basic.java
Message-ID: <CACLiAdj8WEFYsUMsnU491QRefS=OH4UhGKmGBnZ02_Rm_g3iWg@mail.gmail.com>

Please review this patch that improves stability of the
ProcessBuilder/Basic.java test on Windows:

- Increase Timeout
- Fix incompatibility with Windows (Cygwin vs. IntelliJ IDEA)
- Prevent Autorun Scripts in the `cmd /c set` Command

PR: https://github.com/openjdk/jdk/pull/23933

Best regards,
Oleksii Sylichenko

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250501/b7cfada8/attachment.htm>

From vromero at openjdk.org  Thu May  1 18:32:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 18:32:00 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
Message-ID: <m4Ee1G4zMqDSM8ftPnlnPGTAr4_iDT7jOQgGF8F1S34=.789aa973-ef26-41a8-8d3b-d2597f2b874c@github.com>

On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year.

last changes lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810409833

From liach at openjdk.org  Thu May  1 18:57:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 18:57:50 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
Message-ID: <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>

On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year.

src/java.base/share/classes/java/lang/IO.java line 157:

> 155:      * <p>
> 156:      * Writes a prompt as if by calling {@code print}, and then reads a single
> 157:      * line of text as if by calling {@link readln readln()}.

Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`.

src/java.base/share/classes/java/lang/IO.java line 179:

> 177:      * the reader() method.
> 178:      */
> 179:     static BufferedReader br;

The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070645283
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070647143

From duke at openjdk.org  Thu May  1 23:40:49 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 1 May 2025 23:40:49 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
 <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
Message-ID: <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>

On Thu, 1 May 2025 17:40:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @tats-u , there is no bother, I appreciate you looking at this.
>> 
>> The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.
>> 
>> Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.
>> 
>> In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.
>
> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
> As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.

In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. 
JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. 

One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader.

https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070927346

From vromero at openjdk.org  Thu May  1 15:06:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 15:06:04 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API
Message-ID: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>

This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.

For more details please refer to the complete description in the corresponding JIRA entry [1]

TIA

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

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

Commit messages:
 - final adjustments
 - additional refactorings
 - removing unneeded changes
 - more refactorings
 - more refactorings and tests
 - refactoring
 - refactoring
 - covering more cases plus refactoring in order to simplify the code
 - Merge branch 'JDK-8354556' of https://github.com/vicente-romero-oracle/jdk into JDK-8354556
 - additional coverage for other uses of types
 - ... and 11 more: https://git.openjdk.org/jdk/compare/4dd64b49...5e3acc92

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354556
  Stats: 495 lines in 25 files changed: 469 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

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

From duke at openjdk.org  Fri May  2 00:00:59 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Fri, 2 May 2025 00:00:59 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
 <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
 <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>
Message-ID: <dpz22BvUdBRhm09g40hJF6ErZ6YkGsVhe5onequrAE8=.1b58e1c7-342d-4694-99a6-fff46bdda61b@github.com>

On Thu, 1 May 2025 23:33:00 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
>> As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.
>
> In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. 
> JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. 
> 
> One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader.
> 
> https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418

I think we have only to change console encodings by e.g. `chcp 932` (CMD) or `[Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::Get Encoding(932)` (PowerShell) in Windows. They correspond to `GetConsoleCP` and `GetConsoleOutputCP`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070940588

From jlahoda at openjdk.org  Fri May  2 00:57:27 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 00:57:27 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v9]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

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

  Make br field private; tweaks to javadoc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/5d0a867f..9c095792

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

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

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

From liach at openjdk.org  Fri May  2 00:57:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 00:57:27 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v9]
In-Reply-To: <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>
Message-ID: <MmlwdH84URKZQSJ58wgMC8x2oa0K0dk-9fL2UVpd0Wg=.2816b649-b2bb-4755-a9e2-ca4d01079017@github.com>

On Fri, 2 May 2025 00:54:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make br field private; tweaks to javadoc.

Thanks for the update Stuart. Looks all good to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810991411

From smarks at openjdk.org  Fri May  2 00:57:28 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 May 2025 00:57:28 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
 <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>
Message-ID: <DwFCtgnc0mjxhkH-11NwxxcgJWF7oa4US8167hX8Lv4=.b2af64ee-55c2-43b1-b8a7-37ad05d2a67c@github.com>

On Thu, 1 May 2025 18:43:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright year.
>
> src/java.base/share/classes/java/lang/IO.java line 157:
> 
>> 155:      * <p>
>> 156:      * Writes a prompt as if by calling {@code print}, and then reads a single
>> 157:      * line of text as if by calling {@link readln readln()}.
> 
> Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`.

I added `#` prefixes. I had intended `readln()` to indicate that this referred to the no-arg overload of `readln()` but I think that's too subtle so I removed the parens. But one has to look at the link to determine that it refers to the no-arg readln and not the one-arg readln (which is this method). I also changed the `print` to a link as well.

> src/java.base/share/classes/java/lang/IO.java line 179:
> 
>> 177:      * the reader() method.
>> 178:      */
>> 179:     static BufferedReader br;
> 
> The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**.

Added a comment. Making it `private` doesn't really help, but I made it private anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070971289
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070970447

From jlahoda at openjdk.org  Fri May  2 06:13:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 06:13:57 GMT
Subject: Integrated: 8344706: Implement JEP 512: Compact Source Files and
 Instance Main Methods
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <7qJ1POdMGcRYtfcq6u1v6pcCu3MCfOFXoAZIyOf9IVA=.aeb8b7db-e8bf-4db9-9dcc-fd7f55549c39@github.com>

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

This pull request has now been integrated.

Changeset: d29700cc
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d29700cc80003d6baddb419f2974ab226478bacc
Stats:     1061 lines in 59 files changed: 336 ins; 585 del; 140 mod

8344706: Implement JEP 512: Compact Source Files and Instance Main Methods

Co-authored-by: Stuart Marks <smarks at openjdk.org>
Reviewed-by: liach, cstein, vromero, naoto

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

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

From jlahoda at openjdk.org  Fri May  2 11:42:27 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 11:42:27 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type variable
 bounds and type annotations for Object supertypes
Message-ID: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>

Consider code like:

import java.lang.annotation.*;

public class PrintingTest<T extends CharSequence> extends @TA Object {
}

@Target(ElementType.TYPE_USE)
@interface TA {}


when using `-Xprint` to print this code, javac produces this:

public class PrintingTest<T> {

  public PrintingTest();
}

@java.lang.annotation.Target({TYPE_USE})
@interface TA {
}


Note the type variable is missing the bound, and the annotated supertype is missing. This PR proposes to change that to:

public class PrintingTest<T extends java.lang.CharSequence> extends java.lang. at TA Object {

  public PrintingTest();
}

@java.lang.annotation.Target({TYPE_USE})
@interface TA {
}


Please also review the CSR:
https://bugs.openjdk.org/browse/JDK-8356058
and the release note:
https://bugs.openjdk.org/browse/JDK-8356062

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

Commit messages:
 - Adjusting test output.
 - Fixing type var bounds.
 - 8356057: PrintingProcessor (-Xprint) does not print type variable bounds and type annotations for Object supertypes

Changes: https://git.openjdk.org/jdk/pull/25002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356057
  Stats: 167 lines in 6 files changed: 146 ins; 2 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25002/head:pull/25002

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

From duke at openjdk.org  Fri May  2 12:06:49 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 2 May 2025 12:06:49 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
Message-ID: <hGvb-Sf4tz5ECqxEdvi4jAqx4RqKzeOHqZzzZwvf0M0=.4aa3eda2-7589-4aff-b7f5-502a58b53024@github.com>

On Tue, 29 Apr 2025 07:54:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Since when?

src/java.base/share/classes/java/lang/ScopedValue.java line 1:

> 1: /*

It?occurred to?me that?`ScopedValue.NEW_THREAD_BINDINGS` can?be?made package?private and?used in?`Thread`, removing?duplication in?`Thread.NEW_THREAD_BINDINGS`.

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

This?was?done this?way back?when `ScopedValue` lived?under the?`jdk.incubator.*` package?tree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2071516117

From vromero at openjdk.org  Fri May  2 12:14:46 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 12:14:46 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes
In-Reply-To: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
Message-ID: <p5dR5Rt7nPK3xZ0Vk1WTzKqdxkuqBsY7c2F2ZidE_Po=.2f6cb523-4794-416f-b15d-3b99d51896a5@github.com>

On Fri, 2 May 2025 11:37:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> import java.lang.annotation.*;
> 
> public class PrintingTest<T extends CharSequence> extends @TA Object {
> }
> 
> @Target(ElementType.TYPE_USE)
> @interface TA {}
> 
> 
> when using `-Xprint` to print this code, javac produces this:
> 
> public class PrintingTest<T> {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Note the type variable is missing the bound, and the annotated supertype is missing. This PR proposes to change that to:
> 
> public class PrintingTest<T extends java.lang.CharSequence> extends java.lang. at TA Object {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Please also review the CSR:
> https://bugs.openjdk.org/browse/JDK-8356058
> and the release note:
> https://bugs.openjdk.org/browse/JDK-8356062

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25002#pullrequestreview-2811866415

From alanb at openjdk.org  Fri May  2 12:37:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 May 2025 12:37:48 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <hGvb-Sf4tz5ECqxEdvi4jAqx4RqKzeOHqZzzZwvf0M0=.4aa3eda2-7589-4aff-b7f5-502a58b53024@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
 <hGvb-Sf4tz5ECqxEdvi4jAqx4RqKzeOHqZzzZwvf0M0=.4aa3eda2-7589-4aff-b7f5-502a58b53024@github.com>
Message-ID: <k2fLo6iAq4FK9NZC1PjIGn_f2nUGIfbKYj7tcMOnWDw=.e9c6acae-c23d-4bd7-bc74-861406f5f131@github.com>

On Fri, 2 May 2025 12:03:35 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Since when?
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 1:
> 
>> 1: /*
> 
> It?occurred to?me that?`ScopedValue.NEW_THREAD_BINDINGS` can?be?made package?private and?used in?`Thread`, removing?duplication in?`Thread.NEW_THREAD_BINDINGS`.
> 
> --------------------------------------------------------------------------------
> 
> This?was?done this?way back?when `ScopedValue` lived?under the?`jdk.incubator.*` package?tree.

I think it would be better not change that in this PR, as this PR is about making the feature permanent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2071550253

From mullan at openjdk.org  Fri May  2 12:56:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 2 May 2025 12:56:50 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
Message-ID: <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>

On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - merge
>  - add a positive debug log and update exception message
>  - enhancing exception messages and debug outputs
>  - update @since tags as required by JEP 12
>  - add enum back
>  - the change

src/java.base/share/classes/javax/crypto/KDF.java line 481:

> 479: 
> 480:     // Rethrows the IAPE thrown by an implementation, adding an explanation
> 481:     // on in which situation it fails.

suggest rewording as "for the situation in which it fails."

src/java.base/share/classes/javax/crypto/KDF.java line 491:

> 489:                     + "using the supplied derivation "
> 490:                     + "inputs, using the " + source + " "
> 491:                     + theOne.provider().getName()

Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071561925
PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071567362

From nbenalla at openjdk.org  Fri May  2 14:57:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 2 May 2025 14:57:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
Message-ID: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>

Get JDK 26 underway.

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

Commit messages:
 - Update copyright years
 - Update --release 25 symbol information for JDK 24 build 20
 - initial commit start-of-JDK-26

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355746
  Stats: 1193 lines in 54 files changed: 1100 ins; 16 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

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

From nbenalla at openjdk.org  Fri May  2 15:05:44 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 2 May 2025 15:05:44 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <yIUI0Q8Jj344JMFsnDM3poyk7UQZCSKS75SA5YFk6mU=.3e167b09-0df3-4ec9-bf45-6b10f73e0d35@github.com>

On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 26 underway.

This initial commit of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2847422764

From liach at openjdk.org  Fri May  2 15:49:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 15:49:52 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
Message-ID: <lqGuJD-sYxmMHpTuUTNegv_4FbWi11XYAhiH2Sv7zko=.93f8a437-f633-47bc-9f6b-24009d6fd234@github.com>

On Thu, 1 May 2025 14:50:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - merge
>  - add a positive debug log and update exception message
>  - enhancing exception messages and debug outputs
>  - update @since tags as required by JEP 12
>  - add enum back
>  - the change

The changes to finalize this preview feature look good. I did not review the extra security-specific changes in KDF.java and KDFDelayedProviderException.java.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2812347049

From liach at openjdk.org  Fri May  2 15:56:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 15:56:47 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>

On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 26 underway.

Changes requested by liach (Reviewer).

make/conf/version-numbers.conf line 36:

> 34: DEFAULT_VERSION_EXTRA2=0
> 35: DEFAULT_VERSION_EXTRA3=0
> 36: DEFAULT_VERSION_DATE=2026-03-16

Is this accurate?

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58:

> 56:  */
> 57: @SupportedAnnotationTypes("*")
> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26)

This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`.

test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229:

> 227:         // Check the class' major_version. This field is after the magic and minor_version fields, which
> 228:         // use 4 and 2 bytes respectively.
> 229:         if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) {

Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API.  Open a JBS issue and identify the hotspot tests failing without this change.

test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:

> 48: public class HelpOutputColumnWidthTest extends TestRunner {
> 49: 
> 50:     public static final int MAX_COLUMNS = 84;

What is this for?

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2812349246
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071811476
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071815767
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071819374
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071817584

From darcy at openjdk.org  Fri May  2 16:47:48 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 16:47:48 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
Message-ID: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>

On Fri, 2 May 2025 15:47:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> make/conf/version-numbers.conf line 36:
> 
>> 34: DEFAULT_VERSION_EXTRA2=0
>> 35: DEFAULT_VERSION_EXTRA3=0
>> 36: DEFAULT_VERSION_DATE=2026-03-16
> 
> Is this accurate?

One day off; should be 2026-03-17.

I should have double-checked that in the initial authoring of the change.

> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58:
> 
>> 56:  */
>> 57: @SupportedAnnotationTypes("*")
>> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26)
> 
> This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`.

The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation.

> test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229:
> 
>> 227:         // Check the class' major_version. This field is after the magic and minor_version fields, which
>> 228:         // use 4 and 2 bytes respectively.
>> 229:         if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) {
> 
> Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API.  Open a JBS issue and identify the hotspot tests failing without this change.

There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change.

> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
> 
>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>> 49: 
>> 50:     public static final int MAX_COLUMNS = 84;
> 
> What is this for?

It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26".

Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071878858
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071883440
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071881672
PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071880549

From alanb at openjdk.org  Fri May  2 16:47:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 May 2025 16:47:49 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
Message-ID: <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>

On Fri, 2 May 2025 16:43:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229:
>> 
>>> 227:         // Check the class' major_version. This field is after the magic and minor_version fields, which
>>> 228:         // use 4 and 2 bytes respectively.
>>> 229:         if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) {
>> 
>> Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API.  Open a JBS issue and identify the hotspot tests failing without this change.
>
> There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change.

Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071884496

From liach at openjdk.org  Fri May  2 16:58:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 16:58:49 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
Message-ID: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com>

On Fri, 2 May 2025 16:44:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58:
>> 
>>> 56:  */
>>> 57: @SupportedAnnotationTypes("*")
>>> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26)
>> 
>> This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`.
>
> The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation.

May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071896732

From liach at openjdk.org  Fri May  2 16:58:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 16:58:50 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
Message-ID: <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>

On Fri, 2 May 2025 16:45:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change.
>
> Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated.

I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release <N>` argument or migrate class file parsing to ClassFile API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071895599

From aph at openjdk.org  Fri May  2 17:04:05 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 2 May 2025 17:04:05 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v4]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <TxwU7dUbzzrLHiyTMBFC9u5KH8bbx_uayhggLPm5sck=.7e3d511b-c118-42ab-80be-5798cce4cc72@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unnecessary @since 25
 - Remove unnecessary @enablePreview in some tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/d3f2ff1f..8f626617

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

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

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

From darcy at openjdk.org  Fri May  2 17:21:50 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 17:21:50 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <J8LYjKyW-DOppkSZxTWcRYllmQ_WzAwgTxLTdkh9Z4g=.e0d18849-bb60-45ab-851b-d034a26fe6bd@github.com>
 <cc8J6tnifhUTh3SCu7VWsvJHc1afHMZeFQpNgqFF7Ew=.09f294a6-f5ac-4905-9868-17c4a174a123@github.com>
Message-ID: <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@github.com>

On Fri, 2 May 2025 16:54:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release <N>` argument or migrate class file parsing to ClassFile API.

Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071921145

From vromero at openjdk.org  Fri May  2 17:24:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 17:24:42 GMT
Subject: RFR: 8325859: potential information loss during type inference
Message-ID: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>

When an inference context (`IC`) is minimized, the minimized inference context (`MIC`) contains a proper subset of `IC's` inference vars (`IC_IV`). In other words there will be at least one inference variable `T` that belongs to `IC_IV` which doesn't belong to the minimized context inference variable's set (`MIC_IV`). MIC can be propagated to another inference context (AIC) as part of the type inference algo. If at any moment a type containing `T` needs, for example, to be instantiated `AIC` won't be able to perform that operation as it lacks the information to realize that `T` is a free variable it was supposed to know about hadn't a minimization step been performed. This PR is proposing to fix this issue without reducing the universe of inference contexts we apply the minimization algo to.

We are basically proposing to add a field to class InferenceContext which will be supplementary inference context that can be used to look for additional information if necessary. Also when registering a free type listener to an inference context, it could be that it won't be registered in the inference context the client could expect but in a supplementary inference context if it is found out that it contains and instantiation to all the free variables related to the listener. See also some comments inlined in the code,

TIA

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

Commit messages:
 - updating doc
 - 8325859: potential information loss during type inference

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

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

From darcy at openjdk.org  Fri May  2 17:46:58 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 17:46:58 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26
In-Reply-To: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
 <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com>
Message-ID: <Cnl_A-g8Rn37q28wvO9iSEhh_U8oEB6fy_o0ujJen4w=.d9ac811f-413e-4922-b402-792122673299@github.com>

On Fri, 2 May 2025 16:55:49 GMT, Chen Liang <liach at openjdk.org> wrote:

> May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates?

I know it is possible to write getSupportedSourceVersion to return the latest version, but I don't think it is appropriate for this annotation processor to use that idiom since it might actually need to be meaningfully updated with code changes to support the new source level. Explicitly needing to change this annotation is a backstop reminder to do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071949205

From vromero at openjdk.org  Fri May  2 18:03:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 18:03:50 GMT
Subject: RFR: 8325859: potential information loss during type inference
In-Reply-To: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
Message-ID: <iwHSG3I91WwX0QG4JhihK-cCjztRYY9JXsv660gVRwA=.297471bf-b231-4e13-a931-13dcc089dc22@github.com>

On Fri, 2 May 2025 17:18:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> When an inference context (`IC`) is minimized, the minimized inference context (`MIC`) contains a proper subset of `IC's` inference vars (`IC_IV`). In other words there will be at least one inference variable `T` that belongs to `IC_IV` which doesn't belong to the minimized context inference variable's set (`MIC_IV`). MIC can be propagated to another inference context (AIC) as part of the type inference algo. If at any moment a type containing `T` needs, for example, to be instantiated `AIC` won't be able to perform that operation as it lacks the information to realize that `T` is a free variable it was supposed to know about hadn't a minimization step been performed. This PR is proposing to fix this issue without reducing the universe of inference contexts we apply the minimization algo to.
> 
> We are basically proposing to add a field to class InferenceContext which will be supplementary inference context that can be used to look for additional information if necessary. Also when registering a free type listener to an inference context, it could be that it won't be registered in the inference context the client could expect but in a supplementary inference context if it is found out that it contains and instantiation to all the free variables related to the listener. See also some comments inlined in the code,
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 271:

> 269:         if (next != null) {
> 270:             HasTypeVars hasTypeVars = new HasTypeVars();
> 271:             while (next != null && hasTypeVars.visit(result)) {

I think that we should be fine just going for the next supplementaryIC instead of traversing the whole list here. Same for the process to add free listeners, but in the first version I preferred to err on the correctness / completeness side. If we decide to visit more than one chained supplementary IC we can still do some improvements to try to reduce the number of supplementary ICs visited to a minimum

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25011#discussion_r2071967520

From weijun at openjdk.org  Fri May  2 18:31:52 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 May 2025 18:31:52 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
 <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>
Message-ID: <gU8Het2pCRd7EcHGYwNW4laXpCAb1mbgPxrA-_HegwM=.7da4ac42-3343-4599-961f-a14024daf034@github.com>

On Fri, 2 May 2025 12:50:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - merge
>>  - add a positive debug log and update exception message
>>  - enhancing exception messages and debug outputs
>>  - update @since tags as required by JEP 12
>>  - add enum back
>>  - the change
>
> src/java.base/share/classes/javax/crypto/KDF.java line 491:
> 
>> 489:                     + "using the supplied derivation "
>> 490:                     + "inputs, using the " + source + " "
>> 491:                     + theOne.provider().getName()
> 
> Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider."

The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2071997676

From mullan at openjdk.org  Fri May  2 18:39:47 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 2 May 2025 18:39:47 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v5]
In-Reply-To: <gU8Het2pCRd7EcHGYwNW4laXpCAb1mbgPxrA-_HegwM=.7da4ac42-3343-4599-961f-a14024daf034@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <To8P9zSROG54ayME3D-98HIN0qqjfORNadZD8GA4R4I=.440e00b9-9f46-4b0a-ac0f-14612be358e2@github.com>
 <DP4G9gxUfBGeHKkeWaT3q8nCyBdvc-oWh6SoENgFNM4=.8a0c9e82-b3b9-47c8-96d4-853918c410ae@github.com>
 <gU8Het2pCRd7EcHGYwNW4laXpCAb1mbgPxrA-_HegwM=.7da4ac42-3343-4599-961f-a14024daf034@github.com>
Message-ID: <kDBE92WygZKrDPnp3eTuuFXzrw_PWt4M_qe1kZhhTuk=.aa69bfd7-eeb7-4b78-b1db-25080b0efb61@github.com>

On Fri, 2 May 2025 18:29:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/KDF.java line 491:
>> 
>>> 489:                     + "using the supplied derivation "
>>> 490:                     + "inputs, using the " + source + " "
>>> 491:                     + theOne.provider().getName()
>> 
>> Suggest rewording as: "inputs with the " + source + " " + theOne.provider().getName() + " provider."
>
> The exception message following uses `"The " + source + " provider " + theOne.provider.getName()`. Shall I also switch to `"The " + source + " " + theOne.provider.getName() + " provider"`?

Yes, good to make it consistent. I think it reads slightly better if the name of the provider comes before "provider".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2072005947

From weijun at openjdk.org  Fri May  2 18:49:34 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 May 2025 18:49:34 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>

> Finalize the KDF API.

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

  fine tuning debug log and exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24520/files
  - new: https://git.openjdk.org/jdk/pull/24520/files/323b046b..f44dc9bd

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

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

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

From vromero at openjdk.org  Fri May  2 19:06:05 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 19:06:05 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v2]
In-Reply-To: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
Message-ID: <SpeYd7GS1BvXcLkwUyJPcfrKDQV-nZBAcILvylrMdlA=.adb623d2-13d7-4b94-8f4d-48da94d547ea@github.com>

> When an inference context (`IC`) is minimized, the minimized inference context (`MIC`) contains a proper subset of `IC's` inference vars (`IC_IV`). In other words there will be at least one inference variable `T` that belongs to `IC_IV` which doesn't belong to the minimized context inference variable's set (`MIC_IV`). MIC can be propagated to another inference context (AIC) as part of the type inference algo. If at any moment a type containing `T` needs, for example, to be instantiated `AIC` won't be able to perform that operation as it lacks the information to realize that `T` is a free variable it was supposed to know about hadn't a minimization step been performed. This PR is proposing to fix this issue without reducing the universe of inference contexts we apply the minimization algo to.
> 
> We are basically proposing to add a field to class InferenceContext which will be supplementary inference context that can be used to look for additional information if necessary. Also when registering a free type listener to an inference context, it could be that it won't be registered in the inference context the client could expect but in a supplementary inference context if it is found out that it contains and instantiation to all the free variables related to the listener. See also some comments inlined in the code,
> 
> TIA

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

  make visitor static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25011/files
  - new: https://git.openjdk.org/jdk/pull/25011/files/21de35bc..25fc5ba3

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

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

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

From vromero at openjdk.org  Fri May  2 19:32:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 19:32:32 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v2]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <frPmWVlOlA4zMR8-VM118Mi39bODtoyzr4tu4Oglv0o=.5f1a2a9c-e98d-4672-9a21-2a3f7cb8deed@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

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

  updating test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/5e3acc92..1134ffee

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

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

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

From vromero at openjdk.org  Fri May  2 19:41:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 19:41:34 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v3]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <LTnhc1b0-PaFRZdk_1zLQYG_HaGOQVUE9aP_dCigMQE=.6a31e7b5-180f-48ad-989c-ac7f6db8885f@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

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

 - Merge branch 'master' into JDK-8354556
 - updating test
 - final adjustments
 - additional refactorings
 - removing unneeded changes
 - more refactorings
 - more refactorings and tests
 - refactoring
 - refactoring
 - covering more cases plus refactoring in order to simplify the code
 - ... and 13 more: https://git.openjdk.org/jdk/compare/60ba81d7...151908a2

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

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=02
  Stats: 494 lines in 25 files changed: 468 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

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

From vromero at openjdk.org  Fri May  2 19:44:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 19:44:31 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v4]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

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

  changes to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/151908a2..60f1f53b

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

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

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

From darcy at openjdk.org  Fri May  2 19:52:47 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 19:52:47 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes
In-Reply-To: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
Message-ID: <eqCe7uon20WM8qT1lkGHiCm2b3vVe-cpTJLYa5PKIjk=.b39d2d87-6eef-4f77-9858-2ea103699a43@github.com>

On Fri, 2 May 2025 11:37:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> import java.lang.annotation.*;
> 
> public class PrintingTest<T extends CharSequence> extends @TA Object {
> }
> 
> @Target(ElementType.TYPE_USE)
> @interface TA {}
> 
> 
> when using `-Xprint` to print this code, javac produces this:
> 
> public class PrintingTest<T> {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Note the type variable is missing the bound, and the annotated supertype is missing. This PR proposes to change that to:
> 
> public class PrintingTest<T extends java.lang.CharSequence> extends java.lang. at TA Object {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Please also review the CSR:
> https://bugs.openjdk.org/browse/JDK-8356058
> and the release note:
> https://bugs.openjdk.org/browse/JDK-8356062

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 536:

> 534:                     tpe.getBounds()
> 535:                        .stream()
> 536:                        .filter(type -> !isUnimportantObjectType(type))

Perhaps the changes would be easier to ready if the method as "isImportantObjectType()"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25002#discussion_r2072080138

From vromero at openjdk.org  Fri May  2 20:28:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 20:28:06 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
Message-ID: <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>

> When an inference context (`IC`) is minimized, the minimized inference context (`MIC`) contains a proper subset of `IC's` inference vars (`IC_IV`). In other words there will be at least one inference variable `T` that belongs to `IC_IV` which doesn't belong to the minimized context inference variable's set (`MIC_IV`). MIC can be propagated to another inference context (AIC) as part of the type inference algo. If at any moment a type containing `T` needs, for example, to be instantiated `AIC` won't be able to perform that operation as it lacks the information to realize that `T` is a free variable it was supposed to know about hadn't a minimization step been performed. This PR is proposing to fix this issue without reducing the universe of inference contexts we apply the minimization algo to.
> 
> We are basically proposing to add a field to class InferenceContext which will be supplementary inference context that can be used to look for additional information if necessary. Also when registering a free type listener to an inference context, it could be that it won't be registered in the inference context the client could expect but in a supplementary inference context if it is found out that it contains and instantiation to all the free variables related to the listener. See also some comments inlined in the code,
> 
> TIA

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

 - Merge branch 'master' into JDK-8325859
 - make visitor static
 - updating doc
 - 8325859: potential information loss during type inference

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25011/files
  - new: https://git.openjdk.org/jdk/pull/25011/files/25fc5ba3..66e457fe

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

  Stats: 60967 lines in 1626 files changed: 46015 ins; 9376 del; 5576 mod
  Patch: https://git.openjdk.org/jdk/pull/25011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25011/head:pull/25011

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

From vromero at openjdk.org  Fri May  2 20:46:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 20:46:52 GMT
Subject: Integrated: 8322810: Lambda expression types can't be classes
In-Reply-To: <JiKznnTYEFjL9cck6J9GGiNeGctIYzvogObtz_oDro0=.0e8f0099-37f4-4dc7-ad91-b344a4f2931c@github.com>
References: <JiKznnTYEFjL9cck6J9GGiNeGctIYzvogObtz_oDro0=.0e8f0099-37f4-4dc7-ad91-b344a4f2931c@github.com>
Message-ID: <5nGMLVfddMDt152-ZYYrQDeAPmlvqtP3mkzMlWEmDC4=.754d88c7-3dc8-4890-842e-bed054e2c7e5@github.com>

On Wed, 9 Apr 2025 14:03:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Currently javac is accepting code like:
> 
> 
> class Test {
>     void m() {
>         var r = (Test & Runnable) () -> System.out.println("Hello, World!");
>     }
> }
> 
> 
> according to: `4.9 Intersection Types` a notional interface can't be induced here as one of the components is a class different from `j.l.Object`
> 
> With this fix this code pattern will be rejected with a compiler error
> 
> TIA

This pull request has now been integrated.

Changeset: 56468c42
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56468c42bef8524e53a929dc2ae603cff05b55e3
Stats:     77 lines in 6 files changed: 71 ins; 3 del; 3 mod

8322810: Lambda expression types can't be classes

Reviewed-by: mcimadamore

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

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

From darcy at openjdk.org  Fri May  2 21:52:17 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 May 2025 21:52:17 GMT
Subject: RFR: 8356108: Update SourceVersion.RELEASE_25 description for JEPs 511
 and 512
Message-ID: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>

Expected update to keep the description of language evolution accurate.

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

Commit messages:
 - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512

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

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

From vromero at openjdk.org  Fri May  2 22:09:44 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 2 May 2025 22:09:44 GMT
Subject: RFR: 8356108: Update SourceVersion.RELEASE_25 description for JEPs
 511 and 512
In-Reply-To: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
References: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
Message-ID: <wibWRdHAAh3h-Z6CVSCfGYzq_hrQzE_DB3kqB0hPhls=.3c3bd9ae-e6c0-4282-8973-2283463f4868@github.com>

On Fri, 2 May 2025 21:47:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Expected update to keep the description of language evolution accurate.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25015#pullrequestreview-2812981510

From liach at openjdk.org  Fri May  2 22:27:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 22:27:47 GMT
Subject: RFR: 8356108: Update SourceVersion.RELEASE_25 description for JEPs
 511 and 512
In-Reply-To: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
References: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
Message-ID: <z6gz5s1qFcXzLbKUciiN5kzvBZ90HDCORummOEx0xEY=.cad79f84-ef8f-4f2e-8255-4d77fe2f32e2@github.com>

On Fri, 2 May 2025 21:47:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Expected update to keep the description of language evolution accurate.

test/langtools/tools/javac/versions/Versions.java line 411:

> 409:              """
> 410:              import module java.base;
> 411:              public class New25 {

Should we make this a simple source file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25015#discussion_r2072207378

From darcy at openjdk.org  Sat May  3 00:33:46 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 May 2025 00:33:46 GMT
Subject: RFR: 8356108: Update SourceVersion.RELEASE_25 description for JEPs
 511 and 512
In-Reply-To: <z6gz5s1qFcXzLbKUciiN5kzvBZ90HDCORummOEx0xEY=.cad79f84-ef8f-4f2e-8255-4d77fe2f32e2@github.com>
References: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
 <z6gz5s1qFcXzLbKUciiN5kzvBZ90HDCORummOEx0xEY=.cad79f84-ef8f-4f2e-8255-4d77fe2f32e2@github.com>
Message-ID: <8viYh45RTj18c1kMplhKGIvLT1opQmeV3ld26aqQgtM=.97ac988d-cf5c-4771-961d-69fd21e1bbcd@github.com>

On Fri, 2 May 2025 22:24:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should we make this a simple source file?

That isn't necessary.

The purpose of this Versions.java test is focused on making sure setting --release has some effect for each release where a different source language is recognized. It is not attempting to be exhaustive that each new-in-release-N feature is accepted/rejected at appropriate source levels.

Per `javac` regression test conventions, the tests associated with a given feature should include negative tests that a new language construct is rejected on at least one older source/release version.

This test is more of a backstop insurance policy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25015#discussion_r2072256954

From liach at openjdk.org  Sat May  3 00:44:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 May 2025 00:44:48 GMT
Subject: RFR: 8356108: Update SourceVersion.RELEASE_25 description for JEPs
 511 and 512
In-Reply-To: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
References: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
Message-ID: <osrzYY12GCA0fPKVOwJGQgBkxuAuOVpOEOoyUOB2vMI=.ae39e3b7-938c-4bcd-bb76-4b690c1e875f@github.com>

On Fri, 2 May 2025 21:47:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Expected update to keep the description of language evolution accurate.

lgtm, thanks!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25015#pullrequestreview-2813078720

From iris at openjdk.org  Sat May  3 00:54:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Sat, 3 May 2025 00:54:51 GMT
Subject: RFR: 8356108: Update SourceVersion.RELEASE_25 description for JEPs
 511 and 512
In-Reply-To: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
References: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
Message-ID: <SwxstCIoy8zJst8ShmrBUEuuyLNoRAIgqb0v_15HgsU=.3dcbf5bb-51b5-4c86-a36e-2d57c3163cf0@github.com>

On Fri, 2 May 2025 21:47:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Expected update to keep the description of language evolution accurate.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25015#pullrequestreview-2813082733

From liach at openjdk.org  Sat May  3 01:08:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 May 2025 01:08:17 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@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 four commits:

 - Don't need to update latestSupported later
   
 - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
 - Add advanced testing for different latestSupported
   
 - 8355536: Create version constants to model preview language and vm features

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=01
  Stats: 1266 lines in 6 files changed: 1124 ins; 83 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 duke at openjdk.org  Sun May  4 19:00:52 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 4 May 2025 19:00:52 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
Message-ID: <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>

On Sat, 3 May 2025 01:08:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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 four commits:
> 
>  - Don't need to update latestSupported later
>    
>  - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
>  - Add advanced testing for different latestSupported
>    
>  - 8355536: Create version constants to model preview language and vm features

src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413:

> 411:      * ensure the program is compatible with future Java SE releases.
> 412:      * <p>
> 413:      * This is a reflective preview API to allows tools running in Java runtime

Suggestion:

     * This is a reflective preview API that allows tools running in Java runtime

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 419:

> 417:      * @see <a href="https://openjdk.org/jeps/456">
> 418:      * JEP 456: Unnamed Variables &amp; Patterns</a>
> 419: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072682604
PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072683561

From liach at openjdk.org  Sun May  4 20:29:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 20:29:02 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v3]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <9iHgapUiP3vcKCr2JX3m0ZI0PjYe6OKnJvtL4ujo3oI=.97814213-5bd1-486b-bafc-743c2d5666d2@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 incrementally with one additional commit since the last revision:

  Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
  
  Co-authored-by: Luca Kellermann <lukellmann at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25017/files
  - new: https://git.openjdk.org/jdk/pull/25017/files/d0ff022f..0a3f3896

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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  Sun May  4 20:31:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 20:31:45 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
 <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
Message-ID: <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>

On Sun, 4 May 2025 18:46:02 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Don't need to update latestSupported later
>>    
>>  - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
>>  - Add advanced testing for different latestSupported
>>    
>>  - 8355536: Create version constants to model preview language and vm features
>
> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413:
> 
>> 411:      * ensure the program is compatible with future Java SE releases.
>> 412:      * <p>
>> 413:      * This is a reflective preview API to allows tools running in Java runtime
> 
> Suggestion:
> 
>      * This is a reflective preview API that allows tools running in Java runtime

Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072704486

From duke at openjdk.org  Sun May  4 20:35:53 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 4 May 2025 20:35:53 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
 <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
 <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>
Message-ID: <tMCXLFcvKrTglfRiJtmhS6mgqaQRi2K73S_5Z91R1eY=.23328ae5-0ddb-41d6-9835-7db41585eb6e@github.com>

On Sun, 4 May 2025 20:29:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 413:
>> 
>>> 411:      * ensure the program is compatible with future Java SE releases.
>>> 412:      * <p>
>>> 413:      * This is a reflective preview API to allows tools running in Java runtime
>> 
>> Suggestion:
>> 
>>      * This is a reflective preview API that allows tools running in Java runtime
>
> Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release.

It sounded wrong, maybe "to allow" (without 's') would be better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072705126

From liach at openjdk.org  Sun May  4 21:37:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 21:37:26 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v4]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <_MkrZWV7SnFd_3CgOvpa_gER0ie2syWXAEhvS47jHLs=.29f9f5a1-ab2f-4be3-8b5d-bb3184ab77ab@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 incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25017/files
  - new: https://git.openjdk.org/jdk/pull/25017/files/0a3f3896..c1a175ef

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Sun May  4 21:37:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 May 2025 21:37:26 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v2]
In-Reply-To: <tMCXLFcvKrTglfRiJtmhS6mgqaQRi2K73S_5Z91R1eY=.23328ae5-0ddb-41d6-9835-7db41585eb6e@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
 <83bvNuu_357BCWyRAyRx7rjbEh4NPFXKWwMG5nV_Rsc=.4245d1c7-126c-44de-bd0d-2aaec23acc06@github.com>
 <EH2EXKLz60ICZwd65amhBCbjwnzkhBNVxo_mPAAClCU=.7f0d6946-1a90-48be-be78-89ad74891e0f@github.com>
 <h8FFsOzJ32CxA2f6glePn42O1RGuFIb63tDVH5ZWNbI=.3cd7fea4-ad31-420e-89a3-ffe126aa3652@github.com>
 <tMCXLFcvKrTglfRiJtmhS6mgqaQRi2K73S_5Z91R1eY=.23328ae5-0ddb-41d6-9835-7db41585eb6e@github.com>
Message-ID: <ZHj0sC-CZ_W-3Q1yD_XXU39B09fzje9uvcyc1UiTtWE=.d4e7ebc2-2a13-4de1-8cab-9c3528e4de7a@github.com>

On Sun, 4 May 2025 20:33:36 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Don't know why you recommend this, but this aims to explain why this API is reflective preview API instead of an essential preview API (that does not have `reflective = true`). Particular tools wish to perform this specific check, like `javap`; otherwise, I would have marked this as non-reflective, and tools must resort to a third-party knowledge pool to parse preview features related to the current release.
>
> It sounded wrong, maybe "to allow" (without 's') would be better.

Suggestion:

     * This is a reflective preview API to allow tools running in Java runtime

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25017#discussion_r2072719721

From jlahoda at openjdk.org  Mon May  5 05:06:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 May 2025 05:06:52 GMT
Subject: Integrated: 8353565: Javac throws
 "inconsistent stack types at join point" exception
In-Reply-To: <CvrL5_T98AzLUCJ98SD0gyV-CW0W-Lq-HjTG1wfj6B4=.ecdb7427-c527-4d2b-8412-bd92f8b02d9d@github.com>
References: <CvrL5_T98AzLUCJ98SD0gyV-CW0W-Lq-HjTG1wfj6B4=.ecdb7427-c527-4d2b-8412-bd92f8b02d9d@github.com>
Message-ID: <Rxa3J1KFTXF9LppuNvIRJ9bV6diAK38jHqyVnhpKfqY=.6b63eac3-29a0-4a73-9f27-f7285642fc6b@github.com>

On Mon, 14 Apr 2025 08:34:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class T {
>     private Object computeTypeAtMergePoint1(int i) {
>         return (Object) switch (i) {
>             case 0 -> switch (i) {
>                 case 0 -> { yield new A(); }
>                 default -> { yield new B(); }
>             };
>             default -> switch (i) {
>                 case 0 -> { yield new C(); }
>                 default -> { yield new D(); }
>             };
>         };
>     }
>     enum E {A, B}
>     interface I1 {}
>     class A implements I1 {}
>     class B implements I1 {}
>     interface I2 {}
>     class C implements I2 {}
>     class D implements I2 {}
> 
> }
> 
> 
> Compiling this leads to a crash:
> 
> $ .../jdk-24/bin/javac  /tmp/T.java 
> An exception has occurred in the compiler (24-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: inconsistent stack types at join point
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.error(Code.java:1824)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code$State.join(Code.java:1814)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolve(Code.java:1525)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.resolvePending(Code.java:1556)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop(Code.java:382)
>         at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:511)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitReturn(Gen.java:1905)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1773)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:609)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:660)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.internalVisitBlock(Gen.java:1121)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1085)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1137)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:588)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:623)
>         at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(G...

This pull request has now been integrated.

Changeset: a5f4366a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5f4366a7f0b702b748fec9bcbcb95c522ff190b
Stats:     134 lines in 3 files changed: 120 ins; 7 del; 7 mod

8353565: Javac throws "inconsistent stack types at join point" exception

Reviewed-by: vromero, liach, mcimadamore

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

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

From jlahoda at openjdk.org  Mon May  5 09:12:45 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 May 2025 09:12:45 GMT
Subject: RFR: 8356108: Update SourceVersion.RELEASE_25 description for JEPs
 511 and 512
In-Reply-To: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
References: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
Message-ID: <PE2-BzBdR-IjjPLur8HWf_ZIbuR50V_GAUM86vSBtKg=.b2f41e33-40f0-4199-99bc-498c13db0dad@github.com>

On Fri, 2 May 2025 21:47:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Expected update to keep the description of language evolution accurate.

Looks good, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25015#pullrequestreview-2814232491

From abimpoudis at openjdk.org  Mon May  5 09:28:53 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 5 May 2025 09:28:53 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash
In-Reply-To: <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
Message-ID: <hwRJry55rIrw2KTV8Wael4xwPV537SY2NRLX7JZ8zXY=.1aa33e85-48ba-40cf-91cf-c5dfb2faa00f@github.com>

On Fri, 24 Jan 2025 18:43:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JEP 455 adds support for `switch`'ing on `long`, `float`, `double`, and `boolean`. Since this feature is still in preview, the `--enable-preview` flag is required. The compiler was properly checking that when the expressions had primitive type, but not when the expression a corresponding boxed type (i.e., `Long`, `Float`, `Double`, and `Boolean`). This resulted in `BootstrapMethodError` failures at runtime. This PR closes that loophole.
>
> I think the check needs to be on a different place - please see inline.

I had a look and I think what @lahodaj meant was something like this: https://github.com/biboudis/jdk/commit/f05394c9025f6a93d283e1bfe1a26ef83f5ca0b8

Instead of me creating a new PR, @archiecobbs you can reopen yours, merge here my commit above and rereview. What do you think? :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/23303#issuecomment-2850422390

From yzheng at openjdk.org  Mon May  5 09:42:47 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 5 May 2025 09:42:47 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v4]
In-Reply-To: <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>
Message-ID: <nFPBY8CGBTjDDuaRzSFXA1daX0DWp3dF7QXSZuOfSnE=.91545dc2-fec4-4a01-8d34-52e3e0efec98@github.com>

On Fri, 2 May 2025 19:44:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to test

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669:

> 667: 
> 668:     public boolean isValueBased() {
> 669:         return (tsym.flags_field & VALUE_BASED) != 0;

We have encountered a NPE in javac:

  java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null
  	at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669)
  	at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739)
  	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918)
  	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915)
...

It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073144717

From acobbs at openjdk.org  Mon May  5 13:35:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 5 May 2025 13:35:53 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash
In-Reply-To: <hwRJry55rIrw2KTV8Wael4xwPV537SY2NRLX7JZ8zXY=.1aa33e85-48ba-40cf-91cf-c5dfb2faa00f@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
 <hwRJry55rIrw2KTV8Wael4xwPV537SY2NRLX7JZ8zXY=.1aa33e85-48ba-40cf-91cf-c5dfb2faa00f@github.com>
Message-ID: <bxwDTWM_MQ8FPcl4CEyczE_OD36F9P2Jbohg2B_jZoo=.0db2708b-e139-400c-b489-a76387358f5c@github.com>

On Mon, 5 May 2025 09:26:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Instead of me creating a new PR, @archiecobbs you can reopen yours, merge here my commit above and rereview. What do you think? :-)

Sure, doing now...

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

PR Comment: https://git.openjdk.org/jdk/pull/23303#issuecomment-2851030284

From acobbs at openjdk.org  Mon May  5 13:52:17 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 5 May 2025 13:52:17 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v2]
In-Reply-To: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
Message-ID: <h02NErdO1-KZAT5QW-AGskMMiaaEyyIIldE1Ib3IdeQ=.9fb0106d-3215-495e-85f6-53f7137bf99b@github.com>

> JEP 455 adds support for `switch`'ing on `long`, `float`, `double`, and `boolean`. Since this feature is still in preview, the `--enable-preview` flag is required. The compiler was properly checking that when the expressions had primitive type, but not when the expression a corresponding boxed type (i.e., `Long`, `Float`, `Double`, and `Boolean`). This resulted in `BootstrapMethodError` failures at runtime. This PR closes that loophole.

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

 - Address review of #23303
 - Merge branch 'master' into JDK-8348410
 - Fix typo in regression test @summary lines.
 - Check preview enabled for switch on boxed Booleam, Long, Float, or Double.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23303/files
  - new: https://git.openjdk.org/jdk/pull/23303/files/bb8bfe9b..72b7804b

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

  Stats: 528417 lines in 7881 files changed: 196874 ins; 289588 del; 41955 mod
  Patch: https://git.openjdk.org/jdk/pull/23303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23303/head:pull/23303

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

From acobbs at openjdk.org  Mon May  5 13:54:50 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 5 May 2025 13:54:50 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v2]
In-Reply-To: <hwRJry55rIrw2KTV8Wael4xwPV537SY2NRLX7JZ8zXY=.1aa33e85-48ba-40cf-91cf-c5dfb2faa00f@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
 <hwRJry55rIrw2KTV8Wael4xwPV537SY2NRLX7JZ8zXY=.1aa33e85-48ba-40cf-91cf-c5dfb2faa00f@github.com>
Message-ID: <ObJrI5A1KTD3rT6qv6-mn3mXpu_H9_8_7ENluRwk6aM=.84d013d3-52eb-4a00-a638-513ef6f05673@github.com>

On Mon, 5 May 2025 09:26:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> I think the check needs to be on a different place - please see inline.
>
> I had a look and I think what @lahodaj meant was something like this: https://github.com/biboudis/jdk/commit/f05394c9025f6a93d283e1bfe1a26ef83f5ca0b8
> 
> Instead of me creating a new PR, @archiecobbs you can reopen yours, merge here my commit above and rereview. What do you think? :-)

@biboudis I've merged in your patch but currently can't verify anything due to build breakage ([JDK-8355561](https://bugs.openjdk.org/browse/JDK-8355561)).

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

PR Comment: https://git.openjdk.org/jdk/pull/23303#issuecomment-2851084479

From vromero at openjdk.org  Mon May  5 14:46:48 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 5 May 2025 14:46:48 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v4]
In-Reply-To: <nFPBY8CGBTjDDuaRzSFXA1daX0DWp3dF7QXSZuOfSnE=.91545dc2-fec4-4a01-8d34-52e3e0efec98@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QxFySn5mkqhFHBY2Px5kmxuMX2l1DNR6vgBaqSBbzH0=.d94d9b13-54af-41d3-a668-fc0c3795b99d@github.com>
 <nFPBY8CGBTjDDuaRzSFXA1daX0DWp3dF7QXSZuOfSnE=.91545dc2-fec4-4a01-8d34-52e3e0efec98@github.com>
Message-ID: <K31uA3N1-P6fLQbarJUBGqc7kPuH5SH7tnRGv--DQB0=.f6b3ff09-5efe-447a-a06f-2ff8a829a8a4@github.com>

On Mon, 5 May 2025 09:40:16 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes to test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669:
> 
>> 667: 
>> 668:     public boolean isValueBased() {
>> 669:         return (tsym.flags_field & VALUE_BASED) != 0;
> 
> We have encountered a NPE in javac:
> 
>   java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null
>   	at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669)
>   	at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739)
>   	at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918)
>   	at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915)
> ...
> 
> It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519

thanks for the report I will update the PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073595845

From jlahoda at openjdk.org  Mon May  5 15:02:34 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 May 2025 15:02:34 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v2]
In-Reply-To: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
Message-ID: <hg3vQZ_hi3LIDQuX3qsagev7-_uANOzXiGxFA_CDKsI=.2e7ed861-ec81-48e5-8a9f-285b332a66c3@github.com>

> Consider code like:
> 
> import java.lang.annotation.*;
> 
> public class PrintingTest<T extends CharSequence> extends @TA Object {
> }
> 
> @Target(ElementType.TYPE_USE)
> @interface TA {}
> 
> 
> when using `-Xprint` to print this code, javac produces this:
> 
> public class PrintingTest<T> {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Note the type variable is missing the bound, and the annotated supertype is missing. This PR proposes to change that to:
> 
> public class PrintingTest<T extends java.lang.CharSequence> extends java.lang. at TA Object {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Please also review the CSR:
> https://bugs.openjdk.org/browse/JDK-8356058
> and the release note:
> https://bugs.openjdk.org/browse/JDK-8356062

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

  Reflecting review feedback: using isImportantType instead of isUnimportantObjectType.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25002/files
  - new: https://git.openjdk.org/jdk/pull/25002/files/a9f7be23..e78e88a6

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

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

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

From jlahoda at openjdk.org  Mon May  5 15:02:34 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 May 2025 15:02:34 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v2]
In-Reply-To: <eqCe7uon20WM8qT1lkGHiCm2b3vVe-cpTJLYa5PKIjk=.b39d2d87-6eef-4f77-9858-2ea103699a43@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
 <eqCe7uon20WM8qT1lkGHiCm2b3vVe-cpTJLYa5PKIjk=.b39d2d87-6eef-4f77-9858-2ea103699a43@github.com>
Message-ID: <mr1FRh3JBd5UMt3i-ApkbbiEoPf1CvNmcjlbwXBgJ3M=.1fd228da-6017-4d15-a6e8-3f668e7c1c2d@github.com>

On Fri, 2 May 2025 19:49:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback: using isImportantType instead of isUnimportantObjectType.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 536:
> 
>> 534:                     tpe.getBounds()
>> 535:                        .stream()
>> 536:                        .filter(type -> !isUnimportantObjectType(type))
> 
> Perhaps the changes would be easier to ready if the method as "isImportantObjectType()"?

Thanks, done under:
https://github.com/openjdk/jdk/pull/25002/commits/e78e88a6a3f0967d12f3f19a989f5e8e033eb724

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25002#discussion_r2073621768

From jlahoda at openjdk.org  Mon May  5 15:15:04 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 May 2025 15:15:04 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v3]
In-Reply-To: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
Message-ID: <II3ZkCn0VhXEx_T3F9ZS0R_T95zlPJy5LIa12lwyq80=.30db897f-8325-4d15-a94b-37eaa592a392@github.com>

> Consider code like:
> 
> import java.lang.annotation.*;
> 
> public class PrintingTest<T extends CharSequence> extends @TA Object {
> }
> 
> @Target(ElementType.TYPE_USE)
> @interface TA {}
> 
> 
> when using `-Xprint` to print this code, javac produces this:
> 
> public class PrintingTest<T> {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Note the type variable is missing the bound, and the annotated supertype is missing. This PR proposes to change that to:
> 
> public class PrintingTest<T extends java.lang.CharSequence> extends java.lang. at TA Object {
> 
>   public PrintingTest();
> }
> 
> @java.lang.annotation.Target({TYPE_USE})
> @interface TA {
> }
> 
> 
> Please also review the CSR:
> https://bugs.openjdk.org/browse/JDK-8356058
> and the release note:
> https://bugs.openjdk.org/browse/JDK-8356062

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

  Enhancing the test with printing type variables on methods and constructors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25002/files
  - new: https://git.openjdk.org/jdk/pull/25002/files/e78e88a6..308d9f43

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

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

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

From darcy at openjdk.org  Mon May  5 15:44:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 May 2025 15:44:54 GMT
Subject: Integrated: 8356108: Update SourceVersion.RELEASE_25 description for
 JEPs 511 and 512
In-Reply-To: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
References: <bC-boUwjGFj4LWHezaCqkQ-6g_eNn4OAjjY6wvx9BGo=.47255490-322f-4ef6-bd3a-89be7c8891aa@github.com>
Message-ID: <siR6JYStZRoGXlroTExd-aqIkjj7PIaMPgrGwuP-I5g=.a72db96b-8d17-4bfd-9218-26238a9b38fd@github.com>

On Fri, 2 May 2025 21:47:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Expected update to keep the description of language evolution accurate.

This pull request has now been integrated.

Changeset: 6719b921
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6719b9214fb9c99da52e5d6c11f5d40b2aa73bd9
Stats:     19 lines in 2 files changed: 17 ins; 0 del; 2 mod

8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512

Reviewed-by: vromero, liach, iris, jlahoda

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

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

From liach at openjdk.org  Mon May  5 16:11:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 May 2025 16:11:23 GMT
Subject: RFR: 8355536: Create version constants to model preview language
 and vm features [v5]
In-Reply-To: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <_YoWvD7qNQzOVYH7nGma3s_D1k8Blh3D-AyUOqY7DxQ=.d7012548-d463-45aa-be82-5de8d89b2cb1@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 eight commits:

 - 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
   
 - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv
 - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512
 - Add advanced testing for different latestSupported
   
 - 8355536: Create version constants to model preview language and vm features

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

Changes: https://git.openjdk.org/jdk/pull/25017/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=04
  Stats: 1265 lines in 6 files changed: 1123 ins; 83 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 vromero at openjdk.org  Mon May  5 16:30:27 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 5 May 2025 16:30:27 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v5]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <hlQ_wxPVmRXC8jrCMazw0CCVRT2WcED6XzcXe3A2shc=.0633f497-b8fa-4372-9536-acff1794a322@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

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

  addressing review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/60f1f53b..ad7f617d

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

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

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

From lmesnik at openjdk.org  Mon May  5 17:36:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 5 May 2025 17:36:25 GMT
Subject: RFR: 8356193: Remove tests from ProblemList-enable-preview.txt fixed
 by JDK-8344706
Message-ID: <MdA9ObZQv019Y0FynO9LTvIwHnNpqFvXeaqM3GrHhcY=.4285be4d-d281-43c3-b089-88ea9b3fdc6a@github.com>

The JDK-8344706
is integrated and it is needed to remove corresponding tests from problemlists.
Verified that tests pass with --enable-preview.

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

Commit messages:
 - 8356193: Remove tests from ProblemList-enable-preview.txt fixed by JDK-8344706

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

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

From darcy at openjdk.org  Mon May  5 20:01:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 May 2025 20:01:51 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v3]
In-Reply-To: <II3ZkCn0VhXEx_T3F9ZS0R_T95zlPJy5LIa12lwyq80=.30db897f-8325-4d15-a94b-37eaa592a392@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
 <II3ZkCn0VhXEx_T3F9ZS0R_T95zlPJy5LIa12lwyq80=.30db897f-8325-4d15-a94b-37eaa592a392@github.com>
Message-ID: <VqqsPQu9HujHHcv7tpKkcza-I92Uf0QMK1VdlIUSwu4=.6d05ea28-fb4c-4d56-83ab-bd1a99163a90@github.com>

On Mon, 5 May 2025 15:15:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> import java.lang.annotation.*;
>> 
>> public class PrintingTest<T extends CharSequence> extends @TA Object {
>> }
>> 
>> @Target(ElementType.TYPE_USE)
>> @interface TA {}
>> 
>> 
>> when using `-Xprint` to print this code, javac produces this:
>> 
>> public class PrintingTest<T> {
>> 
>>   public PrintingTest();
>> }
>> 
>> @java.lang.annotation.Target({TYPE_USE})
>> @interface TA {
>> }
>> 
>> 
>> Note the type variable is missing the bound, and the annotated supertype is missing. This PR proposes to change that to:
>> 
>> public class PrintingTest<T extends java.lang.CharSequence> extends java.lang. at TA Object {
>> 
>>   public PrintingTest();
>> }
>> 
>> @java.lang.annotation.Target({TYPE_USE})
>> @interface TA {
>> }
>> 
>> 
>> Please also review the CSR:
>> https://bugs.openjdk.org/browse/JDK-8356058
>> and the release note:
>> https://bugs.openjdk.org/browse/JDK-8356062
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enhancing the test with printing type variables on methods and constructors.

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 796:

> 794:                 return true;
> 795:             }
> 796:             return e2.getSuperclass().getKind() != TypeKind.NONE;

I think it would be helpful to include some textual description of the intended semantics here including

"Omit the bound is unannotated java.lang.Object."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25002#discussion_r2074104883

From valeriep at openjdk.org  Mon May  5 20:07:52 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 5 May 2025 20:07:52 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
Message-ID: <ozCQCz3li3hlrxImPLyXO51QYRs13xcOHoxixP0XUJc=.a49fa122-bec8-4b62-8fbf-a65ebf91c737@github.com>

On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tuning debug log and exception message

test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8331008

Should we add 8353888 to all the tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074112296

From acobbs at openjdk.org  Mon May  5 20:43:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 5 May 2025 20:43:56 GMT
Subject: Integrated: 8352612: No way to add back lint categories after "none"
In-Reply-To: <J1PW7hpf9e7P7u6IglvsXe7XDdrfSwFFs9q7hH1Cido=.baa456d2-da5a-452e-8e6f-7421317aabf3@github.com>
References: <J1PW7hpf9e7P7u6IglvsXe7XDdrfSwFFs9q7hH1Cido=.baa456d2-da5a-452e-8e6f-7421317aabf3@github.com>
Message-ID: <bpp3o4IOgMCzr6_HmhxpB6r4Ah9HW-8EE8pp7X-le9w=.732ec538-f1c8-4708-8798-9d700c2b53a4@github.com>

On Tue, 25 Mar 2025 13:42:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR relates to the `-Xlint:none` flag. Currently, it not only disables all lint categories as one would expect, but it also disables all non-mandatory warnings, period. In other words, `-Xlint:none` has `-nowarn` as a hidden side-effect. So for example, trying to do `-Xlint:none,serial` to enable only the `serial` lint category is futile: the category will be enabled but the warnings won't ever appear. This PR removes that hidden side-effect, and also clarifies some of the help output.

This pull request has now been integrated.

Changeset: ca7e4c4e
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca7e4c4e055cf164b1b3707b7cf1ea72b1de77b9
Stats:     57 lines in 11 files changed: 22 ins; 7 del; 28 mod

8352612: No way to add back lint categories after "none"

Reviewed-by: mcimadamore

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

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

From weijun at openjdk.org  Mon May  5 21:03:48 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 5 May 2025 21:03:48 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <ozCQCz3li3hlrxImPLyXO51QYRs13xcOHoxixP0XUJc=.a49fa122-bec8-4b62-8fbf-a65ebf91c737@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
 <ozCQCz3li3hlrxImPLyXO51QYRs13xcOHoxixP0XUJc=.a49fa122-bec8-4b62-8fbf-a65ebf91c737@github.com>
Message-ID: <Cwl0AITUcvjG9XLxPBddevu4s7XkRCXLzaCvVbCxX_c=.b9664acd-2d83-4e1e-b0dc-f1aef2fd4558@github.com>

On Mon, 5 May 2025 20:04:46 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fine tuning debug log and exception message
>
> test/jdk/com/sun/crypto/provider/KDF/HKDFSaltIKMTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8331008
> 
> Should we add 8353888 to all the tests?

The Virtual Threads JEP didn't. https://github.com/openjdk/jdk/commit/2586f36120317cd206464b1e79d3906f711487cb#diff-35150e3bfd3304405ec403aa29cbea7aaa05c7bab3e28ac92e8162683114746a. I assume we don't either. Bug ids should match changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24520#discussion_r2074195043

From nbenalla at openjdk.org  Mon May  5 21:54:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 5 May 2025 21:54:55 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v3]
In-Reply-To: <0bqUaKnM69G9yJBLqrCdHjhLajH2Xt3sSYzpikjypsk=.12a13864-b736-4a90-b201-55fe4be2b14f@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
 <0bqUaKnM69G9yJBLqrCdHjhLajH2Xt3sSYzpikjypsk=.12a13864-b736-4a90-b201-55fe4be2b14f@github.com>
Message-ID: <F3WIX3lUaMGZRVnqTNrnxzQMOkgtPAE3Cu32p5TATTA=.1e938bc8-3f2f-4fb7-a01c-183423d8382a@github.com>

On Fri, 28 Mar 2025 01:59:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR to clarify the documentation of `Elements.overrides` through an `@apiNote`, this PR is essentially a doc-only change. This PR supersedes https://github.com/openjdk/jdk/pull/22244.
>> 
>> TIA.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - feedback: improve api note to convey more context
>  - Merge branch 'master' into elements-api-note
>  - whitespace
>  - Update according to review comments.
>  - Merge remote-tracking branch 'upstream/master' into elements-api-note
>  - Respond to feedback around the wording.
>  - Respond to feedback. Using Jan's comment to not imply particular requirement on the implementation.
>  - (C) 2025
>  - Initial commit obtained from a cherry pick/squash of a now superseded PR.

CSR request has been approved. Thank you all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22920#issuecomment-2852420205

From nbenalla at openjdk.org  Mon May  5 21:54:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 5 May 2025 21:54:57 GMT
Subject: Integrated: 8174840: Elements.overrides does not check the return type
 of the methods
In-Reply-To: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
References: <efF4DNlHjdDzlsakujd_rYGDl0i2t044ueY81y4UflU=.27c16ecc-0174-4270-b377-9d5e828a06ce@github.com>
Message-ID: <O2YX9iz9sGoT2FiJo0CowU2hA-hFuF4mTb2_4eCP2so=.f7e58905-75d9-4997-8b74-5b94d890e2cd@github.com>

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

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

This pull request has now been integrated.

Changeset: 606f2012
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/606f2012b07855b90c4669356857060dcb65cae4
Stats:     134 lines in 3 files changed: 133 ins; 0 del; 1 mod

8174840: Elements.overrides does not check the return type of the methods

Co-authored-by: Pavel Rappo <prappo at openjdk.org>
Reviewed-by: liach, darcy

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

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

From naoto at openjdk.org  Mon May  5 22:44:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 May 2025 22:44:17 GMT
Subject: RFR: 8354908: javac mishandles supplementary character in
 character literal
In-Reply-To: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
References: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
Message-ID: <87Q7cxgJhNtHBeM9MaRJ7n0Cq776_V2Mv1sGACnwLXk=.549f564b-1a64-4700-b6bb-40bd25ee3f27@github.com>

On Wed, 30 Apr 2025 13:05:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Some Unicode characters consist of two surrogates, i.e. two `char`s. And, such Unicode characters cannot be part of a char literal, as there's no way to represent them as a character literal. But, javac currently accepts code with such characters, and only puts the char, the high surrogate, into the literal, ignoring the second one.
> 
> For example, the JDK 24 behavior is:
> 
> $ cat /tmp/T.java 
> public class T {
>     public static void main(String... args) {
>        char c = '?';
>        System.err.println(Integer.toHexString((int) c));
>        System.err.println(Character.isHighSurrogate(c));
>     }
> }
> $ java /tmp/T.java
> d83d
> true
> 
> 
> But, in JDK 11, such literals have been rejected:
> 
> $ java /tmp/T.java
> /tmp/T.java:3: error: unclosed character literal
>        char c = '?';
>                 ^
> /tmp/T.java:3: error: illegal character: '\ude0a'
>        char c = '?';
>                   ^
> /tmp/T.java:3: error: unclosed character literal
>        char c = '?';
>                    ^
> 3 errors
> error: compilation failed
> 
> 
> The proposal in this PR is to explicitly check for this case when scanning character literal, and produce explicit error when a multi-surrogate character is used. javac will produce an error like:
> 
> $ java /tmp/T.java
> /tmp/T.java:3: error: character literal contains more than one UTF-16 code point
>        char c = '?';
>                 ^
> 1 error
> error: compilation failed

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 698:

> 696: 
> 697: compiler.err.illegal.char.literal.multiple.surrogates=\
> 698:     character literal contains more than one UTF-16 code point

The error message is kind of vague. How about using "surrogate code point"?
https://www.unicode.org/glossary/#surrogate_code_point

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24964#discussion_r2074321207

From naoto at openjdk.org  Mon May  5 22:50:20 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 May 2025 22:50:20 GMT
Subject: RFR: 8354908: javac mishandles supplementary character in
 character literal
In-Reply-To: <87Q7cxgJhNtHBeM9MaRJ7n0Cq776_V2Mv1sGACnwLXk=.549f564b-1a64-4700-b6bb-40bd25ee3f27@github.com>
References: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
 <87Q7cxgJhNtHBeM9MaRJ7n0Cq776_V2Mv1sGACnwLXk=.549f564b-1a64-4700-b6bb-40bd25ee3f27@github.com>
Message-ID: <DPgssOfdKg2_yHXWZoinQpUeQq8g6Piq3gCBGPTHhwg=.09859afb-17e0-4bec-9757-51f100113020@github.com>

On Mon, 5 May 2025 22:41:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Some Unicode characters consist of two surrogates, i.e. two `char`s. And, such Unicode characters cannot be part of a char literal, as there's no way to represent them as a character literal. But, javac currently accepts code with such characters, and only puts the char, the high surrogate, into the literal, ignoring the second one.
>> 
>> For example, the JDK 24 behavior is:
>> 
>> $ cat /tmp/T.java 
>> public class T {
>>     public static void main(String... args) {
>>        char c = '?';
>>        System.err.println(Integer.toHexString((int) c));
>>        System.err.println(Character.isHighSurrogate(c));
>>     }
>> }
>> $ java /tmp/T.java
>> d83d
>> true
>> 
>> 
>> But, in JDK 11, such literals have been rejected:
>> 
>> $ java /tmp/T.java
>> /tmp/T.java:3: error: unclosed character literal
>>        char c = '?';
>>                 ^
>> /tmp/T.java:3: error: illegal character: '\ude0a'
>>        char c = '?';
>>                   ^
>> /tmp/T.java:3: error: unclosed character literal
>>        char c = '?';
>>                    ^
>> 3 errors
>> error: compilation failed
>> 
>> 
>> The proposal in this PR is to explicitly check for this case when scanning character literal, and produce explicit error when a multi-surrogate character is used. javac will produce an error like:
>> 
>> $ java /tmp/T.java
>> /tmp/T.java:3: error: character literal contains more than one UTF-16 code point
>>        char c = '?';
>>                 ^
>> 1 error
>> error: compilation failed
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 698:
> 
>> 696: 
>> 697: compiler.err.illegal.char.literal.multiple.surrogates=\
>> 698:     character literal contains more than one UTF-16 code point
> 
> The error message is kind of vague. How about using "surrogate code point"?
> https://www.unicode.org/glossary/#surrogate_code_point

Or "UTF-16 code unit"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24964#discussion_r2074337356

From valeriep at openjdk.org  Mon May  5 23:10:21 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 5 May 2025 23:10:21 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
Message-ID: <HbFASiE30jlau5uYQd8IfunzRxrDsWjjg1K2he6aig8=.c62665fb-5ecb-40be-9be8-25ccb501e531@github.com>

On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tuning debug log and exception message

Looks good.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24520#pullrequestreview-2816353093

From darcy at openjdk.org  Tue May  6 00:15:48 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 May 2025 00:15:48 GMT
Subject: RFR: 8354091: Update RELEASE_25 description for Flexible Constructor
 Bodies
Message-ID: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>

Getting ready for this SourceVersions change to be pushed after 

    JDK-8344703: Compiler Implementation for Flexible Constructor Bodies
    
is integrated.

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

Commit messages:
 - JDK-8354091: Update RELEASE_25 description for Flexible Constructor Bodies

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

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

From iris at openjdk.org  Tue May  6 00:33:14 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 6 May 2025 00:33:14 GMT
Subject: RFR: 8354091: Update RELEASE_25 description for Flexible
 Constructor Bodies
In-Reply-To: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
References: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
Message-ID: <G9BlA6QZQQRvbbFg9U_37Kxy6U9a7Bh21ACr9EaEKaI=.6e407004-0f91-4252-bf5a-62950f2d483e@github.com>

On Tue, 6 May 2025 00:10:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Getting ready for this SourceVersions change to be pushed after 
> 
>     JDK-8344703: Compiler Implementation for Flexible Constructor Bodies
>     
> is integrated.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25053#pullrequestreview-2816483412

From liach at openjdk.org  Tue May  6 02:50:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 02:50:18 GMT
Subject: RFR: 8354091: Update RELEASE_25 description for Flexible
 Constructor Bodies
In-Reply-To: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
References: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
Message-ID: <C-ccqYmbpdJ-MCL8imMbafcywE2SXrtCQeeeaSdngig=.d94b81db-f653-4038-9901-da9c5daeb6ca@github.com>

On Tue, 6 May 2025 00:10:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Getting ready for this SourceVersions change to be pushed after 
> 
>     JDK-8344703: Compiler Implementation for Flexible Constructor Bodies
>     
> is integrated.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25053#pullrequestreview-2816730408

From mcimadamore at openjdk.org  Tue May  6 08:40:27 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 6 May 2025 08:40:27 GMT
Subject: RFR: 8344703: Compiler Implementation for Flexible Constructor
 Bodies [v2]
In-Reply-To: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com>
References: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com>
Message-ID: <YhcbRJOscmdKhGeAvbQDoJ0blZfJ56AbRimnL8YzV7A=.fa506031-bbbc-4309-b778-d2a891a63976@github.com>

> This PR finalizes the Flexible Constructor Bodies feature with no semantics changes.
> The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files).
> 
> We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands.

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

 - Merge branch 'master' into finalize_flex_constr_bodies
 - Initial push

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

Changes: https://git.openjdk.org/jdk/pull/24505/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24505&range=01
  Stats: 136 lines in 39 files changed: 1 ins; 39 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/24505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24505/head:pull/24505

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

From vromero at openjdk.org  Tue May  6 14:24:19 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 6 May 2025 14:24:19 GMT
Subject: RFR: 8344703: Compiler Implementation for Flexible Constructor
 Bodies [v2]
In-Reply-To: <YhcbRJOscmdKhGeAvbQDoJ0blZfJ56AbRimnL8YzV7A=.fa506031-bbbc-4309-b778-d2a891a63976@github.com>
References: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com>
 <YhcbRJOscmdKhGeAvbQDoJ0blZfJ56AbRimnL8YzV7A=.fa506031-bbbc-4309-b778-d2a891a63976@github.com>
Message-ID: <oDcPEHqN8OvfjgEF9ZAFch0YBYgdEd3tCwGNJDGr1fg=.30955a75-9ed4-4173-b2bb-77101af0e050@github.com>

On Tue, 6 May 2025 08:40:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR finalizes the Flexible Constructor Bodies feature with no semantics changes.
>> The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files).
>> 
>> We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into finalize_flex_constr_bodies
>  - Initial push

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24505#pullrequestreview-2818483786

From ihse at openjdk.org  Tue May  6 15:46:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:46:03 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>

> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
> 
> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
> 
> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
> 
> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

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

 - Merge branch 'master' into unicode-sequence-in-comments
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/ae1166af..694b33dc

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

  Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 mod
  Patch: https://git.openjdk.org/jdk/pull/24727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727

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

From naoto at openjdk.org  Tue May  6 17:21:18 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 17:21:18 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
Message-ID: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>

On Tue, 6 May 2025 15:46:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
>> 
>> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
>> 
>> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
>> 
>> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into unicode-sequence-in-comments
>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters

src/java.base/share/classes/java/text/Collator.java line 141:

> 139:      * considered significant during comparison. The assignment of strengths
> 140:      * to language features is locale dependent. A common example is for
> 141:      * different accented forms of the same base letter ("a" vs "?") to be

Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.

src/java.base/share/classes/java/text/RuleBasedCollator.java line 594:

> 592:         // a three-digit number, one digit for primary, one for secondary, etc.
> 593:         //
> 594:         // String:              A     a     B   ?

Maybe "? (\u00e9, e-acute)"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075933987
PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075935811

From ihse at openjdk.org  Tue May  6 18:02:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 18:02:19 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
Message-ID: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>

On Tue, 6 May 2025 17:15:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into unicode-sequence-in-comments
>>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters
>
> src/java.base/share/classes/java/text/Collator.java line 141:
> 
>> 139:      * considered significant during comparison. The assignment of strengths
>> 140:      * to language features is locale dependent. A common example is for
>> 141:      * different accented forms of the same base letter ("a" vs "?") to be
> 
> Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.

I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though).

If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. 

But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075997573

From naoto at openjdk.org  Tue May  6 18:09:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 18:09:25 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
 <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>
Message-ID: <g1nEEI-RAaG_MRVesbDb13DDKf_oe49wObM9oeXSHzM=.864f4b77-66e6-48e2-a021-8348550d23ec@github.com>

On Tue, 6 May 2025 17:59:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/Collator.java line 141:
>> 
>>> 139:      * considered significant during comparison. The assignment of strengths
>>> 140:      * to language features is locale dependent. A common example is for
>>> 141:      * different accented forms of the same base letter ("a" vs "?") to be
>> 
>> Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.
>
> I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though).
> 
> If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. 
> 
> But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that.

Yes, I meant literally `\u00e9` or `\u00E4`, but I think it is better described as `U+00E9` emphasizing the code point. So in this case, I'd suggest

"a" vs "?" (U+00E9)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2076008258

From henryjen at openjdk.org  Tue May  6 18:09:45 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 6 May 2025 18:09:45 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v5]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <4WWeeFJ0bxH4U1XfnLXi2wmekdo6rRRPzegDLnePGPc=.813a8ecc-f500-462a-a865-ca5d632e8423@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

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

  Validation entry name, also output the count of duplicates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/e38774af..24d0776d

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

  Stats: 229 lines in 3 files changed: 151 ins; 45 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24430/head:pull/24430

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

From henryjen at openjdk.org  Tue May  6 18:21:30 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 6 May 2025 18:21:30 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>

> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.

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

  Restore Validator access level

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/24d0776d..e0eff6ef

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

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

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

From liach at openjdk.org  Tue May  6 19:54:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 19:54:31 GMT
Subject: RFR: 8332934: Do loop with continue with subsequent switch leads to
 incorrect stack maps
Message-ID: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>

Currently, if a do loop has a continue statement, it leads to local variable `defined` state leakage through the `Chain` link from the nested statements to the outer blocks.

When the do loop is finished, the local variables are cleared but the state isn't; thus, in the subsequent switch statements, `Gen` incorrectly assumes the uninitialized variable declaration of the same slot in the switch statement is initialized, generating a stack map frame that requires that variable to be present, failing at verification.

The new `DoLoopLocalEscapeThroughContinueTest` ships a minimal reproducer of this failure.

I noted that previously, [JDK-8067429](https://bugs.openjdk.org/browse/JDK-8067429) 7e499fd15b479dd167d9235454587aebd74da6ed tried to address the same local leakage issue by adding ad-hoc restrictions. The result is that all individual usages of `GenContext.exit` are guarded with the `excludeFrom` pattern and was bug-prone, leading to [JDK-8160699](https://bugs.openjdk.org/browse/JDK-8160699) 83dbcb5c1b79ef6b5fd1172805302af3d313ee8a. Now this problem surfaces for continue chains as well, and I don't think it is sensible to add such guards for all continues too.

Instead of providing a patch at where the continue statement leaks the variables, I decided to choose a more holistic approach - we should restrict variable leaking through chains in general. Thus, I captured the restrictions upon GenContext creation, and added the restrictions in addExit and addCont. This way, I re-fixed the two bugs together with this one, with less future maintenance cost and a more clear logic, presumbaly more robust too.

Also in my previous fiddling, LVTHarness failed and the error message was unclear. I added printing of method body for easy debug and find it helpful so I included this utility in this patch.

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

Commit messages:
 - Wrote the old test on windows :(
 - Newline
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/javac-smt-0
 - 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps
 - Stage

Changes: https://git.openjdk.org/jdk/pull/25071/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332934
  Stats: 95 lines in 5 files changed: 74 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25071.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25071/head:pull/25071

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

From liach at openjdk.org  Tue May  6 19:54:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 19:54:31 GMT
Subject: RFR: 8332934: Do loop with continue with subsequent switch leads
 to incorrect stack maps
In-Reply-To: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
References: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
Message-ID: <MQkLZpTG1hKpdWQvm8S-q4HdVF-hiDWDFAqs7DedCbo=.d46bd113-4730-45e8-ae6e-95f9bb6c1fb3@github.com>

On Tue, 6 May 2025 19:42:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, if a do loop has a continue statement, it leads to local variable `defined` state leakage through the `Chain` link from the nested statements to the outer blocks.
> 
> When the do loop is finished, the local variables are cleared but the state isn't; thus, in the subsequent switch statements, `Gen` incorrectly assumes the uninitialized variable declaration of the same slot in the switch statement is initialized, generating a stack map frame that requires that variable to be present, failing at verification.
> 
> The new `DoLoopLocalEscapeThroughContinueTest` ships a minimal reproducer of this failure.
> 
> I noted that previously, [JDK-8067429](https://bugs.openjdk.org/browse/JDK-8067429) 7e499fd15b479dd167d9235454587aebd74da6ed tried to address the same local leakage issue by adding ad-hoc restrictions. The result is that all individual usages of `GenContext.exit` are guarded with the `excludeFrom` pattern and was bug-prone, leading to [JDK-8160699](https://bugs.openjdk.org/browse/JDK-8160699) 83dbcb5c1b79ef6b5fd1172805302af3d313ee8a. Now this problem surfaces for continue chains as well, and I don't think it is sensible to add such guards for all continues too.
> 
> Instead of providing a patch at where the continue statement leaks the variables, I decided to choose a more holistic approach - we should restrict variable leaking through chains in general. Thus, I captured the restrictions upon GenContext creation, and added the restrictions in addExit and addCont. This way, I re-fixed the two bugs together with this one, with less future maintenance cost and a more clear logic, presumbaly more robust too.
> 
> Also in my previous fiddling, LVTHarness failed and the error message was unclear. I added printing of method body for easy debug and find it helpful so I included this utility in this patch.

Preliminary testing: langtools/tools/javac. Submitting tier1 and 2 tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25071#issuecomment-2855751723

From liach at openjdk.org  Tue May  6 20:17:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 May 2025 20:17:53 GMT
Subject: RFR: 8332934: Do loop with continue with subsequent switch leads
 to incorrect stack maps [v2]
In-Reply-To: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
References: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
Message-ID: <VUGczopFM7XEBOn7lzkKQU705p99IdMFJA2S6H2jZSA=.9345edca-0729-45fd-b7b8-b1e4332fbde0@github.com>

> Currently, if a do loop has a continue statement, it leads to local variable `defined` state leakage through the `Chain` link from the nested statements to the outer blocks.
> 
> When the do loop is finished, the local variables are cleared but the state isn't; thus, in the subsequent switch statements, `Gen` incorrectly assumes the uninitialized variable declaration of the same slot in the switch statement is initialized, generating a stack map frame that requires that variable to be present, failing at verification.
> 
> The new `DoLoopLocalEscapeThroughContinueTest` ships a minimal reproducer of this failure.
> 
> I noted that previously, [JDK-8067429](https://bugs.openjdk.org/browse/JDK-8067429) 7e499fd15b479dd167d9235454587aebd74da6ed tried to address the same local leakage issue by adding ad-hoc restrictions. The result is that all individual usages of `GenContext.exit` are guarded with the `excludeFrom` pattern and was bug-prone, leading to [JDK-8160699](https://bugs.openjdk.org/browse/JDK-8160699) 83dbcb5c1b79ef6b5fd1172805302af3d313ee8a. Now this problem surfaces for continue chains as well, and I don't think it is sensible to add such guards for all continues too.
> 
> Instead of providing a patch at where the continue statement leaks the variables, I decided to choose a more holistic approach - we should restrict variable leaking through chains in general. Thus, I captured the restrictions upon GenContext creation, and added the restrictions in addExit and addCont. This way, I re-fixed the two bugs together with this one, with less future maintenance cost and a more clear logic, presumbaly more robust too.
> 
> Also in my previous fiddling, LVTHarness failed and the error message was unclear. I added printing of method body for easy debug and find it helpful so I included this utility in this patch.

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

  This can be null with goto

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25071/files
  - new: https://git.openjdk.org/jdk/pull/25071/files/54c7c878..ab8feeb8

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

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

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

From vromero at openjdk.org  Tue May  6 20:34:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 6 May 2025 20:34:12 GMT
Subject: RFR: 8332934: Do loop with continue with subsequent switch leads
 to incorrect stack maps [v2]
In-Reply-To: <VUGczopFM7XEBOn7lzkKQU705p99IdMFJA2S6H2jZSA=.9345edca-0729-45fd-b7b8-b1e4332fbde0@github.com>
References: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
 <VUGczopFM7XEBOn7lzkKQU705p99IdMFJA2S6H2jZSA=.9345edca-0729-45fd-b7b8-b1e4332fbde0@github.com>
Message-ID: <nzU6Go4l4-KRx5lO9ddD9G7b0i1B6zJICi8F7F-GMw8=.9be07f34-36a6-432d-b7ca-b8cc1383e8ec@github.com>

On Tue, 6 May 2025 20:17:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, if a do loop has a continue statement, it leads to local variable `defined` state leakage through the `Chain` link from the nested statements to the outer blocks.
>> 
>> When the do loop is finished, the local variables are cleared but the state isn't; thus, in the subsequent switch statements, `Gen` incorrectly assumes the uninitialized variable declaration of the same slot in the switch statement is initialized, generating a stack map frame that requires that variable to be present, failing at verification.
>> 
>> The new `DoLoopLocalEscapeThroughContinueTest` ships a minimal reproducer of this failure.
>> 
>> I noted that previously, [JDK-8067429](https://bugs.openjdk.org/browse/JDK-8067429) 7e499fd15b479dd167d9235454587aebd74da6ed tried to address the same local leakage issue by adding ad-hoc restrictions. The result is that all individual usages of `GenContext.exit` are guarded with the `excludeFrom` pattern and was bug-prone, leading to [JDK-8160699](https://bugs.openjdk.org/browse/JDK-8160699) 83dbcb5c1b79ef6b5fd1172805302af3d313ee8a. Now this problem surfaces for continue chains as well, and I don't think it is sensible to add such guards for all continues too.
>> 
>> Instead of providing a patch at where the continue statement leaks the variables, I decided to choose a more holistic approach - we should restrict variable leaking through chains in general. Thus, I captured the restrictions upon GenContext creation, and added the restrictions in addExit and addCont. This way, I re-fixed the two bugs together with this one, with less future maintenance cost and a more clear logic, presumbaly more robust too.
>> 
>> Also in my previous fiddling, LVTHarness failed and the error message was unclear. I added printing of method body for easy debug and find it helpful so I included this utility in this patch.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   This can be null with goto

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25071#pullrequestreview-2819568071

From abimpoudis at openjdk.org  Wed May  7 12:11:17 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 7 May 2025 12:11:17 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v2]
In-Reply-To: <ObJrI5A1KTD3rT6qv6-mn3mXpu_H9_8_7ENluRwk6aM=.84d013d3-52eb-4a00-a638-513ef6f05673@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
 <hwRJry55rIrw2KTV8Wael4xwPV537SY2NRLX7JZ8zXY=.1aa33e85-48ba-40cf-91cf-c5dfb2faa00f@github.com>
 <ObJrI5A1KTD3rT6qv6-mn3mXpu_H9_8_7ENluRwk6aM=.84d013d3-52eb-4a00-a638-513ef6f05673@github.com>
Message-ID: <brkuLlZP6g19AXw6ZA3lkqcBUM-wLFXRLDPjVI3KaAM=.647e0faf-34b1-452d-9605-415272c5496e@github.com>

On Mon, 5 May 2025 13:52:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I had a look and I think what @lahodaj meant was something like this: https://github.com/biboudis/jdk/commit/f05394c9025f6a93d283e1bfe1a26ef83f5ca0b8
>> 
>> Instead of me creating a new PR, @archiecobbs you can reopen yours, merge here my commit above and rereview. What do you think? :-)
>
> @biboudis I've merged in your patch but currently can't verify anything due to build breakage ([JDK-8355561](https://bugs.openjdk.org/browse/JDK-8355561)).

Sounds good. Let me know what you think @archiecobbs ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23303#issuecomment-2858341264

From asotona at openjdk.org  Wed May  7 14:52:04 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 7 May 2025 14:52:04 GMT
Subject: RFR: 8351232: NPE: Cannot invoke "getDeclarationAttributes" because
 "sym" is null
Message-ID: <7xQfFZVHJst-kLD47Uh7RwzTViardUJYqqAgFGBClw0=.88afde19-f536-4936-b6b0-f34d45e45790@github.com>

Javac throws NPE in very specific circumstances described in [JDK-8351232](https://bugs.openjdk.org/browse/JDK-8351232).
The NPE has been fixed as a side effect of "stripMetadata" call in the recent [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fix.

This PR only adds a test case to avoid regression of the NPE.

Please review.

Thank you,
Adam

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

Commit messages:
 - NPE: Cannot invoke "getDeclarationAttributes" because "sym" is null

Changes: https://git.openjdk.org/jdk/pull/25098/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351232
  Stats: 142 lines in 6 files changed: 134 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25098/head:pull/25098

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

From liach at openjdk.org  Wed May  7 14:58:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 14:58:12 GMT
Subject: RFR: 8351232: NPE: Cannot invoke "getDeclarationAttributes"
 because "sym" is null
In-Reply-To: <7xQfFZVHJst-kLD47Uh7RwzTViardUJYqqAgFGBClw0=.88afde19-f536-4936-b6b0-f34d45e45790@github.com>
References: <7xQfFZVHJst-kLD47Uh7RwzTViardUJYqqAgFGBClw0=.88afde19-f536-4936-b6b0-f34d45e45790@github.com>
Message-ID: <R8H8P7fS_NEDRPL7fr4d2qIMItIlFEr0v_iQ54CbsRg=.6128c602-0805-4f50-a366-7d44c03b70f0@github.com>

On Wed, 7 May 2025 14:40:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Javac throws NPE in very specific circumstances described in [JDK-8351232](https://bugs.openjdk.org/browse/JDK-8351232).
> The NPE has been fixed as a side effect of "stripMetadata" call in the recent [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fix.
> 
> This PR only adds a test case to avoid regression of the NPE.
> 
> Please review.
> 
> Thank you,
> Adam

Looks reasonable to me

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25098#pullrequestreview-2822117363

From acobbs at openjdk.org  Wed May  7 15:08:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 7 May 2025 15:08:36 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v3]
In-Reply-To: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
Message-ID: <-J_AJ-9QvL56UaMaZ_RVyt6XezrCIVUqnlSM1X9qbqc=.04293a17-6ac6-4579-a244-8d5b6fcc65fe@github.com>

> JEP 455 adds support for `switch`'ing on `long`, `float`, `double`, and `boolean`. Since this feature is still in preview, the `--enable-preview` flag is required. The compiler was properly checking that when the expressions had primitive type, but not when the expression a corresponding boxed type (i.e., `Long`, `Float`, `Double`, and `Boolean`). This resulted in `BootstrapMethodError` failures at runtime. This PR closes that loophole.

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

 - Merge branch 'master' into JDK-8348410
 - Address review of #23303
 - Merge branch 'master' into JDK-8348410
 - Fix typo in regression test @summary lines.
 - Check preview enabled for switch on boxed Booleam, Long, Float, or Double.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23303/files
  - new: https://git.openjdk.org/jdk/pull/23303/files/72b7804b..0236793e

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

  Stats: 19822 lines in 538 files changed: 12621 ins; 4322 del; 2879 mod
  Patch: https://git.openjdk.org/jdk/pull/23303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23303/head:pull/23303

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

From acobbs at openjdk.org  Wed May  7 15:08:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 7 May 2025 15:08:36 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v3]
In-Reply-To: <ObJrI5A1KTD3rT6qv6-mn3mXpu_H9_8_7ENluRwk6aM=.84d013d3-52eb-4a00-a638-513ef6f05673@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
 <hwRJry55rIrw2KTV8Wael4xwPV537SY2NRLX7JZ8zXY=.1aa33e85-48ba-40cf-91cf-c5dfb2faa00f@github.com>
 <ObJrI5A1KTD3rT6qv6-mn3mXpu_H9_8_7ENluRwk6aM=.84d013d3-52eb-4a00-a638-513ef6f05673@github.com>
Message-ID: <59VTXfW6o2rBp1CMAjsMA-yPvPusWtjh4D7L5SCJX7o=.23d9752e-1327-43e6-a8dd-1ffd24d1e4ad@github.com>

On Mon, 5 May 2025 13:52:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I had a look and I think what @lahodaj meant was something like this: https://github.com/biboudis/jdk/commit/f05394c9025f6a93d283e1bfe1a26ef83f5ca0b8
>> 
>> Instead of me creating a new PR, @archiecobbs you can reopen yours, merge here my commit above and rereview. What do you think? :-)
>
> @biboudis I've merged in your patch but currently can't verify anything due to build breakage ([JDK-8355561](https://bugs.openjdk.org/browse/JDK-8355561)).

> Sounds good. Let me know what you think @archiecobbs ?

OK tests are passing on my machine now so we should be in good shape unless you see something else that's needed. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23303#issuecomment-2858952348

From abimpoudis at openjdk.org  Wed May  7 15:08:37 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 7 May 2025 15:08:37 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v3]
In-Reply-To: <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <uD-Gvk0pMcpRCeJl0RFG1eMYjYmyAkGSAjYXNZEd544=.3081e302-a9e5-4b52-bc21-9cdb6fe4e292@github.com>
Message-ID: <OBv-WhE26WIyUsZfABzPhN1yxaoJ7FxkXICEbOLUwfw=.b72d8655-0a86-424c-86d4-e4e58b448843@github.com>

On Fri, 24 Jan 2025 18:43:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8348410
>>  - Address review of #23303
>>  - Merge branch 'master' into JDK-8348410
>>  - Fix typo in regression test @summary lines.
>>  - Check preview enabled for switch on boxed Booleam, Long, Float, or Double.
>
> I think the check needs to be on a different place - please see inline.

Nice! Let's wait for @lahodaj's review, then. Many thanks for the quick response.

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

PR Comment: https://git.openjdk.org/jdk/pull/23303#issuecomment-2858967059

From liach at openjdk.org  Wed May  7 16:41:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 16:41:16 GMT
Subject: RFR: 8344703: Compiler Implementation for Flexible Constructor
 Bodies [v2]
In-Reply-To: <YhcbRJOscmdKhGeAvbQDoJ0blZfJ56AbRimnL8YzV7A=.fa506031-bbbc-4309-b778-d2a891a63976@github.com>
References: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com>
 <YhcbRJOscmdKhGeAvbQDoJ0blZfJ56AbRimnL8YzV7A=.fa506031-bbbc-4309-b778-d2a891a63976@github.com>
Message-ID: <7VJw0cuklr_kwBCVYaYMRA0ZmpyGYqCRd8AL4g2PHiw=.a72e0760-ab96-47ab-acc1-33053fb50d12@github.com>

On Tue, 6 May 2025 08:40:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR finalizes the Flexible Constructor Bodies feature with no semantics changes.
>> The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files).
>> 
>> We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into finalize_flex_constr_bodies
>  - Initial push

I think we should integrate at the current stage without waiting for anonymous or local class changes - those involve existing specification and is best done in their own RFEs.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24505#pullrequestreview-2822477553

From lancea at openjdk.org  Wed May  7 17:46:28 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 7 May 2025 17:46:28 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
Message-ID: <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>

On Tue, 6 May 2025 18:21:30 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR check the jar file to ensure entries are consistent from the central directory and local file header. Also check there is no duplicate entry names that could override the desired content by accident.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Validator access level

Hi Henry,

Thank you for tackling this one.  I am still going through this but have some initial comments on my 1st pass

Can you also please address the following in jar.properties:

-  remove the duplicate entry of `main.help.opt.extract `
- update `main.help.opt.main.validate` to document the additional actions --validate now takes

We also need to update `open/src/jdk.jartool/share/man/jar.md` as it currently contains no mentions of the `--validate `option

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 120:

> 118:     /**
> 119:      * Helper class to deduplicate entry names.
> 120:      * Keep a coutner for duplicate entry names and check if the entry name is valid on first add.

counter -> counter

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 122:

> 120:      * Keep a coutner for duplicate entry names and check if the entry name is valid on first add.
> 121:      */
> 122:     private class DedupEntryNames {

Need a better name for this class as it is hard to understand what its purpose is from the name

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 122:

> 120:      * Keep a coutner for duplicate entry names and check if the entry name is valid on first add.
> 121:      */
> 122:     private class DedupEntryNames {

This class and some of its methods I would rename as it is difficult to understand what their purpose is and this will help future maintainers

There also needs to be more meaningful class documentation given how the class/methods are used

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 124:

> 122:     private class DedupEntryNames {
> 123:         LinkedHashMap<String, Integer> entries = new LinkedHashMap<>();
> 124:         boolean isCEN;

An enum might be clearer vs using a boolean for clarity

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127:

> 125: 
> 126:         public DedupEntryNames(boolean isCEN) {
> 127:             this.isCEN = isCEN;

Might be clearer if this was an enum vs boolean?

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 135:

> 133:                 isValid = false;
> 134:             } else if (!isZipEntryNameValid(entryName)) {
> 135:                 warn(formatMsg("error.validator.bad.entry.name", entryName));

I think we need to consider a better message as 'malformed' might not be clear enough (also looks like this message was added but not used previously)


error.validator.bad.entry.name=\
        entry name malformed, {0}

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 135:

> 133:                 isValid = false;
> 134:             } else if (!isZipEntryNameValid(entryName)) {
> 135:                 warn(formatMsg("error.validator.bad.entry.name", entryName));

This message for `error.validator.bad.entry.name` could be clearer as  I don't think "malformed" indicating the issues with the file name entry in the CEN/LOC Header.  We should also prefix it a "Warning:"

 `entry name malformed, {0}`

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147:

> 145:                 warn(formatMsg(msg, count.toString(), counter.getKey()));
> 146:             }
> 147:             return true;

This seems to always be true as `warn()` results in `err.println` call (unless I am missing something)

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 150:

> 148:         }
> 149: 
> 150:         public LinkedList<String> dedup() {

Need a better method name and a comment for the method would be helpful for future maintainers

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 169:

> 167: 
> 168:     // Check next CEN entry is matching the specified name
> 169:     private boolean checkNextCenEntry(String locEntryName, LinkedList<String> cenEntryNames) {

The method description and method name could be clearer as to its purpose

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 184:

> 182: 
> 183:     /*
> 184:      * Retrieve entries from the XipInputStream to verify local file headers(LOC)

XipInputStream -> ZipInputStream

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 184:

> 182: 
> 183:     /*
> 184:      * Retrieve entries from the XipInputStream to verify local file headers(LOC)

Typo: `XipInputStream`

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 215:

> 213:     private boolean validate() {
> 214:         try {
> 215:             var dedupCEN = new DedupEntryNames(true);

Please use a more insightful variable name

src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 217:

> 215:             var dedupCEN = new DedupEntryNames(true);
> 216:             zf.stream()
> 217:               .peek(e -> dedupCEN.add(e.getName()))

I am wondering if it might be clearer to consider breaking the above into a separate step for clarity vs part of the current stream traversal?  Otherwise  there should be more comments added for future maintainers

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 147:

> 145:         in incompatible public interfaces
> 146: warn.validator.duplicate.cen.entry=\
> 147:         Warning: {0} copies of {1} is detected in central directory

I would change:

`Warning: {0} copies of {1} is detected in central directory`
to:
`Warning: There were {0}  central directory headers found  for  file name {1} `

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 148:

> 146: warn.validator.duplicate.cen.entry=\
> 147:         Warning: {0} copies of {1} is detected in central directory
> 148: warn.validator.duplicate.loc.entry=\

Same comment as for `warn.validator.duplicate.cen.entry`

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 150:

> 148: warn.validator.duplicate.loc.entry=\
> 149:         Warning: {0} copies of {1} is detected in local file header
> 150: warn.validator.cen.only.entry=\

I would change

`Warning: Entry {0} in central directory is not in local file header`
to
`Warning:  An equivalent local file header was not found  for the central directory header for the file name: {0} `

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 151:

> 149:         Warning: {0} copies of {1} is detected in local file header
> 150: warn.validator.cen.only.entry=\
> 151:         Warning: Entry {0} in central directory is not in local file header

I would change the above to something like:

Warning: An equivalent  Local File header record  for  the  Central Directory Header record  for file {0} was not found

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 152:

> 150: warn.validator.cen.only.entry=\
> 151:         Warning: Entry {0} in central directory is not in local file header
> 152: warn.validator.loc.only.entry=\

Same comment as for `warn.validator.duplicate.loc.entry`

test/jdk/tools/jar/ValidatorTest.java line 106:

> 104:         var template = out.toByteArray();
> 105:         // ISO_8859_1 to keep the 8-bit value
> 106:         var s = new String(template, StandardCharsets.ISO_8859_1);

Is there a reason you are not using UTF8 here  given that is the charset being used for the zip creation?

test/jdk/tools/jar/ValidatorTest.java line 145:

> 143:         var template = out.toByteArray();
> 144:         // ISO_8859_1 to keep the 8-bit value
> 145:         var s = new String(template, StandardCharsets.ISO_8859_1);

Ok, but the zip is being created using UTF_8....

test/jdk/tools/jar/ValidatorTest.java line 232:

> 230:             var err = e.getMessage();
> 231:             System.out.println(err);
> 232:             Assertions.assertTrue(err.contains("Warning: 2 copies of META-INF/MANIFEST.MF is detected in local file header"));

Given you are importing Assertions, you should be able to just use `assertTrue`

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

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2819609944
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076261620
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076262727
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077860557
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076291444
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078105322
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076275933
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077910292
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078098847
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076276973
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076281636
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076283433
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077916062
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077909330
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077908477
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078106177
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078078764
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078088807
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2076319729
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078089755
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2077731161
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078159472
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078131560

From henryjen at openjdk.org  Wed May  7 18:02:33 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 7 May 2025 18:02:33 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <Uvb8haTDHaSUlFccwMonvOOpnMogpbjr2KpffroxpmQ=.0e863939-4729-4ab6-9d67-f276570e9084@github.com>
 <kqx3sTJHVWdZpzTKzo7Ak7bYnBJqbLD1hkkJtK4okwg=.e26d85ff-7ea4-40e1-8593-dd424a0739de@github.com>
Message-ID: <eF015vnVzEp-5sqCQ9q6hmfE_AVQbCmJkNcoSG7BTrc=.9a91c482-3db5-4db9-9e28-eec44cdefe3c@github.com>

On Wed, 7 May 2025 17:13:19 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore Validator access level
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 127:
> 
>> 125: 
>> 126:         public DedupEntryNames(boolean isCEN) {
>> 127:             this.isCEN = isCEN;
> 
> Might be clearer if this was an enum vs boolean?

I feel the same way but wondering if that's an overkill.

> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 147:
> 
>> 145:                 warn(formatMsg(msg, count.toString(), counter.getKey()));
>> 146:             }
>> 147:             return true;
> 
> This seems to always be true as `warn()` results in `err.println` call (unless I am missing something)

I should clean that up better. As we just want to show the message but not really filter out that entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078195738
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2078193636

From archie.cobbs at gmail.com  Wed May  7 18:26:10 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 7 May 2025 13:26:10 -0500
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <CANSoFxtCCkiG1-vH_3bjSpH-bhCQKrEVJZ4zNTcG=WL=sKNMug@mail.gmail.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>
 <CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com>
 <a06a4392-ebc1-4615-91c4-20ce396bb228@oracle.com>
 <CANSoFxtCCkiG1-vH_3bjSpH-bhCQKrEVJZ4zNTcG=WL=sKNMug@mail.gmail.com>
Message-ID: <CANSoFxsZEAzsp5HF4J47-0Ygcd8vbjDbNjU+H80mZMvGCu=b1Q@mail.gmail.com>

I'd like to restart this discussion of JDK-8344159
<https://bugs.openjdk.org/browse/JDK-8344159>  - "Add lint warnings for
unnecessary warning suppression"

Note, this is likely not destined for JDK 25. I'm bringing it up now simply
because some refactoring that arose from the previous discussion back in
November (which is here
<https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html>)
is now mostly done.

I think a fair summary of the current state is: Having the compiler emit
warnings for unnecessary warning suppression is considered a useful idea in
principle, but it's unclear what is the best way to configure/enable that
functionality in the compiler.

In particular, there are subtle corner cases that could be problematic if
these warnings were enabled by -Xlint:all, especially for -Werror builds.

Also complicating things, there are two different ways to suppress
warnings, @SuppressWarnings("foo") and -Xlint:-foo and for similar "corner
case" reasons they need to be configurable separately.

There is a draft <https://bugs.openjdk.org/browse/JDK-8356043>CSR
<https://bugs.openjdk.org/browse/JDK-8356043> that gives an overview of the
current prototype, which proposes to add two new lint categories. If you
are interested in this topic please review the CSR and its comments and let
me know if you have any thoughts or suggestions - but I'm trying to move
the design discussion to this mailing list so follow-up here please.

Here's a quick summary of my latest thinking...

There is value in defining lint categories for these warnings; the main
problem is that including those categories in -Xlint:all may be too
aggressive - at least for now.

So I think we should simply exclude these new lint categories from
-Xlint:all. I'll note that -Xlint:all and -Xlint are synonyms, and the
documentation for -Xlint says "Enable recommended warning categories", so
this is within the existing meaning of this flag.

In the future, if the suppression warnings are deemed sufficiently
advantageous, we could always add them to -Xlint:all. Until if/when that
happens, if you want to enable all lint categories including suppression
then you will have to add it explicitly via -Xlint:all,suppression, etc.

Does this approach sound reasonable?

Thanks,
-Archie

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

From liach at openjdk.org  Wed May  7 18:31:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 18:31:13 GMT
Subject: RFR: 8332934: Do loop with continue with subsequent switch leads
 to incorrect stack maps [v2]
In-Reply-To: <VUGczopFM7XEBOn7lzkKQU705p99IdMFJA2S6H2jZSA=.9345edca-0729-45fd-b7b8-b1e4332fbde0@github.com>
References: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
 <VUGczopFM7XEBOn7lzkKQU705p99IdMFJA2S6H2jZSA=.9345edca-0729-45fd-b7b8-b1e4332fbde0@github.com>
Message-ID: <iptxQNIzh452U3BCELFMtOYYEsaJ59CFpwe1EzmE1Zk=.2290b80b-29b3-4071-af6d-2d3f49121572@github.com>

On Tue, 6 May 2025 20:17:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, if a do loop has a continue statement, it leads to local variable `defined` state leakage through the `Chain` link from the nested statements to the outer blocks.
>> 
>> When the do loop is finished, the local variables are cleared but the state isn't; thus, in the subsequent switch statements, `Gen` incorrectly assumes the uninitialized variable declaration of the same slot in the switch statement is initialized, generating a stack map frame that requires that variable to be present, failing at verification.
>> 
>> The new `DoLoopLocalEscapeThroughContinueTest` ships a minimal reproducer of this failure.
>> 
>> I noted that previously, [JDK-8067429](https://bugs.openjdk.org/browse/JDK-8067429) 7e499fd15b479dd167d9235454587aebd74da6ed tried to address the same local leakage issue by adding ad-hoc restrictions. The result is that all individual usages of `GenContext.exit` are guarded with the `excludeFrom` pattern and was bug-prone, leading to [JDK-8160699](https://bugs.openjdk.org/browse/JDK-8160699) 83dbcb5c1b79ef6b5fd1172805302af3d313ee8a. Now this problem surfaces for continue chains as well, and I don't think it is sensible to add such guards for all continues too.
>> 
>> Instead of providing a patch at where the continue statement leaks the variables, I decided to choose a more holistic approach - we should restrict variable leaking through chains in general. Thus, I captured the restrictions upon GenContext creation, and added the restrictions in addExit and addCont. This way, I re-fixed the two bugs together with this one, with less future maintenance cost and a more clear logic, presumbaly more robust too.
>> 
>> Also in my previous fiddling, LVTHarness failed and the error message was unclear. I added printing of method body for easy debug and find it helpful so I included this utility in this patch.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   This can be null with goto

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25071#issuecomment-2859733419

From liach at openjdk.org  Wed May  7 18:31:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 May 2025 18:31:17 GMT
Subject: Integrated: 8332934: Do loop with continue with subsequent switch
 leads to incorrect stack maps
In-Reply-To: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
References: <IOMCMGHOJVqVHym7VCGUwO39lQ8CiZCHv59mhoOQDB4=.c038e584-671c-4419-8de2-fddf978b2180@github.com>
Message-ID: <fRPY59xX9Fu5XZXSvAPiMapg2CV9RWYGO-M6sxXrj3E=.a7a57cd0-3262-4730-9991-f8b798e43211@github.com>

On Tue, 6 May 2025 19:42:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, if a do loop has a continue statement, it leads to local variable `defined` state leakage through the `Chain` link from the nested statements to the outer blocks.
> 
> When the do loop is finished, the local variables are cleared but the state isn't; thus, in the subsequent switch statements, `Gen` incorrectly assumes the uninitialized variable declaration of the same slot in the switch statement is initialized, generating a stack map frame that requires that variable to be present, failing at verification.
> 
> The new `DoLoopLocalEscapeThroughContinueTest` ships a minimal reproducer of this failure.
> 
> I noted that previously, [JDK-8067429](https://bugs.openjdk.org/browse/JDK-8067429) 7e499fd15b479dd167d9235454587aebd74da6ed tried to address the same local leakage issue by adding ad-hoc restrictions. The result is that all individual usages of `GenContext.exit` are guarded with the `excludeFrom` pattern and was bug-prone, leading to [JDK-8160699](https://bugs.openjdk.org/browse/JDK-8160699) 83dbcb5c1b79ef6b5fd1172805302af3d313ee8a. Now this problem surfaces for continue chains as well, and I don't think it is sensible to add such guards for all continues too.
> 
> Instead of providing a patch at where the continue statement leaks the variables, I decided to choose a more holistic approach - we should restrict variable leaking through chains in general. Thus, I captured the restrictions upon GenContext creation, and added the restrictions in addExit and addCont. This way, I re-fixed the two bugs together with this one, with less future maintenance cost and a more clear logic, presumbaly more robust too.
> 
> Also in my previous fiddling, LVTHarness failed and the error message was unclear. I added printing of method body for easy debug and find it helpful so I included this utility in this patch.

This pull request has now been integrated.

Changeset: 3f6b1777
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f6b17777ffe59d8981e252891ef2e5beeaf2fdd
Stats:     99 lines in 5 files changed: 78 ins; 12 del; 9 mod

8332934: Do loop with continue with subsequent switch leads to incorrect stack maps

Reviewed-by: vromero

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

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

From dnsimon at openjdk.org  Wed May  7 20:08:02 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 May 2025 20:08:02 GMT
Subject: RFR: 8348203: [JVMCI] Make eager JVMCI initialization observable
 in the debugger
In-Reply-To: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com>
Message-ID: <O-heUV3HqfdXpRJMb5aNw4pNZw7w2DBlSjUVfA3Uw1A=.595730c1-07d4-46df-98bd-0399ae1018d7@github.com>

On Tue, 21 Jan 2025 16:59:05 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> I realized that I can't debug (i.e. with a Java debugger) the Graal compiler initialization if it happens eagerly (e.g. with `EagerJVMCI`, `JVMCIPrintProperties`, `JVMCILibDumpJNIConfig`). Not that this is something I need every day, but I think it can easily be fixed by moving the early initializing a little further down, right after `JvmtiExport::post_vm_initialized()`:
> 
> 
>  diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp
> index 1cab9bc5d53..191409c22e3 100644
> --- a/src/hotspot/share/runtime/threads.cpp
> +++ b/src/hotspot/share/runtime/threads.cpp
> @@ -806,12 +806,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    }
>  #endif
>  
> -#if INCLUDE_JVMCI
> - if (force_JVMCI_initialization) {
> - JVMCI::initialize_compiler(CHECK_JNI_ERR);
> - }
> -#endif
> -
>    if (NativeHeapTrimmer::enabled()) {
>      NativeHeapTrimmer::initialize();
>    }
> @@ -826,6 +820,12 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
>    // Notify JVMTI agents that VM initialization is complete - nop if no agents.
>    JvmtiExport::post_vm_initialized();
>  
> +#if INCLUDE_JVMCI
> + if (force_JVMCI_initialization) {
> + JVMCI::initialize_compiler(CHECK_JNI_ERR);
> + }
> +#endif
> +
>    JFR_ONLY(Jfr::on_create_vm_3();)
>  
>  #if INCLUDE_MANAGEMENT

FYI: https://bugs.openjdk.org/browse/JDK-8356447

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

PR Comment: https://git.openjdk.org/jdk/pull/23219#issuecomment-2860185609

From cushon at openjdk.org  Wed May  7 22:04:53 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 7 May 2025 22:04:53 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter after
 JDK-8355065
Message-ID: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>

[JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fixed an issue where if RichDiagnosticFormatter was used recursively, it would overwrite instance state. That fix added guards to prevent the logic from being used recursively. As reported in [JDK-8356441](https://bugs.openjdk.org/browse/JDK-8356441) there are other situations where RichDiagnosticFormatter is used recursively. This fixes updates it to support being used recursively, by saving and restoring instance state on recursive calls.

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

Commit messages:
 - Imports
 - 8356441: IllegalStateException in RichDiagnosticFormatter after JDK-8355065

Changes: https://git.openjdk.org/jdk/pull/25105/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356441
  Stats: 157 lines in 2 files changed: 137 ins; 13 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25105/head:pull/25105

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

From nbenalla at openjdk.org  Thu May  8 13:18:07 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 8 May 2025 13:18:07 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <IQH5pfqDgtW2UCEbM800YyXfqbnB9VBT8f3T0oGZ3tY=.99cb3c22-45d4-43d8-a575-379b315bbc14@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Update release date
 - Update --release 25 symbol information for JDK 25 build 21
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
   
   # Conflicts:
   #	test/langtools/tools/javac/versions/Versions.java
 - feedback: never bump ASM version
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274
    + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274
    + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274
    + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274
    + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274
    + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274
    + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274
    + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274
 - Update --release 25 symbol information for JDK 24 build 20
   The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/
 - initial commit start-of-JDK-26

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=01
  Stats: 1390 lines in 53 files changed: 1299 ins; 16 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

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

From nbenalla at openjdk.org  Thu May  8 13:18:08 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 8 May 2025 13:18:08 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <rGqxr8rPmLc2N3Kq3nR9dVQom8mywOHenCVQF7IAIxo=.f869d0ae-7039-41a8-b57f-b0e926eb357e@github.com>
 <are73fd61fauw3-O7myGGgCt97bpEuPV1cqDgDmf488=.593f9d05-8ca7-4805-9a5b-1d6f0fa3915c@github.com>
Message-ID: <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@github.com>

On Fri, 2 May 2025 16:42:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
>> 
>>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>>> 49: 
>>> 50:     public static final int MAX_COLUMNS = 84;
>> 
>> What is this for?
>
> It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26".
> 
> Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch.

I'll split the releases over  two lines in the next update. The line is a little too long.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2079697514

From vromero at openjdk.org  Thu May  8 13:21:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 May 2025 13:21:57 GMT
Subject: RFR: 8354091: Update RELEASE_25 description for Flexible
 Constructor Bodies
In-Reply-To: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
References: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
Message-ID: <8rmkqezQDNhIkl0gOmkmjAC5c2L-g0Yp81pGxq-lqg4=.02ca3eb6-b032-47f2-8c8e-3a50cd880a1f@github.com>

On Tue, 6 May 2025 00:10:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Getting ready for this SourceVersions change to be pushed after 
> 
>     JDK-8344703: Compiler Implementation for Flexible Constructor Bodies
>     
> is integrated.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25053#pullrequestreview-2825113242

From vromero at openjdk.org  Thu May  8 13:33:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 May 2025 13:33:45 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'master' into JDK-8354556
 - addressing review comment
 - changes to test
 - Merge branch 'master' into JDK-8354556
 - updating test
 - final adjustments
 - additional refactorings
 - removing unneeded changes
 - more refactorings
 - more refactorings and tests
 - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0

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

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=05
  Stats: 497 lines in 25 files changed: 471 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

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

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

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

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
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

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

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

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

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

From mcimadamore at openjdk.org  Thu May  8 15:18:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 May 2025 15:18:00 GMT
Subject: Integrated: 8344703: Compiler Implementation for Flexible Constructor
 Bodies
In-Reply-To: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com>
References: <-P0s0RJfBN-mlTN6VCfRgzFnGTF5kvSBjbc6A9p3om8=.51207eb8-339b-4a66-a5ca-f37e44231946@github.com>
Message-ID: <JM8f_0VQ-fZoLw8uGr-iOwJxOAT76P0RA8dekrnul-0=.e18f3736-2135-4d74-9a0b-30dfb35fdc62@github.com>

On Tue, 8 Apr 2025 11:24:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR finalizes the Flexible Constructor Bodies feature with no semantics changes.
> The main changes in this PR have to do with the various tests, which needed tweaking (e.g. to drop `@enablePreview` and fix corresponding golden files).
> 
> We might, later on, incorporate a fix for [this issue](https://bugs.openjdk.org/browse/JDK-8349754) into this PR, depending on where the specification for this feature lands.

This pull request has now been integrated.

Changeset: c6ffacb5
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6ffacb5754642083f614a5ee6dc76b7d145c605
Stats:     136 lines in 39 files changed: 1 ins; 39 del; 96 mod

8344703: Compiler Implementation for Flexible Constructor Bodies

Reviewed-by: vromero, liach, jlahoda

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

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

From liach at openjdk.org  Thu May  8 16:06:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 16:06:00 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065
In-Reply-To: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
Message-ID: <RpPtnoiQYCcLnfj396dzY1vwdbDK-7lCD7MfLOKrNJ4=.5a98bed0-0f0c-4166-9941-cfe75efc9920@github.com>

On Wed, 7 May 2025 19:25:03 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fixed an issue where if RichDiagnosticFormatter was used recursively, it would overwrite instance state. That fix added guards to prevent the logic from being used recursively. As reported in [JDK-8356441](https://bugs.openjdk.org/browse/JDK-8356441) there are other situations where RichDiagnosticFormatter is used recursively. This fixes updates it to support being used recursively, by saving and restoring instance state on recursive calls.

test/langtools/tools/javac/annotations/typeAnnotations/RichFormatterWithTypeAnnotationsReentrantTest.java line 126:

> 124:                         "^",
> 125:                         "1 error",
> 126:                         "1 warning");

These messages are locale specific. I don't know if we can detect the keys for these messages instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25105#discussion_r2080022589

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

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: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

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

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From cushon at openjdk.org  Thu May  8 16:12:52 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 8 May 2025 16:12:52 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065
In-Reply-To: <RpPtnoiQYCcLnfj396dzY1vwdbDK-7lCD7MfLOKrNJ4=.5a98bed0-0f0c-4166-9941-cfe75efc9920@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
 <RpPtnoiQYCcLnfj396dzY1vwdbDK-7lCD7MfLOKrNJ4=.5a98bed0-0f0c-4166-9941-cfe75efc9920@github.com>
Message-ID: <28oRlsToORXEBq8ljuRRfZA3_Ick25s7h4C-wZhl49w=.b02c8a87-ec93-428c-b152-070cdc616a10@github.com>

On Thu, 8 May 2025 16:03:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fixed an issue where if RichDiagnosticFormatter was used recursively, it would overwrite instance state. That fix added guards to prevent the logic from being used recursively. As reported in [JDK-8356441](https://bugs.openjdk.org/browse/JDK-8356441) there are other situations where RichDiagnosticFormatter is used recursively. This fixes updates it to support being used recursively, by saving and restoring instance state on recursive calls.
>
> test/langtools/tools/javac/annotations/typeAnnotations/RichFormatterWithTypeAnnotationsReentrantTest.java line 126:
> 
>> 124:                         "^",
>> 125:                         "1 error",
>> 126:                         "1 warning");
> 
> These messages are locale specific. I don't know if we can detect the keys for these messages instead.

Thanks! For the purposes of the test the diagnostic text doesn't matter as long as the compiler isn't crashing. I'll look to see if there's a good way to get the diagnostic codes here, another option might be to just relax the assertion to not match on the output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25105#discussion_r2080038165

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From darcy at openjdk.org  Thu May  8 16:32:57 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 May 2025 16:32:57 GMT
Subject: Integrated: 8354091: Update RELEASE_25 description for Flexible
 Constructor Bodies
In-Reply-To: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
References: <jgO6yTIH1ukaf-fNGkSyQ_PEQYqJjBYxr1ACz5J2J-g=.036571d2-c69a-4d99-82cd-bc1ba1affd7c@github.com>
Message-ID: <TYVWLQ8Csfmj0bCNpspbuzlCIIVaHq9nwst3a478oPE=.0bdc69d5-0dff-4efa-ba11-64d7b3d35e65@github.com>

On Tue, 6 May 2025 00:10:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Getting ready for this SourceVersions change to be pushed after 
> 
>     JDK-8344703: Compiler Implementation for Flexible Constructor Bodies
>     
> is integrated.

This pull request has now been integrated.

Changeset: 24d84cf6
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24d84cf66a47e10002a836275794f3f17e147c99
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8354091: Update RELEASE_25 description for Flexible Constructor Bodies

Reviewed-by: iris, liach, vromero

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

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

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
>> 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
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> 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: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From liach at openjdk.org  Thu May  8 17:10:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 17:10:51 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065
In-Reply-To: <28oRlsToORXEBq8ljuRRfZA3_Ick25s7h4C-wZhl49w=.b02c8a87-ec93-428c-b152-070cdc616a10@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
 <RpPtnoiQYCcLnfj396dzY1vwdbDK-7lCD7MfLOKrNJ4=.5a98bed0-0f0c-4166-9941-cfe75efc9920@github.com>
 <28oRlsToORXEBq8ljuRRfZA3_Ick25s7h4C-wZhl49w=.b02c8a87-ec93-428c-b152-070cdc616a10@github.com>
Message-ID: <0ubapKkgcURpIAycIyjg_mw5nZZffa20uAeZUIoxjFc=.d1842035-d833-4a20-9296-1701ac71d1ae@github.com>

On Thu, 8 May 2025 16:10:39 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> test/langtools/tools/javac/annotations/typeAnnotations/RichFormatterWithTypeAnnotationsReentrantTest.java line 126:
>> 
>>> 124:                         "^",
>>> 125:                         "1 error",
>>> 126:                         "1 warning");
>> 
>> These messages are locale specific. I don't know if we can detect the keys for these messages instead.
>
> Thanks! For the purposes of the test the diagnostic text doesn't matter as long as the compiler isn't crashing. I'll look to see if there's a good way to get the diagnostic codes here, another option might be to just relax the assertion to not match on the output.

Yep, or running with jtreg options or flags to ensure the locale of the JVM would work too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25105#discussion_r2080125064

From aph at openjdk.org  Thu May  8 17:23:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:23:09 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v5]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <h49xNNsfCgZ8Nbnc9ZctlLktqYWV-n5j-ojQZUTHtEQ=.4d792781-40bf-4123-88ca-be9c10a420ff@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

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

  ScopedValue::orElse() does not accept null as an argument.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/8f626617..a80b034c

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

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

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

From aph at openjdk.org  Thu May  8 17:23:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:23:09 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <NQ32IYSUNxVd-tXxSsXcQws2oqloSMOOsFkLhZOZTHI=.79bb71a2-d132-4ebe-920f-2694761a7e06@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
 <NQ32IYSUNxVd-tXxSsXcQws2oqloSMOOsFkLhZOZTHI=.79bb71a2-d132-4ebe-920f-2694761a7e06@github.com>
Message-ID: <DSWIRvVOesuILrioviU6AKwaA1V_4olZcYcgkvWJG94=.576853bc-4c40-48fa-9568-58b1e6ed15d5@github.com>

On Wed, 30 Apr 2025 12:48:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this?

Fixed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863756144

From aph at openjdk.org  Thu May  8 17:29:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:29:08 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v6]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <gn_ctjNLQw59RNq3o8RQxt1jPn3Exs-UZtKH68v8PPc=.6970ce11-ec2a-4554-82ec-1b7633424034@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Fix merge
 - Merge from https://github.com/openjdk/jdk
 - ScopedValue::orElse() does not accept null as an argument.
 - Remove unnecessary @since 25
 - Remove unnecessary @enablePreview in some tests
 - Since when?
 - ScopedValue::orElse() does not accept null as an argument.
 - 8355720: Implement JEP 506: Scoped Values
 - Implement JEP 506: Scoped Values

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

Changes: https://git.openjdk.org/jdk/pull/24923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=05
  Stats: 21 lines in 5 files changed: 3 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/24923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24923/head:pull/24923

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

From aph at openjdk.org  Thu May  8 17:33:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 May 2025 17:33:09 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>

> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a null argument.

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

  Fix merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24923/files
  - new: https://git.openjdk.org/jdk/pull/24923/files/8354bcb5..7d354394

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

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

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

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From duke at openjdk.org  Thu May  8 17:49:59 2025
From: duke at openjdk.org (Petr Portnov | PROgrm_JARvis)
Date: Thu, 8 May 2025 17:49:59 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <o_ZGOUToREyR8QkQz4xtNtq6-U9IWhynBN27rGfFQ0E=.bcc1b4ca-fc3a-4c62-ac97-76c8f3eea5b4@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

src/java.base/share/classes/java/lang/ScopedValue.java line 613:

> 611:      */
> 612:     public T orElse(T other) {
> 613:         Objects.requireNonNull(other);

Shouldn't the NPE be specified in the Javadoc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2080181692

From cushon at openjdk.org  Thu May  8 17:51:13 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 8 May 2025 17:51:13 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065 [v2]
In-Reply-To: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
Message-ID: <WESp4ZCwzjs_d7qs0EglDFRmiJ8iNmAw2Ml8t5kF_V0=.cd8d95d1-6a34-4040-aca8-8d1508f71612@github.com>

> [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fixed an issue where if RichDiagnosticFormatter was used recursively, it would overwrite instance state. That fix added guards to prevent the logic from being used recursively. As reported in [JDK-8356441](https://bugs.openjdk.org/browse/JDK-8356441) there are other situations where RichDiagnosticFormatter is used recursively. This fixes updates it to support being used recursively, by saving and restoring instance state on recursive calls.

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

 - Avoid asserting on localized text
 - Merge remote-tracking branch 'origin/master' into b416188790
 - Imports
 - 8356441: IllegalStateException in RichDiagnosticFormatter after JDK-8355065

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25105/files
  - new: https://git.openjdk.org/jdk/pull/25105/files/d7238c1d..7babdb1e

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

  Stats: 733 lines in 20 files changed: 568 ins; 85 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/25105.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25105/head:pull/25105

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

From liach at openjdk.org  Thu May  8 17:51:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 17:51:13 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065 [v2]
In-Reply-To: <WESp4ZCwzjs_d7qs0EglDFRmiJ8iNmAw2Ml8t5kF_V0=.cd8d95d1-6a34-4040-aca8-8d1508f71612@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
 <WESp4ZCwzjs_d7qs0EglDFRmiJ8iNmAw2Ml8t5kF_V0=.cd8d95d1-6a34-4040-aca8-8d1508f71612@github.com>
Message-ID: <L5rsxxQD5mde8QbZcje-IY6C9WRdmf8fSysNmJK0Wmk=.929c341b-d970-4210-9f6f-f5008cddf567@github.com>

On Thu, 8 May 2025 17:48:32 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fixed an issue where if RichDiagnosticFormatter was used recursively, it would overwrite instance state. That fix added guards to prevent the logic from being used recursively. As reported in [JDK-8356441](https://bugs.openjdk.org/browse/JDK-8356441) there are other situations where RichDiagnosticFormatter is used recursively. This fixes updates it to support being used recursively, by saving and restoring instance state on recursive calls.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Avoid asserting on localized text
>  - Merge remote-tracking branch 'origin/master' into b416188790
>  - Imports
>  - 8356441: IllegalStateException in RichDiagnosticFormatter after JDK-8355065

Looks sensible

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25105#pullrequestreview-2825912253

From cushon at openjdk.org  Thu May  8 17:51:13 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 8 May 2025 17:51:13 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065 [v2]
In-Reply-To: <0ubapKkgcURpIAycIyjg_mw5nZZffa20uAeZUIoxjFc=.d1842035-d833-4a20-9296-1701ac71d1ae@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
 <RpPtnoiQYCcLnfj396dzY1vwdbDK-7lCD7MfLOKrNJ4=.5a98bed0-0f0c-4166-9941-cfe75efc9920@github.com>
 <28oRlsToORXEBq8ljuRRfZA3_Ick25s7h4C-wZhl49w=.b02c8a87-ec93-428c-b152-070cdc616a10@github.com>
 <0ubapKkgcURpIAycIyjg_mw5nZZffa20uAeZUIoxjFc=.d1842035-d833-4a20-9296-1701ac71d1ae@github.com>
Message-ID: <ZQqZVfSwXQe_2Nlxh2pwjOjGA9jDfjwq0d3t9jrHoTo=.16a00148-918f-40e6-ad8a-fa5dee2cb5ae@github.com>

On Thu, 8 May 2025 17:08:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Thanks! For the purposes of the test the diagnostic text doesn't matter as long as the compiler isn't crashing. I'll look to see if there's a good way to get the diagnostic codes here, another option might be to just relax the assertion to not match on the output.
>
> Yep, or running with jtreg options or flags to ensure the locale of the JVM would work too.

I updated this to just assert it exits with a regular diagnostic error instead of a crash.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25105#discussion_r2080179193

From liach at openjdk.org  Thu May  8 18:05:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 18:05:55 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <o_ZGOUToREyR8QkQz4xtNtq6-U9IWhynBN27rGfFQ0E=.bcc1b4ca-fc3a-4c62-ac97-76c8f3eea5b4@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <o_ZGOUToREyR8QkQz4xtNtq6-U9IWhynBN27rGfFQ0E=.bcc1b4ca-fc3a-4c62-ac97-76c8f3eea5b4@github.com>
Message-ID: <WF_FZi87cHdpZxxfsw6ni_AmiEaTfb3O1bvisjSS6Mc=.349014ba-1ff0-450f-86f1-1c3286dd7073@github.com>

On Thu, 8 May 2025 17:47:12 GMT, Petr Portnov | PROgrm_JARvis <duke at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 613:
> 
>> 611:      */
>> 612:     public T orElse(T other) {
>> 613:         Objects.requireNonNull(other);
> 
> Shouldn't the NPE be specified in the Javadoc?

In the class specification, right above the API notes:

 * <p> Unless otherwise specified, passing a {@code null} argument to a method in this
 * class will cause a {@link NullPointerException} to be thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24923#discussion_r2080203356

From liach at openjdk.org  Thu May  8 18:20:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 18:20:54 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863891143

From liach at openjdk.org  Thu May  8 18:23:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 18:23:54 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <1r-gaHy_VBrhT8yIqt2UIJ6g87BHJUJOWsSsxMOzTyA=.97592f84-858c-4a18-a19c-2a04885fdef3@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

Reviewed the Javadoc and specification updates and `@enablePreview` removals for the end of preview. These are all related tests that can have the directive removed, aside from the thread flock test I asked about.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2825991095

From alanb at openjdk.org  Thu May  8 18:40:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 18:40:55 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
Message-ID: <oszVdhpU15ledtaju36JyfGNG4N43Q7q_bXvWIwiv64=.17a88f47-ef05-4d5a-9df7-459c09bec3a2@github.com>

On Thu, 8 May 2025 18:18:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead?

ThreadFlock supports the inheritance of scoped values into structured concurrency contexts. No changes in this PR to that construct.

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863955030

From vromero at openjdk.org  Thu May  8 18:57:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 8 May 2025 18:57:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
Message-ID: <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>

On Thu, 8 May 2025 13:33:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - addressing review comment
>  - changes to test
>  - Merge branch 'master' into JDK-8354556
>  - updating test
>  - final adjustments
>  - additional refactorings
>  - removing unneeded changes
>  - more refactorings
>  - more refactorings and tests
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/900b3ff7...5d834ce0

note to reviewers: I had an offline discussion with Dan, I will introduce some changes to the implementation

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2863994317

From alanb at openjdk.org  Thu May  8 19:00:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 May 2025 19:00:54 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v3]
In-Reply-To: <DSWIRvVOesuILrioviU6AKwaA1V_4olZcYcgkvWJG94=.576853bc-4c40-48fa-9568-58b1e6ed15d5@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <VkBzyrZMCwgRSotwkP2RdSV3x6B83eJgZF4mU830098=.b0d247e3-966a-441c-b7a1-974613eed3b3@github.com>
 <NQ32IYSUNxVd-tXxSsXcQws2oqloSMOOsFkLhZOZTHI=.79bb71a2-d132-4ebe-920f-2694761a7e06@github.com>
 <DSWIRvVOesuILrioviU6AKwaA1V_4olZcYcgkvWJG94=.576853bc-4c40-48fa-9568-58b1e6ed15d5@github.com>
Message-ID: <FuN5J7ypBsvyW2GXNpr_9mIZ59fQrYtbfNoVK1gXgKY=.c93ce9f9-87cc-4108-a0bf-09528dc80f3c@github.com>

On Thu, 8 May 2025 17:18:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this?
>
>> @theRealAph Can you include the update to javax/security/auth/Subject.java as part of this?
> 
> Fixed now.

@theRealAph One other test that will need attention is runtime/ClassFile/ClassFileVersionTest.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2864000920

From liach at openjdk.org  Thu May  8 19:53:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 19:53:53 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <p1-YD8qt9XC1iQmDHogYaEYqIepOV20IJ5Zhgipoq38=.6829d786-6557-49ad-94a1-b0f22290bac8@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

May I provide a quick patch to use an alternative mechanism to test preview class file versions for that class instead of changing that in this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2864114798

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From cushon at openjdk.org  Thu May  8 21:31:55 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 8 May 2025 21:31:55 GMT
Subject: RFR: 8347291: Exhaustive switch over a generic sealed abstract
 class [v2]
In-Reply-To: <Emxf5G5iVLbrdC4Qmj1-_13G_CJTjhoANXNZqrIQltY=.b0425f0c-bc34-4442-8409-ebbb09c6b0f7@github.com>
References: <TMMDmgmn3wLFjSti-hVkk5FDM6nqW1P3r51LZ7iVXDU=.305ed575-f9d6-4815-b28a-23513d79627f@github.com>
 <Emxf5G5iVLbrdC4Qmj1-_13G_CJTjhoANXNZqrIQltY=.b0425f0c-bc34-4442-8409-ebbb09c6b0f7@github.com>
Message-ID: <8lIuDGWDb5_71rpY9mvjxTc57V1egrj8i5wloxn0YI0=.fcc6a2f2-57fc-42ff-84d9-d4377b543975@github.com>

On Sun, 6 Apr 2025 04:52:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change avoids javac incorrectly reporting switches like the example in [JDK-8347291](https://bugs.openjdk.org/browse/JDK-8347291) as exhaustive.
>> 
>> As Jan noted in the bug it seems like the inference behaviour here may not be correct. If it was able to infer a type without crashing that would also avoid the bug.
>> 
>> However with the current inference behaviour, it's safer to assume that if inference crashes the subtype may need to be handled by the switch, instead of assuming that it doesn't.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Handle error types in InferenceUnitTest
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - 8347291: Exhaustive switch over a generic sealed abstract class

> IIRC, I was looking into this when this came up. I think when I was debugging, there seemed to be incorrectly sorted bounds sent to intersection type, which then broke the rest of the inference machinery. I've had this: [lahodaj at 108e5af](https://github.com/lahodaj/jdk/commit/108e5afa2bca60c5ae9b1270c23865aa615bfe52)
> 
> But I think, at that time, the idea was to take a better look at the (pattern) inference as a whole.
> 
> @mcimadamore - any insights? Thanks!

Thanks! My feeling here is still that this is complementary to inference fixes, as long as there's a `} catch (Infer.InferenceException ex) {` I think it's worth considering treating that case conservatively, i.e. not assuming a switch is exhaustive if inference throws an exception.

If it's possible to ensure inference never throws an exception that needs to be caught that would also be good, and avoids this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23286#issuecomment-2864362304

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 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: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
>> 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
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From dholmes at openjdk.org  Fri May  9 02:08:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 02:08:58 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <IQH5pfqDgtW2UCEbM800YyXfqbnB9VBT8f3T0oGZ3tY=.99cb3c22-45d4-43d8-a575-379b315bbc14@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <IQH5pfqDgtW2UCEbM800YyXfqbnB9VBT8f3T0oGZ3tY=.99cb3c22-45d4-43d8-a575-379b315bbc14@github.com>
Message-ID: <iVZYQLfDj7Otw7cwmAhj4Q1YWpyXbCIpt3pIlzhB61Q=.504812a7-1024-4ce2-8a84-285db9f2452d@github.com>

On Thu, 8 May 2025 13:18:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Update release date
>  - Update --release 25 symbol information for JDK 25 build 21
>    The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>    
>    # Conflicts:
>    #	test/langtools/tools/javac/versions/Versions.java
>  - feedback: never bump ASM version
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274
>     + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274
>     + update src/java.compiler/share/classes/...

Hotspot source and test changes look trivially good.

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2826771967

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From alanb at openjdk.org  Fri May  9 05:56:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 05:56:51 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <p1-YD8qt9XC1iQmDHogYaEYqIepOV20IJ5Zhgipoq38=.6829d786-6557-49ad-94a1-b0f22290bac8@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <p1-YD8qt9XC1iQmDHogYaEYqIepOV20IJ5Zhgipoq38=.6829d786-6557-49ad-94a1-b0f22290bac8@github.com>
Message-ID: <oVXDQkJ3zdmpE0yOmrIyCS6r3riw-FXwy4dj4vKrSF0=.cc235b02-1a33-4466-afe4-d406b22a2f23@github.com>

On Thu, 8 May 2025 19:51:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> May I provide a quick patch to use an alternative mechanism to test preview class file versions for that class instead of changing that in this PR?

That would be good as it shouldn't depend on ScopedValue being a preview API class.

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865223857

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
>> 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
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From alanb at openjdk.org  Fri May  9 08:21:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:21:55 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v7]
In-Reply-To: <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
Message-ID: <IChO1rwbpyy_NOsxnZ28x__1qUf5ewjDeaR9HcvPkxQ=.478bfd01-6ecc-4261-9a32-024b3776b186@github.com>

On Tue, 29 Apr 2025 10:15:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
>> 
>> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>    
>    [skip ci]
>  - User copyright text w/o `"Classpath" exception`
>    
>    [skip ci]

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 278:

> 276:      */
> 277:     private URL toResourceInRootPath(String name) {
> 278:         var file = programDescriptor.sourceRootPath().resolve(name);

"name" is an abstract resource name, so it's a '/' separated sequence of names. Is there is mapping step missing here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2081175002

From alanb at openjdk.org  Fri May  9 08:26:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:26:56 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v7]
In-Reply-To: <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
Message-ID: <sJUAVPNBjPpge0lyYdUG_BevuhV75Wk2EqQBe_3XmrA=.67748589-9354-4200-90dd-78808869c41c@github.com>

On Tue, 29 Apr 2025 10:15:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
>> 
>> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>    
>    [skip ci]
>  - User copyright text w/o `"Classpath" exception`
>    
>    [skip ci]

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 232:

> 230:         String binaryName = toBinaryName(name);
> 231:         if (binaryName == null || sourceFileClasses.get(binaryName) == null) {
> 232:             return toResourceInRootPath(name); // can be null

"can be null" is a bit confusing here. I initially read it that name can be null but this isn't possible, at least not with a well behaved class loader as the getResource methods are specified to reject null so will never delegate a null to findResource. The comment is really that it might return null (meaning not found).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2081182875

From aph at openjdk.org  Fri May  9 08:28:00 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 May 2025 08:28:00 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <nT6D0pn8ukOB8fEymeCgTQz93g_xIA7COYgQyVIHw7E=.fe01335c-3c95-40d8-9b8a-525287ec045f@github.com>
Message-ID: <tiQjg6Rvni0fJX1557KfFYZWy35Zn2k-491gLESdQEI=.6f8ff4e8-94c1-4a78-9b97-9e0cc82acb0b@github.com>

On Thu, 8 May 2025 18:18:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> I noted that `ThreadFlock` is using scoped values but throwing `StructureViolationException` introduced by structured concurrency - is it considered an implementation artifact and part of structured concurrency instead?
> 
> Context: test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java

That's an interesting question that I'll leave to @AlanBateman .

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865632535

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From alanb at openjdk.org  Fri May  9 08:32:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:32:56 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
Message-ID: <dFux5Ige8612jyYeGHCX-gFS_grEz7AJC_0T337pvDk=.4a59627c-7100-452c-aa49-8c0295c1ae06@github.com>

On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge

> I'm getting a test failure in [ClassFileVersionTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java#45) because `ScopedValue` is not a Preview API. Should I just fix the test to use some other Preview Class?

Chen offered to change this test to use the ClassFile API and construct the class with the preview minor number. The PR to change this test is reviewed so I think all good, nothing more to do here.

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865640747

From alanb at openjdk.org  Fri May  9 08:32:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:32:57 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v7]
In-Reply-To: <dFux5Ige8612jyYeGHCX-gFS_grEz7AJC_0T337pvDk=.4a59627c-7100-452c-aa49-8c0295c1ae06@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <kH601TXb6NC3f3cIpp2Y5J3q61-taMDydwBSUPxbbEY=.54ec23d3-3f35-4ff4-853d-1add193fb80c@github.com>
 <dFux5Ige8612jyYeGHCX-gFS_grEz7AJC_0T337pvDk=.4a59627c-7100-452c-aa49-8c0295c1ae06@github.com>
Message-ID: <N7XVebZ3fAxePrUsXVkQqUU-koehhmX-hVXevzK0tlM=.bb56e3f8-e79e-48ac-be82-45429dcaf714@github.com>

On Fri, 9 May 2025 08:28:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge
>
>> I'm getting a test failure in [ClassFileVersionTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java#45) because `ScopedValue` is not a Preview API. Should I just fix the test to use some other Preview Class?
> 
> Chen offered to change this test to use the ClassFile API and construct the class with the preview minor number. The PR to change this test is reviewed so I think all good, nothing more to do here.

> That's an interesting question that I'll leave to @AlanBateman .

Nothing to do as the test uses StructureViolationException so needs to continue to be compile/run with preview features enabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2865643883

From cstein at openjdk.org  Fri May  9 08:41:57 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 08:41:57 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v7]
In-Reply-To: <IChO1rwbpyy_NOsxnZ28x__1qUf5ewjDeaR9HcvPkxQ=.478bfd01-6ecc-4261-9a32-024b3776b186@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
 <IChO1rwbpyy_NOsxnZ28x__1qUf5ewjDeaR9HcvPkxQ=.478bfd01-6ecc-4261-9a32-024b3776b186@github.com>
Message-ID: <pMSG0TaQx67griXS8ByZ46CFzuA4IF2b9fpEVnt49-s=.9cba8bf2-b649-4b85-a323-2835eba0a30b@github.com>

On Fri, 9 May 2025 08:19:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>    
>>    [skip ci]
>>  - User copyright text w/o `"Classpath" exception`
>>    
>>    [skip ci]
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 278:
> 
>> 276:      */
>> 277:     private URL toResourceInRootPath(String name) {
>> 278:         var file = programDescriptor.sourceRootPath().resolve(name);
> 
> "name" is an abstract resource name, so it's a '/' separated sequence of names. Is there is mapping step missing here?

Hm, if it missing, it was missing before. I moved the line from the former location with a different variable name:
`var programPath = programDescriptor.sourceRootPath().resolve(name);` into this new helper method. All tests and manual usages remain "green".

Which kind of mapping are you missing here? From `/` to `\` or `.`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2081212514

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From cstein at openjdk.org  Fri May  9 08:44:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 08:44:53 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v7]
In-Reply-To: <sJUAVPNBjPpge0lyYdUG_BevuhV75Wk2EqQBe_3XmrA=.67748589-9354-4200-90dd-78808869c41c@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
 <sJUAVPNBjPpge0lyYdUG_BevuhV75Wk2EqQBe_3XmrA=.67748589-9354-4200-90dd-78808869c41c@github.com>
Message-ID: <HxuasqCpE_FJBU2lVnmOf4VrIeAT6Uc5Nd44QV8MWSg=.28f1e749-0e5f-4538-9417-3c310c88d411@github.com>

On Fri, 9 May 2025 08:24:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>    
>>    [skip ci]
>>  - User copyright text w/o `"Classpath" exception`
>>    
>>    [skip ci]
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 232:
> 
>> 230:         String binaryName = toBinaryName(name);
>> 231:         if (binaryName == null || sourceFileClasses.get(binaryName) == null) {
>> 232:             return toResourceInRootPath(name); // can be null
> 
> "can be null" is a bit confusing here. I initially read it that name can be null but this isn't possible, at least not with a well behaved class loader as the getResource methods are specified to reject null so will never delegate a null to findResource. The comment is really that it might return null (meaning not found).

Yes. I can either update the comment to read `returning null here is expected by the caller` or refactor the method to read `toResourceInRootPathOrNull(String name)`. Another option would be to make the return type an `Optional<URL>` and handle the not-available case at the call site.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2081217674

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From alanb at openjdk.org  Fri May  9 09:28:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 09:28:52 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v7]
In-Reply-To: <pMSG0TaQx67griXS8ByZ46CFzuA4IF2b9fpEVnt49-s=.9cba8bf2-b649-4b85-a323-2835eba0a30b@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
 <IChO1rwbpyy_NOsxnZ28x__1qUf5ewjDeaR9HcvPkxQ=.478bfd01-6ecc-4261-9a32-024b3776b186@github.com>
 <pMSG0TaQx67griXS8ByZ46CFzuA4IF2b9fpEVnt49-s=.9cba8bf2-b649-4b85-a323-2835eba0a30b@github.com>
Message-ID: <j_1Exnsl0LOT1QCeqoKabekU6FENIwl4Lbp_GUDTpVk=.0e688efc-fbc6-48a2-b249-e06ec017f93f@github.com>

On Fri, 9 May 2025 08:39:17 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 278:
>> 
>>> 276:      */
>>> 277:     private URL toResourceInRootPath(String name) {
>>> 278:         var file = programDescriptor.sourceRootPath().resolve(name);
>> 
>> "name" is an abstract resource name, so it's a '/' separated sequence of names. Is there is mapping step missing here?
>
> Hm, if it missing, it was missing before. I moved the line from the former location with a different variable name:
> `var programPath = programDescriptor.sourceRootPath().resolve(name);` into this new helper method. All tests and manual usages remain "green".
> 
> Which kind of mapping are you missing here? From `/` to `\` or `.`?

In java.base, look at jdk.internal.module.Resources.toFilePath to see how the built-in class loaders map resource names to relative file paths. I don't think you'll need as much here. My point is that a resource name can't be be used a file path. Also it's okay if you want to separate it to a separate issue, it's just something that jumps out when scanning this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2081296721

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From cstein at openjdk.org  Fri May  9 09:47:12 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:47:12 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v8]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <c1akLHQqwslWwoteAf__QLxKY38y30y0Li3WFMmEqaE=.60e6704e-f0cd-464e-aafc-975a10e41e77@github.com>

> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
> 
> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.

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

  Reuse internal resource resolver and remove confusing comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/0a65733f..b6ebbf0c

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

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

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

From cstein at openjdk.org  Fri May  9 09:47:12 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:47:12 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v7]
In-Reply-To: <j_1Exnsl0LOT1QCeqoKabekU6FENIwl4Lbp_GUDTpVk=.0e688efc-fbc6-48a2-b249-e06ec017f93f@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
 <IChO1rwbpyy_NOsxnZ28x__1qUf5ewjDeaR9HcvPkxQ=.478bfd01-6ecc-4261-9a32-024b3776b186@github.com>
 <pMSG0TaQx67griXS8ByZ46CFzuA4IF2b9fpEVnt49-s=.9cba8bf2-b649-4b85-a323-2835eba0a30b@github.com>
 <j_1Exnsl0LOT1QCeqoKabekU6FENIwl4Lbp_GUDTpVk=.0e688efc-fbc6-48a2-b249-e06ec017f93f@github.com>
Message-ID: <AsGtSmmi5XGxoZhQExA0oJIG7xStOqFwR3DLyuKFuNs=.adde49fb-264e-46d5-8810-a2a9a5601793@github.com>

On Fri, 9 May 2025 09:26:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hm, if it missing, it was missing before. I moved the line from the former location with a different variable name:
>> `var programPath = programDescriptor.sourceRootPath().resolve(name);` into this new helper method. All tests and manual usages remain "green".
>> 
>> Which kind of mapping are you missing here? From `/` to `\` or `.`?
>
> In java.base, look at jdk.internal.module.Resources.toFilePath to see how the built-in class loaders map resource names to relative file paths. I don't think you'll need as much here. My point is that a resource name can't be be used a file path. Also it's okay if you want to separate it to a separate issue, it's just something that jumps out when scanning this.

Right. With `jdk.internal.module.Resources` being already used in the `MemoryModuleFinder` sibling, I'll replace the too simple `.resolve(name)` as suggested and in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2081327935

From cstein at openjdk.org  Fri May  9 09:52:13 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:52:13 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v9]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <ksI7OYmN0EVhzakrZcV9Fgvji2b0fkPZo1zjH9Vwt2w=.d1be8faf-6276-4c1c-ba21-a3e48bbffbbb@github.com>

> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
> 
> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.

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

  Fix interim javac compilation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/b6ebbf0c..809122fb

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

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

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

From ihse at openjdk.org  Fri May  9 10:04:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:04:09 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v3]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <OaO3i0WE6Wt6FDeg9Chm58zh4Vg-jJ5oMOkpvc0PRhA=.208dfa65-1b75-4952-9a65-c326b1118c06@github.com>

> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
> 
> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
> 
> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
> 
> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

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

 - Merge branch 'master' into unicode-sequence-in-comments
 - Merge branch 'master' into unicode-sequence-in-comments
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/694b33dc..dd9a77c5

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

  Stats: 14771 lines in 491 files changed: 7892 ins; 4380 del; 2499 mod
  Patch: https://git.openjdk.org/jdk/pull/24727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727

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

From ihse at openjdk.org  Fri May  9 10:12:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:12:09 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v4]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>

> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
> 
> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
> 
> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
> 
> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Clarify non-ASCII characters with unicode code point

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/dd9a77c5..53aa4066

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

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

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

From ihse at openjdk.org  Fri May  9 10:12:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:12:12 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v2]
In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
Message-ID: <T7BaCfqTjE-a2Soo1fPYD3PnJ64bsS-YM27NLwxcuKY=.aa500d13-5cad-4bea-aaa5-c94f7118b21b@github.com>

On Tue, 6 May 2025 17:16:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into unicode-sequence-in-comments
>>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters
>
> src/java.base/share/classes/java/text/RuleBasedCollator.java line 594:
> 
>> 592:         // a three-digit number, one digit for primary, one for secondary, etc.
>> 593:         //
>> 594:         // String:              A     a     B   ?
> 
> Maybe "? (\u00e9, e-acute)"?

I used the `U+` code point notation here as well. I think that is better to make sure there are no misunderstandings, and no risk of the escaped character inadvertently being converted into an actual unicode character down the line by processors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2081372676

From cstein at openjdk.org  Fri May  9 10:44:52 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 10:44:52 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v10]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <8bndEf05H0ECJqpRh8wLY6-DYjgv96iij8fhzEUA_JY=.76a9daec-54e8-4059-8bc7-66af6c7c8720@github.com>

> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
> 
> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.

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

  Catch and rethrow IO exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/809122fb..3b825161

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

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

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

From ihse at openjdk.org  Fri May  9 10:47:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:47:53 GMT
Subject: RFR: 8354968: Replace unicode sequences in comment text with UTF-8
 characters [v4]
In-Reply-To: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
Message-ID: <xA7HUgNAtNicDp0v65bJcACLZBbMCZQjiUgARidIM0U=.fac13cc3-1cb0-4b99-a514-8584238d7ff0@github.com>

On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
>> 
>> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
>> 
>> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
>> 
>> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify non-ASCII characters with unicode code point

Now that [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971) is committed, this PR is ready to be integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24727#issuecomment-2866080024

From cstein at openjdk.org  Fri May  9 11:14:18 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 11:14:18 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v11]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <tvH5crtuN_sBnvUvsTqFj0_AfAWowY-8cGhMTxghTdE=.353298d8-7606-4ead-9feb-8d4aa9d21c0e@github.com>

> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
> 
> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.

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

  Removed redundant catch block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/3b825161..c921f2c9

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

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

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

From cstein at openjdk.org  Fri May  9 11:37:52 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 11:37:52 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v7]
In-Reply-To: <HxuasqCpE_FJBU2lVnmOf4VrIeAT6Uc5Nd44QV8MWSg=.28f1e749-0e5f-4538-9417-3c310c88d411@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <RP_isAMESaw6eZCoeXg6DdqJXJtu8wsT3j1gk8O_USY=.d4e5cead-a8ee-4496-b076-d09ba9866a18@github.com>
 <sJUAVPNBjPpge0lyYdUG_BevuhV75Wk2EqQBe_3XmrA=.67748589-9354-4200-90dd-78808869c41c@github.com>
 <HxuasqCpE_FJBU2lVnmOf4VrIeAT6Uc5Nd44QV8MWSg=.28f1e749-0e5f-4538-9417-3c310c88d411@github.com>
Message-ID: <U-NDhFAC3z2djnZNIIfinSep6yJp2cGkzw26dBZGjQ8=.bdb2a0c4-7ef8-454b-9a9b-ad4b55a62e4e@github.com>

On Fri, 9 May 2025 08:42:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 232:
>> 
>>> 230:         String binaryName = toBinaryName(name);
>>> 231:         if (binaryName == null || sourceFileClasses.get(binaryName) == null) {
>>> 232:             return toResourceInRootPath(name); // can be null
>> 
>> "can be null" is a bit confusing here. I initially read it that name can be null but this isn't possible, at least not with a well behaved class loader as the getResource methods are specified to reject null so will never delegate a null to findResource. The comment is really that it might return null (meaning not found).
>
> Yes. I can either update the comment to read `returning null here is expected by the caller` or refactor the method to read `toResourceInRootPathOrNull(String name)`. Another option would be to make the return type an `Optional<URL>` and handle the not-available case at the call site.

I removed the comment without touching any names nor return types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2081488836

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). 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 plown through testcases:
> 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
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From mullan at openjdk.org  Fri May  9 13:26:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 May 2025 13:26:53 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v6]
In-Reply-To: <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <IGzpehDXDsv_5MZ1ZOO1MnrqLPp1bYNS4anT8Z-8f88=.577c3298-d6d9-48bc-86cf-21c83bfb910b@github.com>
Message-ID: <XIUm_tuA58_jwhqIDYBGu2ohThmDW54vfyJ2-PFvItU=.612b809e-c3e5-496c-87e0-f9b8a8a126d8@github.com>

On Fri, 2 May 2025 18:49:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Finalize the KDF API.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fine tuning debug log and exception message

We should also update the comments and info string of `com/sun/crypto/provider/SunJCE.java` with the HKDF algorithms.

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

PR Comment: https://git.openjdk.org/jdk/pull/24520#issuecomment-2866532132

From mcimadamore at openjdk.org  Fri May  9 14:03:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 May 2025 14:03:52 GMT
Subject: RFR: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065 [v2]
In-Reply-To: <WESp4ZCwzjs_d7qs0EglDFRmiJ8iNmAw2Ml8t5kF_V0=.cd8d95d1-6a34-4040-aca8-8d1508f71612@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
 <WESp4ZCwzjs_d7qs0EglDFRmiJ8iNmAw2Ml8t5kF_V0=.cd8d95d1-6a34-4040-aca8-8d1508f71612@github.com>
Message-ID: <LCzN8OlLg6RnJNxp16G_TbUJwtKWQdouoaoix7X3lbA=.41cc0b51-fb0a-4aed-8ef5-597d4d002202@github.com>

On Thu, 8 May 2025 17:51:13 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fixed an issue where if RichDiagnosticFormatter was used recursively, it would overwrite instance state. That fix added guards to prevent the logic from being used recursively. As reported in [JDK-8356441](https://bugs.openjdk.org/browse/JDK-8356441) there are other situations where RichDiagnosticFormatter is used recursively. This fixes updates it to support being used recursively, by saving and restoring instance state on recursive calls.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Avoid asserting on localized text
>  - Merge remote-tracking branch 'origin/master' into b416188790
>  - Imports
>  - 8356441: IllegalStateException in RichDiagnosticFormatter after JDK-8355065

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25105#pullrequestreview-2828480418

From mcimadamore at openjdk.org  Fri May  9 14:20:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 May 2025 14:20:54 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
Message-ID: <tpW3MR9sfSHPWtWkQ5GvaB_5uXYuAhbM6TEWhtwCN8Y=.147d1c9b-6893-498b-ab13-c9578f3c0656@github.com>

On Fri, 2 May 2025 20:28:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> When an inference context (`IC`) is minimized, the minimized inference context (`MIC`) contains a proper subset of `IC's` inference vars (`IC_IV`). In other words there will be at least one inference variable `T` that belongs to `IC_IV` which doesn't belong to the minimized context inference variable's set (`MIC_IV`). MIC can be propagated to another inference context (AIC) as part of the type inference algo. If at any moment a type containing `T` needs, for example, to be instantiated `AIC` won't be able to perform that operation as it lacks the information to realize that `T` is a free variable it was supposed to know about hadn't a minimization step been performed. This PR is proposing to fix this issue without reducing the universe of inference contexts we apply the minimization algo to.
>> 
>> We are basically proposing to add a field to class InferenceContext which will be supplementary inference context that can be used to look for additional information if necessary. Also when registering a free type listener to an inference context, it could be that it won't be registered in the inference context the client could expect but in a supplementary inference context if it is found out that it contains and instantiation to all the free variables related to the listener. See also some comments inlined in the code,
>> 
>> TIA
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8325859
>  - make visitor static
>  - updating doc
>  - 8325859: potential information loss during type inference

The way this was designed, IIRC, was that if MIC is derived from IC, every time a variable is inferred in MIC, the resolution is forwarded to all the equivalent type variables in IC. If there's more type-variables in IC that are neither contained in MIC, nor equivalent to another var contained in MIC, it seems like an issue, as the minimization algo is not designed to work in this way.

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2866734687

From cstein at openjdk.org  Fri May  9 14:22:38 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 14:22:38 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v12]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <o8AKzhZkYlrO7_pM9iTksrTjTVpVxFxKLDX9dvE14Y4=.f4de0008-1205-4508-a721-818fc4aea2b8@github.com>

> Please review this change adding a missing resource file test to the `MemoryClassLoader::findResource` override in order to resolve all files beneath the source root path in source launch mode - analog to what was already implemented for `MemoryClassLoader::getResource`.
> 
> With this change applied, files in `META-INF/services/` are resolved; allowing services providers being supplied in source form.

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

  Prevent NPE by removing redundant check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/c921f2c9..79dde479

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

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

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

From maurizio.cimadamore at oracle.com  Fri May  9 14:31:09 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 9 May 2025 15:31:09 +0100
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <CANSoFxsZEAzsp5HF4J47-0Ygcd8vbjDbNjU+H80mZMvGCu=b1Q@mail.gmail.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>
 <CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com>
 <a06a4392-ebc1-4615-91c4-20ce396bb228@oracle.com>
 <CANSoFxtCCkiG1-vH_3bjSpH-bhCQKrEVJZ4zNTcG=WL=sKNMug@mail.gmail.com>
 <CANSoFxsZEAzsp5HF4J47-0Ygcd8vbjDbNjU+H80mZMvGCu=b1Q@mail.gmail.com>
Message-ID: <4a5cce73-3b39-416b-8308-2edbef4dfa15@oracle.com>

Hi Archie,
my 0.02$ below:

On 07/05/2025 19:26, Archie Cobbs wrote:
> I'd like to restart this discussion of JDK-8344159 
> <https://bugs.openjdk.org/browse/JDK-8344159>? - "Add lint warnings 
> for unnecessary warning suppression"
>
> Note, this is likely not destined for JDK 25. I'm bringing it up now 
> simply because some refactoring that arose from the previous 
> discussion back in November (which is here 
> <https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html>) 
> is now mostly done.
>
> I think a fair summary of the current state is: Having the compiler 
> emit warnings for unnecessary warning suppression is considered a 
> useful idea in principle, but it's unclear what is the best way to 
> configure/enable that functionality in the compiler.
>
> In particular, there are subtle corner cases that could be problematic 
> if these warnings were enabled by -Xlint:all, especially for -Werror 
> builds.

IMHO, this is a problem present with the addition of every new lint 
warning. It's not specific to this one. Of course, some new lint warning 
operate on brand new language features, so the potential to compromise 
existing compilaton units is low. But I'd expect that warnings such as 
"serial" would have ran into similar corner cases (e.g. previously ok 
code started to report new warnings, and to fail with Werror).

So I think this seems ok, and not enough to cause a tweak to the 
treatment of lint:all.

I'll add here that a more robust fix for Werror issues is to enable 
developers to be more specific in the warnings they'd like to promote to 
errors (as discussed in the past). I'll CC Kevin who has always been a 
fan of this feature ;-)

>
> Also complicating things, there are two different ways to suppress 
> warnings, @SuppressWarnings("foo") and -Xlint:-foo and for similar 
> "corner case" reasons they need to be configurable separately.

IMHO, the main value of this new lint warning is to detect the use of 
`@SuppressWarnings` that are redundant. Sure there's the command-line 
flavor as well, but that renders any source code analysis dependent on 
the flags passed to javac. In other words, detecting redundant 
`@SuppressWarnings` has a more "timeless" nature that does not apply to 
detecting redundant command-line suppressions. The former tells you 
something about _your code_, in a way that is independent from which 
flags you use to compile it. Which is why I think we should only worry 
about that.

Maurizio

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

From vromero at openjdk.org  Fri May  9 14:35:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 14:35:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
Message-ID: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>

> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
> 
> For more details please refer to the complete description in the corresponding JIRA entry [1]
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8354556

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

  documentation and adding alias to lint categories

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/5d834ce0..d52ec33b

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

  Stats: 101 lines in 9 files changed: 36 ins; 28 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/24746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746

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

From liach at openjdk.org  Fri May  9 14:42:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 14:42:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
Message-ID: <DlQOmW_D7TLbjg1as-pR0bIXPdatgg4Ri-RkIxoRJJs=.23ddc244-e1b5-4147-8bd3-c480c1387898@github.com>

On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation and adding alias to lint categories

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

> 432:             // we need to do this as forward references are not allowed
> 433:             if (alias != null) {
> 434:                 alias.alias = this;

I think we wish to make this a union-find-like structure (if you are familiar with leetcode problems) - we need to have some category as roots that point to themselves. Other category like synchronization can point to identity. When we use a `LintCategory` we do a "find root" to find the actual category to use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2081830955

From acobbs at openjdk.org  Fri May  9 15:00:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 15:00:56 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
Message-ID: <BpTRu7UQNj2Mout2Jc-ptU27dlRW0vFWdcT9c8QgD2g=.a7f3a1e3-8ddf-4a44-b0f3-96dbe3377dbe@github.com>

On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation and adding alias to lint categories

I don't understand the point of having two separate `LintCategory`'s `SYNCHRONIZATION` and `IDENTITY`.  That's like having two different humans just so you can call them `Robert` or `Bobby`.

Put another way, are we proposing here to temporarily support compiler configurations like `Xlint:-identity,synchronization` and `Xlint:-synchronization,identity`?
* If not, then there should be a single `LintCategory.IDENTITY` that is addressable through all the usual naming mechanisms (i.e., `@SuppressWarnings`, `-Xlint:foo`) as either `"synchronization"` or `"identity"`. That is `"synchronization"` is just a true alias.
* If so, then we are creating a future backward-incompatibility when we merge `SYNCHRONIZATION` into `IDENTITY`. After that merge, what is `Xlint:-synchronization,identity` or `Xlint:-identity,-synchronization` supposed to mean?

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2866880798

From acobbs at openjdk.org  Fri May  9 15:03:13 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 15:03:13 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v6]
In-Reply-To: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
Message-ID: <qLfio34EGI0o_1CANF7uRlcRFMKzTW4QzT5woVQaZeE=.771470ee-6a61-432b-af9c-bb417deaf0e7@github.com>

> This PR is a sub-task split off from [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features.
> 
> Lexical features don't know about classes, members or symbols, so their source file positions must be matched to the source file character offset range of the innermost containing `JCModuleDecl`, `JCPackageDecl`, `JCClassDecl`, `JCMethodDecl`, or `JCVariableDecl`. That means we need the end positions of all such declarations to be available.
> 
> The parser doesn't normally store lexical end positions unless explicitly requested, and we don't want to mandate it for performance reasons.
> 
> Instead, we can just add an `int endPos` field to these five AST nodes. This field can be populated as part of the normal parsing of these node types, which already supports the (optional) tracking of end positions.

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

 - Merge branch 'master' into JDK-8350212 to fix conflict.
 - Update copyrights.
 - Refactoring/cleanup for handling of ending positions.
 - Add missing variable decl end position.
 - Add end position for variables coming from variableDeclaratorId().
 - Track source end positions of declarations that support @SuppressWarnings.

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

Changes: https://git.openjdk.org/jdk/pull/23669/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23669&range=05
  Stats: 401 lines in 13 files changed: 203 ins; 88 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/23669.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23669/head:pull/23669

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

From liach at openjdk.org  Fri May  9 15:16:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 15:16:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v7]
In-Reply-To: <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <BErjvrR3lrvxuwYJtLzLhXTLwQ-TlxslD2MnWABEwCA=.7c1639f8-d72d-42a6-b12d-f02fdb54945f@github.com>
Message-ID: <DCD-qgyrUoWynl5O9lO18RwhCSlvOCpVeyCQ9jrjyJk=.02877687-1c4b-4e9b-aac8-f06992e086c4@github.com>

On Fri, 9 May 2025 14:35:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.
>> 
>> For more details please refer to the complete description in the corresponding JIRA entry [1]
>> 
>> TIA
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8354556
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation and adding alias to lint categories

Good point; maybe instead of creating new `LintCategory`, we use this union-find approach to deduplicate when we parse LintCategory from strings.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2866948054

From archie.cobbs at gmail.com  Fri May  9 15:23:44 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 9 May 2025 10:23:44 -0500
Subject: Proposal: Warnings for unnecessary warning suppression
In-Reply-To: <4a5cce73-3b39-416b-8308-2edbef4dfa15@oracle.com>
References: <CANSoFxth8njxzfag-Rff5WqYe7Ykx=L3e7v1VJ_ArcW8cN_iMQ@mail.gmail.com>
 <dbbf859a-6320-4058-b5ce-e99144c2f5a9@oracle.com>
 <CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com>
 <a06a4392-ebc1-4615-91c4-20ce396bb228@oracle.com>
 <CANSoFxtCCkiG1-vH_3bjSpH-bhCQKrEVJZ4zNTcG=WL=sKNMug@mail.gmail.com>
 <CANSoFxsZEAzsp5HF4J47-0Ygcd8vbjDbNjU+H80mZMvGCu=b1Q@mail.gmail.com>
 <4a5cce73-3b39-416b-8308-2edbef4dfa15@oracle.com>
Message-ID: <CANSoFxtGn7QZ85mE4yeiiyCe_Eqodm9559RO5n9rL3azy+ahzA@mail.gmail.com>

Hi Maurizio,

Thanks for your input.

On Fri, May 9, 2025 at 9:31?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> IMHO, this is a problem present with the addition of every new lint
> warning. It's not specific to this one. Of course, some new lint warning
> operate on brand new language features, so the potential to compromise
> existing compilaton units is low. But I'd expect that warnings such as
> "serial" would have ran into similar corner cases (e.g. previously ok code
> started to report new warnings, and to fail with Werror).
>
> So I think this seems ok, and not enough to cause a tweak to the treatment
> of lint:all.
>
That sounds good to me, but Joe Darcy had some reservations (see CSR). So
we would need to decide how to proceed.

Maybe the thing to do is just to ensure that it gets introduced early in
the cycle so we can get some experience with it...?

> I'll add here that a more robust fix for Werror issues is to enable
> developers to be more specific in the warnings they'd like to promote to
> errors (as discussed in the past). I'll CC Kevin who has always been a fan
> of this feature ;-)
>
Good news: that PR is already in place  :)
https://github.com/openjdk/jdk/pull/23622

> Also complicating things, there are two different ways to suppress
> warnings, @SuppressWarnings("foo") and -Xlint:-foo and for similar
> "corner case" reasons they need to be configurable separately.
>
> IMHO, the main value of this new lint warning is to detect the use of
> `@SuppressWarnings` that are redundant. Sure there's the command-line
> flavor as well, but that renders any source code analysis dependent on the
> flags passed to javac. In other words, detecting redundant
> `@SuppressWarnings` has a more "timeless" nature that does not apply to
> detecting redundant command-line suppressions. The former tells you
> something about _your code_, in a way that is independent from which flags
> you use to compile it. Which is why I think we should only worry about that.
>
I think that's a reasonable way to start - that is, we just add the
category for "suppression" now and worry later about possibly adding
"supression-option".

Joe - any thoughts?

-Archie

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

From acobbs at openjdk.org  Fri May  9 15:28:26 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 15:28:26 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v2]
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: <scBllm-kh2YIluOJqvWA44eKdIspYTH6Xu7hZEOHC0M=.4ee7fb04-2d6c-4421-a758-d1d484afc35c@github.com>

> This PR refines the `-Werror` flag to support lint categories just like `-Xlint` does. So, for example `-Werror:all,-preview` would cause an error if any warning other than a `preview` warning occurred.
> 
> A few notes:
> * Some warnings emitted by the compiler do not have a corresponding `Lint` category. As always, they cause an error if `-Werror` is given, but what if `-Werror:all` is given instead? The answer given here is yes, an error will occur.
> * The `-Werror` works the same way as before, i.e., any warning results in an error. That means if `-Werror` is given `-Werror:foo` flags have no effect.
> * Refactoring has been done to allow `-Xlint` and `-Werror` to utilize the same "parsing" logic. The existing `-Xlint` flag has a particular behavior when conflicting flags are combined (e.g., `-Xlint:all -Xlint:none -Xlint:foo -Xlint:-foo` equals `-Xlint:all`). This behavior has been preserved and Javadocumented.
> * A few minor cleanups are included

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

 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Add support for -Werror:key.

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

Changes: https://git.openjdk.org/jdk/pull/23622/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23622&range=01
  Stats: 263 lines in 14 files changed: 201 ins; 36 del; 26 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 cushon at openjdk.org  Fri May  9 15:47:58 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 9 May 2025 15:47:58 GMT
Subject: Integrated: 8356441: IllegalStateException in RichDiagnosticFormatter
 after JDK-8355065
In-Reply-To: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
References: <WSN5ffmjBckzgZ-gQS5G9BhY00U7vUEiVxBZgKoy8gA=.78318962-ba62-4918-9e97-04d74d565b9e@github.com>
Message-ID: <EyKz20k-76j3SwwsoByrdwVsdlLr-s9DzUJZanXLgek=.d89e3f05-ccca-41bc-81fa-7cd090066cfb@github.com>

On Wed, 7 May 2025 19:25:03 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> [JDK-8355065](https://bugs.openjdk.org/browse/JDK-8355065) fixed an issue where if RichDiagnosticFormatter was used recursively, it would overwrite instance state. That fix added guards to prevent the logic from being used recursively. As reported in [JDK-8356441](https://bugs.openjdk.org/browse/JDK-8356441) there are other situations where RichDiagnosticFormatter is used recursively. This fixes updates it to support being used recursively, by saving and restoring instance state on recursive calls.

This pull request has now been integrated.

Changeset: 0e0bd642
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e0bd642aba3ac859043fc9505343d06d780f13a
Stats:     143 lines in 2 files changed: 123 ins; 13 del; 7 mod

8356441: IllegalStateException in RichDiagnosticFormatter after JDK-8355065

Reviewed-by: liach, mcimadamore

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

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