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

From naoto at openjdk.org  Fri May  9 16:08:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 16:08:50 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: <d8w5t3NiWOgO1Yrp8hxcnKDEvaBgqBlgewshQe9qLU8=.a37e2def-3802-478d-bc4d-f66dd5519b8a@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

LGTM. Thanks for the changes

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24727#pullrequestreview-2828887346

From jjg3 at pobox.com  Fri May  9 16:40:43 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Fri, 9 May 2025 09:40:43 -0700
Subject: RFR: 8354968: Replace unicode sequences in comment text with
 UTF-8 characters
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <193f8f76-1884-4fcd-b98d-70e29d442174@pobox.com>

As a point of history, a long time ago (including Peter Ah?'s time), it 
was policy to use ASCII encoding, and not any richer character set.

Last time I looked, there was still some discrepancies in the makefiles 
for the encoding used for `javac` and `javadoc`.

-- Jon

On 4/17/25 7:48 AM, Magnus Ihse Bursie 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.
>
> -------------
>
> Commit messages:
>   - 8354968: Replace unicode sequences in comment text with UTF-8 characters
>
> Changes: https://git.openjdk.org/jdk/pull/24727/files
>    Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24727&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8354968
>    Stats: 158 lines in 153 files changed: 0 ins; 2 del; 156 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 acobbs at openjdk.org  Fri May  9 17:19:06 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 17:19:06 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of local
 class in early construction context
Message-ID: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>

Consider a class like this:

class Outer {
  Outer() {
    class Local {
      Local(Outer Outer.this) {  // "receiver parameter"
      }
    }
    super();
  }
}

Normally, a reference to `Outer.this` appearing anywhere in `Local` would generate an error because `Local` is defined in an early construction context of `Outer`. But in the above example, `Outer.this` is a "receiver parameter", which is the relatively obscure mechanism by which type annotations can be added to the outer instance (JLS ?8.4).

This is allowed, even though the outer instance is otherwise inaccessible here. However, the compiler was reporting an error. This PR adds an exception for receiver parameters to the illegal early access check. It also adds a missing bug ID to the regression test.

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

Commit messages:
 - Update copyrights.
 - Allow prologue references to "Foo.this" when appearing as a receiver parameter.

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

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

From forax at openjdk.org  Fri May  9 17:37:51 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 9 May 2025 17:37:51 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
Message-ID: <7_IVj0Z6N2y7P7Lel9LfmYayEni_ZjNaqqTdikkqFYU=.9f1dee3e-e903-46e5-aaa6-21ed70bbcedc@github.com>

On Fri, 9 May 2025 17:13:08 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Consider a class like this:
> 
> class Outer {
>   Outer() {
>     class Local {
>       Local(Outer Outer.this) {  // "receiver parameter"
>       }
>     }
>     super();
>   }
> }
> 
> Normally, a reference to `Outer.this` appearing anywhere in `Local` would generate an error because `Local` is defined in an early construction context of `Outer`. But in the above example, `Outer.this` is a "receiver parameter", which is the relatively obscure mechanism by which type annotations can be added to the outer instance (JLS ?8.4).
> 
> This is allowed, even though the outer instance is otherwise inaccessible here. However, the compiler was reporting an error. This PR adds an exception for receiver parameters to the illegal early access check. It also adds a missing bug ID to the regression test.

Hello,
and the spec seem to forget to consider that two other cases when you declare of a constructor of an inner class
-  you may want to reference to both the enclosing this and the current this,
- you may want to reference the current this (maybe using the syntax CucrentClass.this)


class Outer {
  Outer() {
    class Local {
      Local(Local this, Outer Outer.this) {  // both are receiver parameters
      }
      Local(Local Local.this) {  // a receiver parameter
      }
    }
  }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2867393104

From liach at openjdk.org  Fri May  9 17:48:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 17:48:09 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <7_IVj0Z6N2y7P7Lel9LfmYayEni_ZjNaqqTdikkqFYU=.9f1dee3e-e903-46e5-aaa6-21ed70bbcedc@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <7_IVj0Z6N2y7P7Lel9LfmYayEni_ZjNaqqTdikkqFYU=.9f1dee3e-e903-46e5-aaa6-21ed70bbcedc@github.com>
Message-ID: <ZQM09RkcaLJZn-aYD2Nm5GLd9V06OIMRT7_zEVAWMS0=.458e9929-4edf-443e-9920-cb66b3b82e85@github.com>

On Fri, 9 May 2025 17:35:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Consider a class like this:
>> 
>> class Outer {
>>   Outer() {
>>     class Local {
>>       Local(Outer Outer.this) {  // "receiver parameter"
>>       }
>>     }
>>     super();
>>   }
>> }
>> 
>> Normally, a reference to `Outer.this` appearing anywhere in `Local` would generate an error because `Local` is defined in an early construction context of `Outer`. But in the above example, `Outer.this` is a "receiver parameter", which is the relatively obscure mechanism by which type annotations can be added to the outer instance (JLS ?8.4).
>> 
>> This is allowed, even though the outer instance is otherwise inaccessible here. However, the compiler was reporting an error. This PR adds an exception for receiver parameters to the illegal early access check. It also adds a missing bug ID to the regression test.
>
> Hello,
> and the spec seem to forget to consider that two other cases when you declare of a constructor of an inner class
> -  you may want to reference to both the enclosing this and the current this,
> - you may want to reference the current this (maybe using the syntax CucrentClass.this)
> 
> 
> class Outer {
>   Outer() {
>     class Local {
>       Local(Local this, Outer Outer.this) {  // both are receiver parameters
>       }
>       Local(Local Local.this) {  // a receiver parameter
>       }
>     }
>   }
> }

Hi remi @forax, I don't think constructors have receiver parameters - top-level classes or static member classes have no receiver for constructors. The concept of receiver parameter for a constructor is closely tied to the enclosing instance. So `Local(Local Local.this)` is never a valid receiver.

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2867451794

From vromero at openjdk.org  Fri May  9 17:56:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 17:56:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v8]
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: <R8STKNBDgmA68EdQ0ZCv3I816482MKqwetdf7xw2sQw=.4eb9760e-7c6d-4434-b06d-595ffb7b004e@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:

  additional documentation changes and bug fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/d52ec33b..1ff2f2c6

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

  Stats: 79 lines in 7 files changed: 41 ins; 7 del; 31 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 prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 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: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@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.
> 
> 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?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From weijun at openjdk.org  Fri May  9 20:05:10 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 May 2025 20:05:10 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>

> Finalize the KDF API.

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

  new algorithms in SunJCE

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

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

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

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 acobbs at openjdk.org  Fri May  9 20:16:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 20:16:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
Message-ID: <VInvs8NiAub_DyV0XF_p9XniiQ9GTvKWwHX6xR3cjDw=.501b40a5-3206-4327-af1e-329f1ee21781@github.com>

On Thu, 8 May 2025 18:55:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

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

@vicente-romero-oracle, please see my [`identity-alias-synchronization`](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:identity-alias-synchronization?files) branch for an example of only having a single `LintCategory` with an alias. This branch passes `make test TEST="langtools_javac"`. This patch is based on an another PR that I already had lying around which had some related changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867784880

From vromero at openjdk.org  Fri May  9 20:28:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 20:28:14 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
Message-ID: <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>

On Thu, 8 May 2025 18:55:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

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

> @vicente-romero-oracle, please see my [`identity-alias-synchronization`](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:identity-alias-synchronization?files) branch for an example of only having a single `LintCategory` with an alias. This branch passes `make test TEST="langtools_javac"`. This patch is based on an another PR that I already had lying around which had some related changes.

I was working on something in this line too, just pushed the patch

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867804036

From vromero at openjdk.org  Fri May  9 20:28:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 20:28:12 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
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: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@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:

  fixing bugs, removing dead code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/1ff2f2c6..ea631161

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

  Stats: 57 lines in 3 files changed: 12 ins; 34 del; 11 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 20:46:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 20:46:57 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
Message-ID: <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com>

On Fri, 9 May 2025 20:28:12 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:
> 
>   fixing bugs, removing dead code

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

> 2214:             }
> 2215:             case ModuleMainClassAttribute a -> ((ModuleHeaderDescription) feature).moduleMainClass = a.mainClass().asInternalName();
> 2216:             case RuntimeVisibleTypeAnnotationsAttribute a -> {/* do nothing for now */}

I think this will make createsymbol created older reference/weakhashmap APIs' type parameter for older releases always have this annotation; but this should be fine. We can fix this for 26. The question is that now their type parameter and the actual parameter uses will see some inconsistent values for releases < 25 in the future.

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

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

From vromero at openjdk.org  Fri May  9 20:56:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 May 2025 20:56:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <5xTeZSIFVd9QbREf8ocKEh-nZ9Jx_kd2mUNgc8lJJMA=.80ec43f7-5d16-4dc3-9948-5f9d92f0d903@github.com>
Message-ID: <6zIXpQATpCOWVMh3AdcX0h7_M8H2nqHgK2Ok9ym7sys=.035df212-854c-4b1a-968c-0f3853d13c5a@github.com>

On Fri, 9 May 2025 20:43:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing bugs, removing dead code
>
> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 2216:
> 
>> 2214:             }
>> 2215:             case ModuleMainClassAttribute a -> ((ModuleHeaderDescription) feature).moduleMainClass = a.mainClass().asInternalName();
>> 2216:             case RuntimeVisibleTypeAnnotationsAttribute a -> {/* do nothing for now */}
> 
> I think this will make createsymbol created older reference/weakhashmap APIs' type parameter for older releases always have this annotation; but this should be fine. We can fix this for 26. The question is that now their type parameter and the actual parameter uses will see some inconsistent values for releases < 25 in the future.

Jan is taking a look at the changes for CreateSymbols. The change included in this PR is the minimum for the build to pass, I will double check with him if what he is doing will be pushed in a separate PR or as part of this PR, not sure yet. Time is tight and we want this in 25 this is why I decided to move on with this PR even though the CreateSymbols code complete. I forgot to mention this before, sorry

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

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

From acobbs at openjdk.org  Fri May  9 21:09:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 21:09:53 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
Message-ID: <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>

On Fri, 9 May 2025 20:25:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I was working on something in this line too, just pushed the patch

Looks reasonable, a couple of comments...

Can't `LintCategory.alias` be `final`? If so I think this obviates the patch to `DetectMutableStaticFields.java`.

This is not a general solution to aliasing of lint categories. For example, if someone were to add an alias `filenames` for `path`, then [this code](https://github.com/openjdk/jdk/blob/68a118509a562334eb8c099129d79520041b10cf/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L506-L507) and a few other examples like it would break.

Do we care about that? If so then we might want to implement a proper fix for lint aliases as a separate pre-requisite to this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867878715

From liach at openjdk.org  Fri May  9 21:09:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 21:09:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
Message-ID: <-kiskE2-Ejcqxz1znbiJRJ-ZtGdkyZmY7awv7fasv4E=.a52127c6-0339-473b-8018-a97aa93f9efb@github.com>

On Fri, 9 May 2025 20:28:12 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:
> 
>   fixing bugs, removing dead code

Note: The tests and the core library changes look good to me.

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

> 426:             this.alias = alias;
> 427:             map.put(option, this);
> 428:             // we need to do this as forward references are not allowed

Suggestion:


Redundant comment from last revision.

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

> 452:         public final boolean annotationSuppression;
> 453: 
> 454:         public String alias;

Suggestion:

        public final String alias;

We are no longer storing LintCategory objects.

test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java line 96:

> 94:         ignore("com/sun/tools/javac/file/JRTIndex", "sharedInstance");
> 95:         ignore("com/sun/tools/javac/main/JavaCompiler", "versionRB");
> 96:         ignore("com/sun/tools/javac/code/Lint$LintCategory", "alias");

Can remove this once alias is final

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867879980
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082492124
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082496953
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2082497326

From liach at openjdk.org  Fri May  9 21:12:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 21:12:53 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
Message-ID: <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>

On Fri, 9 May 2025 21:06:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Do we care about that? If so then we might want to implement a proper fix for lint aliases as a separate pre-requisite to this issue.

I think if we do that, we should encapsulate `option` and move all access, such as `option.isSet`, to dedicated methods on `LintCategory`. We are a bit short on time for this, so IMO our best approach is to open a followup issue that we can work on for 26 given the short time to RDP1.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867884046

From acobbs at openjdk.org  Fri May  9 21:27:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 21:27:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
Message-ID: <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>

On Fri, 9 May 2025 21:09:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think if we do that, we should encapsulate `option` and move all access, such as `option.isSet`, to dedicated methods on `LintCategory`. We are a bit short on time for this, so IMO our best approach is to open a followup issue that we can work on for 26 given the short time to RDP1.

That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867906064

From mcimadamore at openjdk.org  Fri May  9 21:40:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 May 2025 21:40:50 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
Message-ID: <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>

On Fri, 9 May 2025 17:13:08 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Consider a class like this:
> 
> class Outer {
>   Outer() {
>     class Local {
>       Local(Outer Outer.this) {  // "receiver parameter"
>       }
>     }
>     super();
>   }
> }
> 
> Normally, a reference to `Outer.this` appearing anywhere in `Local` would generate an error because `Local` is defined in an early construction context of `Outer`. But in the above example, `Outer.this` is a "receiver parameter", which is the relatively obscure mechanism by which type annotations can be added to the outer instance (JLS ?8.4).
> 
> This is allowed, even though the outer instance is otherwise inaccessible here. However, the compiler was reporting an error. This PR adds an exception for receiver parameters to the illegal early access check. It also adds a missing bug ID to the regression test.

The changes look good -- but I wonder -- is there really no way to prevent javac from "going down the rabbit hole" and attempting to prove that `Foo.this` is a good/accessible enclosing this (via `resolveSelf`) ? E.g. it feels like javac shouldn't even be in that method for a receiver parameter.

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2867922620

From mcimadamore at openjdk.org  Fri May  9 21:44:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 May 2025 21:44:50 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
Message-ID: <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>

On Fri, 9 May 2025 21:37:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The changes look good -- but I wonder -- is there really no way to prevent javac from "going down the rabbit hole" and attempting to prove that `Foo.this` is a good/accessible enclosing this (via `resolveSelf`) ? E.g. it feels like javac shouldn't even be in that method for a receiver parameter.

Looking at the code -- the "bad" call seems to be in `MemberEnter:checkReceiver` which calls `Attr::attribExpr` on the _name_ of the receiver parameter. Which then causes this sad outcome. Maybe a more "piecemeal" attribution would work better (e.g. attribute just the "type part" of the parameter name, leaving `this` aside).

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2867935752

From acobbs at openjdk.org  Fri May  9 21:51:50 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 May 2025 21:51:50 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
Message-ID: <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>

On Fri, 9 May 2025 21:42:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The changes look good -- but I wonder -- is there really no way to prevent javac from "going down the rabbit hole" and attempting to prove that `Foo.this` is a good/accessible enclosing this (via `resolveSelf`) ? E.g. it feels like javac shouldn't even be in that method for a receiver parameter.

It happens at the start of `MemberEnter.checkReceiver()` where it needs to attribute the parameter to verify it has the correct type, and that means attributing the expression `Foo.this`. This seems like a reasonable thing to do at that point... so maybe the problem is that the early access check is happening then (during attribution) instead of later somehow?

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2867942974

From liach at openjdk.org  Fri May  9 22:41:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 22:41:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
 <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
Message-ID: <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>

On Fri, 9 May 2025 21:24:58 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer.

Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2867998674

From cstein at openjdk.org  Sat May 10 06:13:46 2025
From: cstein at openjdk.org (Christian Stein)
Date: Sat, 10 May 2025 06:13:46 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v13]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <0ZbpBXZ2jQrlF1ADjDLs887xNfDb0GHWv4szkVIPQD4=.b8d8ae01-a008-4d6f-a531-a231450ea66a@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 FileSystemException on Unix-based file systems

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/79dde479..95d1067d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=11-12

  Stats: 3 lines in 1 file changed: 3 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 liach at openjdk.org  Sat May 10 14:34:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 14:34:57 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@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>
 <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@github.com>
Message-ID: <nE3vY86gAkbMoBwkJJcKRHrTgv25Bauh7Zhu87waQRM=.5bcf63ed-06bd-45b5-9225-797eccc4c21c@github.com>

On Fri, 2 May 2025 17:19:11 GMT, Joe Darcy <darcy 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.
>
>> 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.

See #25124.

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

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

From acobbs at openjdk.org  Sat May 10 15:27:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 15:27:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
 <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
 <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>
Message-ID: <CAf7PHYDZAibVVrsKlRlXvFGJ9XAfM9rjh9soCvDDIE=.a4ab7a2b-93e2-4f90-80c0-be9187290b1c@github.com>

On Fri, 9 May 2025 22:39:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.

OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases).

@vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868963258

From vromero at openjdk.org  Sat May 10 15:31:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 15:31:45 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v10]
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: <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@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:

  integrating code from Archie

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/ea631161..a9a53783

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

  Stats: 151 lines in 7 files changed: 98 ins; 25 del; 28 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  Sat May 10 15:33:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 15:33:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
Message-ID: <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>

On Fri, 9 May 2025 20:28:12 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:
> 
>   fixing bugs, removing dead code

Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868971783

From vromero at openjdk.org  Sat May 10 15:37:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 15:37:51 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v6]
In-Reply-To: <CAf7PHYDZAibVVrsKlRlXvFGJ9XAfM9rjh9soCvDDIE=.a4ab7a2b-93e2-4f90-80c0-be9187290b1c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <hAF_7fvPkGafWoSY_39wuSM9BsXlEJutSMLl1SLuuYI=.cdac8c15-7a77-400a-87c4-73a3d0a01370@github.com>
 <PF_c_Cn28KPO4J5f6Jj4jSWN5RIJGd-btQsfNa80j0I=.f0a31cee-de94-4033-ae47-60f7d8feed0a@github.com>
 <BPoc_smVnc5o4qfZIYiUBzfek5OspUXWQrsjODDrnME=.64da805b-726a-4f1c-8b02-025060946455@github.com>
 <ke72Wce0xsvGp_9sZM-YBpn5MeoiAKH2oOcrtvbm_go=.f1c89d3b-3b84-4184-9861-f87cefc85f64@github.com>
 <m8gmGD58e_TJJ0ik_n842YC7bACrA_wYqNED6QZbeos=.58a6b464-4313-474e-9362-d7f80fbac8f1@github.com>
 <WP_HCElTvyntrwXlrXvgC-hLlyaftjWDDYtThJwG-Kk=.7a0810c7-f185-407f-8908-87f3c4870173@github.com>
 <CdtTwok4N_tN_rF-m6hmHx4frol7Yz7RuGuXg2d50Ek=.a6b01a79-5410-404a-9773-e9e406c17d01@github.com>
 <CAf7PHYDZAibVVrsKlRlXvFGJ9XAfM9rjh9soCvDDIE=.a4ab7a2b-93e2-4f90-80c0-be9187290b1c@github.com>
Message-ID: <bv-ku-BDfYjHJu7CFwqKJvAya2TtIpWZn-TasyxVRI0=.0e62d976-4ecd-4bfa-a0d4-92ffca7b94e9@github.com>

On Sat, 10 May 2025 15:24:52 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> That's why I was offering my existing patch which basically does that already. But it's OK to wait if you prefer.
>> 
>> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.
>
>> Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.
> 
> OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases).
> 
> @vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks!

I have integrated @archiecobbs's code. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868972990

From vromero at openjdk.org  Sat May 10 15:37:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 15:37:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
Message-ID: <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>

On Sat, 10 May 2025 15:31:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing bugs, removing dead code
>
> Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.

> > Sure, I think vicente is open to patches and PRs to his fork. And I can help review; just remember to @liach.
> 
> OK thanks. I've rebased my changes on @vicente-romero-oracle's branch to simply any evaluation. [Here's the diff](https://github.com/vicente-romero-oracle/jdk/compare/JDK-8354556...archiecobbs:jdk:JDK-8354556+aliases).
> 
> @vicente-romero-oracle please feel free to take it or leave it, I'm not trying to butt in to your PR, rather just trying to avoid a small bit of technical debt. Thanks!

heh, I was doing the same, thanks anyway :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868973659

From acobbs at openjdk.org  Sat May 10 15:43:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 15:43:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
 <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
Message-ID: <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>

On Sat, 10 May 2025 15:35:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> heh, I was doing the same, thanks anyway :)

Awesome, thanks!

Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868976097

From nbenalla at openjdk.org  Sat May 10 15:44:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Sat, 10 May 2025 15:44:51 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v2]
In-Reply-To: <nE3vY86gAkbMoBwkJJcKRHrTgv25Bauh7Zhu87waQRM=.5bcf63ed-06bd-45b5-9225-797eccc4c21c@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>
 <h0NG79gUPcH1_prs_0-BfqFkNnXGmlyJR6M79uUnJhU=.efdcbe80-3565-4be8-8fe3-b88c9791effb@github.com>
 <nE3vY86gAkbMoBwkJJcKRHrTgv25Bauh7Zhu87waQRM=.5bcf63ed-06bd-45b5-9225-797eccc4c21c@github.com>
Message-ID: <vmbm4WtGBMVdkQQTbwPIM65_xTpPTF-rn8es_pImq3Q=.a1f79864-3b8f-4132-ad95-8dbe58b62654@github.com>

On Sat, 10 May 2025 14:32:10 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.
>
> See #25124.

Thanks Chen!

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

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

From acobbs at openjdk.org  Sat May 10 16:00:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 16:00:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
Message-ID: <Jl13VWa5dPTXvqGhuVkOfQPCQPZL7c0Q-vPgjQ9p8eo=.8e30584f-76e1-4537-a5b6-71d81dc3ac0b@github.com>

On Sat, 10 May 2025 15:31:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.

Good point... I prototyped that in commit be160a3261b.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868989327

From vromero at openjdk.org  Sat May 10 16:05:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:05:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v10]
In-Reply-To: <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
Message-ID: <_tMq_VvOY6ER-1qTRe7TDbBBCPWFW7080gRydehdBME=.7131f939-c8dc-4443-8c44-ce31fbc227a3@github.com>

On Sat, 10 May 2025 15:31: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 incrementally with one additional commit since the last revision:
> 
>   integrating code from Archie

> > Thanks. Looks good, but the Lint to all option names streaming can be replaced by the static map lookup/iteration.
> 
> Good point... I prototyped that in commit [be160a3](https://github.com/openjdk/jdk/commit/be160a3261bebcbd09c350a3feda6e696f26a3e3).

thanks! I will integrate it

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868993387

From vromero at openjdk.org  Sat May 10 16:05:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:05:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
 <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
 <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>
Message-ID: <j7Yb8_4DGE2zRvsEH8fOYKGiq9iJNi2COuZnMTj0b4w=.d42d37a8-d3c2-459b-bf93-917d3db1d1dd@github.com>

On Sat, 10 May 2025 15:41:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > heh, I was doing the same, thanks anyway :)
> 
> Awesome, thanks!
> 
> Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes.

thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2868993581

From vromero at openjdk.org  Sat May 10 16:39:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:39:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
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: <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@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 two additional commits since the last revision:

 - additional changes from Archie
 - removing dead code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/a9a53783..973307eb

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

  Stats: 66 lines in 7 files changed: 16 ins; 35 del; 15 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  Sat May 10 16:39:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:39:38 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v10]
In-Reply-To: <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <Xfb8mMaM4ZG2HbsEQuP8PoR_Mn0JybO8mhqDMvbYsUQ=.35f17611-2eca-4068-a3d4-889d34eeb1c1@github.com>
Message-ID: <QFz-yN_7ifVnh8V9LqQXJ8emqZ1ct5gFFqSjAUiKTjo=.d97305ed-8b9c-44f8-a47a-aa3918555b07@github.com>

On Sat, 10 May 2025 15:31: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 incrementally with one additional commit since the last revision:
> 
>   integrating code from Archie

I integrated the rest of Archie's changes, thanks guys for the contributions and the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869007212

From vromero at openjdk.org  Sat May 10 16:50:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 16:50:51 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v9]
In-Reply-To: <j7Yb8_4DGE2zRvsEH8fOYKGiq9iJNi2COuZnMTj0b4w=.d42d37a8-d3c2-459b-bf93-917d3db1d1dd@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <cyoebKk_ofol8YM-lU38mApiiLnqidJcOqbugOSd5js=.ee638f21-7f89-4884-bf12-dd55a7da90e1@github.com>
 <OumhW90asXXtvx7mmxJXL63qq_PobA4heS5Phgb6BrI=.aeb99e3d-e4de-4a43-9922-d47ac8fdf36b@github.com>
 <nib-ZZMyLpeB93Q5ENIt-eFINj0q2yWEGqDZ7bo78_o=.4e9f97aa-90dc-4b8f-93d5-eaa4995d456b@github.com>
 <I3FPARS1QhUMONXA1VULa0L2Jigu0QHpG7fep5DF8UQ=.a753305f-e8b0-44c0-8bdc-ffb9958ba28e@github.com>
 <j7Yb8_4DGE2zRvsEH8fOYKGiq9iJNi2COuZnMTj0b4w=.d42d37a8-d3c2-459b-bf93-917d3db1d1dd@github.com>
Message-ID: <ksTB2GyTHMoCi2I9APkJdJo45dfd0NA2ctndzuuD4fo=.0f91cb05-df3a-4ef4-97de-36f90a19da4b@github.com>

On Sat, 10 May 2025 16:03:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > heh, I was doing the same, thanks anyway :)
> 
> Awesome, thanks!
> 
> Apologies for the mid-air collision :) I've merged your latest merge into my merge, leaving just a few minor fixes.

thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869011552

From liach at openjdk.org  Sat May 10 19:39:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 19:39:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
In-Reply-To: <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
Message-ID: <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>

On Sat, 10 May 2025 16:39: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 two additional commits since the last revision:
> 
>  - additional changes from Archie
>  - removing dead code

As much as I dislike streams, I think we will probably keep them for their conciseness except this one, which made things less concise.

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

> 420:             ArrayList<String> optionList = new ArrayList<>(1 + aliases.length);
> 421:             optionList.add(option);
> 422:             Stream.of(aliases).forEach(optionList::add);

Suggestion:

            Collections.addAll(optionList, aliases);

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

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2831052002
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2083275193

From liach at openjdk.org  Sat May 10 19:43:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 10 May 2025 19:43:53 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: <WKLP3rmT56ZPgSQxFdOgDaMLnjmOBe4DqbGwTznPO3o=.6aea6272-45ed-414c-9a37-a61c736a5398@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

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

> 655:                "Undet vars: " + undetvars + '\n';
> 656:         /*
> 657:         // keep it for debugging

Should we control this with an `options.isSet` switch instead, maybe passing the options through Infer?

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

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

From acobbs at openjdk.org  Sat May 10 20:04:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 20:04:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
In-Reply-To: <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
 <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
Message-ID: <GL17OxIMdIiO8YrxKCiLvwodQvmi9PeQqqPFm-Ey3e0=.dbbda840-cf4b-4151-8a59-f1535571c07d@github.com>

On Sat, 10 May 2025 19:32:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - additional changes from Archie
>>  - removing dead code
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 422:
> 
>> 420:             ArrayList<String> optionList = new ArrayList<>(1 + aliases.length);
>> 421:             optionList.add(option);
>> 422:             Stream.of(aliases).forEach(optionList::add);
> 
> Suggestion:
> 
>             Collections.addAll(optionList, aliases);

Wow, somehow I never knew `Collections.addAll()` existed. Thanks for the tip - that's simpler.

(I'll let @vicente-romero-oracle fix it.)

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

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

From vromero at openjdk.org  Sat May 10 20:28:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 20:28:39 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
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: <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@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:

  Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/973307eb..63fd151f

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

  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 vromero at openjdk.org  Sat May 10 20:28:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 20:28:39 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v11]
In-Reply-To: <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <K5NLszEQ8y7LlGY4ffAG8rIkl5csr29qlTKBcf4ehEs=.77ec03c1-1d0f-441a-b997-0c70ee9a588b@github.com>
 <naEEBS9Un6FvBFlwxzsXR8RwpgL-zzTLEB8hglPk_ho=.16af1305-422a-45ad-b9ca-b855cf4af583@github.com>
Message-ID: <s5XwKCIy9MBpOGUZTR_ZuzI2mz-bsXE_-z2QErrrIGw=.e077c752-7c50-4937-95a4-ebd5b445ec92@github.com>

On Sat, 10 May 2025 19:36:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> As much as I dislike streams, I think we will probably keep them for their conciseness except this one, which made things less concise.

thanks! committed

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869141760

From acobbs at openjdk.org  Sat May 10 20:40:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 10 May 2025 20:40:54 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
In-Reply-To: <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
Message-ID: <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com>

On Sat, 10 May 2025 20:28:39 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:
> 
>   Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

FYI, this issue now effectively fixes [JDK-7004476 Lint.LintCategory should support aliases](https://bugs.openjdk.org/browse/JDK-7004476), which happened to be closed as "Rejected" on Monday. Not sure if anything needs to be done.

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869145567

From vromero at openjdk.org  Sat May 10 22:48:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 10 May 2025 22:48:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
In-Reply-To: <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
 <3mgdx3uS6hYjqdiYla9QMMDB34uAyqNxZoLnxSO1yjI=.0c900a96-b1c6-449b-9155-100618aad111@github.com>
Message-ID: <7sbyHtJrLFM2tyXex553OXX12Mch_Q2mXwJg3qKSEqk=.e568d019-99d3-4c04-8ad6-0c6d071aef62@github.com>

On Sat, 10 May 2025 20:38:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> FYI, this issue now effectively fixes [JDK-7004476 Lint.LintCategory should support aliases](https://bugs.openjdk.org/browse/JDK-7004476), which happened to be closed as "Rejected" on Monday. Not sure if anything needs to be done.

I guess we can add a note to that bug once this one goes through

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2869184983

From mcimadamore at openjdk.org  Sun May 11 10:14:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Sun, 11 May 2025 10:14:51 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
Message-ID: <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>

On Fri, 9 May 2025 21:48:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > The changes look good -- but I wonder -- is there really no way to prevent javac from "going down the rabbit hole" and attempting to prove that `Foo.this` is a good/accessible enclosing this (via `resolveSelf`) ? E.g. it feels like javac shouldn't even be in that method for a receiver parameter.
> 
> It happens at the start of `MemberEnter.checkReceiver()` where it needs to attribute the parameter to verify it has the correct type, and that means attributing the expression `Foo.this`. This seems like a reasonable thing to do at that point... so maybe the problem is that the early access check is happening then (during attribution) instead of later somehow?

My feeling is that at this point we should just attribute `Foo` -- and leave `this` alone. That is, `this` is just an extra syntactic token that is used to denote the receiver parameter name. Attributing it as `Foo.this` causes the compiler to think it's an outer `this` access, which this is not. So let's just type-check the type (and leave `this` off to the side) ? After all this code only wants to make sure the type before `.this` makes sense for the context in which the receiver parameter appears.

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2869669494

From alanb at openjdk.org  Sun May 11 17:09:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 11 May 2025 17:09:52 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: <0dcTQBkhjRuEbzel6ux6ZX6pGg9BgVWSbSXYI5QI3L4=.0f7b1564-ede4-4c43-b3a2-29fb0b54d8cf@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

Marked as reviewed by alanb (Reviewer).

I ran tier1-6 so I think we are good and there isn't anything left to bring over from the loom repo. There are a few files that will need their copyright header updated before integration. The CSR also needs to be finalized.

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

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2831452149
PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2870007648

From kbarrett at openjdk.org  Sun May 11 19:13:52 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 11 May 2025 19:13:52 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v12]
In-Reply-To: <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <aywAMR14DaO2dPfzllNsKNfkjbXEIINzNB8aZUBevYo=.a6901bc0-35a0-4fbc-84af-7532f3da8a4c@github.com>
Message-ID: <tkStczMT5a1Bn13ih4GEUb2YqYTZboeaIlqCLAW5ul4=.07c5fbd7-743c-4067-80b5-1f2c695af54d@github.com>

On Sat, 10 May 2025 20:28:39 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:
> 
>   Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

I'm coming here from "far away" and am not familiar with all the work leading
up to this proposal, so maybe there's some rationale that I don't know about.
(I did look, but didn't find anything other than this draft JEP:
https://openjdk.org/jeps/8340476. And that doesn't really deal with the issue
I discuss below.)

Keeping that in mind, I'm surprised by some parts of this change.  Specifically

2) Apply the annotation to the following:
- The referent parameter of all constructors in classes PhantomReference, SoftReference, and WeakReference
...
 - The type parameter T of Reference, PhantomReference, SoftReference, WeakReference, and ReferenceQueue 

I wonder why it is not sufficient to apply the annotation to the type
parameter T of Reference, and leave it at that?

The type parameter of the subclasses is passed as the type parameter to
Reference in the `extends` clause. I would expect if the type parameter for a
subclass didn't satisfy the annotation that would be noticed there. Indeed, if
that isn't the case then many uses of Reference types won't benefit from this
annotation, since they are using classes derived from one of those subclasses
and won't have this internal annotation. That would significantly limit the
utility of this annotation in this area.

Similarly, I wonder why the constructors need the annotation. And why don't
the return type of `get` or the argument for `Reference::refersTo` need it?
(Maybe because those values can be null? But there's nothing that prevents
passing null to one of the constructors. It's not very useful to do so, but
not forbidden.  I've even seen a use-case for doing so.)

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2870055928

From mcimadamore at openjdk.org  Mon May 12 09:01:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 May 2025 09:01:01 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v3]
In-Reply-To: <-J_AJ-9QvL56UaMaZ_RVyt6XezrCIVUqnlSM1X9qbqc=.04293a17-6ac6-4579-a244-8d5b6fcc65fe@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <-J_AJ-9QvL56UaMaZ_RVyt6XezrCIVUqnlSM1X9qbqc=.04293a17-6ac6-4579-a244-8d5b6fcc65fe@github.com>
Message-ID: <P8MHQL8Sxxy84xb7zzywqW0rfacuiYZyYdOf-zit9es=.45c39ac5-8889-4ea1-b22d-4a9cb8bc6816@github.com>

On Wed, 7 May 2025 15:08:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

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

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23303#pullrequestreview-2832418771

From jlahoda at openjdk.org  Mon May 12 09:08:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 May 2025 09:08:53 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v3]
In-Reply-To: <-J_AJ-9QvL56UaMaZ_RVyt6XezrCIVUqnlSM1X9qbqc=.04293a17-6ac6-4579-a244-8d5b6fcc65fe@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <-J_AJ-9QvL56UaMaZ_RVyt6XezrCIVUqnlSM1X9qbqc=.04293a17-6ac6-4579-a244-8d5b6fcc65fe@github.com>
Message-ID: <S2LGaEBZXZR_oTjLeqnKdU7Nv1FHJat6x4bh0kYYepk=.604de28c-2a0d-497e-8d88-f3da0e10a2dd@github.com>

On Wed, 7 May 2025 15:08:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

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

Looks good, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23303#pullrequestreview-2832450028

From vromero at openjdk.org  Mon May 12 10:42:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 May 2025 10:42:50 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <tpW3MR9sfSHPWtWkQ5GvaB_5uXYuAhbM6TEWhtwCN8Y=.147d1c9b-6893-498b-ab13-c9578f3c0656@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <tpW3MR9sfSHPWtWkQ5GvaB_5uXYuAhbM6TEWhtwCN8Y=.147d1c9b-6893-498b-ab13-c9578f3c0656@github.com>
Message-ID: <jLXOZTnK7r4fwtdDsFrfURg8OCT-6sAwp_AZzbCGfRo=.ab2e1362-756b-4c53-bff3-e454e32008d1@github.com>

On Fri, 9 May 2025 14:18:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

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

yes I think this is an issue of the minimization algo. I mean there will always be at least one variable in MIC that won't be in IC and if MIC is asked to substitute that variable by its corresponding inference variable, then MIC won't be able to do it as it doesn't know how to map it and, potentially, some constraints won't be added to the inference variable. When we obtain MIC from IC we just don't know what queries we will do on MIC. The algo doesn't have this info.

I guess that there could be two ways to fix this:

- keeping links to the original inference contexts which will have more info, which is what this PR is doing
- trying to generate a more complete MIC gathering additional info

the second option seems like more complex as we could need some heuristics like type variables appearing in the same type, etc, and it could be harder to make sure that we get all the needed info. Also a more fluffy MIC would impact performance

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2872007453

From vromero at openjdk.org  Mon May 12 11:08:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 May 2025 11:08:52 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <WKLP3rmT56ZPgSQxFdOgDaMLnjmOBe4DqbGwTznPO3o=.6aea6272-45ed-414c-9a37-a61c736a5398@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <WKLP3rmT56ZPgSQxFdOgDaMLnjmOBe4DqbGwTznPO3o=.6aea6272-45ed-414c-9a37-a61c736a5398@github.com>
Message-ID: <onBtY2i30iTIcjN-77m3f6KgKVVGjfn8WU_PD7mqSII=.dedd9e07-9e5c-4715-a8be-d561600f4519@github.com>

On Sat, 10 May 2025 19:40:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 657:
> 
>> 655:                "Undet vars: " + undetvars + '\n';
>> 656:         /*
>> 657:         // keep it for debugging
> 
> Should we control this with an `options.isSet` switch instead, maybe passing the options through Infer?

yes we could do that, but then we will probably want to add a test for that option, etc, probably not worthy, also we could just drop this code

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

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

From jlahoda at openjdk.org  Mon May 12 11:16:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 May 2025 11:16:09 GMT
Subject: RFR: 8354908: javac mishandles supplementary character in
 character literal [v2]
In-Reply-To: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
References: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
Message-ID: <41x4IdFHFNLrzL4JFzCiGmtv9-4qIO_OukPGWrsg9yE=.8e5dc356-9dcd-4fd3-b099-9f8527d1d768@github.com>

> 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

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

  Reflecting review comment: using UTF-16 code unit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24964/files
  - new: https://git.openjdk.org/jdk/pull/24964/files/ae1201b3..1c768046

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

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

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

From jlahoda at openjdk.org  Mon May 12 11:17:37 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 May 2025 11:17:37 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v4]
In-Reply-To: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
Message-ID: <f_ETcyI0z7FX3dNoJJ4qPsGk4Uhsno7DqWQIPPRQzgI=.d7bf74f7-7abd-4120-9fa8-13b525df9fa6@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 comment: adding description.

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

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

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

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 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 12 11:17:37 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 May 2025 11:17:37 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v3]
In-Reply-To: <VqqsPQu9HujHHcv7tpKkcza-I92Uf0QMK1VdlIUSwu4=.6d05ea28-fb4c-4d56-83ab-bd1a99163a90@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
 <II3ZkCn0VhXEx_T3F9ZS0R_T95zlPJy5LIa12lwyq80=.30db897f-8325-4d15-a94b-37eaa592a392@github.com>
 <VqqsPQu9HujHHcv7tpKkcza-I92Uf0QMK1VdlIUSwu4=.6d05ea28-fb4c-4d56-83ab-bd1a99163a90@github.com>
Message-ID: <uazT-f0mdFiKr51eFBhX5dwM3pOZ8b1d3gSyj5_NVl0=.4e175f1c-c9e9-4126-9080-4827c6481bd9@github.com>

On Mon, 5 May 2025 19:59:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

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

Done:
https://github.com/openjdk/jdk/pull/25002/commits/9bb3677511b936002a22dde7401ba01ed116a2a8

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

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

From jlahoda at openjdk.org  Mon May 12 11:22:10 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 May 2025 11:22:10 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v5]
In-Reply-To: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
Message-ID: <zO5ydffJEMfTdcYc-8rMM3z3KL7EzqAMKVsXv0OKWSo=.f9cae71d-ab7e-465b-8095-da48cd5e4c49@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:

  Adding test for recursive bounds.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25002/files
  - new: https://git.openjdk.org/jdk/pull/25002/files/9bb36775..3f50dbb7

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

  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 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 mullan at openjdk.org  Mon May 12 12:19:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 May 2025 12:19:56 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
Message-ID: <HSOcYbKCScm1rg-Avq2zAv1wjKrxs9QsxvAy-0Qx_3I=.8a39a3ce-5328-4528-ad76-fdc23ad659aa@github.com>

On Fri, 9 May 2025 20:05:10 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:
> 
>   new algorithms in SunJCE

Marked as reviewed by mullan (Reviewer).

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

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

From liach at openjdk.org  Mon May 12 12:37:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 May 2025 12:37:53 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <onBtY2i30iTIcjN-77m3f6KgKVVGjfn8WU_PD7mqSII=.dedd9e07-9e5c-4715-a8be-d561600f4519@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <WKLP3rmT56ZPgSQxFdOgDaMLnjmOBe4DqbGwTznPO3o=.6aea6272-45ed-414c-9a37-a61c736a5398@github.com>
 <onBtY2i30iTIcjN-77m3f6KgKVVGjfn8WU_PD7mqSII=.dedd9e07-9e5c-4715-a8be-d561600f4519@github.com>
Message-ID: <3fUQBdRQR_NkvphbZPwTTeoI4lFbc2I41kW_CD3Lfj0=.e9eeb3c6-3a66-4279-bf90-ac75e745bfac@github.com>

On Mon, 12 May 2025 11:06:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 657:
>> 
>>> 655:                "Undet vars: " + undetvars + '\n';
>>> 656:         /*
>>> 657:         // keep it for debugging
>> 
>> Should we control this with an `options.isSet` switch instead, maybe passing the options through Infer?
>
> yes we could do that, but then we will probably want to add a test for that option, etc, probably not worthy, also we could just drop this code

Let's drop this commented out debug stub then

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

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

From acobbs at openjdk.org  Mon May 12 14:36:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 12 May 2025 14:36:51 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
 <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
Message-ID: <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>

On Sun, 11 May 2025 10:12:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> My feeling is that at this point we should just attribute `Foo` -- and leave `this` alone. That is, `this` is just an extra syntactic token that is used to denote the receiver parameter name. Attributing it as `Foo.this` causes the compiler to think it's an outer `this` access, which this is not. So let's just type-check the type (and leave `this` off to the side) ? After all this code only wants to make sure the type before `.this` makes sense for the context in which the receiver parameter appears.

I tried out that approach in [this branch](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8356551-alt). I'm reaching the limits of my grasp so this may not be the simplest way to do this. AFAICT we still have to (a) assign some type/symbol to the parameter expression (to avoid NPE later) and (b) do the static check stuff.

Let me know which version you prefer, or any other thoughts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2872828788

From acobbs at openjdk.org  Mon May 12 14:45:06 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 12 May 2025 14:45:06 GMT
Subject: RFR: 8348410: Preview flag not checked during compilation
 resulting in runtime crash [v3]
In-Reply-To: <-J_AJ-9QvL56UaMaZ_RVyt6XezrCIVUqnlSM1X9qbqc=.04293a17-6ac6-4579-a244-8d5b6fcc65fe@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
 <-J_AJ-9QvL56UaMaZ_RVyt6XezrCIVUqnlSM1X9qbqc=.04293a17-6ac6-4579-a244-8d5b6fcc65fe@github.com>
Message-ID: <u7nV-YjL-5pVF7nv4bWaGUiNIlIu_ZmQcQDujNqdi5s=.0ca607b2-0c6e-4133-b150-e9c7cc84d42a@github.com>

On Wed, 7 May 2025 15:08:36 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

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

Thanks for the reviews!

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

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

From acobbs at openjdk.org  Mon May 12 14:45:07 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 12 May 2025 14:45:07 GMT
Subject: Integrated: 8348410: Preview flag not checked during compilation
 resulting in runtime crash
In-Reply-To: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
References: <X0JQ-ru9GCcTdlirR__0s2eEPDuK9w3IG6k6yLOZHJk=.1dcc0d2a-c800-4e12-a478-3101556ac8ab@github.com>
Message-ID: <l2VUZfqydc-V6TFlBX7aM5gU3ojE84hBibWlJjeZ6qU=.e3935760-a999-4eb3-b78f-bacd11ffe52d@github.com>

On Fri, 24 Jan 2025 17:12:00 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: f5525ecf
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5525ecf585b3876ae332d30b0e641ff0c844e58
Stats:     186 lines in 2 files changed: 182 ins; 0 del; 4 mod

8348410: Preview flag not checked during compilation resulting in runtime crash

Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: jlahoda, mcimadamore

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

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

From mcimadamore at openjdk.org  Mon May 12 15:36:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 May 2025 15:36:01 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
 <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
 <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>
Message-ID: <VVg3xpRzJRu9MisU7wUc2Tke7UELjLro9BGs6iJBMok=.d27a0075-be89-42ac-9cb8-4e8f1f44f947@github.com>

On Mon, 12 May 2025 14:34:06 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> I tried out that approach in [this branch](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8356551-alt). I'm reaching the limits of my grasp so this may not be the simplest way to do this. AFAICT we still have to (a) assign some type/symbol to the parameter expression (to avoid NPE later) and (b) do the static check stuff.
> 
> Let me know which version you prefer, or any other thoughts.

Thanks for the experiment.
My general feeling is that we can get away with a lot less. The code in `checkReceiver` is sending `Foo.this` into attribution. But then it's not really using the full results of the attribution -- instead it's just looking at the type qualifier, and enforcing that this type is the same as the enclosing instance type:


checkType(tree.nameexpr, outertype, Errors.IncorrectConstructorReceiverName(outertype, tree.nameexpr.type));

(see `tree.nameexpr.type`).

So, my idea was to simply compute `tree.nameexpr.type` by calling `Attr::attribType` on the qualifier, and then keep `checkReceiver` the same as it is today. This also should not need to add any new method in `Resolve`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2873031241

From mcimadamore at openjdk.org  Mon May 12 15:36:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 May 2025 15:36:02 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <VVg3xpRzJRu9MisU7wUc2Tke7UELjLro9BGs6iJBMok=.d27a0075-be89-42ac-9cb8-4e8f1f44f947@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
 <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
 <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>
 <VVg3xpRzJRu9MisU7wUc2Tke7UELjLro9BGs6iJBMok=.d27a0075-be89-42ac-9cb8-4e8f1f44f947@github.com>
Message-ID: <FkKNhvQPSPk7p4zmNRoQx0Dkw9X9opppsod96uJfj-I=.e06dd401-361e-4b0e-a764-bd6b81839eb1@github.com>

On Mon, 12 May 2025 15:31:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> we still have to (a) assign some type/symbol to the parameter expression (to avoid NPE later)

Can you expand a bit more -- who's trying to access this (and then failing with NPE) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2873038583

From mcimadamore at openjdk.org  Mon May 12 15:42:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 May 2025 15:42:51 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <jLXOZTnK7r4fwtdDsFrfURg8OCT-6sAwp_AZzbCGfRo=.ab2e1362-756b-4c53-bff3-e454e32008d1@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <tpW3MR9sfSHPWtWkQ5GvaB_5uXYuAhbM6TEWhtwCN8Y=.147d1c9b-6893-498b-ab13-c9578f3c0656@github.com>
 <jLXOZTnK7r4fwtdDsFrfURg8OCT-6sAwp_AZzbCGfRo=.ab2e1362-756b-4c53-bff3-e454e32008d1@github.com>
Message-ID: <TjTbJ-aZsx3RoFi9FeLS5f51TMdyEIcw2PJvjnJ3ow0=.4d960a08-d124-4310-844c-577b1fccd8e7@github.com>

On Mon, 12 May 2025 10:39:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > 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.
> 
> yes I think this is an issue of the minimization algo. I mean there will always be at least one variable in MIC that won't be in IC and if MIC is asked to substitute that variable by its corresponding inference variable, then MIC won't be able to do it as it doesn't know how to map it and, potentially, some constraints won't be added to the inference variable. When we obtain MIC from IC we just don't know what queries we will do on MIC. The algo doesn't have this info.
> 
> I guess that there could be two ways to fix this:
> 
>     * keeping links to the original inference contexts which will have more info, which is what this PR is doing
> 
>     * trying to generate a more complete MIC gathering additional info
> 
> 
> the second option seems like more complex as we could need some heuristics like type variables appearing in the same type, etc, and it could be harder to make sure that we get all the needed info. Also a more fluffy MIC would impact performance

I agree that keeping a link to the original context is conceptually simpler -- I guess I'm worried that the implementation started off one way (e.g. avoid a link between context, and use free type listeners) and now it's moving in a different way (adding links between context). Which means that now we have both kinds of complexities.

More concretely, `InferenceContext::min` has code to track dependencies via listeners. This PR doesn't remove that code, but it adds a _new_ field, by which an inference context could point to its original version. Then it adds some more code to make sure that when we instantiate a type var on a context, all the contexts it depend on get the memo. While I believe this fixes the issue, I wouldn't be surprised if the original inference context would now be notified multiple times, once through the legacy mechanism, and once through the new mechanism.

Is it possible to simplify the code so that the old mechanism goes away, and we do everything using the new field?

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2873067954

From acobbs at openjdk.org  Mon May 12 15:59:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 12 May 2025 15:59:51 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <FkKNhvQPSPk7p4zmNRoQx0Dkw9X9opppsod96uJfj-I=.e06dd401-361e-4b0e-a764-bd6b81839eb1@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
 <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
 <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>
 <VVg3xpRzJRu9MisU7wUc2Tke7UELjLro9BGs6iJBMok=.d27a0075-be89-42ac-9cb8-4e8f1f44f947@github.com>
 <FkKNhvQPSPk7p4zmNRoQx0Dkw9X9opppsod96uJfj-I=.e06dd401-361e-4b0e-a764-bd6b81839eb1@github.com>
Message-ID: <k4wwDBKTFJXU1hc-h1ZVp3CKxwDnou11HgDCUGRs2jI=.37c7d787-cc04-4bb6-a65a-4a41d4eebeae@github.com>

On Mon, 12 May 2025 15:32:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Can you expand a bit more -- who's trying to access this (and then failing with NPE) ?

The compiler expects the parameter to have an associated symbol:

java.lang.NullPointerException: Cannot read field "kind" because "tree.sym" is null
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.visitIdent(Flow.java:3395)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2710)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.visitVarDef(TreeScanner.java:142)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.visitVarDef(Flow.java:3444)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1066)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.visitMethodDef(TreeScanner.java:132)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:960)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:58)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.visitClassDef(TreeScanner.java:125)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.visitClassDef(Flow.java:3347)
	at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:859)
	at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:460)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.analyzeTree(Flow.java:3470)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow$CaptureAnalyzer.analyzeTree(Flow.java:3463)
	at jdk.compiler.interim/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:231)
	at jdk.compiler.interim/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1406)
	at jdk.compiler.interim/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1380)
	at jdk.compiler.interim/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:968)
	at jdk.compiler.interim/com.sun.tools.javac.main.Main.compile(Main.java:319)
	at jdk.compiler.interim/com.sun.tools.javac.main.Main.compile(Main.java:178)
	at jdk.compiler.interim/com.sun.tools.javac.Main.compile(Main.java:66)
	at jdk.compiler.interim/com.sun.tools.javac.Main.main(Main.java:52)


I guess we could hack some placeholder.

> So, my idea was to simply compute `tree.nameexpr.type` by calling `Attr::attribType` on the qualifier, and then keep `checkReceiver` the same as it is today.

You then get this problem when the outer class is generic:

RecvParam.java:24: error: the receiver name does not match the enclosing class type
        public void m4(Inner3<T> Inner3.this, short s) {
                                       ^
  required: Inner3<T>
  found:    Inner3


Plus, you still haven't dealt with any static context issues... (e.g., see unit test `/annotations/typeAnnotations/failures/common/receiver/StaticThings.java`).

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2873131767

From darcy at openjdk.org  Mon May 12 17:25:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 May 2025 17:25:54 GMT
Subject: RFR: 8356057: PrintingProcessor (-Xprint) does not print type
 variable bounds and type annotations for Object supertypes [v5]
In-Reply-To: <zO5ydffJEMfTdcYc-8rMM3z3KL7EzqAMKVsXv0OKWSo=.f9cae71d-ab7e-465b-8095-da48cd5e4c49@github.com>
References: <izlgVet-Bf7skYKS4ZhyBdhpqirxvMs4OUIRpQDNJFE=.f5f91bad-4ff3-4d72-b06e-0a58910dfc08@github.com>
 <zO5ydffJEMfTdcYc-8rMM3z3KL7EzqAMKVsXv0OKWSo=.f9cae71d-ab7e-465b-8095-da48cd5e4c49@github.com>
Message-ID: <xvsdvur0e0iZcSlY5TNHbELpuLxvMTAGN37Wt4voHbk=.d04b13cf-a3ab-4f8e-b4fb-afaf41959052@github.com>

On Mon, 12 May 2025 11:22:10 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:
> 
>   Adding test for recursive bounds.

Marked as reviewed by darcy (Reviewer).

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

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

From mcimadamore at openjdk.org  Mon May 12 21:42:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 May 2025 21:42:51 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
Message-ID: <_r9M-aNEhniK9J56yMpUQ3rhj8JqvegdZ6FMLLy_618=.90ddfb07-7385-44f1-912f-edacbeadb507@github.com>

On Fri, 9 May 2025 17:13:08 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Consider a class like this:
> 
> class Outer {
>   Outer() {
>     class Local {
>       Local(Outer Outer.this) {  // "receiver parameter"
>       }
>     }
>     super();
>   }
> }
> 
> Normally, a reference to `Outer.this` appearing anywhere in `Local` would generate an error because `Local` is defined in an early construction context of `Outer`. But in the above example, `Outer.this` is a "receiver parameter", which is the relatively obscure mechanism by which type annotations can be added to the outer instance (JLS ?8.4).
> 
> This is allowed, even though the outer instance is otherwise inaccessible here. However, the compiler was reporting an error. This PR adds an exception for receiver parameters to the illegal early access check. It also adds a missing bug ID to the regression test.

In light of more recent comment, I decided to approve this PR as is. While it might be possible to perhaps change the code in `MemberEnter` to avoid going through `resolveSelf`, it all seems a bit harder than I first thought/hoped. Thanks @archiecobbs  for the analysis. The only comment I have is that, maybe instead of comparing trees, we could perhaps use a flag in `AttrContext` to signal that we're checking the receiver parameter. But I don't think it will make a massive difference, so I'm just leaving this comment for your consideration.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25153#pullrequestreview-2834690975

From naoto at openjdk.org  Mon May 12 22:04:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 May 2025 22:04:51 GMT
Subject: RFR: 8354908: javac mishandles supplementary character in
 character literal [v2]
In-Reply-To: <41x4IdFHFNLrzL4JFzCiGmtv9-4qIO_OukPGWrsg9yE=.8e5dc356-9dcd-4fd3-b099-9f8527d1d768@github.com>
References: <SUlHkqI0oCFSFvlTd46PuvqWQ_t6R9Cym0WbfRwvgdE=.be271d2e-64e8-4d2c-b078-be94a38b5217@github.com>
 <41x4IdFHFNLrzL4JFzCiGmtv9-4qIO_OukPGWrsg9yE=.8e5dc356-9dcd-4fd3-b099-9f8527d1d768@github.com>
Message-ID: <Ow8aO9G0i4TYGd083zNlZAakAYN8cYueF56RaAnKils=.ab648106-784a-49da-bd96-3c580accf458@github.com>

On Mon, 12 May 2025 11:16:09 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
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comment: using UTF-16 code unit

Marked as reviewed by naoto (Reviewer).

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

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

From acobbs at openjdk.org  Mon May 12 22:44:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 12 May 2025 22:44:53 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <FkKNhvQPSPk7p4zmNRoQx0Dkw9X9opppsod96uJfj-I=.e06dd401-361e-4b0e-a764-bd6b81839eb1@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
 <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
 <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>
 <VVg3xpRzJRu9MisU7wUc2Tke7UELjLro9BGs6iJBMok=.d27a0075-be89-42ac-9cb8-4e8f1f44f947@github.com>
 <FkKNhvQPSPk7p4zmNRoQx0Dkw9X9opppsod96uJfj-I=.e06dd401-361e-4b0e-a764-bd6b81839eb1@github.com>
Message-ID: <0Fc-FY1RN2PT7rd5AddGBIjwfu5foYhORG5eLxDetsQ=.99203f64-1975-452e-aa0a-bee931cfb04c@github.com>

On Mon, 12 May 2025 15:32:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> I tried out that approach in [this branch](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8356551-alt). I'm reaching the limits of my grasp so this may not be the simplest way to do this. AFAICT we still have to (a) assign some type/symbol to the parameter expression (to avoid NPE later) and (b) do the static check stuff.
>>> 
>>> Let me know which version you prefer, or any other thoughts.
>> 
>> Thanks for the experiment.
>> My general feeling is that we can get away with a lot less. The code in `checkReceiver` is sending `Foo.this` into attribution. But then it's not really using the full results of the attribution -- instead it's just looking at the type qualifier, and enforcing that this type is the same as the enclosing instance type:
>> 
>> 
>> checkType(tree.nameexpr, outertype, Errors.IncorrectConstructorReceiverName(outertype, tree.nameexpr.type));
>> 
>> (see `tree.nameexpr.type`).
>> 
>> So, my idea was to simply compute `tree.nameexpr.type` by calling `Attr::attribType` on the qualifier, and then keep `checkReceiver` the same as it is today. This also should not need to add any new method in `Resolve`.
>
>> we still have to (a) assign some type/symbol to the parameter expression (to avoid NPE later)
> 
> Can you expand a bit more -- who's trying to access this (and then failing with NPE) ?

@mcimadamore thanks for the review - and for the idea.

I have some fuzziness on exactly how `AttrContext` is supposed to be used, which is why I didn't go that route originally. `AttrContext` seems to correspond to lexical scopes, but here we want to "pass a note" with a narrower focus, i.e., just a variable declaration.

But maybe I'm being to pedantic. [This patch](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8356551-alt2) seems to work - what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2874362003

From daniel.smith at oracle.com  Tue May 13 01:31:31 2025
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 13 May 2025 01:31:31 +0000
Subject: 2025 JVM Language Summit
Message-ID: <5B7673E9-AA6A-475A-9B5E-02A197667F45@oracle.com>

2025 JVM LANGUAGE SUMMIT -- CALL FOR SPEAKERS

We are pleased to announce the 2025 JVM Language Summit to be held at Oracle?s Santa Clara campus on August 4-6, 2025. Registration is now open for speakers, with general attendee registration coming soon. Speaker submissions will be accepted through May 30.

The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice.

Presentations will be recorded and made available to the public.

This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions.

Please review additional details at:
https://jvmlangsummit.com

To register:
https://register.jvmlangsummit.com

Questions:
info2025 at jvmlangsummit.com


From acobbs at openjdk.org  Tue May 13 01:51:50 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 May 2025 01:51:50 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v3]
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: <ENFIAb-wan682Eskw3r6KdzCv0lgriT-_Yht432NQfw=.1de885aa-5a8a-4f2d-8662-576317118b3d@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 incrementally with one additional commit since the last revision:

  Update man page.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23622/files
  - new: https://git.openjdk.org/jdk/pull/23622/files/646b7eca..9069f902

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

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 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 jlahoda at openjdk.org  Tue May 13 04:46:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 May 2025 04:46:58 GMT
Subject: Integrated: 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: <vepVL9bcPnYHxbEJhdCO69LFpoIzkPN7TOoupKMCVm4=.1f0308ea-65e4-482e-beb0-c4b4f0a3c6e2@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

This pull request has now been integrated.

Changeset: 24d77ade
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24d77adee9643c341d27366532c95923e1d97248
Stats:     243 lines in 6 files changed: 222 ins; 2 del; 19 mod

8356057: PrintingProcessor (-Xprint) does not print type variable bounds and type annotations for Object supertypes

Reviewed-by: darcy, vromero

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

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

From jlahoda at openjdk.org  Tue May 13 06:18:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 May 2025 06:18:58 GMT
Subject: Integrated: 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: <KspXncIZCFht5ay3gSks3nivE8_RCX5nJWaG1h7DeEk=.9fb86784-7d42-4248-9433-132f29943dd7@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

This pull request has now been integrated.

Changeset: 03dca032
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03dca0323d79ef5fb1c8ee1152667e2188fa5e01
Stats:     62 lines in 4 files changed: 60 ins; 0 del; 2 mod

8354908: javac mishandles supplementary character in character literal

Reviewed-by: naoto, vromero

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

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

From mcimadamore at openjdk.org  Tue May 13 08:52:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 13 May 2025 08:52:58 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <0Fc-FY1RN2PT7rd5AddGBIjwfu5foYhORG5eLxDetsQ=.99203f64-1975-452e-aa0a-bee931cfb04c@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
 <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
 <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>
 <VVg3xpRzJRu9MisU7wUc2Tke7UELjLro9BGs6iJBMok=.d27a0075-be89-42ac-9cb8-4e8f1f44f947@github.com>
 <FkKNhvQPSPk7p4zmNRoQx0Dkw9X9opppsod96uJfj-I=.e06dd401-361e-4b0e-a764-bd6b81839eb1@github.com>
 <0Fc-FY1RN2PT7rd5AddGBIjwfu5foYhORG5eLxDetsQ=.99203f64-1975-452e-aa0a-bee931cfb04c@github.com>
Message-ID: <HEUAdYUjI-TbxWMNAcs34W4sawQVauWM09o5avwFjzE=.17081e21-fdde-45ed-bd77-f21800aa85ca@github.com>

On Mon, 12 May 2025 22:42:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> But maybe I'm being to pedantic. [This patch](https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8356551-alt2) seems to work - what do you think?

I believe that works ok. `AttrContext` is sometimes used this way, and there's a lot of "state" flags (see `isAnonymousDiamond`).

Another idea would be to just temporarily disable the `ctorPrologue` flag for the enclosing class env while attributing the receiver parameter (which should amount to the same effect) -- but that's probably a bit harder to do because you need to traverse the `env` to find exactly the one that you need to disable.

Either the patch in the current PR or the one you linked look fine to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2875595896

From jlahoda at openjdk.org  Tue May 13 11:34:32 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 May 2025 11:34:32 GMT
Subject: RFR: 8348906: InstanceOfTree#getType doesn't specify when it returns
 null
Message-ID: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>

`InstanceOfTree.getType()` returns `null` if the `instanceof` uses a pattern different than the type test pattern. This is not documented, and should be documented. This PR proposes the documentation for this.

Alternatively, we could change `getType()` to return a type for other types of patterns, but the meaning of that is not quite clear even for record patterns, and it gets even less clear with the possible future patterns. I believe it has been mostly a conscious decision to not handle record patterns in this method. Possibly, it was a mistake to handle the type test/binding patterns in `getType()`, but that's not something that we should change, I think.

Please also review the CSR:
https://bugs.openjdk.org/browse/JDK-8356857

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

Commit messages:
 - Adding test.
 - 8348906: InstanceOfTree#getType doesn't specify when it returns null

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

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

From jpai at openjdk.org  Tue May 13 12:05:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 May 2025 12:05:19 GMT
Subject: RFR: 8327466: ct.sym zip not reproducible across build environment
 timezones
Message-ID: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>

Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466.

Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output.

The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries.

Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp.

The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument.

The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html.

The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix.

I have run this change in tier1 and tier5 and this and other tests continue to pass.

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

Commit messages:
 - 8327466: ct.sym zip not reproducible across build environment timezones

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

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

From erikj at openjdk.org  Tue May 13 13:02:06 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 13 May 2025 13:02:06 GMT
Subject: RFR: 8327466: ct.sym zip not reproducible across build environment
 timezones
In-Reply-To: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
References: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
Message-ID: <SKNsMHcQ1AV-IZFcPNaHFkeYE1Jk0lQiFCld-YpWhBo=.aa05a200-5a4f-4dec-a519-f9c3fc633c90@github.com>

On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466.
> 
> Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output.
> 
> The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries.
> 
> Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp.
> 
> The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument.
> 
> The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html.
> 
> The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix.
> 
> I have run this change in tier1 and tier5 and this and other tests co...

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25207#pullrequestreview-2836670871

From jlahoda at openjdk.org  Tue May 13 13:20:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 May 2025 13:20:52 GMT
Subject: RFR: 8327466: ct.sym zip not reproducible across build environment
 timezones
In-Reply-To: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
References: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
Message-ID: <TE1WGq_pumg2qMHr35K-buqHf9cXxlCgAH20jJRBrnI=.374305ac-20f0-41ee-b57e-caec13f3cae1@github.com>

On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466.
> 
> Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output.
> 
> The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries.
> 
> Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp.
> 
> The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument.
> 
> The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html.
> 
> The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix.
> 
> I have run this change in tier1 and tier5 and this and other tests co...

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25207#pullrequestreview-2836754836

From acobbs at openjdk.org  Tue May 13 14:33:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 May 2025 14:33:56 GMT
Subject: RFR: 8356551: Javac rejects receiver parameter in constructor of
 local class in early construction context
In-Reply-To: <HEUAdYUjI-TbxWMNAcs34W4sawQVauWM09o5avwFjzE=.17081e21-fdde-45ed-bd77-f21800aa85ca@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
 <FeTjt_ZgH2ACjbm8aEKe5jfUFFUOfnA88EfY_-qMqlw=.c63ef0b4-dc37-47e1-8316-c9f49f48f747@github.com>
 <Wp8Fsvcj9tOFPstomqaQfKUvGIOP1E-rHJ_0dp4MWTA=.68bc1d57-bcbf-46d5-89ed-d8248c05a1b5@github.com>
 <pNd_OzuqIzDQd2sKtUKDJcW5N5tMuBfpuYDO6WP_138=.82847e26-4ab1-4097-b569-d8e3cd6dd611@github.com>
 <d3SvPzRm-FdNCIP2tX5ZXgQOEiOfX4RIbTLQ7OVLHbk=.10aa1466-9690-49f6-944b-a8307a030194@github.com>
 <Iia33Vt7pZ1uritG-JvKiZURP86YwMBIvkTCoMX-TqE=.762fd93b-e6ac-4cf0-83ff-b17503b9b9f0@github.com>
 <VVg3xpRzJRu9MisU7wUc2Tke7UELjLro9BGs6iJBMok=.d27a0075-be89-42ac-9cb8-4e8f1f44f947@github.com>
 <FkKNhvQPSPk7p4zmNRoQx0Dkw9X9opppsod96uJfj-I=.e06dd401-361e-4b0e-a764-bd6b81839eb1@github.com>
 <0Fc-FY1RN2PT7rd5AddGBIjwfu5foYhORG5eLxDetsQ=.99203f64-1975-452e-aa0a-bee931cfb04c@github.com>
 <HEUAdYUjI-TbxWMNAcs34W4sawQVauWM09o5avwFjzE=.17081e21-fdde-45ed-bd77-f21800aa85ca@github.com>
Message-ID: <O6jgEX8-2XffU_TAcoZi-D_3Y0J0GYkjYnS19z8utpE=.fa902f2f-fd1f-4433-bd29-eb7ccffa5bef@github.com>

On Tue, 13 May 2025 08:50:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Either the patch in the current PR or the one you linked look fine to me.

OK thanks. I'll just stick with the current patch for simplicity (one less field to be carried around everywhere).

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25153#issuecomment-2876763390

From acobbs at openjdk.org  Tue May 13 14:33:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 May 2025 14:33:57 GMT
Subject: Integrated: 8356551: Javac rejects receiver parameter in constructor
 of local class in early construction context
In-Reply-To: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
References: <q3lWQ0DQhe4dsRuA0mPO5NHsrwZAo4NkukhTiyg0GaQ=.e3745ea7-012a-4a8b-857e-ae4dbe7a9cee@github.com>
Message-ID: <PMCvqpYDwblKMhJuDUMET-77AtecEE1EJ9oLROtACF4=.4425f5b7-3f62-4bb5-9cea-9a89b81ff1b2@github.com>

On Fri, 9 May 2025 17:13:08 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Consider a class like this:
> 
> class Outer {
>   Outer() {
>     class Local {
>       Local(Outer Outer.this) {  // "receiver parameter"
>       }
>     }
>     super();
>   }
> }
> 
> Normally, a reference to `Outer.this` appearing anywhere in `Local` would generate an error because `Local` is defined in an early construction context of `Outer`. But in the above example, `Outer.this` is a "receiver parameter", which is the relatively obscure mechanism by which type annotations can be added to the outer instance (JLS ?8.4).
> 
> This is allowed, even though the outer instance is otherwise inaccessible here. However, the compiler was reporting an error. This PR adds an exception for receiver parameters to the illegal early access check. It also adds a missing bug ID to the regression test.

This pull request has now been integrated.

Changeset: b8c69dfb
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8c69dfb2adb0eb8cce6b5e81a7388a6430eb8fb
Stats:     30 lines in 3 files changed: 22 ins; 0 del; 8 mod

8356551: Javac rejects receiver parameter in constructor of local class in early construction context

Reviewed-by: mcimadamore

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

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

From nbenalla at openjdk.org  Tue May 13 15:03:39 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 13 May 2025 15:03:39 GMT
Subject: RFR: 8343054: Add support for a new `@info` javadoc block tag for API
 guidance
Message-ID: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>

This PR adds a new `@info` block tag to javadoc, it can be used to document general guidance for APIs.

Tests will be added to this patch later, CSR is still under review.

TIA

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

Commit messages:
 - implement `@info` javadoc block tag

Changes: https://git.openjdk.org/jdk/pull/25215/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343054
  Stats: 285 lines in 21 files changed: 267 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25215/head:pull/25215

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

From nbenalla at openjdk.org  Tue May 13 15:44:56 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 13 May 2025 15:44:56 GMT
Subject: RFR: 8341736: Add support for a new `@info` javadoc block tag for
 API guidance
In-Reply-To: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
References: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
Message-ID: <6isbbhUbONVsAbKC-LZEh9O5ZB9kv6R1F2xeHtuwHrs=.98aaf3c1-2c31-4d37-9ce0-2f9ea606edcf@github.com>

On Tue, 13 May 2025 14:58:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This PR adds a new `@info` block tag to javadoc, it can be used to document general guidance for APIs.
> 
> Tests will be added to this patch later, CSR is still under review.
> 
> TIA

Closing this for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25215#issuecomment-2877016683

From nbenalla at openjdk.org  Tue May 13 15:44:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 13 May 2025 15:44:57 GMT
Subject: Withdrawn: 8341736: Add support for a new `@info` javadoc block tag
 for API guidance
In-Reply-To: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
References: <yKct1t4-TsBaqCmE9Fg38tdIEtVeJP8V5NIbPL-7yk0=.3fd8a9ea-a3f3-4c75-97c2-0eefe53d2603@github.com>
Message-ID: <RjSMoEKisxpNMXUEI3xnIW8SsF8eDqFwGPe-IUIzMjM=.3cd333f0-7b68-48ab-b79f-3de4f0d6e799@github.com>

On Tue, 13 May 2025 14:58:27 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This PR adds a new `@info` block tag to javadoc, it can be used to document general guidance for APIs.
> 
> Tests will be added to this patch later, CSR is still under review.
> 
> TIA

This pull request has been closed without being integrated.

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

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

From acobbs at openjdk.org  Tue May 13 16:04:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 13 May 2025 16:04:33 GMT
Subject: RFR: 8349754: Invalid "early reference" error when class extends
 an outer class [v3]
In-Reply-To: <cghFkzkY0v-zPbQJLdzYEK9fJtEW8Kp0AY6ehR4I2og=.464c4b4f-872e-466b-80bb-261214ffb31f@github.com>
References: <cghFkzkY0v-zPbQJLdzYEK9fJtEW8Kp0AY6ehR4I2og=.464c4b4f-872e-466b-80bb-261214ffb31f@github.com>
Message-ID: <KxyZDzFxUKabuWfPUkeFyRRYRSODsaNuMM-nEkJ5MkM=.0dda6862-ea00-48fb-9463-e96a0c1d6fe2@github.com>

> The compiler is generating a bogus error for this input:
> 
> $ cat Outer.java
> class Outer {
>     private int i;
>     class Sub extends Outer {
>         Sub() {
>             i = 42;
>             super();
>         }
>     }
> }
> $ javac --enable-preview --source 24 Outer.java
> Outer.java:5: error: cannot reference i before supertype constructor has been called
>             i = 42;
>             ^
> Note: Outer.java uses preview features of Java SE 24.
> Note: Recompile with -Xlint:preview for details.
> 1 error 
> 
> 
> The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class.

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

 - Merge branch 'master' into JDK-8349754 to fix conflict.
 - Simplify logic using Symbol.isMemberOf() per review suggestion.
 - Fix incorrect "early reference" error.

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

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

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

From vromero at openjdk.org  Tue May 13 19:36:11 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 May 2025 19:36:11 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
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: <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@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 34 commits:

 - Merge branch 'master' into JDK-8354556
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - additional changes from Archie
 - removing dead code
 - integrating code from Archie
 - fixing bugs, removing dead code
 - additional documentation changes and bug fixes
 - documentation and adding alias to lint categories
 - Merge branch 'master' into JDK-8354556
 - addressing review comment
 - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29

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

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=12
  Stats: 661 lines in 32 files changed: 576 ins; 37 del; 48 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  Tue May 13 20:00:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 May 2025 20:00:00 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
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: <YfH-tAME9QF5hA05eO931sPuQhJT0QLvMPYvjfujUjc=.4eb8db38-c5ea-44d3-94d8-92f0b4248ee0@github.com>

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

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1:
> 
>> 1: /*
> 
> Need to add handling of `RequiresIdentity` in `createAnnotation`

update on CreateSymbols, the complete implementation with the changes for CreateSymbols should be included in the PR for [1]. Which will be developed in parallel to this proposal

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

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

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

From liach at openjdk.org  Tue May 13 22:51:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 22:51:55 GMT
Subject: RFR: 8348906: InstanceOfTree#getType doesn't specify when it
 returns null
In-Reply-To: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>
References: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>
Message-ID: <jqpl22z_XmEoe4Y6K5PXy--rN7D1RuCtzVY7JoSyQGw=.ff5cf84c-3b94-4cf9-ba44-ba4c262670c6@github.com>

On Tue, 13 May 2025 11:29:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `InstanceOfTree.getType()` returns `null` if the `instanceof` uses a pattern different than the type test pattern. This is not documented, and should be documented. This PR proposes the documentation for this.
> 
> Alternatively, we could change `getType()` to return a type for other types of patterns, but the meaning of that is not quite clear even for record patterns, and it gets even less clear with the possible future patterns. I believe it has been mostly a conscious decision to not handle record patterns in this method. Possibly, it was a mistake to handle the type test/binding patterns in `getType()`, but that's not something that we should change, I think.
> 
> Please also review the CSR:
> https://bugs.openjdk.org/browse/JDK-8356857

We should also update the examples on `InstanceOfTree` itself and `getPattern` to indicate all three possibilities we have right now for (type, pattern) - at least one of these is non-null.

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

PR Comment: https://git.openjdk.org/jdk/pull/25205#issuecomment-2878129058

From ihse at openjdk.org  Wed May 14 06:46:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:46:57 GMT
Subject: Integrated: 8354968: Replace unicode sequences in comment text with
 UTF-8 characters
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <sgBPptQGphRdBvFWPXl8SJm3092mzM3MjrlJs3LVL3A=.df2ae687-a101-48de-a821-4f8973c7558a@github.com>

On Thu, 17 Apr 2025 14:42:37 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.

This pull request has now been integrated.

Changeset: a3e094e1
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3e094e1a0716adf52dad6407eb7877682beec92
Stats:     158 lines in 153 files changed: 0 ins; 2 del; 156 mod

8354968: Replace unicode sequences in comment text with UTF-8 characters

Reviewed-by: naoto

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

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

From jpai at openjdk.org  Wed May 14 12:41:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 May 2025 12:41:59 GMT
Subject: RFR: 8327466: ct.sym zip not reproducible across build environment
 timezones
In-Reply-To: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
References: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
Message-ID: <u0FypZDvedzHS46fkc-y-raXON6twu82Ft1wKmetnw0=.930d3d42-d563-43bd-8313-30987396e8d1@github.com>

On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466.
> 
> Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output.
> 
> The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries.
> 
> Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp.
> 
> The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument.
> 
> The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html.
> 
> The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix.
> 
> I have run this change in tier1 and tier5 and this and other tests co...

Thank you Erik and Jan for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25207#issuecomment-2880061230

From jpai at openjdk.org  Wed May 14 12:42:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 May 2025 12:42:00 GMT
Subject: Integrated: 8327466: ct.sym zip not reproducible across build
 environment timezones
In-Reply-To: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
References: <nMzlFqcajKOtEACTPn-4iZIgfDWPL93eb92-uu9bU3M=.6f1c620b-7f71-40d9-bd50-3c7b901013f1@github.com>
Message-ID: <0GmtuBkNc1HGnzMG12gcrrkKqmOnRywgBFNVY7CIDc8=.4c03bcd7-2716-4aad-8284-12f9b758ba4f@github.com>

On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466.
> 
> Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output.
> 
> The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries.
> 
> Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp.
> 
> The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument.
> 
> The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html.
> 
> The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix.
> 
> I have run this change in tier1 and tier5 and this and other tests co...

This pull request has now been integrated.

Changeset: a989245a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a989245a2424d136f5d2a828eda666c3867b0f48
Stats:     186 lines in 2 files changed: 180 ins; 4 del; 2 mod

8327466: ct.sym zip not reproducible across build environment timezones

Reviewed-by: erikj, jlahoda

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

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

From jlahoda at openjdk.org  Wed May 14 13:44:48 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 May 2025 13:44:48 GMT
Subject: RFR: 8348906: InstanceOfTree#getType doesn't specify when it
 returns null [v2]
In-Reply-To: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>
References: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>
Message-ID: <u0zxU9jTwwFgENjTmM8thedh8bxtctxfJrYBFtszCrI=.b51af9b6-eb60-45c1-aa09-b7ea2096c5f2@github.com>

> `InstanceOfTree.getType()` returns `null` if the `instanceof` uses a pattern different than the type test pattern. This is not documented, and should be documented. This PR proposes the documentation for this.
> 
> Alternatively, we could change `getType()` to return a type for other types of patterns, but the meaning of that is not quite clear even for record patterns, and it gets even less clear with the possible future patterns. I believe it has been mostly a conscious decision to not handle record patterns in this method. Possibly, it was a mistake to handle the type test/binding patterns in `getType()`, but that's not something that we should change, I think.
> 
> Please also review the CSR:
> https://bugs.openjdk.org/browse/JDK-8356857

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

  Reflecting review comment - adding examples.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25205/files
  - new: https://git.openjdk.org/jdk/pull/25205/files/11c94956..f8495d59

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

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

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

From ihse at openjdk.org  Wed May 14 14:28:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:28:10 GMT
Subject: RFR: 8356977: UTF-8 cleanups
Message-ID: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>

I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

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

Commit messages:
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

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

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

From jlahoda at openjdk.org  Wed May 14 14:53:34 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 May 2025 14:53:34 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added
 @jdk.internal.RequiresIdentity
Message-ID: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>

This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.

Important parts of the patch:
- `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
- for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
- for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
- for type variables, the synthetic annotation is filtered out in the API method

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

Depends on: https://git.openjdk.org/jdk/pull/24746

Commit messages:
 - Cleanup.
 - Fixing build
 - Adjustments, annotation filtering, adding more tests
 - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556
 - Improving the behavior of the PrintingProcessor.
 - First support for runtime visible and invisible type annotations in CreateSymbols.
 - Merge branch 'master' into JDK-8354556

Changes: https://git.openjdk.org/jdk/pull/25232/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25232&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356894
  Stats: 543 lines in 12 files changed: 512 ins; 14 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25232/head:pull/25232

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

From vromero at openjdk.org  Wed May 14 15:29:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 14 May 2025 15:29:55 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity
In-Reply-To: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
Message-ID: <wSqih3txvVgbA2niGYg9qJWYMC2x1URsV48P46ShRRM=.fa813478-ac86-4cef-89c3-66b8afa9cef1@github.com>

On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
> 
> Important parts of the patch:
> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API method

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2840646906

From henryjen at openjdk.org  Wed May 14 16:42:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 14 May 2025 16:42:56 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: <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@github.com>

On Wed, 7 May 2025 17:41:07 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
>
> 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....

UTF-8 messed up the index, we don't want any conversion to happen.
Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory
Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory
Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header
Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2089340789

From lancea at openjdk.org  Wed May 14 17:29:52 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 May 2025 17:29:52 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@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>
 <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@github.com>
Message-ID: <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com>

On Wed, 14 May 2025 16:39:54 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> UTF-8 messed up the index, we don't want any conversion to happen. Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header

Without looking into this in finer detail I am not sure what the issue is and is why the other tests typically use the actual offset to modify.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2089413418

From jlahoda at openjdk.org  Wed May 14 18:04:59 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 May 2025 18:04:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
Message-ID: <xge1nQel0cyouOx5KB7Jd7zJXhx2Krb83VG3LY-bqJ0=.f2cfce9b-91a0-43ec-b343-7775b9637f60@github.com>

On Tue, 13 May 2025 19:36:11 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 34 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - fixing bugs, removing dead code
>  - additional documentation changes and bug fixes
>  - documentation and adding alias to lint categories
>  - Merge branch 'master' into JDK-8354556
>  - addressing review comment
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5673:

> 5671:     void checkRequiresIdentity(JCTree tree, Lint lint) {
> 5672:         switch (tree) {
> 5673:             case JCClassDecl classDecl : {

Nit - unless fall-through is needed (it does not seem to be, on the first sight), I would suggest to use `->` instead of `:`, esp. given the cases use blocks anyway.

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

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

From jlahoda at openjdk.org  Wed May 14 19:18:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 May 2025 19:18:03 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
Message-ID: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>

On Tue, 13 May 2025 19:36:11 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 34 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - fixing bugs, removing dead code
>  - additional documentation changes and bug fixes
>  - documentation and adding alias to lint categories
>  - Merge branch 'master' into JDK-8354556
>  - addressing review comment
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29

javac changes look overall good to me. One question and some comments for consideration inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2673:

> 2671:             result = check(tree, capturedRes, KindSelector.VAL, resultInfo);
> 2672:         }
> 2673:         if (env.info.lint.isEnabled(LintCategory.IDENTITY)) {

This is the only place where there's a check whether the lint is enabled before the call to `checkRequiresIdentity`. Is there a reason for that?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5671:

> 5669:     }
> 5670: 
> 5671:     void checkRequiresIdentity(JCTree tree, Lint lint) {

For consideration: as far as I can see, we have a sharp(er) type when we call `checkRequiresIdentity`, but we give up the type, and re-instante it here using the pattern matching switch. I wonder if it would be more elegant (and hopefully not really too much longer) if the `checkRequiresIdentity` method would have multiple overloads, with the sharp(er) types, like `JCClassDecl`/`JCVariableDecl`, etc.

Or is there a reason to given up the sharp(er) type and re-create it using the switch?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5823:

> 5821:                 SymbolMetadata sm = t.tsym.getMetadata();
> 5822:                 if (sm != null && !t.getTypeArguments().isEmpty()) {
> 5823:                     for (Attribute.TypeCompound ta: sm.getTypeAttributes().stream()

The code here, and the code in `checkIfTypeParamsRequiresIdentity` look similar a lot (although they manipulate `List<Type>` and `List<JCExpression>`, of course. I wonder if there's a chance to share the code, at least partially.

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

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2841121286
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089504249
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089507277
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2089509893

From liach at openjdk.org  Wed May 14 19:35:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 May 2025 19:35:51 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity
In-Reply-To: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
Message-ID: <m88P3a7Wm4wgOCs05Uo2whqQ3xR62P2K9Wr7g_mzQtA=.bdb7a81f-cf39-4755-8868-00b34cfe6942@github.com>

On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
> 
> Important parts of the patch:
> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API method

Looks good to me too; though I don't know why we need special treatment for requiresIdentityInternal for Symbol.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2841288882

From vromero at openjdk.org  Wed May 14 19:43:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 14 May 2025 19:43:56 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <TjTbJ-aZsx3RoFi9FeLS5f51TMdyEIcw2PJvjnJ3ow0=.4d960a08-d124-4310-844c-577b1fccd8e7@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <tpW3MR9sfSHPWtWkQ5GvaB_5uXYuAhbM6TEWhtwCN8Y=.147d1c9b-6893-498b-ab13-c9578f3c0656@github.com>
 <jLXOZTnK7r4fwtdDsFrfURg8OCT-6sAwp_AZzbCGfRo=.ab2e1362-756b-4c53-bff3-e454e32008d1@github.com>
 <TjTbJ-aZsx3RoFi9FeLS5f51TMdyEIcw2PJvjnJ3ow0=.4d960a08-d124-4310-844c-577b1fccd8e7@github.com>
Message-ID: <2XyjAPBmQHrLGSO5pmEUrdaVbq60KubZUBCHbi7rrik=.3c6c4517-32de-4153-9595-4c13dabf64c4@github.com>

On Mon, 12 May 2025 15:40:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > > 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.
> > 
> > 
> > yes I think this is an issue of the minimization algo. I mean there will always be at least one variable in MIC that won't be in IC and if MIC is asked to substitute that variable by its corresponding inference variable, then MIC won't be able to do it as it doesn't know how to map it and, potentially, some constraints won't be added to the inference variable. When we obtain MIC from IC we just don't know what queries we will do on MIC. The algo doesn't have this info.
> > I guess that there could be two ways to fix this:
> > ```
> > * keeping links to the original inference contexts which will have more info, which is what this PR is doing
> > 
> > * trying to generate a more complete MIC gathering additional info
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > the second option seems like more complex as we could need some heuristics like type variables appearing in the same type, etc, and it could be harder to make sure that we get all the needed info. Also a more fluffy MIC would impact performance
> 
> I agree that keeping a link to the original context is conceptually simpler -- I guess I'm worried that the implementation started off one way (e.g. avoid a link between context, and use free type listeners) and now it's moving in a different way (adding links between context). Which means that now we have both kinds of complexities.
> 
> More concretely, `InferenceContext::min` has code to track dependencies via listeners. This PR doesn't remove that code, but it adds a _new_ field, by which an inference context could point to its original version. Then it adds some more code to make sure that when we instantiate a type var on a context, all the contexts it depend on get the memo. While I believe this fixes the issue, I wouldn't be surprised if the original inference context would now be notified multiple times, once through the legacy mechanism, and once through the new mechanism.
> 
> Is it possible to simplify the code so that the old mechanism goes away, and we do everything using the new field?

I have made several experiments to avoid the use of the free type listeners, the prototypes are just moving the code in the listeners to other places basically keeping the same level of complexity but trying to remove the timing component associated to the listeners. I have fixed several bugs or missing parts in the prototypes but the build then fails somewhere else. Also above you said:

>Then it adds some more code to make sure that when we instantiate a type var on a context, all the contexts it depend on get the memo

there is no cascade notification to other contexts when a type var is instantiated, the new code is just using the supplementary contexts as a kind of dictionary to look for the inference vars a given inference context doesn't know about. Given that there are no cascade notifications I don't think that the original inference context will be notified multiple times. Anyways multiple notification should not be possible as every time a free type listener is executed it is removed from the free type listener's map.

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2881355329

From aturbanov at openjdk.org  Thu May 15 09:12:05 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 15 May 2025 09:12:05 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity
In-Reply-To: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
Message-ID: <xnsbATDpTU91gwNHfZ4NBbEFdvc0zgP-biY_95jVuR4=.be466e71-df64-4cad-b4a0-c4db77e0c26e@github.com>

On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
> 
> Important parts of the patch:
> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API method

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 1578:

> 1576:                     Assert.check(sym.kind == MTH);
> 1577:                     sym.flags_field |= RESTRICTED;
> 1578:                 }  else if (proxy.type.tsym == syms.requiresIdentityType.tsym) {

Suggestion:

                } else if (proxy.type.tsym == syms.requiresIdentityType.tsym) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25232#discussion_r2090678802

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 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: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@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*

After an offline discussion, we agreed to wait a bit with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 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: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@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*

This pull request has been closed without being integrated.

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

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

From asotona at openjdk.org  Thu May 15 12:06:57 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 May 2025 12:06:57 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: <nnhqvTpgXD6CuSaEnljNTd7NY9TmvmM7IXqjYD0gutY=.5c1f5b3a-af5d-474e-8a2a-0633012dcbf2@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

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25098#issuecomment-2883574443

From asotona at openjdk.org  Thu May 15 12:06:59 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 May 2025 12:06:59 GMT
Subject: Integrated: 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: <_cRBGDdJbN-GeWg5mHA6xBejTNtDDJuMQ08aKwqbIPw=.8eb45830-9118-4d1e-a44a-ead3553541d5@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

This pull request has now been integrated.

Changeset: 1d36f173
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d36f173c4e924d5049f153eceb13b09e7adebab
Stats:     142 lines in 6 files changed: 134 ins; 3 del; 5 mod

8351232: NPE: Cannot invoke "getDeclarationAttributes" because "sym" is null

Reviewed-by: liach

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

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

From mcimadamore at openjdk.org  Thu May 15 13:14:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 13:14:59 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: <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@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

Btw, I've looked at the issue in JBS again, and simplified it a bit:


class Generics {
       public static void main(String... args) {
            Integer i = null;
            runT(() -> supplyNull(i));
        }

        static <R, X> R supplyNull(X... varargs) {
            System.out.println(varargs.getClass().getComponentType());
            return null;
        }
              
        static <T> void runT(Runnable runnable) { runnable.run(); }
}


(I've removed a call to `Integer::valueOf` that was not necessary to reproduce the issue -- but was adding some extra noise).

Note that here the calls to `supplyNull` and `runT` are completely independent. That's because the call to `supplyNull` occurs in a void-compatible lambda (the target of the lambda is `Runnable`). As such, it is not possible for inference of the nested call to `supplyNull` to have any effect on the inference of the `runT` call.

However, when debugging, I see that when we call `checkMethod` for `supplyNull`, we attempt to propagate its inference context outwards. This is done even though the `resultInfo` says that the expected type is `void` (where `void` is the return type of the function descriptor).

In other words, it seems to me that `Infer::shouldPropagate` is buggy: it returns true if all the conditions below are satisfied:
* the enclosing method is a generic method
* the return type of the current method contains some inference vars
* no eager resolution is required

But we never check what the target-type of the current method actually is. Normally, the target will be some non-void type -- so when we propagate, we will need to check compatibility again, which will fix up all the types. But in this case (which is a corner case due to void-compatible lambdas), the target happens to be `void` -- meaning inference will never be "completed".

See the implementation of `Attr.ExpressionLambdaReturnContext::compatible`:


           @Override
            public boolean compatible(Type found, Type req, Warner warn) {
                //a void return is compatible with an expression statement lambda
                if (req.hasTag(VOID)) {
                    expStmtExpected = true;
                    return TreeInfo.isExpressionStatement(expr);
                } else {
                    return super.compatible(found, req, warn);
                }
            }


In other words, if the expected type is `void` (as in this case), `super.compatible` will not be called -- which means the deferred type for the nested generic method call will remain uninferred.

Adding an extra check to `Infer::shouldPropagate` to _not_ propagate when the target happens to be `void` seems to fix the issue in JBS. (but, I have not ran any other test).

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2883767203

From vromero at openjdk.org  Thu May 15 15:04:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 15:04:55 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@github.com>
Message-ID: <hsDX9-No4Bq345HcPsjBBpsyV5IfosijeEPqgplx6xU=.d682fd91-59c3-472d-8b10-8789fb385cd7@github.com>

On Thu, 15 May 2025 13:12:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Btw, I've looked at the issue in JBS again, and simplified it a bit:
> 
> ```
> class Generics {
>        public static void main(String... args) {
>             Integer i = null;
>             runT(() -> supplyNull(i));
>         }
> 
>         static <R, X> R supplyNull(X... varargs) {
>             System.out.println(varargs.getClass().getComponentType());
>             return null;
>         }
>               
>         static <T> void runT(Runnable runnable) { runnable.run(); }
> }
> ```
> 
> (I've removed a call to `Integer::valueOf` that was not necessary to reproduce the issue -- but was adding some extra noise).
> 
> Note that here the calls to `supplyNull` and `runT` are completely independent. That's because the call to `supplyNull` occurs in a void-compatible lambda (the target of the lambda is `Runnable`). As such, it is not possible for inference of the nested call to `supplyNull` to have any effect on the inference of the `runT` call.
> 
> However, when debugging, I see that when we call `checkMethod` for `supplyNull`, we attempt to propagate its inference context outwards. This is done even though the `resultInfo` says that the expected type is `void` (where `void` is the return type of the function descriptor).
> 
> In other words, it seems to me that `Infer::shouldPropagate` is buggy: it returns true if all the conditions below are satisfied:
> 
>     * the enclosing method is a generic method
> 
>     * the return type of the current method contains some inference vars
> 
>     * no eager resolution is required
> 
> 
> But we never check what the target-type of the current method actually is. Normally, the target will be some non-void type -- so when we propagate, we will need to check compatibility again, which will fix up all the types. But in this case (which is a corner case due to void-compatible lambdas), the target happens to be `void` -- meaning inference will never be "completed".
> 
> See the implementation of `Attr.ExpressionLambdaReturnContext::compatible`:
> 
> ```
>            @Override
>             public boolean compatible(Type found, Type req, Warner warn) {
>                 //a void return is compatible with an expression statement lambda
>                 if (req.hasTag(VOID)) {
>                     expStmtExpected = true;
>                     return TreeInfo.isExpressionStatement(expr);
>                 } else {
>                     return super.compatible(found, req, warn);
>                 }
>             }
> ```
> 
> In other words, if the expected type is `void` (as in this case), `super.compatible` will not be called -- which means the deferred type for the nested generic method call will remain uninferred.
> 
> Adding an extra check to `Infer::shouldPropagate` to _not_ propagate when the target happens to be `void` seems to fix the issue in JBS. (but, I have not ran any other test).

good catch, yes this is a bug in `Infer::shouldPropagate` and one we should fix for sure, but I think that the fundamental problem is still there and will show its head again as soon as, for example, the lambda is not void-compatible

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884160827

From mcimadamore at openjdk.org  Thu May 15 15:19:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 15:19:54 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <hsDX9-No4Bq345HcPsjBBpsyV5IfosijeEPqgplx6xU=.d682fd91-59c3-472d-8b10-8789fb385cd7@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@github.com>
 <hsDX9-No4Bq345HcPsjBBpsyV5IfosijeEPqgplx6xU=.d682fd91-59c3-472d-8b10-8789fb385cd7@github.com>
Message-ID: <Wu4y7u2jFwQzPx6Z7SudqOFp2HNesZ2Zz-xnTgTrY-g=.93fb006b-7508-4960-9448-700b939e134a@github.com>

On Thu, 15 May 2025 15:02:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> good catch, yes this is a bug in `Infer::shouldPropagate` and one we should fix for sure, but I think that the fundamental problem is still there and will show its head again as soon as, for example, the lambda is not void-compatible

If the target type is non-void, then it will be checked by the `compatible` method I shown above. This is a deferred type check which will cause the inference context to be inferred in full. The problem of this issue is that the final inference step is never executed -- because the target type is `void`.

If you can find a case w/o `void` that exhibits the same issue, we can certainly look into that more.

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884210676

From mcimadamore at openjdk.org  Thu May 15 15:28:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 15:28:53 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <Wu4y7u2jFwQzPx6Z7SudqOFp2HNesZ2Zz-xnTgTrY-g=.93fb006b-7508-4960-9448-700b939e134a@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@github.com>
 <hsDX9-No4Bq345HcPsjBBpsyV5IfosijeEPqgplx6xU=.d682fd91-59c3-472d-8b10-8789fb385cd7@github.com>
 <Wu4y7u2jFwQzPx6Z7SudqOFp2HNesZ2Zz-xnTgTrY-g=.93fb006b-7508-4960-9448-700b939e134a@github.com>
Message-ID: <WxVbwWYnfJYBn1qM5UeECi4zUb_vyChAF3GduQ3kyzM=.a541fba0-932a-415a-ad73-56665fde2041@github.com>

On Thu, 15 May 2025 15:17:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> If you can find a case w/o `void` that exhibits the same issue, we can certainly look into that more.

Uhmmm. This:


static class Generic {

        public static void main(String... args) {
            Integer i = null;
            runT(() -> supplyNull(i));
        }

        static <R, X> R supplyNull(X... varargs) {
            System.out.println(varargs.getClass().getComponentType());
            return null;
        }

        static <T> void runT(Supplier<T> runnable) { runnable.get(); }
    }


Seems to exhibit same incorrect behavior. Inference goes a bit further (I see R being replaced, but not X).

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884233369

From vromero at openjdk.org  Thu May 15 15:28:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 15:28:54 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <Wu4y7u2jFwQzPx6Z7SudqOFp2HNesZ2Zz-xnTgTrY-g=.93fb006b-7508-4960-9448-700b939e134a@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@github.com>
 <hsDX9-No4Bq345HcPsjBBpsyV5IfosijeEPqgplx6xU=.d682fd91-59c3-472d-8b10-8789fb385cd7@github.com>
 <Wu4y7u2jFwQzPx6Z7SudqOFp2HNesZ2Zz-xnTgTrY-g=.93fb006b-7508-4960-9448-700b939e134a@github.com>
Message-ID: <CbXZxW4-alqtWOn-mNYQAyLKi1BvJud-_QWpvPWOFSc=.a8af467d-d319-439f-beed-1f12d09420a7@github.com>

On Thu, 15 May 2025 15:17:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > good catch, yes this is a bug in `Infer::shouldPropagate` and one we should fix for sure, but I think that the fundamental problem is still there and will show its head again as soon as, for example, the lambda is not void-compatible
> 
> If the target type is non-void, then it will be checked by the `compatible` method I shown above. This is a deferred type check which will cause the inference context to be inferred in full. The problem of this issue is that the final inference step is never executed -- because the target type is `void`.
> 
> If you can find a case w/o `void` that exhibits the same issue, we can certainly look into that more.

I'm seeing the same issue as the one reported with this test case:


import java.util.function.*;

class Generic {

    public static void main(String... args) {
        runT(() -> supplyNull(Integer.valueOf(1)));
    }

    static <R, X> R supplyNull(X... varargs) {
        System.out.println(varargs.getClass().getComponentType());
        return null;
    }

    static <T> void runT(Supplier<T> supp) { supp.get(); }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884239036

From vromero at openjdk.org  Thu May 15 15:42:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 15:42:55 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <WxVbwWYnfJYBn1qM5UeECi4zUb_vyChAF3GduQ3kyzM=.a541fba0-932a-415a-ad73-56665fde2041@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@github.com>
 <hsDX9-No4Bq345HcPsjBBpsyV5IfosijeEPqgplx6xU=.d682fd91-59c3-472d-8b10-8789fb385cd7@github.com>
 <Wu4y7u2jFwQzPx6Z7SudqOFp2HNesZ2Zz-xnTgTrY-g=.93fb006b-7508-4960-9448-700b939e134a@github.com>
 <WxVbwWYnfJYBn1qM5UeECi4zUb_vyChAF3GduQ3kyzM=.a541fba0-932a-415a-ad73-56665fde2041@github.com>
Message-ID: <7_ihh5zu006Fa4imMxPXkQdyJuBKMfS_96vUzKzfFN8=.0793583a-799c-4c00-9679-88f1bf87cc3d@github.com>

On Thu, 15 May 2025 15:24:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > If you can find a case w/o `void` that exhibits the same issue, we can certainly look into that more.
> 
> Uhmmm. This:
> 
> ```
> static class Generic {
> 
>         public static void main(String... args) {
>             Integer i = null;
>             runT(() -> supplyNull(i));
>         }
> 
>         static <R, X> R supplyNull(X... varargs) {
>             System.out.println(varargs.getClass().getComponentType());
>             return null;
>         }
> 
>         static <T> void runT(Supplier<T> runnable) { runnable.get(); }
>     }
> ```
> 
> Seems to exhibit same incorrect behavior. Inference goes a bit further (I see R being replaced, but not X).

right I was writing a very similar example, and X is not replaced because the minimized inference context doesn't know about X

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884281998

From mcimadamore at openjdk.org  Thu May 15 15:58:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 15:58:00 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <7_ihh5zu006Fa4imMxPXkQdyJuBKMfS_96vUzKzfFN8=.0793583a-799c-4c00-9679-88f1bf87cc3d@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <rIro2BwmBW5kFjE0FjwDkGF_yYYVvja0cs_HZJ0EAeY=.bd29198b-ff53-4b9a-af7c-9332684e5a88@github.com>
 <hsDX9-No4Bq345HcPsjBBpsyV5IfosijeEPqgplx6xU=.d682fd91-59c3-472d-8b10-8789fb385cd7@github.com>
 <Wu4y7u2jFwQzPx6Z7SudqOFp2HNesZ2Zz-xnTgTrY-g=.93fb006b-7508-4960-9448-700b939e134a@github.com>
 <WxVbwWYnfJYBn1qM5UeECi4zUb_vyChAF3GduQ3kyzM=.a541fba0-932a-415a-ad73-56665fde2041@github.com>
 <7_ihh5zu006Fa4imMxPXkQdyJuBKMfS_96vUzKzfFN8=.0793583a-799c-4c00-9679-88f1bf87cc3d@github.com>
Message-ID: <oaaJtZyQP2WO9kBi4DgXdcPddWZ9aOzED2Ji4dqsnM4=.9b15ab3a-75c6-437c-8519-aabe45c628fd@github.com>

On Thu, 15 May 2025 15:39:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> right I was writing a very similar example, and X is not replaced because the minimized inference context doesn't know about X

That is true -- however, when we create the minimized context, we set a listener from the minimized context to the original context, so that whenever *any* propagated variable is solved, we also solve the "independent" variables. This listener works -- the problem is that the replacement in the inferred method signature never occurs. So I'd like to spend some more time understanding exactly why this happens.

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884324095

From mcimadamore at openjdk.org  Thu May 15 15:58:05 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 15:58:05 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: <E2iUZIHjoUL9plY-4S8t9rwyvF0bHaHgTPzh3twaDSI=.4668733f-5d9a-4084-a990-b23c0119c037@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

> > right I was writing a very similar example, and X is not replaced because the minimized inference context doesn't know about X
> 
> That is true -- however, when we create the minimized context, we set a listener from the minimized context to the original context, so that whenever _any_ propagated variable is solved, we also solve the "independent" variables. This listener works -- the problem is that the replacement in the inferred method signature never occurs. So I'd like to spend some more time understanding exactly why this happens.

It also seems to me that this problem has been there for a long time -- possibly since the introduction of `InferenceContext::min` -- we do all the correct checks, but some of the types are left "uninferred" in the AST. Which then shows up whenever the translation strategy relies on the type being inferred (such as here -- as we need the inferred type to know which vararg array to create).

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884328829

From mcimadamore at openjdk.org  Thu May 15 16:00:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 16:00:01 GMT
Subject: RFR: 8349754: Invalid "early reference" error when class extends
 an outer class [v3]
In-Reply-To: <KxyZDzFxUKabuWfPUkeFyRRYRSODsaNuMM-nEkJ5MkM=.0dda6862-ea00-48fb-9463-e96a0c1d6fe2@github.com>
References: <cghFkzkY0v-zPbQJLdzYEK9fJtEW8Kp0AY6ehR4I2og=.464c4b4f-872e-466b-80bb-261214ffb31f@github.com>
 <KxyZDzFxUKabuWfPUkeFyRRYRSODsaNuMM-nEkJ5MkM=.0dda6862-ea00-48fb-9463-e96a0c1d6fe2@github.com>
Message-ID: <UPxcKPTl7XQbw1kqeqHdFFsSjx6SrfXydy-c4tybat8=.c77d2e22-61ab-4c80-922e-4cde81f041a1@github.com>

On Tue, 13 May 2025 16:04:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler is generating a bogus error for this input:
>> 
>> $ cat Outer.java
>> class Outer {
>>     private int i;
>>     class Sub extends Outer {
>>         Sub() {
>>             i = 42;
>>             super();
>>         }
>>     }
>> }
>> $ javac --enable-preview --source 24 Outer.java
>> Outer.java:5: error: cannot reference i before supertype constructor has been called
>>             i = 42;
>>             ^
>> Note: Outer.java uses preview features of Java SE 24.
>> Note: Recompile with -Xlint:preview for details.
>> 1 error 
>> 
>> 
>> The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8349754 to fix conflict.
>  - Simplify logic using Symbol.isMemberOf() per review suggestion.
>  - Fix incorrect "early reference" error.

The changes (still) look good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23545#pullrequestreview-2844267001

From acobbs at openjdk.org  Thu May 15 16:38:05 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 16:38:05 GMT
Subject: RFR: 8349754: Invalid "early reference" error when class extends
 an outer class [v3]
In-Reply-To: <KxyZDzFxUKabuWfPUkeFyRRYRSODsaNuMM-nEkJ5MkM=.0dda6862-ea00-48fb-9463-e96a0c1d6fe2@github.com>
References: <cghFkzkY0v-zPbQJLdzYEK9fJtEW8Kp0AY6ehR4I2og=.464c4b4f-872e-466b-80bb-261214ffb31f@github.com>
 <KxyZDzFxUKabuWfPUkeFyRRYRSODsaNuMM-nEkJ5MkM=.0dda6862-ea00-48fb-9463-e96a0c1d6fe2@github.com>
Message-ID: <VxIGWb8oRRhZ-itIV_AMtgNSfvlkxZi3dfBFco9FQfY=.f5c04f52-dc58-4a08-b5a2-e2811f19a663@github.com>

On Tue, 13 May 2025 16:04:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The compiler is generating a bogus error for this input:
>> 
>> $ cat Outer.java
>> class Outer {
>>     private int i;
>>     class Sub extends Outer {
>>         Sub() {
>>             i = 42;
>>             super();
>>         }
>>     }
>> }
>> $ javac --enable-preview --source 24 Outer.java
>> Outer.java:5: error: cannot reference i before supertype constructor has been called
>>             i = 42;
>>             ^
>> Note: Outer.java uses preview features of Java SE 24.
>> Note: Recompile with -Xlint:preview for details.
>> 1 error 
>> 
>> 
>> The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8349754 to fix conflict.
>  - Simplify logic using Symbol.isMemberOf() per review suggestion.
>  - Fix incorrect "early reference" error.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23545#issuecomment-2884431411

From acobbs at openjdk.org  Thu May 15 16:38:06 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 15 May 2025 16:38:06 GMT
Subject: Integrated: 8349754: Invalid "early reference" error when class
 extends an outer class
In-Reply-To: <cghFkzkY0v-zPbQJLdzYEK9fJtEW8Kp0AY6ehR4I2og=.464c4b4f-872e-466b-80bb-261214ffb31f@github.com>
References: <cghFkzkY0v-zPbQJLdzYEK9fJtEW8Kp0AY6ehR4I2og=.464c4b4f-872e-466b-80bb-261214ffb31f@github.com>
Message-ID: <4ZTBBNeLqet06NsPZC0WajDbjGmqxx4-OZsW2LbxNPU=.b6415fa5-c07b-4b90-b267-49d88a80c094@github.com>

On Mon, 10 Feb 2025 20:51:34 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler is generating a bogus error for this input:
> 
> $ cat Outer.java
> class Outer {
>     private int i;
>     class Sub extends Outer {
>         Sub() {
>             i = 42;
>             super();
>         }
>     }
> }
> $ javac --enable-preview --source 24 Outer.java
> Outer.java:5: error: cannot reference i before supertype constructor has been called
>             i = 42;
>             ^
> Note: Outer.java uses preview features of Java SE 24.
> Note: Recompile with -Xlint:preview for details.
> 1 error 
> 
> 
> The trick here is that the expression `i` refers to `Outer.this.i`, not `this.i`, but the error checking logic is mistakenly assuming the latter. This patch adds an exception for this case, which happens when the field is `private` and declared in a class which is both a superclass and an outer class.

This pull request has now been integrated.

Changeset: 850c789a
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/850c789a827e21cda3096276d9638f56fae76c3e
Stats:     26 lines in 2 files changed: 20 ins; 0 del; 6 mod

8349754: Invalid "early reference" error when class extends an outer class

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.org  Thu May 15 16:39:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 16:39:57 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: <flFo0LaYN9e5KrpNYiK3FaxRRJoBYK_EydSguGgTcao=.2d841a25-cc58-4322-8dfd-482c335533ca@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

I think I see the problem now. I believe the issue is in `Check::checkMethod`. That method does this at the start:


if (inferenceContext.free(mtype)) {
            inferenceContext.addFreeTypeListener(List.of(mtype),
                    solvedContext -> checkMethod(solvedContext.asInstType(mtype), sym, env, argtrees, argtypes, useVarargs, solvedContext));
            return mtype;
        }


This is correct -- if `mtype` has some free type variable, we need to come back later and re-run this again (to set the correct type on the AST).

But there's an issue -- if we propagate (`Infer::shouldPropagate` is `true`), then the input inference context is NOT the inference context for the call being checked (in this case `supplyNull`) but the outer context, which contains the propagated vars.

While this was correct before the introduction of context minimization -- because in such case outer inference contexts were always strict supersets of nested inference contexts "contained", this is no longer true with minimization: we can have an outer context that omits some variables from the nested context. At which point, the listener above will "miss the memo" -- e.g. it will instantiate the method type using the outer context inferred vars -- but this will still leave "holes" (because the outer context will not contain all the variables that can appear in `mtype`).

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884441846

From jlahoda at openjdk.org  Thu May 15 16:48:35 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 May 2025 16:48:35 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
Message-ID: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>

A consider class like this:


public class TwoMains {
    private static void main(String... args) {}
    static void main() {
        System.out.println("Should be called, but is not.");
    }
}


The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.

Something similar happens if the return type is not `void`.

This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.

It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

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

Commit messages:
 - 8357016: Candidate main methods not computed properly

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

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

From mcimadamore at openjdk.org  Thu May 15 16:48:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 16:48:59 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: <Q2w-WY0oApHx1Mref3RdNK0EzPKkF8jNGjnJ_Tla6Uc=.f546c832-eff9-4d0e-904f-8465b7be99d6@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

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

> 101:      * needs to deal with an inference variable that has been eliminated from IC_IV while minimizing it
> 102:      */
> 103:     InferenceContext supplementaryIC;

Let's call this `next`, or `parent` ?

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

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

From mcimadamore at openjdk.org  Thu May 15 16:49:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 16:49:00 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <iwHSG3I91WwX0QG4JhihK-cCjztRYY9JXsv660gVRwA=.297471bf-b231-4e13-a931-13dcc089dc22@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <iwHSG3I91WwX0QG4JhihK-cCjztRYY9JXsv660gVRwA=.297471bf-b231-4e13-a931-13dcc089dc22@github.com>
Message-ID: <jQU6qEDUUIWMNbdeqVu8KWZOfZKS7z5AhXe_7efm1Qk=.2e475f08-cd53-4c12-9b2a-8a280b0273ce@github.com>

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

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

Maybe we can replace the visitor with asking `supplimentaryIC.free(t)` ? e.g. this could maybe use recusion?


Type result = t;
if (current.free(t)) {
    result = types.subst(t, inferencevars, instTypes());
}
if (supplimentaryIC != null) {
    return supplimentaryIC.asInstTypes(t);
 }
 ```

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

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

From cstein at openjdk.org  Thu May 15 16:54:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 15 May 2025 16:54:34 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v14]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <iCWtjgHJs86_GnpRMKulfBHA4TEePZ6TkOrsanUsCAw=.fb1b06a5-b29e-40a7-81f5-b5b36aae8a5e@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:

  Revert change after JDK-8356678 being addressed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/95d1067d..be6cb82b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=12-13

  Stats: 3 lines in 1 file changed: 0 ins; 3 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 vromero at openjdk.org  Thu May 15 16:54:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 16:54:57 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <Q2w-WY0oApHx1Mref3RdNK0EzPKkF8jNGjnJ_Tla6Uc=.f546c832-eff9-4d0e-904f-8465b7be99d6@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <Q2w-WY0oApHx1Mref3RdNK0EzPKkF8jNGjnJ_Tla6Uc=.f546c832-eff9-4d0e-904f-8465b7be99d6@github.com>
Message-ID: <6eoWCxjF0D02mNLS7BKR0JLyjbouE_bFZdYThlQ8Oiw=.894a2a32-0646-4523-8aab-c6fa206bbf50@github.com>

On Thu, 15 May 2025 16:45:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 103:
> 
>> 101:      * needs to deal with an inference variable that has been eliminated from IC_IV while minimizing it
>> 102:      */
>> 103:     InferenceContext supplementaryIC;
> 
> Let's call this `next`, or `parent` ?

I think it is more a `child` context than a `parent` one, `nested`?

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

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

From abimpoudis at openjdk.org  Thu May 15 16:58:29 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 15 May 2025 16:58:29 GMT
Subject: RFR: 8347530: Improve error message with invalid permits clauses
Message-ID: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>

Currently we report one kind of error message (`subclass {0} must extend sealed class`) when there is a compile-type error in cases like the following:


sealed class C0 permits S0 {}
class S0 {}  


This PR proposes to improve error reporting since there are other kinds of declarations that can also participate in sealed hierarchies like records, enums and interfaces.

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

Commit messages:
 - 8347530: Improve error message with invalid permits clauses

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

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

From vromero at openjdk.org  Thu May 15 17:17:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 17:17:54 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <jQU6qEDUUIWMNbdeqVu8KWZOfZKS7z5AhXe_7efm1Qk=.2e475f08-cd53-4c12-9b2a-8a280b0273ce@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <iwHSG3I91WwX0QG4JhihK-cCjztRYY9JXsv660gVRwA=.297471bf-b231-4e13-a931-13dcc089dc22@github.com>
 <jQU6qEDUUIWMNbdeqVu8KWZOfZKS7z5AhXe_7efm1Qk=.2e475f08-cd53-4c12-9b2a-8a280b0273ce@github.com>
Message-ID: <920-fgnbjXHDzGRFISciQ8Zvu7f_Uuf3T83_lYNyC8E=.16e81110-2f23-4f9f-8ebf-83a80828e77b@github.com>

On Thu, 15 May 2025 16:44:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Maybe we can replace the visitor with asking `supplimentaryIC.free(t)` ? e.g. this could maybe use recusion?
> 
> ```
> Type result = t;
> if (current.free(t)) {
>     result = types.subst(t, inferencevars, instTypes());
> }
> if (supplimentaryIC != null) {
>     return supplimentaryIC.asInstTypes(t);
>  }
> ```

right but won't this solution imply to recursively visit the whole chain of supplementaryICs? the current approach should stop as soon as there are no more supplementaryICs to visit. Actually I think that one of our performance tests failed and that was why I had to introduce this visitor if I recall correctly

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

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

From vromero at openjdk.org  Thu May 15 17:31:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 17:31:02 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <flFo0LaYN9e5KrpNYiK3FaxRRJoBYK_EydSguGgTcao=.2d841a25-cc58-4322-8dfd-482c335533ca@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <flFo0LaYN9e5KrpNYiK3FaxRRJoBYK_EydSguGgTcao=.2d841a25-cc58-4322-8dfd-482c335533ca@github.com>
Message-ID: <Edd5QtujpvZIzxenSQyxhLBlQRt87IpZf7Tmopzj-jw=.16a362f2-fdc4-4ee1-a31b-93c1946f7761@github.com>

On Thu, 15 May 2025 16:37:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I think I see the problem now. I believe the issue is in `Check::checkMethod`. That method does this at the start:
> 
> ```
> if (inferenceContext.free(mtype)) {
>             inferenceContext.addFreeTypeListener(List.of(mtype),
>                     solvedContext -> checkMethod(solvedContext.asInstType(mtype), sym, env, argtrees, argtypes, useVarargs, solvedContext));
>             return mtype;
>         }
> ```
> 
> This is correct -- if `mtype` has some free type variable, we need to come back later and re-run this again (to set the correct type on the AST).
> 
> But there's an issue -- if we propagate (`Infer::shouldPropagate` is `true`), then the input inference context is NOT the inference context for the call being checked (in this case `supplyNull`) but the outer context, which contains the propagated vars.
> 
> While this was correct before the introduction of context minimization -- because in such case outer inference contexts were always strict supersets of nested inference contexts "contained", this is no longer true with minimization: we can have an outer context that omits some variables from the nested context. At which point, the listener above will "miss the memo" -- e.g. it will instantiate the method type using the outer context inferred vars -- but this will still leave "holes" (because the outer context will not contain all the variables that can appear in `mtype`).

correct, these were my findings too, and if we try to make the minimized context more `chubby` then for a lot of cases we will probably kill the whole point of doing the minimization at all. So the supplementary context was the solution I found to keep the whole minimization algo going while doing some bookkeeping in case it could be needed by an outer inference context

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884566605

From mcimadamore at openjdk.org  Thu May 15 17:50:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 17:50:54 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <6eoWCxjF0D02mNLS7BKR0JLyjbouE_bFZdYThlQ8Oiw=.894a2a32-0646-4523-8aab-c6fa206bbf50@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <Q2w-WY0oApHx1Mref3RdNK0EzPKkF8jNGjnJ_Tla6Uc=.f546c832-eff9-4d0e-904f-8465b7be99d6@github.com>
 <6eoWCxjF0D02mNLS7BKR0JLyjbouE_bFZdYThlQ8Oiw=.894a2a32-0646-4523-8aab-c6fa206bbf50@github.com>
Message-ID: <AVjGjTeIbvf0LdvNXM7hP6lEwZPR-3VkzQc8lZZmH9U=.6bfdf8bd-091b-4603-ab61-5e1fe2b4a984@github.com>

On Thu, 15 May 2025 16:51:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 103:
>> 
>>> 101:      * needs to deal with an inference variable that has been eliminated from IC_IV while minimizing it
>>> 102:      */
>>> 103:     InferenceContext supplementaryIC;
>> 
>> Let's call this `next`, or `parent` ?
>
> I think it is more a `child` context than a `parent` one, `nested`?

I said parent because it seems the supplimentary IC is the inner context. And we copy the inner context to the outer. So, in a way, some variables in the outer context come from the parent.

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

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

From mcimadamore at openjdk.org  Thu May 15 17:58:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 17:58:51 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <920-fgnbjXHDzGRFISciQ8Zvu7f_Uuf3T83_lYNyC8E=.16e81110-2f23-4f9f-8ebf-83a80828e77b@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <iwHSG3I91WwX0QG4JhihK-cCjztRYY9JXsv660gVRwA=.297471bf-b231-4e13-a931-13dcc089dc22@github.com>
 <jQU6qEDUUIWMNbdeqVu8KWZOfZKS7z5AhXe_7efm1Qk=.2e475f08-cd53-4c12-9b2a-8a280b0273ce@github.com>
 <920-fgnbjXHDzGRFISciQ8Zvu7f_Uuf3T83_lYNyC8E=.16e81110-2f23-4f9f-8ebf-83a80828e77b@github.com>
Message-ID: <nDHkDZVf7IUoOwm5jXkiPJWaotHSDG5m188Ab-TNa2k=.924d2957-12f6-4454-990a-ee9c5aec0c86@github.com>

On Thu, 15 May 2025 17:15:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Actually I think that one of our performance tests failed and that was why I had to introduce this visitor if I recall correctly

I wanted to ask about this -- e.g. how much fixing this undoes the benefit of minimization. It seems we're in tricky territory.

Now, the problem with the visitor is that it picks up any type-variables -- it should at least filter out class type-variables and focus on method type-variables.

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

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

From vromero at openjdk.org  Thu May 15 18:02:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 18:02:51 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <AVjGjTeIbvf0LdvNXM7hP6lEwZPR-3VkzQc8lZZmH9U=.6bfdf8bd-091b-4603-ab61-5e1fe2b4a984@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <Q2w-WY0oApHx1Mref3RdNK0EzPKkF8jNGjnJ_Tla6Uc=.f546c832-eff9-4d0e-904f-8465b7be99d6@github.com>
 <6eoWCxjF0D02mNLS7BKR0JLyjbouE_bFZdYThlQ8Oiw=.894a2a32-0646-4523-8aab-c6fa206bbf50@github.com>
 <AVjGjTeIbvf0LdvNXM7hP6lEwZPR-3VkzQc8lZZmH9U=.6bfdf8bd-091b-4603-ab61-5e1fe2b4a984@github.com>
Message-ID: <c2a09bVQuoo8rFH4XZbJNjVPdZevlp25XpRh2p3bD14=.ff7b41b1-617c-4b7e-a92e-4c87f7fd56be@github.com>

On Thu, 15 May 2025 17:48:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I think it is more a `child` context than a `parent` one, `nested`?
>
> I said parent because it seems the supplimentary IC is the inner context. And we copy the inner context to the outer. So, in a way, some variables in the outer context come from the parent.

I see, yes makes sense

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

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

From mcimadamore at openjdk.org  Thu May 15 18:02:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 18:02:52 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <nDHkDZVf7IUoOwm5jXkiPJWaotHSDG5m188Ab-TNa2k=.924d2957-12f6-4454-990a-ee9c5aec0c86@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <iwHSG3I91WwX0QG4JhihK-cCjztRYY9JXsv660gVRwA=.297471bf-b231-4e13-a931-13dcc089dc22@github.com>
 <jQU6qEDUUIWMNbdeqVu8KWZOfZKS7z5AhXe_7efm1Qk=.2e475f08-cd53-4c12-9b2a-8a280b0273ce@github.com>
 <920-fgnbjXHDzGRFISciQ8Zvu7f_Uuf3T83_lYNyC8E=.16e81110-2f23-4f9f-8ebf-83a80828e77b@github.com>
 <nDHkDZVf7IUoOwm5jXkiPJWaotHSDG5m188Ab-TNa2k=.924d2957-12f6-4454-990a-ee9c5aec0c86@github.com>
Message-ID: <p5UJCFLxP75OnQlEVtB1TAtb3_jdwMqUye3T1TdtnOA=.6379507c-e974-4e55-b9bf-1158912d7b2a@github.com>

On Thu, 15 May 2025 17:56:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Maybe we can replace the visitor with asking `supplimentaryIC.free(t)` ? e.g. this could maybe use recusion?
>>> 
>>> ```
>>> Type result = t;
>>> if (current.free(t)) {
>>>     result = types.subst(t, inferencevars, instTypes());
>>> }
>>> if (supplimentaryIC != null) {
>>>     return supplimentaryIC.asInstTypes(t);
>>>  }
>>> ```
>> 
>> right but won't this solution imply to recursively visit the whole chain of supplementaryICs? the current approach should stop as soon as there are no more supplementaryICs to visit. Actually I think that one of our performance tests failed and that was why I had to introduce this visitor if I recall correctly
>
>> Actually I think that one of our performance tests failed and that was why I had to introduce this visitor if I recall correctly
> 
> I wanted to ask about this -- e.g. how much fixing this undoes the benefit of minimization. It seems we're in tricky territory.
> 
> Now, the problem with the visitor is that it picks up any type-variables -- it should at least filter out class type-variables and focus on method type-variables.

How feasible would it be to collect all the variables from all the supplimentary contexts, and then to only one subst? I assume the cost is with `types.subst` which is a visitor?

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

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

From mcimadamore at openjdk.org  Thu May 15 18:08:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 May 2025 18:08:51 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <Edd5QtujpvZIzxenSQyxhLBlQRt87IpZf7Tmopzj-jw=.16a362f2-fdc4-4ee1-a31b-93c1946f7761@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <flFo0LaYN9e5KrpNYiK3FaxRRJoBYK_EydSguGgTcao=.2d841a25-cc58-4322-8dfd-482c335533ca@github.com>
 <Edd5QtujpvZIzxenSQyxhLBlQRt87IpZf7Tmopzj-jw=.16a362f2-fdc4-4ee1-a31b-93c1946f7761@github.com>
Message-ID: <35r_CIurK4BrrRKdZvau3m2HK5EecwYrxfOBED4bieI=.6fb3cc51-c391-494b-8382-5f69d2ebe30f@github.com>

On Thu, 15 May 2025 17:28:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Another option, but I think it will be more complex, could be for the minimization algo to don't physically reduce the size of a given inference context but to make some variables "inactive" so that they won't participate in the propagation and resolution algos but they can be queried if needed

Yes, that would be another way to do it -- e.g. keep the outer inference context a strict superset of the nested one -- but make incorporation only touch few bits.

Which... leads me to a possible "interim" solution: when we create the min context, we know which variables are NOT going to be propagated out. Is there a way we can somehow save these variables on the outer context -- in  separate lists? If we could do that, then `asInstTypes` only needs a small tweak to use the non-minimized variable list instead of the minimized one.

In a way we can decide whether to save a pointer to the original context, or whether to store all the actual vars (but in a separate place, so it won't be used by the other inference machinery). Maybe we should try both approaches and see which one leads to simpler code?

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884664415

From naoto at openjdk.org  Thu May 15 18:32:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 18:32:53 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

test/jdk/sun/text/resources/LocaleDataTest.java line 106:

> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
> 106:  *        LocaleNames/fr_FR/US=?tats-Unis

This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029

From henryjen at openjdk.org  Thu May 15 18:37:08 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 18:37:08 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v7]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <TkWSwAgnlTdNgnVJ7YlPdbepHsy-LP71I1LgS14Zm4E=.fd310021-74d0-4c57-99c9-1c13f6c8f38d@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:

  Move all validation into EntryValidator, update the document

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

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

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

  Stats: 212 lines in 4 files changed: 105 ins; 22 del; 85 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 vromero at openjdk.org  Thu May 15 18:49:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 18:49:52 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <35r_CIurK4BrrRKdZvau3m2HK5EecwYrxfOBED4bieI=.6fb3cc51-c391-494b-8382-5f69d2ebe30f@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <pduy0292xyYEi2o9j0Nogv6FYsgI72Q8ainqG9fuSpI=.5bd7d395-e914-486b-8e0e-185bb7dd850f@github.com>
 <flFo0LaYN9e5KrpNYiK3FaxRRJoBYK_EydSguGgTcao=.2d841a25-cc58-4322-8dfd-482c335533ca@github.com>
 <Edd5QtujpvZIzxenSQyxhLBlQRt87IpZf7Tmopzj-jw=.16a362f2-fdc4-4ee1-a31b-93c1946f7761@github.com>
 <35r_CIurK4BrrRKdZvau3m2HK5EecwYrxfOBED4bieI=.6fb3cc51-c391-494b-8382-5f69d2ebe30f@github.com>
Message-ID: <3wVnTyIoCVobO-ZGfAvRocWA_vQngnn5H94H8fwmIsc=.bae90677-f96c-4a0e-b317-a48763cf639b@github.com>

On Thu, 15 May 2025 18:06:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Another option, but I think it will be more complex, could be for the minimization algo to don't physically reduce the size of a given inference context but to make some variables "inactive" so that they won't participate in the propagation and resolution algos but they can be queried if needed
> 
> Yes, that would be another way to do it -- e.g. keep the outer inference context a strict superset of the nested one -- but make incorporation only touch few bits.
> 
> Which... leads me to a possible "interim" solution: when we create the min context, we know which variables are NOT going to be propagated out. Is there a way we can somehow save these variables on the outer context -- in separate lists? If we could do that, then `asInstTypes` only needs a small tweak to use the non-minimized variable list instead of the minimized one.
> 
> In a way we can decide whether to save a pointer to the original context, or whether to store all the actual vars (but in a separate place, so it won't be used by the other inference machinery). Maybe we should try both approaches and see which one leads to simpler code?

yes this is exactly the way I thought we could approach this other alternative, using different lists for the variables we don't want to participate in the outer context resolution and propagation steps

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2884763061

From vromero at openjdk.org  Thu May 15 18:49:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 18:49:53 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v3]
In-Reply-To: <p5UJCFLxP75OnQlEVtB1TAtb3_jdwMqUye3T1TdtnOA=.6379507c-e974-4e55-b9bf-1158912d7b2a@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <iwHSG3I91WwX0QG4JhihK-cCjztRYY9JXsv660gVRwA=.297471bf-b231-4e13-a931-13dcc089dc22@github.com>
 <jQU6qEDUUIWMNbdeqVu8KWZOfZKS7z5AhXe_7efm1Qk=.2e475f08-cd53-4c12-9b2a-8a280b0273ce@github.com>
 <920-fgnbjXHDzGRFISciQ8Zvu7f_Uuf3T83_lYNyC8E=.16e81110-2f23-4f9f-8ebf-83a80828e77b@github.com>
 <nDHkDZVf7IUoOwm5jXkiPJWaotHSDG5m188Ab-TNa2k=.924d2957-12f6-4454-990a-ee9c5aec0c86@github.com>
 <p5UJCFLxP75OnQlEVtB1TAtb3_jdwMqUye3T1TdtnOA=.6379507c-e974-4e55-b9bf-1158912d7b2a@github.com>
Message-ID: <MIg04ybLkiChhg_Kn48qCJK6rNT-EvWkAjfnx21mAXI=.ba98f889-aaf8-4c70-a398-6e2c36e84259@github.com>

On Thu, 15 May 2025 17:59:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Actually I think that one of our performance tests failed and that was why I had to introduce this visitor if I recall correctly
>> 
>> I wanted to ask about this -- e.g. how much fixing this undoes the benefit of minimization. It seems we're in tricky territory.
>> 
>> Now, the problem with the visitor is that it picks up any type-variables -- it should at least filter out class type-variables and focus on method type-variables.
>
> How feasible would it be to collect all the variables from all the supplimentary contexts, and then to only one subst? I assume the cost is with `types.subst` which is a visitor?

> > Actually I think that one of our performance tests failed and that was why I had to introduce this visitor if I recall correctly
> 
> I wanted to ask about this -- e.g. how much fixing this undoes the benefit of minimization. It seems we're in tricky territory.
> 
> Now, the problem with the visitor is that it picks up any type-variables -- it should at least filter out class type-variables and focus on method type-variables.

the difference in performance is negligible

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

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

From vromero at openjdk.org  Thu May 15 19:07:37 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 19:07:37 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v14]
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: <H5OXqp27HjDZFSKaU6jlJkyXyQnW8dhIEz0p7OK4ok8=.f9ee1992-29d7-47a4-be14-41f35c840d1d@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:

  update warning message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/22acaf29..bdbcd332

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

  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 vromero at openjdk.org  Thu May 15 19:32:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 19:32:59 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
 <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
Message-ID: <2oFLdya1PI3WV3lloInRQG1oHs3k2gNhmZjv-V-OLrg=.8e5773fa-4993-4ef1-9e78-7899fa86fd4c@github.com>

On Wed, 14 May 2025 18:23:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2673:
> 
>> 2671:             result = check(tree, capturedRes, KindSelector.VAL, resultInfo);
>> 2672:         }
>> 2673:         if (env.info.lint.isEnabled(LintCategory.IDENTITY)) {
> 
> This is the only place where there's a check whether the lint is enabled before the call to `checkRequiresIdentity`. Is there a reason for that?

left over of the initial approach I guess. I will remove it

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

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

From vromero at openjdk.org  Thu May 15 19:48:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 19:48:55 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
 <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
Message-ID: <rrqDosHsQmnGjNyIRZ9_outXOjA5w1HmytH-BsXiXNc=.4f3b990b-b100-4145-a414-6d48e3d815e9@github.com>

On Wed, 14 May 2025 18:25:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5671:
> 
>> 5669:     }
>> 5670: 
>> 5671:     void checkRequiresIdentity(JCTree tree, Lint lint) {
> 
> For consideration: as far as I can see, we have a sharp(er) type when we call `checkRequiresIdentity`, but we give up the type, and re-instante it here using the pattern matching switch. I wonder if it would be more elegant (and hopefully not really too much longer) if the `checkRequiresIdentity` method would have multiple overloads, with the sharp(er) types, like `JCClassDecl`/`JCVariableDecl`, etc.
> 
> Or is there a reason to given up the sharp(er) type and re-create it using the switch?

I guess the motivation was to have all this related code in one place, if this code is split into several overloaded methods then I guess an entity, a class, should probably be defined to contain all this code. Dunno I guess the current solution seemed more self-contained to me

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

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

From cstein at openjdk.org  Thu May 15 19:59:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 15 May 2025 19:59:20 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v15]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <3w3nCrqGdH57ii2WG3jJdTUmrQmLMa_0xuONkhFYPRs=.e76a194b-e261-40b3-a636-e62ff4c48951@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336470-source-launcher-get-resources
 - Revert change after JDK-8356678 being addressed
 - Prevent FileSystemException on Unix-based file systems
 - Prevent NPE by removing redundant check
 - Removed redundant catch block
 - Catch and rethrow IO exception
 - Fix interim javac compilation
 - Reuse internal resource resolver and remove confusing comment
 - Update copyright year
   
   [skip ci]
 - User copyright text w/o `"Classpath" exception`
   
   [skip ci]
 - ... and 2 more: https://git.openjdk.org/jdk/compare/66dbbfe2...11956f24

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/be6cb82b..11956f24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=13-14

  Stats: 57606 lines in 1849 files changed: 36666 ins; 11655 del; 9285 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 vromero at openjdk.org  Thu May 15 20:29:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 20:29:16 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v15]
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: <nIpblBXs9ugE3vM9aB_41A8cFunwwSZvGdLrZfXVETU=.0b7c960b-1048-4d6a-aaa7-45b195df88b4@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 comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/bdbcd332..6c8d2b1d

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

  Stats: 21 lines in 2 files changed: 1 ins; 12 del; 8 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 henryjen at openjdk.org  Thu May 15 21:57:17 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 21:57:17 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v8]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <MuvMoKXj9GSHjncG8_kd0Cv4yXEjch_eLzTYSt-bCzI=.94cabdc7-f6d5-4cfa-a7d6-4ed88ad35506@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:

  Adjust message based on review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/1150fb50..1bc1f8cb

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

  Stats: 10 lines in 2 files changed: 3 ins; 1 del; 6 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  Thu May 15 22:03:52 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 22:03:52 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v6]
In-Reply-To: <eF015vnVzEp-5sqCQ9q6hmfE_AVQbCmJkNcoSG7BTrc=.9a91c482-3db5-4db9-9e28-eec44cdefe3c@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>
 <eF015vnVzEp-5sqCQ9q6hmfE_AVQbCmJkNcoSG7BTrc=.9a91c482-3db5-4db9-9e28-eec44cdefe3c@github.com>
Message-ID: <oLzSUYfFRmJx5u0PQ_sCrNQ_GcCMcWAL4oTYTBgYKUE=.195065c9-9241-441f-b338-cb106238c9a4@github.com>

On Wed, 7 May 2025 18:00:23 GMT, Henry Jen <henryjen at openjdk.org> wrote:

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

Refactored to consolidate validation on entries into a standalone EntryValidator. Hope that's easier to understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2092018706

From henryjen at openjdk.org  Thu May 15 22:03:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 15 May 2025 22:03:54 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: <L1vMczkBh8bC7NSDRxKyHFZCD_OpI7IzEo6gZz_9VZ4=.f3489630-fdf3-460f-b5f8-84ca8ebf4210@github.com>

On Wed, 7 May 2025 17:28:34 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
>
> 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`

I didn't use static import. Since that seems to be preferred, I changed to do static imports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2092017390

From vromero at openjdk.org  Thu May 15 22:32:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 22:32:12 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v16]
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: <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@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 comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/6c8d2b1d..def2505f

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

  Stats: 18 lines in 1 file changed: 1 ins; 4 del; 13 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  Thu May 15 22:36:58 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 15 May 2025 22:36:58 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v13]
In-Reply-To: <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <QvL1wMiufgj6kq6NBb2ciWTkVQ28MWWIWRmGE47mVHs=.08668b90-b5eb-4272-af23-5c501fccf079@github.com>
 <LH5l3EylBKng_NqAM062OyAsMoB62Pc3LMFhNlV1y00=.3ceab033-5328-40bb-8bdd-ac7c6dcb055d@github.com>
Message-ID: <juZlcfGRQPU29v_XUPougKrcEsvn2UhhbqVM6lpSS3k=.2f580724-0899-4445-ad02-92dc844ed500@github.com>

On Wed, 14 May 2025 18:27:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8354556
>>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - additional changes from Archie
>>  - removing dead code
>>  - integrating code from Archie
>>  - fixing bugs, removing dead code
>>  - additional documentation changes and bug fixes
>>  - documentation and adding alias to lint categories
>>  - Merge branch 'master' into JDK-8354556
>>  - addressing review comment
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/e7ce661a...22acaf29
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5823:
> 
>> 5821:                 SymbolMetadata sm = t.tsym.getMetadata();
>> 5822:                 if (sm != null && !t.getTypeArguments().isEmpty()) {
>> 5823:                     for (Attribute.TypeCompound ta: sm.getTypeAttributes().stream()
> 
> The code here, and the code in `checkIfTypeParamsRequiresIdentity` look similar a lot (although they manipulate `List<Type>` and `List<JCExpression>`, of course. I wonder if there's a chance to share the code, at least partially.

I have rewritten both using streams, technically we could still reuse some code but not a big deal, dunno

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

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

From valeriep at openjdk.org  Thu May 15 23:52:53 2025
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 15 May 2025 23:52:53 GMT
Subject: RFR: 8353888: Implement JEP 510: Key Derivation Function API [v7]
In-Reply-To: <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
 <vNY7UaUfDQbUMHYep-RikluWmdvHfsH6s8bev3nvhMM=.f7dc3bc4-041a-4854-a9f0-20c5dc82f2da@github.com>
Message-ID: <zo2M5TJ2zl-9cJjI0_7LX7M-D52GImRSwfepZ2nfciU=.2e16dbda-06fa-425d-a0d0-9952babdb9e9@github.com>

On Fri, 9 May 2025 20:05:10 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:
> 
>   new algorithms in SunJCE

Updates look good. Thanks~

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

Marked as reviewed by valeriep (Reviewer).

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

From alanb at openjdk.org  Fri May 16 05:28:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 May 2025 05:28:03 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v15]
In-Reply-To: <3w3nCrqGdH57ii2WG3jJdTUmrQmLMa_0xuONkhFYPRs=.e76a194b-e261-40b3-a636-e62ff4c48951@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <3w3nCrqGdH57ii2WG3jJdTUmrQmLMa_0xuONkhFYPRs=.e76a194b-e261-40b3-a636-e62ff4c48951@github.com>
Message-ID: <NvQPYu3db5RPDTbvGEWs7-Kc8dmb1HWuFF47Phu3nT8=.0e2c532f-90c6-4c48-87a6-4f6ca4a91bb7@github.com>

On Thu, 15 May 2025 19:59:20 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8336470-source-launcher-get-resources
>  - Revert change after JDK-8356678 being addressed
>  - Prevent FileSystemException on Unix-based file systems
>  - Prevent NPE by removing redundant check
>  - Removed redundant catch block
>  - Catch and rethrow IO exception
>  - Fix interim javac compilation
>  - Reuse internal resource resolver and remove confusing comment
>  - Update copyright year
>    
>    [skip ci]
>  - User copyright text w/o `"Classpath" exception`
>    
>    [skip ci]
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/3a13630f...11956f24

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 284:

> 282:             var path = Resources.toFilePath(programDescriptor.sourceRootPath(), name);
> 283:             return path == null ? null : path.toUri().toURL();
> 284:         } catch (IOException e) {

toUri throws IOError so I think you will need handle this too, otherwise I think the updated toResourceInRootPath looks okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2092344247

From cstein at openjdk.org  Fri May 16 07:22:46 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 16 May 2025 07:22:46 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v16]
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <Oq_HwaQz-WToZAmfvfdIK3lvhTdmATXbdRhLputbM0U=.544e96d0-d750-470d-b3de-2a9fe8070685@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 two additional commits since the last revision:

 - Improve classloader test
 - Handle IOError thrown by Path::toUri

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20193/files
  - new: https://git.openjdk.org/jdk/pull/20193/files/11956f24..bd60486a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20193&range=14-15

  Stats: 44 lines in 3 files changed: 33 ins; 5 del; 6 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 alanb at openjdk.org  Fri May 16 08:07:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 May 2025 08:07:55 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v16]
In-Reply-To: <Oq_HwaQz-WToZAmfvfdIK3lvhTdmATXbdRhLputbM0U=.544e96d0-d750-470d-b3de-2a9fe8070685@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <Oq_HwaQz-WToZAmfvfdIK3lvhTdmATXbdRhLputbM0U=.544e96d0-d750-470d-b3de-2a9fe8070685@github.com>
Message-ID: <RpJUl39D7LedqRciLsTR38pJTE4Bipk7mn60SNAX8_E=.eed0524f-31be-4d0b-a33c-915d2f01cfdf@github.com>

On Fri, 16 May 2025 07:22:46 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:
> 
>  - Improve classloader test
>  - Handle IOError thrown by Path::toUri

Latest version looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20193#pullrequestreview-2845841524

From jpai at openjdk.org  Fri May 16 10:09:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 10:09:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <TDnYscB6gOFFKO8pUp31ZPWiasbGcz0cVvYYysQXKAk=.55a15b59-f9ab-43b8-a461-6b4366bbf312@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

test/jdk/tools/launcher/Arrrghs.java line 607:

> 605:         //private method with parameter, usable method without parameter:
> 606:         createJar(new File("some.jar"), new File("Foo"),
> 607:             "private static void main(String[] args){}",

Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case?

test/jdk/tools/launcher/Arrrghs.java line 635:

> 633:         tr.contains("Error: abstract class Foo can not instantiated");
> 634:         if (!tr.testStatus)
> 635:             System.out.println(tr);

Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092758973
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092755321

From jpai at openjdk.org  Fri May 16 10:13:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 10:13:52 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:

> 281:     make inner class static or move inner class out to separate source file
> 282: java.launcher.cls.error8=\
> 283:     Error: abstract class {0} can not instantiated\n\

Nit - should this use a comma instead of the newline?

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

> 111: # 0: string
> 112: launcher.err.cant.find.main.method=\
> 113:     can''t find main(String[]) or main() method in class: {0}

Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092763055
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092765139

From jpai at openjdk.org  Fri May 16 10:30:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 10:30:51 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <aewAlr-bFrHqF9zqYnR_I488muadvF8en4O9uTyK4Tc=.40e070fd-ca25-4ff1-aa30-410bec2ac981@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794:

> 792:                           """
> 793:                           public class WrongMainPrivate {
> 794:                               private static void main(String[] args) {}

Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092789314

From cstein at openjdk.org  Fri May 16 10:40:57 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 16 May 2025 10:40:57 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v15]
In-Reply-To: <NvQPYu3db5RPDTbvGEWs7-Kc8dmb1HWuFF47Phu3nT8=.0e2c532f-90c6-4c48-87a6-4f6ca4a91bb7@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <3w3nCrqGdH57ii2WG3jJdTUmrQmLMa_0xuONkhFYPRs=.e76a194b-e261-40b3-a636-e62ff4c48951@github.com>
 <NvQPYu3db5RPDTbvGEWs7-Kc8dmb1HWuFF47Phu3nT8=.0e2c532f-90c6-4c48-87a6-4f6ca4a91bb7@github.com>
Message-ID: <LLgxQDbsMK8L7GkZnBbh2-8SJNzmbTCcf9ugpIhVieM=.892973c5-3634-4dce-bab9-0076526ba594@github.com>

On Fri, 16 May 2025 05:25:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8336470-source-launcher-get-resources
>>  - Revert change after JDK-8356678 being addressed
>>  - Prevent FileSystemException on Unix-based file systems
>>  - Prevent NPE by removing redundant check
>>  - Removed redundant catch block
>>  - Catch and rethrow IO exception
>>  - Fix interim javac compilation
>>  - Reuse internal resource resolver and remove confusing comment
>>  - Update copyright year
>>    
>>    [skip ci]
>>  - User copyright text w/o `"Classpath" exception`
>>    
>>    [skip ci]
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/30d5d804...11956f24
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java line 284:
> 
>> 282:             var path = Resources.toFilePath(programDescriptor.sourceRootPath(), name);
>> 283:             return path == null ? null : path.toUri().toURL();
>> 284:         } catch (IOException e) {
> 
> toUri throws IOError so I think you will need handle this too, otherwise I think the updated toResourceInRootPath looks okay.

Caught and handled in https://github.com/openjdk/jdk/pull/20193/commits/6a0db8a6c7e630e37a431463b67749303a6e3d13

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20193#discussion_r2092803350

From jlahoda at openjdk.org  Fri May 16 11:06:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:06:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly
In-Reply-To: <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>
Message-ID: <YN0gc3xdaXnc_7NgHqn1sKRyLAdN2aXxdPVt9Ed2H1U=.d1c8df2a-6945-4e77-a3b5-a21c7ec506bf@github.com>

On Fri, 16 May 2025 10:10:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:
> 
>> 281:     make inner class static or move inner class out to separate source file
>> 282: java.launcher.cls.error8=\
>> 283:     Error: abstract class {0} can not instantiated\n\
> 
> Nit - should this use a comma instead of the newline?

The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties line 113:
> 
>> 111: # 0: string
>> 112: launcher.err.cant.find.main.method=\
>> 113:     can''t find main(String[]) or main() method in class: {0}
> 
> Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo.

Pieces of text in `MessageFormat` can be quoted using `'...'`. So, a single `'` does not work, as that is considered to be part of quoting. Using `''` escapes that behavior.

> test/jdk/tools/launcher/Arrrghs.java line 635:
> 
>> 633:         tr.contains("Error: abstract class Foo can not instantiated");
>> 634:         if (!tr.testStatus)
>> 635:             System.out.println(tr);
> 
> Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code?

`tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092836696
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092838074
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092835532

From jlahoda at openjdk.org  Fri May 16 11:12:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:12:08 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

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

  Adding tests as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25256/files
  - new: https://git.openjdk.org/jdk/pull/25256/files/1c6a0123..a351686d

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

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

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

From jlahoda at openjdk.org  Fri May 16 11:12:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:12:08 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <TDnYscB6gOFFKO8pUp31ZPWiasbGcz0cVvYYysQXKAk=.55a15b59-f9ab-43b8-a461-6b4366bbf312@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <TDnYscB6gOFFKO8pUp31ZPWiasbGcz0cVvYYysQXKAk=.55a15b59-f9ab-43b8-a461-6b4366bbf312@github.com>
Message-ID: <pYZwwmT0oFAXEanS5DthzeFMbzfVTDfDQ2lXA3JfD24=.e06e6c93-942c-41c0-9545-bf23cdbd0ab4@github.com>

On Fri, 16 May 2025 10:07:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding tests as suggested.
>
> test/jdk/tools/launcher/Arrrghs.java line 607:
> 
>> 605:         //private method with parameter, usable method without parameter:
>> 606:         createJar(new File("some.jar"), new File("Foo"),
>> 607:             "private static void main(String[] args){}",
> 
> Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case?

Done:
https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f

> test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794:
> 
>> 792:                           """
>> 793:                           public class WrongMainPrivate {
>> 794:                               private static void main(String[] args) {}
> 
> Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too?

Done:
https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844131
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844245

From vromero at openjdk.org  Fri May 16 11:25:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 16 May 2025 11:25:51 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
Message-ID: <b8hyBRPvKNMvtLjUIWu1gU-KQEQ2dEqeT6e6KOUegAY=.bfe57d94-4f49-4215-8f1c-5e73db77eea0@github.com>

On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests as suggested.

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:

> 281:     make inner class static or move inner class out to separate source file
> 282: java.launcher.cls.error8=\
> 283:     Error: abstract class {0} can not instantiated\n\

typo: can not `be` instantiated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092862512

From jpai at openjdk.org  Fri May 16 11:49:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 11:49:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <YN0gc3xdaXnc_7NgHqn1sKRyLAdN2aXxdPVt9Ed2H1U=.d1c8df2a-6945-4e77-a3b5-a21c7ec506bf@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <hJqy2FbAjXy8-R6F7mr_oqWJegUxCnp6OB0wBHzboNk=.115deed6-416b-40f1-916b-1d4fb4e34147@github.com>
 <YN0gc3xdaXnc_7NgHqn1sKRyLAdN2aXxdPVt9Ed2H1U=.d1c8df2a-6945-4e77-a3b5-a21c7ec506bf@github.com>
Message-ID: <igmV2WJXemU2ROiGOAOkG3yXafMBVXiLfBxNS_0qf3M=.826f52fd-76af-4d08-a511-2050206bbca5@github.com>

On Fri, 16 May 2025 11:02:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:
>> 
>>> 281:     make inner class static or move inner class out to separate source file
>>> 282: java.launcher.cls.error8=\
>>> 283:     Error: abstract class {0} can not instantiated\n\
>> 
>> Nit - should this use a comma instead of the newline?
>
> The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional.

Sounds fine to me then.

>> test/jdk/tools/launcher/Arrrghs.java line 635:
>> 
>>> 633:         tr.contains("Error: abstract class Foo can not instantiated");
>>> 634:         if (!tr.testStatus)
>>> 635:             System.out.println(tr);
>> 
>> Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code?
>
> `tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option.

Thank you for that. I didn't even realize that this was a "main()" test. I saw that there was a `@Test` annotation on these test methods and assumed it was either a testng or junit test. Turns out it's just another internal annotation of the `TestHelper`.

> It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option.

What you have in the current PR is fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092893716
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092892219

From jlahoda at openjdk.org  Fri May 16 11:54:07 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 11:54:07 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v3]
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

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

  Review comment: correcting typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25256/files
  - new: https://git.openjdk.org/jdk/pull/25256/files/a351686d..f63dab37

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

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

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

From jpai at openjdk.org  Fri May 16 11:54:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 11:54:07 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v2]
In-Reply-To: <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <rTt0ecK6pxNZcmf7a3YChhle3BxeLN-yVbUhnCo0FBc=.f438c5d5-0a35-453a-a755-b3c6aaee816e@github.com>
Message-ID: <u1KsiUhF-HbE9f08k6sIR6VDeZljwZh5zBuxAvaegt4=.8c10bcf0-6db2-47d6-9a26-985cd03a887c@github.com>

On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests as suggested.

I went through the JLS updates linked in the CSR for JEP 512 https://bugs.openjdk.org/browse/JDK-8353437. The proposed changes in this PR looks good to me. The additional test coverage being added is good too.

I am not completely sure if the `Arrrghs.java` test and the `test/jdk/tools/launcher/InstanceMainTest.java` test fully cover all the scenarios of the new rules of determining a main method, but that's something that can be looked into as a separate activity.

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

PR Comment: https://git.openjdk.org/jdk/pull/25256#issuecomment-2886504200

From jpai at openjdk.org  Fri May 16 11:57:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 16 May 2025 11:57:53 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v3]
In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
Message-ID: <jM9RsiOyq8lwFahgViitmHLH0icIvCbQ1n_divFPcYI=.70711efb-97cf-4284-96cc-a4e0bd98d4e0@github.com>

On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: correcting typo.

test/jdk/tools/launcher/Arrrghs.java line 649:

> 647:                 """);
> 648:         tr = doExec(javaCmd, "-jar", "some.jar");
> 649:         tr.contains("Error: abstract class Foo can not instantiated");

After the latest typo fix, this check would also need an update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092905785

From vromero at openjdk.org  Fri May 16 12:01:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 16 May 2025 12:01:51 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v3]
In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com>
Message-ID: <9nkgB8f4tHZhM5HWcaivVzI7ibIZ0DfWlwRykr_uYrY=.8a0198cb-f35f-42ed-948d-2110a4694ef1@github.com>

On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: correcting typo.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2846416794

From weijun at openjdk.org  Fri May 16 12:28:06 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 May 2025 12:28:06 GMT
Subject: Integrated: 8353888: Implement JEP 510: Key Derivation Function API
In-Reply-To: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
References: <CKMuatIxnNbKzIcC5nBuKx2A-jRZjW1QWdldePef7N0=.a14b7dfb-de4f-40f8-8f3e-9364c1465f68@github.com>
Message-ID: <kEmA_BJnB48AKgosw0ulkfICLsoRKDa43FMGBL-yblo=.fd4af403-2e59-4b95-b474-1867199e78ec@github.com>

On Tue, 8 Apr 2025 18:14:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Finalize the KDF API.

This pull request has now been integrated.

Changeset: 079fccfa
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/079fccfa9a03b890e698c52c689dea0f19f8fbee
Stats:     209 lines in 18 files changed: 160 ins; 29 del; 20 mod

8353888: Implement JEP 510: Key Derivation Function API

Reviewed-by: valeriep, mullan, liach

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

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

From abimpoudis at openjdk.org  Fri May 16 12:45:51 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 16 May 2025 12:45:51 GMT
Subject: RFR: 8347530: Improve error message with invalid permits clauses
 [v2]
In-Reply-To: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>
References: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>
Message-ID: <GdW1UTlnbRxRIzUDgVhpMOoIl7XXuPXYH6ag2-fngyo=.a0c62bfc-a817-4894-a460-a5af22d618dd@github.com>

> Currently we report one kind of error message (`subclass {0} must extend sealed class`) when there is a compile-type error in cases like the following:
> 
> 
> sealed class C0 permits S0 {}
> class S0 {}  
> 
> 
> This PR proposes to improve error reporting since there are other kinds of declarations that can also participate in sealed hierarchies like records, enums and interfaces.

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

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25255/files
  - new: https://git.openjdk.org/jdk/pull/25255/files/3195b3ad..4fb2f9af

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

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

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

From jlahoda at openjdk.org  Fri May 16 12:45:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 12:45:52 GMT
Subject: RFR: 8347530: Improve error message with invalid permits clauses
 [v2]
In-Reply-To: <GdW1UTlnbRxRIzUDgVhpMOoIl7XXuPXYH6ag2-fngyo=.a0c62bfc-a817-4894-a460-a5af22d618dd@github.com>
References: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>
 <GdW1UTlnbRxRIzUDgVhpMOoIl7XXuPXYH6ag2-fngyo=.a0c62bfc-a817-4894-a460-a5af22d618dd@github.com>
Message-ID: <VyaGAudejtMrgf9hTMT2KRggyT5yjM9PCll-mqc9O0M=.ce141209-0453-4ef8-b3a5-56cbb7115bd1@github.com>

On Fri, 16 May 2025 12:42:35 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Currently we report one kind of error message (`subclass {0} must extend sealed class`) when there is a compile-type error in cases like the following:
>> 
>> 
>> sealed class C0 permits S0 {}
>> class S0 {}  
>> 
>> 
>> This PR proposes to improve error reporting since there are other kinds of declarations that can also participate in sealed hierarchies like records, enums and interfaces.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5474:

> 5472:                                                         .anyMatch(d -> d.tsym == c);
> 5473:                             if (!thisIsASuper) {
> 5474:                                 KindName subtypingLeftKind;

I wonder, would: `KindName.kindName(subType.tsym)` work?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25255#discussion_r2092971642

From abimpoudis at openjdk.org  Fri May 16 12:45:53 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 16 May 2025 12:45:53 GMT
Subject: RFR: 8347530: Improve error message with invalid permits clauses
 [v2]
In-Reply-To: <VyaGAudejtMrgf9hTMT2KRggyT5yjM9PCll-mqc9O0M=.ce141209-0453-4ef8-b3a5-56cbb7115bd1@github.com>
References: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>
 <GdW1UTlnbRxRIzUDgVhpMOoIl7XXuPXYH6ag2-fngyo=.a0c62bfc-a817-4894-a460-a5af22d618dd@github.com>
 <VyaGAudejtMrgf9hTMT2KRggyT5yjM9PCll-mqc9O0M=.ce141209-0453-4ef8-b3a5-56cbb7115bd1@github.com>
Message-ID: <UIhgPHJcUhcAPQVFpl6_GxRUPAB0DkMBmLdOyT0ksTE=.c52518f0-1e62-4b35-b70e-7544d2531362@github.com>

On Fri, 16 May 2025 12:40:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5474:
> 
>> 5472:                                                         .anyMatch(d -> d.tsym == c);
>> 5473:                             if (!thisIsASuper) {
>> 5474:                                 KindName subtypingLeftKind;
> 
> I wonder, would: `KindName.kindName(subType.tsym)` work?

Indeed and I updated the PR. Thanks @lahodaj

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25255#discussion_r2092974831

From jlahoda at openjdk.org  Fri May 16 13:07:51 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 16 May 2025 13:07:51 GMT
Subject: RFR: 8347530: Improve error message with invalid permits clauses
 [v2]
In-Reply-To: <GdW1UTlnbRxRIzUDgVhpMOoIl7XXuPXYH6ag2-fngyo=.a0c62bfc-a817-4894-a460-a5af22d618dd@github.com>
References: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>
 <GdW1UTlnbRxRIzUDgVhpMOoIl7XXuPXYH6ag2-fngyo=.a0c62bfc-a817-4894-a460-a5af22d618dd@github.com>
Message-ID: <ytrsLWPgrbOsacd8SlopgKrCVvwF__OyRA42c9XieWw=.334a59f2-125e-4b53-a2b3-d1c2706f4c80@github.com>

On Fri, 16 May 2025 12:45:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Currently we report one kind of error message (`subclass {0} must extend sealed class`) when there is a compile-type error in cases like the following:
>> 
>> 
>> sealed class C0 permits S0 {}
>> class S0 {}  
>> 
>> 
>> This PR proposes to improve error reporting since there are other kinds of declarations that can also participate in sealed hierarchies like records, enums and interfaces.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

Looks good to me!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25255#pullrequestreview-2846575216

From davthomp at redhat.com  Fri May 16 13:21:14 2025
From: davthomp at redhat.com (David Thompson)
Date: Fri, 16 May 2025 09:21:14 -0400
Subject: JDK-8356411
Message-ID: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>

Hello,

I've started looking at JDK-8356411. I've narrowed it down to
`MarkdownTransformer` (in particular `Lower.flushText`) not taking into
account that the leading whitespace has been stripped from the markdown
text following the `@see` tag (and probably other similar tags). I've been
working on a fix for this but don't have anything working yet.

I've noticed that Hannes Wallnoefer has been assigned this issue. Is it
worthwhile for me to continue investigating?

Thanks,

-- 
David Thompson
they/she/he
Devtools at Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250516/eaa14b83/attachment.htm>

From cstein at openjdk.org  Fri May 16 13:22:11 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 16 May 2025 13:22:11 GMT
Subject: RFR: 8336470: Source launcher should work with service loader SPI
 in unnamed module [v16]
In-Reply-To: <Oq_HwaQz-WToZAmfvfdIK3lvhTdmATXbdRhLputbM0U=.544e96d0-d750-470d-b3de-2a9fe8070685@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
 <Oq_HwaQz-WToZAmfvfdIK3lvhTdmATXbdRhLputbM0U=.544e96d0-d750-470d-b3de-2a9fe8070685@github.com>
Message-ID: <rV_OxXzlbsEzPamZaeMe4qfGFzrsNDHMk5qfixBeu5M=.5027b106-70c0-4ef9-b3ec-cfb7bca2470b@github.com>

On Fri, 16 May 2025 07:22:46 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:
> 
>  - Improve classloader test
>  - Handle IOError thrown by Path::toUri

GHA checks, local tests, and an internal tier 1 run on more platforms look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/20193#issuecomment-2886705229

From cstein at openjdk.org  Fri May 16 13:22:12 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 16 May 2025 13:22:12 GMT
Subject: Integrated: 8336470: Source launcher should work with service loader
 SPI in unnamed module
In-Reply-To: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
References: <zpP9XHzM8c0jnViLDFd_uFHMhIiaAkpQOidUlE6AJLo=.f9f27e27-ca12-4bbe-a776-e384cd183726@github.com>
Message-ID: <GT1xuC-P3xiX4aONjmPIqzHnWRisoZ2HdenrlPj9r9o=.9f0a0400-1e91-4211-bfc7-f2ab540a19d5@github.com>

On Tue, 16 Jul 2024 11:45:47 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.

This pull request has now been integrated.

Changeset: bca293d0
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bca293d0124af098d36cdfb18c15df18c8ce53b9
Stats:     122 lines in 7 files changed: 103 ins; 4 del; 15 mod

8336470: Source launcher should work with service loader SPI in unnamed module

Reviewed-by: alanb

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

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

From chen.l.liang at oracle.com  Fri May 16 13:51:45 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 16 May 2025 13:51:45 +0000
Subject: JDK-8356411
In-Reply-To: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
References: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
Message-ID: <SJ2PR10MB7669448043A4D508572B984FA293A@SJ2PR10MB7669.namprd10.prod.outlook.com>

CC'ing the javadoc-dev list too.
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David Thompson <davthomp at redhat.com>
Sent: Friday, May 16, 2025 8:21 AM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Cc: Hannes Wallnoefer <hannes.wallnoefer at oracle.com>
Subject: JDK-8356411

Hello,

I've started looking at JDK-8356411. I've narrowed it down to `MarkdownTransformer` (in particular `Lower.flushText`) not taking into account that the leading whitespace has been stripped from the markdown text following the `@see` tag (and probably other similar tags). I've been working on a fix for this but don't have anything working yet.

I've noticed that Hannes Wallnoefer has been assigned this issue. Is it worthwhile for me to continue investigating?

Thanks,

--
David Thompson
they/she/he
Devtools at Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250516/3152cf36/attachment-0001.htm>

From hannes.wallnoefer at oracle.com  Fri May 16 13:54:47 2025
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 16 May 2025 13:54:47 +0000
Subject: [External] : JDK-8356411
In-Reply-To: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
References: <CAJ0D3QQiRDk0hhMS3DA7V67Hcm9MOh=L-e0_0J2hcpZLtbB8+Q@mail.gmail.com>
Message-ID: <0FE6F539-FE52-4FFD-B0E8-7A3D20B82264@oracle.com>

Hi David, 

I haven?t looked into this bug yet, but I suspected it might have something to do with stripping whitespace. 

I plan to look into the issue soon, but if you?re interested in getting the issue fixed you are certainly welcome to continue investigating..

Hannes

> On 16.05.2025, at 15:21, David Thompson <davthomp at redhat.com> wrote:
> 
> Hello,
> 
> I've started looking at JDK-8356411. I've narrowed it down to `MarkdownTransformer` (in particular `Lower.flushText`) not taking into account that the leading whitespace has been stripped from the markdown text following the `@see` tag (and probably other similar tags). I've been working on a fix for this but don't have anything working yet.
> 
> I've noticed that Hannes Wallnoefer has been assigned this issue. Is it worthwhile for me to continue investigating?
> 
> Thanks,
> 
> --
> David Thompson
> they/she/he
> Devtools at Red Hat


From lancea at openjdk.org  Fri May 16 19:00:00 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 May 2025 19:00:00 GMT
Subject: RFR: 8345431: Detect duplicate entries in jar files with jar
 --validate [v8]
In-Reply-To: <MuvMoKXj9GSHjncG8_kd0Cv4yXEjch_eLzTYSt-bCzI=.94cabdc7-f6d5-4cfa-a7d6-4ed88ad35506@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <MuvMoKXj9GSHjncG8_kd0Cv4yXEjch_eLzTYSt-bCzI=.94cabdc7-f6d5-4cfa-a7d6-4ed88ad35506@github.com>
Message-ID: <ogb8nRQUga5OZlGei9xRAkHN9D1v4cJ-gFqQsA5fm6E=.db9bd5e3-e719-4573-88be-7aef725fccc2@github.com>

On Thu, 15 May 2025 21:57:17 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:
> 
>   Adjust message based on review feedback

Hi Henry,

A few comments based on an initial pass through last update

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

> 63:      * - does not contain a backslash, '\'
> 64:      * - does not contain a drive letter
> 65:      * - path element does not include '..'

change to 
 >    * - path element does not include '.' or '..'

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

> 115:      * and UNIX file systems etc.
> 116:      * Also validate that the file name is not "." and that any name element is
> 117:      * not equal to ".."

Also validate that the file name is not "." or ".." and that any name element is
     * not equal to ".." or "."

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

> 130:      * - CEN and LOC should have same entries, in the same order
> 131:      * NOTE: This implementation assumes CEN entries are to be added before
> 132:      *       add any LOC entries.

I think you should probably expand this comment a bit with the expected work flow as it takes a while to grasp your intent otherwise

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

> 153:             }
> 154: 
> 155:             boolean isPlaceHolder() {

A comment would be helpful here for future maintainers

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

> 285: \                             or invalid file names that could lead to unintended effects.\n\
> 286: \                             Check with the developer to ensure the jar archive integrity\n\
> 287: \                             when warnings observed after using this option.

I  think this could be improved perhaps something like:


main.help.opt.main.validate=\
\      --validate             Validate the contents of the jar archive. This option will:\n\
\                             + validate that the API exported by a multi-release\n\
\                                 jar archive is consistent across all different release\n\
\                                versions.\n\
\                             + warn if there are duplicate or invalid file names\n\


I think you can remove the verbiage WRT "Check with..."  from the help message

src/jdk.jartool/share/man/jar.md line 111:

> 109: `--validate`
> 110: :   Validate the contents of the jar archive.
> 111:     Check with the developer to ensure the jar archive integrity

You can remove here and add a suggestion in the "integrity of a Jar Archive" section as to what to do.

src/jdk.jartool/share/man/jar.md line 223:

> 221: 
> 222: ## Integrity of a jar Archive
> 223: As a jar archive is based on ZIP format, it is possible to manufacture a jar archive using tools

manufacture -> create

src/jdk.jartool/share/man/jar.md line 224:

> 222: ## Integrity of a jar Archive
> 223: As a jar archive is based on ZIP format, it is possible to manufacture a jar archive using tools
> 224: other than the `jar` command. The `--validate` options checks a jar archive for some integrity

`The '--validate' option performs the following integrity checks:`

src/jdk.jartool/share/man/jar.md line 237:

> 235: -   The API exported by a multi-release jar archive is consistent across all different release
> 236:     versions.
> 237: 

I would consider something similar to:


 - That there are no duplicate Zip Entry file names
 - Verify that the Zip Entry file name:
      - is not an absolute path
      - the file name is not '.' or '..'
      - does not contain a backslash, ''
      - does not contain a drive letter
      - path element does not include '.' or '..
  - The API exported by a multi-release jar archive is consistent across all different release versions.

 The jar tool will return a status code of 0 if there were  no integrity issues encountered and a status code of 1 an issue was found.
  
When an integrity issue is reported, it will often require that the jar file is re-created by the original source of the jar file
```.

test/jdk/tools/jar/ValidatorTest.java line 325:

> 323:     }
> 324: 
> 325:     private void rm(String cmdline) {

Maybe I missed it, but is this method used?

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

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2847026334
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093296698
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093300176
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093421481
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093422620
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093445110
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093448844
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093450314
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093452262
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093475451
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2093537089

From henryjen at openjdk.org  Sat May 17 01:27:38 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Sat, 17 May 2025 01:27:38 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@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:

  Address review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/1bc1f8cb..da4a9139

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

  Stats: 53 lines in 4 files changed: 12 ins; 20 del; 21 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 jlahoda at openjdk.org  Mon May 19 03:49:20 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 03:49:20 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v4]
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <EEHy4qY8GtcneNUjXWZJj-2UF6i_N7z-05oBncDKR24=.9a21e713-e6df-4e75-b58d-a422bc411950@github.com>

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

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

  Adjusting message and tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25256/files
  - new: https://git.openjdk.org/jdk/pull/25256/files/f63dab37..db7e7ceb

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

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

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

From jpai at openjdk.org  Mon May 19 06:22:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 May 2025 06:22:56 GMT
Subject: RFR: 8357016: Candidate main methods not computed properly [v4]
In-Reply-To: <EEHy4qY8GtcneNUjXWZJj-2UF6i_N7z-05oBncDKR24=.9a21e713-e6df-4e75-b58d-a422bc411950@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
 <EEHy4qY8GtcneNUjXWZJj-2UF6i_N7z-05oBncDKR24=.9a21e713-e6df-4e75-b58d-a422bc411950@github.com>
Message-ID: <vS5YDG53mDSz6jH9vclF2PSYGwTVBuoHb5gSTBoWdxA=.b897aee8-2133-4502-9de8-248d342ede27@github.com>

On Mon, 19 May 2025 03:49:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting message and tests.

The updated changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2849510798

From jlahoda at openjdk.org  Mon May 19 07:32:02 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 07:32:02 GMT
Subject: Integrated: 8357016: Candidate main methods not computed properly
In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com>
Message-ID: <wLWCtjTOidPjqk0X3M19yNPmPiMt175rbVBS5OCjSFI=.4b0d5f9c-5dff-4822-8f84-1d266048ce39@github.com>

On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A consider class like this:
> 
> 
> public class TwoMains {
>     private static void main(String... args) {}
>     static void main() {
>         System.out.println("Should be called, but is not.");
>     }
> }
> 
> 
> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
> 
> Something similar happens if the return type is not `void`.
> 
> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
> 
> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).

This pull request has now been integrated.

Changeset: 77a3e04f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77a3e04ffc27554c14e3d45ba16ad0ee8f3c1eb1
Stats:     177 lines in 8 files changed: 151 ins; 10 del; 16 mod

8357016: Candidate main methods not computed properly

Reviewed-by: jpai, vromero

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

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

From jlahoda at openjdk.org  Mon May 19 08:31:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 08:31:56 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v16]
In-Reply-To: <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
Message-ID: <path6TRLoBeD1bFwvVZvX6tD6Us6Ypp6RUgocuTnFOc=.f621fb44-24ed-40b8-afb0-57163e5ba87c@github.com>

On Thu, 15 May 2025 22:32:12 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:
> 
>   addressing review comments

javac changes look good to me, with one trivial nit in `Check`.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5848:

> 5846:         }
> 5847:     }
> 5848:  }

Nit - there appears to be an extra space at the beginning of this line.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2849882159
PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2095145360

From liach at openjdk.org  Mon May 19 10:55:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 May 2025 10:55:53 GMT
Subject: RFR: 8348906: InstanceOfTree#getType doesn't specify when it
 returns null [v2]
In-Reply-To: <u0zxU9jTwwFgENjTmM8thedh8bxtctxfJrYBFtszCrI=.b51af9b6-eb60-45c1-aa09-b7ea2096c5f2@github.com>
References: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>
 <u0zxU9jTwwFgENjTmM8thedh8bxtctxfJrYBFtszCrI=.b51af9b6-eb60-45c1-aa09-b7ea2096c5f2@github.com>
Message-ID: <ONWh5rTjA1O2z2HHHmV61kvuzesUkgQ0mIao0bfxnoI=.83280d8d-a65b-46b8-ad59-f9b11bf9550d@github.com>

On Wed, 14 May 2025 13:44:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> `InstanceOfTree.getType()` returns `null` if the `instanceof` uses a pattern different than the type test pattern. This is not documented, and should be documented. This PR proposes the documentation for this.
>> 
>> Alternatively, we could change `getType()` to return a type for other types of patterns, but the meaning of that is not quite clear even for record patterns, and it gets even less clear with the possible future patterns. I believe it has been mostly a conscious decision to not handle record patterns in this method. Possibly, it was a mistake to handle the type test/binding patterns in `getType()`, but that's not something that we should change, I think.
>> 
>> Please also review the CSR:
>> https://bugs.openjdk.org/browse/JDK-8356857
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comment - adding examples.

Looks much more informative now.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25205#pullrequestreview-2850327178

From duke at openjdk.org  Mon May 19 11:53:56 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Mon, 19 May 2025 11:53:56 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v16]
In-Reply-To: <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <GzzgfleafLsCdPZxFZ05PIGjejVSBNdfn-OU4eJMBBA=.60c11dfc-876e-4719-8e57-659ca5554cfe@github.com>
Message-ID: <argMlZQAGTefG5GDtGD7TnNH1lqGPLozrCo_YS-NeEA=.156eff07-f8fa-4b10-b566-7bb0375ba58b@github.com>

On Thu, 15 May 2025 22:32:12 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:
> 
>   addressing review comments

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

> 306:             "Ljdk/internal/ValueBased+Annotation;";
> 307:     private static final String REQUIRES_IDENTITY_ANNOTATION =
> 308:             "Ljdk/internal/RequieresIdentity;";

typo: RequieresIdentity -> RequiresIdentity

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

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

From vromero at openjdk.org  Mon May 19 13:47:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 13:47:50 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v17]
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: <VH-SkrPWeoWzA0EHZCD1Ys5QIBa8jVhqZJas6wJsryo=.ea1082d8-e75e-4725-a4ab-c66d669a289a@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:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24746/files
  - new: https://git.openjdk.org/jdk/pull/24746/files/def2505f..cf92614c

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

  Stats: 2 lines in 2 files changed: 0 ins; 0 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  Mon May 19 14:35:40 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 14:35:40 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
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: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@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 39 commits:

 - Merge branch 'master' into JDK-8354556
 - review comments
 - addressing review comments
 - addressing review comments
 - update warning message
 - Merge branch 'master' into JDK-8354556
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - additional changes from Archie
 - removing dead code
 - integrating code from Archie
 - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

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

Changes: https://git.openjdk.org/jdk/pull/24746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=17
  Stats: 647 lines in 32 files changed: 562 ins; 37 del; 48 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 rriggs at openjdk.org  Mon May 19 15:39:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 May 2025 15:39:50 GMT
Subject: RFR: 8356193: Remove tests from ProblemList-enable-preview.txt
 fixed by JDK-8344706
In-Reply-To: <MdA9ObZQv019Y0FynO9LTvIwHnNpqFvXeaqM3GrHhcY=.4285be4d-d281-43c3-b089-88ea9b3fdc6a@github.com>
References: <MdA9ObZQv019Y0FynO9LTvIwHnNpqFvXeaqM3GrHhcY=.4285be4d-d281-43c3-b089-88ea9b3fdc6a@github.com>
Message-ID: <DAPpLCm-OCFvtx6haOZq8WDPEr7w6b5Xyue_AV9yf4Y=.83e1f294-a85b-4cda-b9cd-bd6f36c62eb6@github.com>

On Mon, 5 May 2025 16:22:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

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

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25042#pullrequestreview-2851244656

From jlahoda at openjdk.org  Mon May 19 16:02:00 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 16:02:00 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
In-Reply-To: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
Message-ID: <4WJiJCaO8Kf9FzD4YX0nP13CoVOcDw9wePKvBVyaQw8=.81f09b20-763c-4e6b-a0ff-a12167e0644c@github.com>

On Mon, 19 May 2025 14:35:40 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 39 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - review comments
>  - addressing review comments
>  - addressing review comments
>  - update warning message
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

javac changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24746#pullrequestreview-2851310025

From lmesnik at openjdk.org  Mon May 19 17:11:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 19 May 2025 17:11:58 GMT
Subject: Integrated: 8356193: Remove tests from ProblemList-enable-preview.txt
 fixed by JDK-8344706
In-Reply-To: <MdA9ObZQv019Y0FynO9LTvIwHnNpqFvXeaqM3GrHhcY=.4285be4d-d281-43c3-b089-88ea9b3fdc6a@github.com>
References: <MdA9ObZQv019Y0FynO9LTvIwHnNpqFvXeaqM3GrHhcY=.4285be4d-d281-43c3-b089-88ea9b3fdc6a@github.com>
Message-ID: <D8rfqZ16kf92f__7rookx2BTtm321fgp7SstIRbxRHY=.6a6743f5-0251-4bdc-9634-6c88ee2f1d71@github.com>

On Mon, 5 May 2025 16:22:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: bd995256
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd99525633e4d3d3f180a6678eedb8780dbb6139
Stats:     3 lines in 2 files changed: 0 ins; 3 del; 0 mod

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

Reviewed-by: rriggs

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

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

From nbenalla at openjdk.org  Mon May 19 18:11:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 18:11:34 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v3]
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: <Nu5ZnPIRoa--jtdnVjIdy2i7lgJIM4Nf040_kOO39Y0=.e18061ba-9024-4176-9177-4be9d9843e51@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 nine commits:

 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - 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=02
  Stats: 1705 lines in 56 files changed: 1616 ins; 16 del; 73 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 vromero at openjdk.org  Mon May 19 19:21:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 19:21:57 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
In-Reply-To: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
Message-ID: <cllOLOISOc5eGoHidGa1OrbhnGS04BWPIIs4eERCWdc=.9019fd88-095f-4022-a33c-0e8d6b33c1a3@github.com>

On Mon, 19 May 2025 14:35:40 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 39 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - review comments
>  - addressing review comments
>  - addressing review comments
>  - update warning message
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2892039464

From vromero at openjdk.org  Mon May 19 21:19:36 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 21:19:36 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v4]
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: <uw_ZykYZhaxlr4oLe2WJ4uTE1Ictgsz6L3mlillcsnM=.6c105fbf-0bc8-4d35-b880-82fd5830d6fc@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 six additional commits since the last revision:

 - Merge branch 'master' into JDK-8325859
 - experiments, addressing review comments
 - 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/66e457fe..1629c25e

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

  Stats: 53260 lines in 1607 files changed: 25910 ins; 19033 del; 8317 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  Mon May 19 21:22:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 21:22:07 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v5]
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: <u2WoVEgB7s3XqezdTrZNS-OFDO5sztSS6DlKKw98feI=.ea772f72-7d25-49b1-94cf-9bfe9b90fa38@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:

  removing dead code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25011/files
  - new: https://git.openjdk.org/jdk/pull/25011/files/1629c25e..71ddef6d

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

  Stats: 11 lines in 1 file changed: 0 ins; 10 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  Mon May 19 21:43:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 21:43:30 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v6]
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: <ACi5y8XAwJVkarPt_ezSvb9hHgYr93Im7-jh6TQbHGo=.e32af6df-b6c6-4c36-8b8d-79662227b00b@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:

  removing unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25011/files
  - new: https://git.openjdk.org/jdk/pull/25011/files/71ddef6d..a3e3662f

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

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 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  Mon May 19 21:47:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 21:47:14 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v7]
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: <0NspRaxKl7hw7EXaUj1M9tj361lBf2HKWK4M0wTe_p0=.9fbf844f-2745-46d5-897b-db3ae2f927b5@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:

  field renamed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25011/files
  - new: https://git.openjdk.org/jdk/pull/25011/files/a3e3662f..8922570a

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

  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  Mon May 19 22:50:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 22:50:04 GMT
Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref
 API [v18]
In-Reply-To: <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
References: <edDSW_2Nd6TU7wCeqkISmt5TDnQbx_Tv2QRo9yy982c=.11a193ba-9d92-4499-b5a2-56a177c2ae6c@github.com>
 <MPgukNWo0agINMH9L7hhU13BNo-_ZlWV311WmPyZSVQ=.d4b4e536-4280-416c-91f9-910561b97169@github.com>
Message-ID: <uRyaK_g1CX8Xba6I2uCuPjiOAuzdAa1WfX1Blg0df88=.12cdaa10-5aff-4080-9f1a-7cde88af85c2@github.com>

On Mon, 19 May 2025 14:35:40 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 39 commits:
> 
>  - Merge branch 'master' into JDK-8354556
>  - review comments
>  - addressing review comments
>  - addressing review comments
>  - update warning message
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/265d6301...904bd4cd

thanks guys for the reviews and contributions

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

PR Comment: https://git.openjdk.org/jdk/pull/24746#issuecomment-2892451481

From vromero at openjdk.org  Mon May 19 22:50:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 19 May 2025 22:50:06 GMT
Subject: Integrated: 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: <5a5jcUgnclxBixFti4n6YX4EPOqXQBKCzhQqZQVPXHU=.987b3c82-af88-47a6-a2bd-d91c1002aedf@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

This pull request has now been integrated.

Changeset: 637e9d16
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/637e9d16ddb21003234abcd32f759aefd91f21f9
Stats:     647 lines in 32 files changed: 562 ins; 37 del; 48 mod

8354556: Expand value-based class warnings to java.lang.ref API

Co-authored-by: Archie Cobbs <acobbs at openjdk.org>
Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Mon May 19 22:54:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 22:54:09 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity [v2]
In-Reply-To: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
Message-ID: <iqp6MZZgFYpvuTDd372qTseKyYX35wgbUNMAUXtSXto=.3718c36a-4cd8-4a78-8b9c-46972b4e03c1@github.com>

> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
> 
> Important parts of the patch:
> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API method

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

 - Cleanup.
 - Fixing build
 - Adjustments, annotation filtering, adding more tests
 - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556
 - Merge branch 'master' into JDK-8354556
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - additional changes from Archie
 - removing dead code
 - integrating code from Archie
 - fixing bugs, removing dead code
 - ... and 31 more: https://git.openjdk.org/jdk/compare/e7ce661a...daed20ff

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

Changes: https://git.openjdk.org/jdk/pull/25232/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25232&range=01
  Stats: 1197 lines in 41 files changed: 1088 ins; 51 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/25232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25232/head:pull/25232

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

From jlahoda at openjdk.org  Tue May 20 02:42:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 May 2025 02:42:57 GMT
Subject: Integrated: 8348906: InstanceOfTree#getType doesn't specify when it
 returns null
In-Reply-To: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>
References: <A1yiu9cP6xErxxHT6mWPTfLUPLLcBcH8Dbl-nnuwzug=.50527679-7a6b-441c-ae26-736bd731641a@github.com>
Message-ID: <5SIMOi7z4N7C8RRO4sZ0cveKWV6LyDYsCF9S5uk-PBg=.0ab2e57c-8e06-4f98-946f-594abdf58df3@github.com>

On Tue, 13 May 2025 11:29:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `InstanceOfTree.getType()` returns `null` if the `instanceof` uses a pattern different than the type test pattern. This is not documented, and should be documented. This PR proposes the documentation for this.
> 
> Alternatively, we could change `getType()` to return a type for other types of patterns, but the meaning of that is not quite clear even for record patterns, and it gets even less clear with the possible future patterns. I believe it has been mostly a conscious decision to not handle record patterns in this method. Possibly, it was a mistake to handle the type test/binding patterns in `getType()`, but that's not something that we should change, I think.
> 
> Please also review the CSR:
> https://bugs.openjdk.org/browse/JDK-8356857

This pull request has now been integrated.

Changeset: 39d8d109
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39d8d109dd8ab300ff6579f8077468a6b02cfbda
Stats:     120 lines in 2 files changed: 113 ins; 0 del; 7 mod

8348906: InstanceOfTree#getType doesn't specify when it returns null

Reviewed-by: liach

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

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

From mcimadamore at openjdk.org  Tue May 20 10:14:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 May 2025 10:14:03 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v7]
In-Reply-To: <0NspRaxKl7hw7EXaUj1M9tj361lBf2HKWK4M0wTe_p0=.9fbf844f-2745-46d5-897b-db3ae2f927b5@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <0NspRaxKl7hw7EXaUj1M9tj361lBf2HKWK4M0wTe_p0=.9fbf844f-2745-46d5-897b-db3ae2f927b5@github.com>
Message-ID: <0q0Rj8BkqAPxgHXnZtp2Vt6jre3X_EhsDG_woweBqfQ=.408033bc-d1a1-4f93-9e6e-3f1428cfeb30@github.com>

On Mon, 19 May 2025 21:47:14 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 incrementally with one additional commit since the last revision:
> 
>   field renamed

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

> 278:     void addFreeTypeListener(List<Type> types, FreeTypeListener ftl) {
> 279:         List<Type> myFreeVars = freeVarsIn(types);
> 280:         if (parentIC == null) {

I'm not sure I get this. In the sense: I get what the code is doing, but I'm not sure I understand why it's needed. E.g. the problem we're trying to solve is when an outer method has some inference variables that have not been propagated. This means that when the outer inference context is solved, calling `asInstTypes` on that outer context won't replace all the types. But your new patch to `asInstTypes` collects (correctly) all the inference variables from all parent contexts -- and uses those to do the type subst. Isn't that enough?

I'm a bit surprised that we also need to be picky when adding listeners -- as I'd assume that once the outer inference context is solved, all the nested inference contexts will also be solved too?

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

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

From vromero at openjdk.org  Tue May 20 14:06:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 May 2025 14:06:12 GMT
Subject: RFR: 8325859: potential information loss during type inference
 [v8]
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: <RqyAapLaZefCaNyyeNI0jpKtRUi4qvDTDDW-DV4Ti3k=.82943f7d-cf9e-4881-9029-7492166e4a60@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:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25011/files
  - new: https://git.openjdk.org/jdk/pull/25011/files/8922570a..aac9fee5

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

  Stats: 17 lines in 1 file changed: 0 ins; 16 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 mcimadamore at openjdk.org  Tue May 20 14:12:05 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 May 2025 14:12:05 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v8]
In-Reply-To: <RqyAapLaZefCaNyyeNI0jpKtRUi4qvDTDDW-DV4Ti3k=.82943f7d-cf9e-4881-9029-7492166e4a60@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <RqyAapLaZefCaNyyeNI0jpKtRUi4qvDTDDW-DV4Ti3k=.82943f7d-cf9e-4881-9029-7492166e4a60@github.com>
Message-ID: <Oy5vRcqsncIJFdL_RvDHpsKNbQ5of_R7zwpCEXkC_rc=.c724b4f3-ddb0-4bcc-a710-215b4d0a4fef@github.com>

On Tue, 20 May 2025 14:06:12 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 incrementally with one additional commit since the last revision:
> 
>   addressing review comments

The new simpler patch looks great! Thanks for persevering!!!

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

> 571:     public String toString() {
> 572:         return "Inference vars: " + inferencevars + '\n' +
> 573:                "Undet vars: " + undetvars + '\n';

Optional: should this also print the parent?

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25011#pullrequestreview-2854369139
PR Review Comment: https://git.openjdk.org/jdk/pull/25011#discussion_r2098081186

From vromero at openjdk.org  Tue May 20 14:12:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 May 2025 14:12:06 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v8]
In-Reply-To: <Oy5vRcqsncIJFdL_RvDHpsKNbQ5of_R7zwpCEXkC_rc=.c724b4f3-ddb0-4bcc-a710-215b4d0a4fef@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <RqyAapLaZefCaNyyeNI0jpKtRUi4qvDTDDW-DV4Ti3k=.82943f7d-cf9e-4881-9029-7492166e4a60@github.com>
 <Oy5vRcqsncIJFdL_RvDHpsKNbQ5of_R7zwpCEXkC_rc=.c724b4f3-ddb0-4bcc-a710-215b4d0a4fef@github.com>
Message-ID: <kW4XTt-xtIhem4KLYR5kU4zLrc3zgSWVL219bG3bpXo=.2375790e-7927-46e9-aa7e-f6e8c8679220@github.com>

On Tue, 20 May 2025 14:07:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new simpler patch looks great! Thanks for persevering!!!

thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25011#issuecomment-2894577851

From vromero at openjdk.org  Tue May 20 14:38:41 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 May 2025 14:38:41 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v9]
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: <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@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:

  updating IC::toString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25011/files
  - new: https://git.openjdk.org/jdk/pull/25011/files/aac9fee5..8a20cb0d

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

  Stats: 5 lines in 1 file changed: 4 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  Tue May 20 14:38:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 May 2025 14:38:42 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v8]
In-Reply-To: <Oy5vRcqsncIJFdL_RvDHpsKNbQ5of_R7zwpCEXkC_rc=.c724b4f3-ddb0-4bcc-a710-215b4d0a4fef@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <RqyAapLaZefCaNyyeNI0jpKtRUi4qvDTDDW-DV4Ti3k=.82943f7d-cf9e-4881-9029-7492166e4a60@github.com>
 <Oy5vRcqsncIJFdL_RvDHpsKNbQ5of_R7zwpCEXkC_rc=.c724b4f3-ddb0-4bcc-a710-215b4d0a4fef@github.com>
Message-ID: <pAHGiHQU-pjfiwWYXJ0cHchxyX0wHWqcynkLrXiKwHI=.3004811d-59a5-4526-8236-74dd557eb4b8@github.com>

On Tue, 20 May 2025 14:07:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 573:
> 
>> 571:     public String toString() {
>> 572:         return "Inference vars: " + inferencevars + '\n' +
>> 573:                "Undet vars: " + undetvars + '\n';
> 
> Optional: should this also print the parent?

sure, done

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

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

From vromero at openjdk.org  Tue May 20 14:38:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 May 2025 14:38:42 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v9]
In-Reply-To: <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
Message-ID: <IAnDaPTBPbV_rVfGdn9LVOv0GXShypGXi7eH5IOZN9Q=.54f6a0f4-b4c1-4f4c-af3f-9fe485f2a0e5@github.com>

On Tue, 20 May 2025 14:35:04 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 incrementally with one additional commit since the last revision:
> 
>   updating IC::toString

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

> 573:                "Undet vars: " + undetvars + '\n';
> 574:         if (parentIC != null) {
> 575:             result += "\nParent : " + parentIC.toString();

I was thinking about using an indentation, probably with a toString overload, but if the chain of parents gets long then one will need to scroll to the sides to see them all

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

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

From vromero at openjdk.org  Tue May 20 15:56:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 May 2025 15:56:56 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity [v2]
In-Reply-To: <iqp6MZZgFYpvuTDd372qTseKyYX35wgbUNMAUXtSXto=.3718c36a-4cd8-4a78-8b9c-46972b4e03c1@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
 <iqp6MZZgFYpvuTDd372qTseKyYX35wgbUNMAUXtSXto=.3718c36a-4cd8-4a78-8b9c-46972b4e03c1@github.com>
Message-ID: <BMQr36GrCdeG8f6XZEi0421y87wjWRwxOfnmXEU8Cl8=.8fcb035c-1fea-4d9a-8990-f9216ba143f0@github.com>

On Mon, 19 May 2025 22:54:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
>> 
>> Important parts of the patch:
>> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
>> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
>> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
>> - for type variables, the synthetic annotation is filtered out in the API method
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Cleanup.
>  - Fixing build
>  - Adjustments, annotation filtering, adding more tests
>  - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - fixing bugs, removing dead code
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/e7ce661a...daed20ff

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2854765603

From acobbs at openjdk.org  Tue May 20 15:59:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 20 May 2025 15:59:35 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v4]
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: <tx-yJjsEjji7Q3vhr-BvoqJi77m3vzMtDrUFUueDO8w=.31024c54-127a-4686-bc92-24de299b3c59@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 four commits:

 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Update man page.
 - 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=03
  Stats: 196 lines in 13 files changed: 140 ins; 34 del; 22 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 lancea at openjdk.org  Tue May 20 16:07:57 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 May 2025 16:07:57 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
Message-ID: <tS9_tBI1KCYr4Z4NS2IrniR-gGG2Gat9z2S1-Rt_Wmc=.0123a91e-3a05-4b7e-bef0-c18aa0eed8b3@github.com>

On Sat, 17 May 2025 01:27:38 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:
> 
>   Address review feedback

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

> 283: \                             versions.\n\
> 284: \                             Warn if there are duplicate or invalid file names
> 285: 

Would probably be clearer if:

> main.help.opt.main.validate=\
> \      --validate             Validate the contents of the jar archive. This option: \n\
> \                              - Validates that the API exported by a multi-release\n\
> \                                 jar archive is consistent across all different release\n\
> \                                 versions.`
> \                              - Issues a warning if there are invalid or duplicate file names
>

src/jdk.jartool/share/man/jar.md line 222:

> 220: ## Integrity of a jar Archive
> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
> 222: other than the `jar` command. The `--validate` option performs the following integrity checks:

I would  simplify to:

The `--validate` option  may be used to perform the following integrity checks against a jar archive:

src/jdk.jartool/share/man/jar.md line 239:

> 237: 
> 238: Check with the developer to ensure the jar archive integrity when warnings observed after using
> 239: the `--validate` option.

I don't see a need for this last sentence given the last sentence in the paragraph above.

I would not know who "the developer" is (though the same could be said of "the original source of the jar file"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098323828
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098341490
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098346535

From mcimadamore at openjdk.org  Tue May 20 16:30:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 May 2025 16:30:55 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v9]
In-Reply-To: <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
Message-ID: <D5Tiy1ob3eCSl5n-cr4UySBbn3B-k22DIrL6_JZVSWs=.1419097c-46cd-4d7c-b307-e0b97b09c555@github.com>

On Tue, 20 May 2025 14:38:41 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 incrementally with one additional commit since the last revision:
> 
>   updating IC::toString

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25011#pullrequestreview-2854873744

From mcimadamore at openjdk.org  Tue May 20 16:30:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 May 2025 16:30:59 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v9]
In-Reply-To: <IAnDaPTBPbV_rVfGdn9LVOv0GXShypGXi7eH5IOZN9Q=.54f6a0f4-b4c1-4f4c-af3f-9fe485f2a0e5@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
 <IAnDaPTBPbV_rVfGdn9LVOv0GXShypGXi7eH5IOZN9Q=.54f6a0f4-b4c1-4f4c-af3f-9fe485f2a0e5@github.com>
Message-ID: <EmOsaZcebWrtxsq2SYyPE0K-ng7ifoxbbuqQ3Vb3ISs=.62a86db8-01b0-4b71-9358-cbb2f16ed1c5@github.com>

On Tue, 20 May 2025 14:35:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updating IC::toString
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 575:
> 
>> 573:                "Undet vars: " + undetvars + '\n';
>> 574:         if (parentIC != null) {
>> 575:             result += "\nParent : " + parentIC.toString();
> 
> I was thinking about using an indentation, probably with a toString overload, but if the chain of parents gets long then one will need to scroll to the sides to see them all

I see what you mean. The fact that the string representation is multiline, but also recursively used leads to issues -- because every time we do a `\n` we will break indentation. It's not terribly important. Another possibility would be to list the "other variables" (e.g. the ones that appear in the parent contexts), without listing all the parent contexts explicitly. That should scale a bit better.

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

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

From henryjen at openjdk.org  Tue May 20 16:57:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 16:57:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
Message-ID: <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>

On Sat, 17 May 2025 01:27:38 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:
> 
>   Address review feedback

src/jdk.jartool/share/man/jar.md line 235:

> 233: 
> 234: The jar tool will return a status code of 0 if there were no integrity issues encountered and a
> 235: status code of 1 an issue was found. When an integrity issue is reported, it will often require

I am wondering if we should not explicitly said status code of 1 to be more flexible.
s/status code of 1/non-zero status code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098459726

From henryjen at openjdk.org  Tue May 20 17:32:15 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 17:32:15 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v10]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <ZOjTb3XvEzR6RtDdwt1tWswMPOgFs9_xp_tmieHdIyk=.8c5ac78d-ccae-40fd-8823-2e56914ed042@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:

  Adapt review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/da4a9139..0caecfcd

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

  Stats: 12 lines in 2 files changed: 2 ins; 2 del; 8 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 lancea at openjdk.org  Tue May 20 18:03:54 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 May 2025 18:03:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
Message-ID: <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>

On Tue, 20 May 2025 16:55:44 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code

Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098574945

From henryjen at openjdk.org  Tue May 20 18:16:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 18:16:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
Message-ID: <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>

On Tue, 20 May 2025 18:00:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.jartool/share/man/jar.md line 235:
>> 
>>> 233: 
>>> 234: The jar tool will return a status code of 0 if there were no integrity issues encountered and a
>>> 235: status code of 1 an issue was found. When an integrity issue is reported, it will often require
>> 
>> I am wondering if we should not explicitly said status code of 1 to be more flexible.
>> s/status code of 1/non-zero status code
>
>> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code
> 
> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...

We report all issues, not just one, so that would also involve what do we prioritized for the exit code...
In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order.
Also the process could fail with other issues like I/O or non-zip file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098596892

From lancea at openjdk.org  Tue May 20 18:33:53 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 May 2025 18:33:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
Message-ID: <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>

On Tue, 20 May 2025 18:14:15 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>>> I am wondering if we should not explicitly said status code of 1 to be more flexible. s/status code of 1/non-zero status code
>> 
>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...
>
> We report all issues, not just one, so that would also involve what do we prioritized for the exit code...
> In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order.
> Also the process could fail with other issues like I/O or non-zip file.

Yes I understand and currently we have no documentation as to what the return values might be.  An inconsistency in the order should also be 1 based we only return a 0 if there are no issues.  Any warning should be treated the same

My point is that it is worth considering with these changes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098625246

From vromero at openjdk.org  Tue May 20 19:31:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 20 May 2025 19:31:55 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v9]
In-Reply-To: <EmOsaZcebWrtxsq2SYyPE0K-ng7ifoxbbuqQ3Vb3ISs=.62a86db8-01b0-4b71-9358-cbb2f16ed1c5@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
 <IAnDaPTBPbV_rVfGdn9LVOv0GXShypGXi7eH5IOZN9Q=.54f6a0f4-b4c1-4f4c-af3f-9fe485f2a0e5@github.com>
 <EmOsaZcebWrtxsq2SYyPE0K-ng7ifoxbbuqQ3Vb3ISs=.62a86db8-01b0-4b71-9358-cbb2f16ed1c5@github.com>
Message-ID: <RSTEbhAaZZWBu3dEUShG4MBpSA0jmijItulMfukG42g=.71dbeed2-b744-4180-9256-e3ba906856b7@github.com>

On Tue, 20 May 2025 16:25:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java line 575:
>> 
>>> 573:                "Undet vars: " + undetvars + '\n';
>>> 574:         if (parentIC != null) {
>>> 575:             result += "\nParent : " + parentIC.toString();
>> 
>> I was thinking about using an indentation, probably with a toString overload, but if the chain of parents gets long then one will need to scroll to the sides to see them all
>
> I see what you mean. The fact that the string representation is multiline, but also recursively used leads to issues -- because every time we do a `\n` we will break indentation. It's not terribly important. Another possibility would be to list the "other variables" (e.g. the ones that appear in the parent contexts), without listing all the parent contexts explicitly. That should scale a bit better.

you mean showing only the variables of the adjacent parent context and ignoring the rest of the chain?

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

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

From henryjen at openjdk.org  Tue May 20 22:02:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 20 May 2025 22:02:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
Message-ID: <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>

On Tue, 20 May 2025 18:30:46 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> We report all issues, not just one, so that would also involve what do we prioritized for the exit code...
>> In general, a non-zero code for invalid jar needs attention. We still 0 with unmatched order.
>> Also the process could fail with other issues like I/O or non-zip file.
>
> Yes I understand and currently we have no documentation as to what the return values might be.  An inconsistency in the order should also be 1 based we only return a 0 if there are no issues.  Any warning should be treated the same
> 
> My point is that it is worth considering with these changes

Point taken. For documentation wise, I don't think it's necessary to specify at this point.
For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2098943146

From jlahoda at openjdk.org  Wed May 21 06:19:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 May 2025 06:19:36 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity [v3]
In-Reply-To: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
Message-ID: <VwjvT5xaEjm_4ISKdAr7ZQCK1NFKw4WRtEfuvJnZiOs=.45963654-88ec-48b4-a415-84b690b219bf@github.com>

> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
> 
> Important parts of the patch:
> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API method

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

 - Merge remote-tracking branch 'upstream/master' into JDK-8356894
 - Cleanup.
 - Fixing build
 - Adjustments, annotation filtering, adding more tests
 - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556
 - Merge branch 'master' into JDK-8354556
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - additional changes from Archie
 - removing dead code
 - integrating code from Archie
 - ... and 32 more: https://git.openjdk.org/jdk/compare/1a97eb42...696cd663

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

Changes: https://git.openjdk.org/jdk/pull/25232/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25232&range=02
  Stats: 543 lines in 12 files changed: 513 ins; 14 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25232/head:pull/25232

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

From abimpoudis at openjdk.org  Wed May 21 06:47:58 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 21 May 2025 06:47:58 GMT
Subject: Integrated: 8347530: Improve error message with invalid permits
 clauses
In-Reply-To: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>
References: <baNFEJq5TNv7v1VAarDFF08nXlWMjwPXY62RVUe77Vw=.4a0c89e8-fbbb-44d2-9243-35b8c1bf7bfd@github.com>
Message-ID: <wx_9wdre063aOS2zYD2g2kiFjC9GJTMvYPsTspRu5is=.37b7c8ff-61b2-4ac0-b26c-d4804ba26c45@github.com>

On Thu, 15 May 2025 16:15:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Currently we report one kind of error message (`subclass {0} must extend sealed class`) when there is a compile-type error in cases like the following:
> 
> 
> sealed class C0 permits S0 {}
> class S0 {}  
> 
> 
> This PR proposes to improve error reporting since there are other kinds of declarations that can also participate in sealed hierarchies like records, enums and interfaces.

This pull request has now been integrated.

Changeset: 50a7755f
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50a7755fa45529966373b58652c15975157ab846
Stats:     78 lines in 7 files changed: 73 ins; 0 del; 5 mod

8347530: Improve error message with invalid permits clauses

Reviewed-by: jlahoda

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

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

From mcimadamore at openjdk.org  Wed May 21 09:25:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 May 2025 09:25:54 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v9]
In-Reply-To: <RSTEbhAaZZWBu3dEUShG4MBpSA0jmijItulMfukG42g=.71dbeed2-b744-4180-9256-e3ba906856b7@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
 <IAnDaPTBPbV_rVfGdn9LVOv0GXShypGXi7eH5IOZN9Q=.54f6a0f4-b4c1-4f4c-af3f-9fe485f2a0e5@github.com>
 <EmOsaZcebWrtxsq2SYyPE0K-ng7ifoxbbuqQ3Vb3ISs=.62a86db8-01b0-4b71-9358-cbb2f16ed1c5@github.com>
 <RSTEbhAaZZWBu3dEUShG4MBpSA0jmijItulMfukG42g=.71dbeed2-b744-4180-9256-e3ba906856b7@github.com>
Message-ID: <Sb9RIFBMgdsg9Z6KYfEQZR1BhYTihsCVO3I8VwV7igI=.110ff0a7-ae5a-47bd-a088-8a3f600b81ce@github.com>

On Tue, 20 May 2025 19:27:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> you mean showing only the variables of the adjacent parent context and ignoring the rest of the chain?

Yeah -- but perhaps that's not very helpful as some of those variables will have same name even if different... Just leave it for now :-)

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

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

From abimpoudis at openjdk.org  Wed May 21 10:02:15 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 21 May 2025 10:02:15 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
Message-ID: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>

javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:


static abstract class Getters<T> {
    abstract class Getter {
        abstract T get();
    }
}

static class Usage<T, G extends Getters<T>> {
    public T test(G.Getter getter) {
        return getter.get(); // incompatible types: Object cannot be converted to T
    }
}


It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.

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

Commit messages:
 - 8343580: Type error with inner classes of generic classes in functions generic by outer

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

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

From vromero at openjdk.org  Wed May 21 11:31:08 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 May 2025 11:31:08 GMT
Subject: RFR: 8325859: Potential information loss during type inference
 [v9]
In-Reply-To: <Sb9RIFBMgdsg9Z6KYfEQZR1BhYTihsCVO3I8VwV7igI=.110ff0a7-ae5a-47bd-a088-8a3f600b81ce@github.com>
References: <R64n-HpBRGSIq76DroRJk_YiyLu1ChHnzXBbg5wlDEk=.c0c6140d-ccd7-4361-930d-a19dfabe5105@github.com>
 <u1RZudEldelgmFlN7EPmYxAZixWPq7btRYZ2SoWRXEs=.2f489750-2dd0-4552-8506-e525aca1c30f@github.com>
 <IAnDaPTBPbV_rVfGdn9LVOv0GXShypGXi7eH5IOZN9Q=.54f6a0f4-b4c1-4f4c-af3f-9fe485f2a0e5@github.com>
 <EmOsaZcebWrtxsq2SYyPE0K-ng7ifoxbbuqQ3Vb3ISs=.62a86db8-01b0-4b71-9358-cbb2f16ed1c5@github.com>
 <RSTEbhAaZZWBu3dEUShG4MBpSA0jmijItulMfukG42g=.71dbeed2-b744-4180-9256-e3ba906856b7@github.com>
 <Sb9RIFBMgdsg9Z6KYfEQZR1BhYTihsCVO3I8VwV7igI=.110ff0a7-ae5a-47bd-a088-8a3f600b81ce@github.com>
Message-ID: <wsyO1LDyH1jKoOvI4sOUdHjTJiVEbRBaC9ED0tC009Q=.f9ceec13-8d6d-4b65-b1f4-e54a7f2dfabf@github.com>

On Wed, 21 May 2025 09:23:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> you mean showing only the variables of the adjacent parent context and ignoring the rest of the chain?
>
>> you mean showing only the variables of the adjacent parent context and ignoring the rest of the chain?
> 
> Yeah -- but perhaps that's not very helpful as some of those variables will have same name even if different... Just leave it for now :-)

right, ship sailing, all tests are green, thanks!

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

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

From vromero at openjdk.org  Wed May 21 11:31:10 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 May 2025 11:31:10 GMT
Subject: Integrated: 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: <cFauIsgcKnlPseH1uZ3dHIyFyIAJK5dlRvIeH3uuWJ4=.7033cd4a-3223-4a65-8053-48f6ef7ef4a9@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

This pull request has now been integrated.

Changeset: a4f66f54
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a4f66f5439f7fe585bd3664b7f2ceec23234e554
Stats:     77 lines in 3 files changed: 73 ins; 0 del; 4 mod

8325859: Potential information loss during type inference

Reviewed-by: mcimadamore

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

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

From jpai at openjdk.org  Wed May 21 12:49:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 12:49:55 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
Message-ID: <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>

On Tue, 20 May 2025 22:00:39 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Yes I understand and currently we have no documentation as to what the return values might be.  An inconsistency in the order should also be 1 based we only return a 0 if there are no issues.  Any warning should be treated the same
>> 
>> My point is that it is worth considering with these changes
>
> Point taken. For documentation wise, I don't think it's necessary to specify at this point.
> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

Hello Lance/Henry,

> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...

I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. 

Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100203673

From jpai at openjdk.org  Wed May 21 13:00:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 13:00:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
 <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
Message-ID: <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>

On Wed, 21 May 2025 12:47:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Point taken. For documentation wise, I don't think it's necessary to specify at this point.
>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
>
> Hello Lance/Henry,
> 
>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...
> 
> I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. 
> 
> Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures.

> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it).

Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100232060

From lancea at openjdk.org  Wed May 21 14:02:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 14:02:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
 <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
 <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>
Message-ID: <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com>

On Wed, 21 May 2025 12:58:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Lance/Henry,
>> 
>>> Well, now would be a good time to consider say a value of 2 for duplicates, 3 for invalid names, etc...
>> 
>> I think from a specification point of view, for this current PR, we should only specify that the `--validate` operation returns a non-zero exit code when the `--validate` operation identifies any issues in the JAR file or the validation operation itself runs into some error. For the latter, where the operation itself runs into an error, we could explicitly state that the exit code will be `-1` (for example). For the case where the validate operation has identified issues in the JAR file, I think we should just return a single consistent non-zero code, irrespective of which validations failed. 
>> 
>> Using a separate exit code for different validation failures I think would make it hard to maintain as the number of validations increase in future and when more than one validation failure happens in the JAR file. What we could however consider is specifying the exact error message (or error string, imagine `ERR-12345` for duplicate entry names) that get reported for these individual validation failures.
>
>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
> 
> For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it).
> 
> Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation.

> Point taken. For documentation wise, I don't think it's necessary to specify at this point. For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.

I am OK to currently specify as non-zero, it is a discussion that can be continued as to what if anything more to do (as Jai mentions)

Any warnings should result in a non-zero for a return code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100377057

From liach at openjdk.org  Wed May 21 14:31:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 14:31:54 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
Message-ID: <5elv0wD5NMDuNYUac_mx8GWfgGwttZvw88DXhgiVNNU=.0acb31fd-1f70-4157-ac30-c51e22e71e9c@github.com>

On Wed, 21 May 2025 09:55:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
> 
> 
> static abstract class Getters<T> {
>     abstract class Getter {
>         abstract T get();
>     }
> }
> 
> static class Usage<T, G extends Getters<T>> {
>     public T test(G.Getter getter) {
>         return getter.get(); // incompatible types: Object cannot be converted to T
>     }
> }
> 
> 
> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.

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

> 1153:             if (allparams_field == null) {
> 1154:                 Type enclosingType = getEnclosingType();
> 1155:                 if (!enclosingType.isUnbound() && enclosingType.getUpperBound() instanceof Type t) {

Shouldn't this be a while loop in case you have G bounded by another type variable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2100448606

From abimpoudis at openjdk.org  Wed May 21 14:36:54 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 21 May 2025 14:36:54 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <5elv0wD5NMDuNYUac_mx8GWfgGwttZvw88DXhgiVNNU=.0acb31fd-1f70-4157-ac30-c51e22e71e9c@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <5elv0wD5NMDuNYUac_mx8GWfgGwttZvw88DXhgiVNNU=.0acb31fd-1f70-4157-ac30-c51e22e71e9c@github.com>
Message-ID: <ATQCEO4A3hGySDYeGc3Nr2xqwguJhfE42j2yqMoOQsY=.82d0bcf3-b11d-4fe7-a718-b1c058feedc5@github.com>

On Wed, 21 May 2025 14:28:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
>> 
>> 
>> static abstract class Getters<T> {
>>     abstract class Getter {
>>         abstract T get();
>>     }
>> }
>> 
>> static class Usage<T, G extends Getters<T>> {
>>     public T test(G.Getter getter) {
>>         return getter.get(); // incompatible types: Object cannot be converted to T
>>     }
>> }
>> 
>> 
>> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1155:
> 
>> 1153:             if (allparams_field == null) {
>> 1154:                 Type enclosingType = getEnclosingType();
>> 1155:                 if (!enclosingType.isUnbound() && enclosingType.getUpperBound() instanceof Type t) {
> 
> Shouldn't this be a while loop in case you have G bounded by another type variable?

You mean an intersection type? I think you are right. So do you have something like the following, in mind?


static class Usage<T, G extends Getters<T> && SomethingElse> {
    public T test(G.Getter getter) {
        return getter.get(); // incompatible types: Object cannot be converted to T
    }
}


`G` would be raw if `SomethingElse` is raw if its definition is parametric, e.g. `interface SomethingElse<T>` and not raw if its definition is really `interface SomethingElse`. Did you mean that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2100460377

From liach at openjdk.org  Wed May 21 14:40:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 14:40:52 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <ATQCEO4A3hGySDYeGc3Nr2xqwguJhfE42j2yqMoOQsY=.82d0bcf3-b11d-4fe7-a718-b1c058feedc5@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <5elv0wD5NMDuNYUac_mx8GWfgGwttZvw88DXhgiVNNU=.0acb31fd-1f70-4157-ac30-c51e22e71e9c@github.com>
 <ATQCEO4A3hGySDYeGc3Nr2xqwguJhfE42j2yqMoOQsY=.82d0bcf3-b11d-4fe7-a718-b1c058feedc5@github.com>
Message-ID: <NcnFT2KVkBh8yE-VnHNszbdodQiBdVX56EDVusTibX4=.36832cb8-6b13-4205-bbbb-959a4ec6e4b6@github.com>

On Wed, 21 May 2025 14:34:12 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1155:
>> 
>>> 1153:             if (allparams_field == null) {
>>> 1154:                 Type enclosingType = getEnclosingType();
>>> 1155:                 if (!enclosingType.isUnbound() && enclosingType.getUpperBound() instanceof Type t) {
>> 
>> Shouldn't this be a while loop in case you have G bounded by another type variable?
>
> You mean an intersection type? I think you are right. So, do you have something like the following, in mind?
> 
> 
> static class Usage<T, G extends Getters<T> && SomethingElse> {
>     public T test(G.Getter getter) {
>         return getter.get();
>     }
> }
> 
> 
> `G` would be raw if `SomethingElse` is raw if its definition is parametric, e.g. `interface SomethingElse<T>` and not raw if its definition is really `interface SomethingElse`. Did you mean that?

Nah, I was more thinking about

<T, U extends Getters<T>, G extends U>

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2100469586

From abimpoudis at openjdk.org  Wed May 21 14:48:57 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 21 May 2025 14:48:57 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <NcnFT2KVkBh8yE-VnHNszbdodQiBdVX56EDVusTibX4=.36832cb8-6b13-4205-bbbb-959a4ec6e4b6@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <5elv0wD5NMDuNYUac_mx8GWfgGwttZvw88DXhgiVNNU=.0acb31fd-1f70-4157-ac30-c51e22e71e9c@github.com>
 <ATQCEO4A3hGySDYeGc3Nr2xqwguJhfE42j2yqMoOQsY=.82d0bcf3-b11d-4fe7-a718-b1c058feedc5@github.com>
 <NcnFT2KVkBh8yE-VnHNszbdodQiBdVX56EDVusTibX4=.36832cb8-6b13-4205-bbbb-959a4ec6e4b6@github.com>
Message-ID: <i7BkrAyIwCOHUB70-fKmH9T9krtiapf_b1HZa_SvY5E=.0197c718-f284-4d82-9a1c-7ef225edc4f4@github.com>

On Wed, 21 May 2025 14:38:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> You mean an intersection type? I think you are right. So, do you have something like the following, in mind?
>> 
>> 
>> static class Usage<T, G extends Getters<T> && SomethingElse> {
>>     public T test(G.Getter getter) {
>>         return getter.get();
>>     }
>> }
>> 
>> 
>> `G` would be raw if `SomethingElse` is raw if its definition is parametric, e.g. `interface SomethingElse<T>` and not raw if its definition is really `interface SomethingElse`. Did you mean that?
>
> Nah, I was more thinking about
> 
> <T, U extends Getters<T>, G extends U>

I think that wouldn't be a problem.

In the original example we try to type-check `G.Getter`. 
With your example `<T, U extends Getters<T>, G extends U>` we would type check `G.Getter` for validity and then `U.Getter`. But maybe I am wrong. 

In any case, both cases deserve corresponding test cases and correct treatment. Thanks @liach. Will update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2100489041

From liach at openjdk.org  Wed May 21 14:53:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 14:53:51 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <i7BkrAyIwCOHUB70-fKmH9T9krtiapf_b1HZa_SvY5E=.0197c718-f284-4d82-9a1c-7ef225edc4f4@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <5elv0wD5NMDuNYUac_mx8GWfgGwttZvw88DXhgiVNNU=.0acb31fd-1f70-4157-ac30-c51e22e71e9c@github.com>
 <ATQCEO4A3hGySDYeGc3Nr2xqwguJhfE42j2yqMoOQsY=.82d0bcf3-b11d-4fe7-a718-b1c058feedc5@github.com>
 <NcnFT2KVkBh8yE-VnHNszbdodQiBdVX56EDVusTibX4=.36832cb8-6b13-4205-bbbb-959a4ec6e4b6@github.com>
 <i7BkrAyIwCOHUB70-fKmH9T9krtiapf_b1HZa_SvY5E=.0197c718-f284-4d82-9a1c-7ef225edc4f4@github.com>
Message-ID: <3bbSV-bgKQZ2Z1hfShKVvfKOIMZBX-9Vp2yonIgmZIw=.d137f0ba-7a3f-4a53-84ff-40479ee66e89@github.com>

On Wed, 21 May 2025 14:46:35 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Nah, I was more thinking about
>> 
>> <T, U extends Getters<T>, G extends U>
>
> I think that wouldn't be a problem.
> 
> In the original example we try to type-check `G.Getter`. 
> With your example `<T, U extends Getters<T>, G extends U>` we would type check `G.Getter` for validity and then `U.Getter`. But maybe I am wrong. 
> 
> In any case, both cases deserve corresponding test cases and correct treatment. Thanks @liach. Will update.

You are right. I missed that this call `allparams` is already recursive!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2100494812

From abimpoudis at openjdk.org  Wed May 21 14:53:52 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 21 May 2025 14:53:52 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <3bbSV-bgKQZ2Z1hfShKVvfKOIMZBX-9Vp2yonIgmZIw=.d137f0ba-7a3f-4a53-84ff-40479ee66e89@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <5elv0wD5NMDuNYUac_mx8GWfgGwttZvw88DXhgiVNNU=.0acb31fd-1f70-4157-ac30-c51e22e71e9c@github.com>
 <ATQCEO4A3hGySDYeGc3Nr2xqwguJhfE42j2yqMoOQsY=.82d0bcf3-b11d-4fe7-a718-b1c058feedc5@github.com>
 <NcnFT2KVkBh8yE-VnHNszbdodQiBdVX56EDVusTibX4=.36832cb8-6b13-4205-bbbb-959a4ec6e4b6@github.com>
 <i7BkrAyIwCOHUB70-fKmH9T9krtiapf_b1HZa_SvY5E=.0197c718-f284-4d82-9a1c-7ef225edc4f4@github.com>
 <3bbSV-bgKQZ2Z1hfShKVvfKOIMZBX-9Vp2yonIgmZIw=.d137f0ba-7a3f-4a53-84ff-40479ee66e89@github.com>
Message-ID: <-t1NGE-mCpUAhF0TQS6ZQHQigcNGvjbO5UvG9kK2oho=.1bcc9c14-613f-4189-993e-df755a3ab9f6@github.com>

On Wed, 21 May 2025 14:49:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I think that wouldn't be a problem.
>> 
>> In the original example we try to type-check `G.Getter`. 
>> With your example `<T, U extends Getters<T>, G extends U>` we would type check `G.Getter` for validity and then `U.Getter`. But maybe I am wrong. 
>> 
>> In any case, both cases deserve corresponding test cases and correct treatment. Thanks @liach. Will update.
>
> You are right. I missed that this call `allparams` is already recursive!

Maybe I am wrong. We will figure it with more tests. Your comment was very useful I think. Thank you!!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2100498582

From henryjen at openjdk.org  Wed May 21 15:24:56 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 21 May 2025 15:24:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v9]
In-Reply-To: <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <-qdStu3ePB_Xsp-VLXIrjFjyAEo_fBWLECBRN5eErDg=.9a5a3ce6-de03-4ac7-b958-4fabe0fb087d@github.com>
 <IGieWxsGRLqRnsp9Mw4eQ89d0JjeqZMSMmZfynuwRPY=.a2871ae5-e566-4b2c-a099-532042e1f8b9@github.com>
 <a9gxvVVTB3YrO1wkyPhYqmBo_QW_izPnhuapPmz8vnQ=.d3febb71-9d1b-4060-8660-cbcdb701c102@github.com>
 <9oDEkaJb2RR58k_Z-mQV3k_GwlFTLe4JmSD_2S7fiaA=.d5b468fb-4410-4205-8235-daae99fedf12@github.com>
 <PphfDWen7gKIUoGPV2NnZ2M7_LB47Rd2VmpzTnKDpGk=.5415e56a-eb35-4c65-bca5-692457061f11@github.com>
 <PsoyPBx8Ayu9MaNQoao_JYd6OLb8Omp7TuSJQUa9P5k=.de0888a1-ac2d-4691-ad0a-80b16d29f69e@github.com>
 <Ax8PvcYBimeOnK_3CrsKLOXKpEWqb2ISH-IYCPjvPHc=.f77d4095-d575-42b6-84a8-b46704d81912@github.com>
 <h8HAePVzWzxJTsr6oiT7gEAuBNdIWGwGwLm_Htd50Ws=.09efd46e-cd36-43b1-a6f0-1f18275edbac@github.com>
 <1k_uCX5TM9o-ewEsAvEeG16VPUqRo9BwnwPOQdJuqYA=.e2930b9d-89c9-4664-b663-8434fec12718@github.com>
Message-ID: <RkcTG-90KW50Fxpjqe2jJkW9XUq4VVhs21GlGgEgPQM=.6a4ef3aa-0b37-42dc-94d0-0d83b847802c@github.com>

On Wed, 21 May 2025 14:00:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
>> 
>> For the `jar --validate` operation, it would be useful to not just warn (and thus exit with a non-zero exit code) for issues that violate the ZIP or JAR specification, but also for inconsistencies and uncommon JAR contents that might cause some unexpected behaviour within the platform runtime. This helps with identifying and analyzing such unexpected issues in the JAR (but not strictly violations of any specification) even before that JAR gets used in the platform runtime. This is no different for the duplicate entries in the JAR file, for which we issue warnings even if the ZIP specification explicitly allows it (and the JAR specification doesn't make a mention of it).
>> 
>> Based on some experiments we have run, it's not very common for a JAR file to have a different order in CEN as compared to LOC, so I think any JAR file that has a different order between these structures should result in a warning (and thus a non-zero exit code) from the validate operation.
>
>> Point taken. For documentation wise, I don't think it's necessary to specify at this point. For the inconsistent order in the LOC and CEN, we can treat it as invalid, I chose not to because that's not a violation, but if we do extend that as specification for JAR file format, then we can change that to invalid and non-zero exit code.
> 
> I am OK to currently specify as non-zero, it is a discussion that can be continued as to what if anything more to do (as Jai mentions)
> 
> Any warnings should result in a non-zero for a return code.

OK, I'll update the PR to consider inconsistent order to be invalid even though it won't cause issue but indeed a sign that's not created by the official `jar` tool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100570620

From jlahoda at openjdk.org  Wed May 21 15:35:03 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 May 2025 15:35:03 GMT
Subject: RFR: 8357361: Exception when compiling switch expression with inferred
 type.
Message-ID: <0f92-CEJGKj0HqWwtFnxMk-9Hwivak74-kJT-MPPzhk=.43f8e19b-4ad1-41a0-ab8a-fc0e017537cf@github.com>

There's a missing erasure in `TransTypes`, which eventually leads to an attempt to cast to a captured wildcard type (for the case shown in the bug report), which cannot be done. (In this case, `TransTypes` will report an error.)

(There's a unused/unnecessary code in the close vicinity of the added erasure, and a similar code in `visitSwitch`. I could resist deleting that unnecessary code.)

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

Commit messages:
 - 8357361: Exception when compiling switch expression with inferred type.

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

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

From henryjen at openjdk.org  Wed May 21 15:49:29 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 21 May 2025 15:49:29 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@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:

  Mismatched order is considered invalid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/0caecfcd..b0df54d2

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

  Stats: 24 lines in 2 files changed: 16 ins; 5 del; 3 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 jpai at openjdk.org  Wed May 21 16:35:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:35:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <aWjWvMnIEOc4h5tngG9Xl138XUGVTRaZiFj5lyhb6bo=.2634cace-d6b2-4119-8494-3274b25a8662@github.com>

On Wed, 21 May 2025 15:49:29 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:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/man/jar.md line 106:

> 104:     overwriting (replacing) earlier copies unless -k is specified.
> 105: 
> 106: `-d` or `--describe-module`

I'm going to start with some trivial nits and other review comments. The copyright year on this file will need a update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100728423

From jpai at openjdk.org  Wed May 21 16:44:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:44:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>

On Wed, 21 May 2025 15:49:29 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:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/man/jar.md line 110:

> 108: 
> 109: `--validate`
> 110: :   Validate the contents of the jar archive.

Validate the contents of the JAR file.

src/jdk.jartool/share/man/jar.md line 111:

> 109: `--validate`
> 110: :   Validate the contents of the jar archive.
> 111:     See `Integrity of a jar Archive` section below for more details.

In recent times, both in code and in API specification, we have been using `JAR` and `ZIP` (upper case) to refer to the JAR/ZIP files. For the tool itself, using the lower case jar is appropriate. Furthermore, JAR itself means Java archive, so I think we can remove the "Archive" word from that sentence. Perhaps this (and the corresponding section) should be "Integrity of a JAR file".

src/jdk.jartool/share/man/jar.md line 221:

> 219: 
> 220: ## Integrity of a jar Archive
> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools

Nit - As a JAR file is based on ZIP format, it is possible to create a JAR file ...

src/jdk.jartool/share/man/jar.md line 223:

> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
> 222: other than the `jar` command. The --validate option may be used to perform the following
> 223: integrity checks against a jar archive:

Nit - "integrity checks against a JAR file:"

src/jdk.jartool/share/man/jar.md line 225:

> 223: integrity checks against a jar archive:
> 224: 
> 225: - That there are no duplicate Zip Entry file names

Nit - "... ZIP entry file names"

src/jdk.jartool/share/man/jar.md line 226:

> 224: 
> 225: - That there are no duplicate Zip Entry file names
> 226: - Verify that the Zip Entry file name:

Nit - ".... ZIP entry file name:"

src/jdk.jartool/share/man/jar.md line 237:

> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise
> 236: a non-zero status code would be returned.
> 237: When an integrity issue is reported, it will often require that the jar file is re-created by the

Nit - "... require that the JAR file is re-created by the original source of the JAR file."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100734549
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100733984
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100742813
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100743231
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100736667
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100737171
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100740992

From jpai at openjdk.org  Wed May 21 16:48:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:48:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <Bp4U2JkzCeZykmalvThoeOCO5XTdl7IrpP0SaZZGdaU=.d69d936b-57fc-4b6c-8b71-155b68c5b64d@github.com>

On Wed, 21 May 2025 15:49:29 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:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/man/jar.md line 235:

> 233:   versions.
> 234: 
> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise

Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100748899

From jpai at openjdk.org  Wed May 21 16:55:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 16:55:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>

On Wed, 21 May 2025 15:49:29 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:
> 
>   Mismatched order is considered invalid

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454:

> 452:                     new FileInputStream(file)))) {
> 453: 
> 454:             return Validator.validate(this, zf, zis);

I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate.

The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem.

It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100761422

From jpai at openjdk.org  Wed May 21 17:31:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 May 2025 17:31:55 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
Message-ID: <hnTAf2Jrr2_rUheZyAgz5zqzEf7O8scbMAaYWc1zsg0=.58a3e165-d095-4916-bd82-cc49b2fdae5d@github.com>

On Wed, 21 May 2025 15:49:29 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:
> 
>   Mismatched order is considered invalid

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

> 117:      * element is not equal to "." or ".."
> 118:      *
> 119:      * @param entryName CEN/LOC header file name field entry

Nit - `@param entryName ZIP entry name`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2100821550

From vromero at openjdk.org  Wed May 21 18:01:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 May 2025 18:01:00 GMT
Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity [v3]
In-Reply-To: <VwjvT5xaEjm_4ISKdAr7ZQCK1NFKw4WRtEfuvJnZiOs=.45963654-88ec-48b4-a415-84b690b219bf@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
 <VwjvT5xaEjm_4ISKdAr7ZQCK1NFKw4WRtEfuvJnZiOs=.45963654-88ec-48b4-a415-84b690b219bf@github.com>
Message-ID: <fT62bK6o4i946rOiIXJHi2nuZySQ4f4qTV1XUlm3Qds=.811febc0-e6b7-4ce1-82b1-e713b0d325f8@github.com>

On Wed, 21 May 2025 06:19:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
>> 
>> Important parts of the patch:
>> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
>> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
>> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
>> - for type variables, the synthetic annotation is filtered out in the API method
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8356894
>  - Cleanup.
>  - Fixing build
>  - Adjustments, annotation filtering, adding more tests
>  - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556
>  - Merge branch 'master' into JDK-8354556
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - additional changes from Archie
>  - removing dead code
>  - integrating code from Archie
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/1a97eb42...696cd663

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2858674319

From vromero at openjdk.org  Wed May 21 18:08:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 May 2025 18:08:51 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
Message-ID: <qpUH2BcwoVg8Ft5ZaoKqQuCPhj2aW3rWZ670Xno4eJY=.3ca8eb99-ed4f-4692-8c02-6bb62627fb9b@github.com>

On Wed, 21 May 2025 09:55:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
> 
> 
> static abstract class Getters<T> {
>     abstract class Getter {
>         abstract T get();
>     }
> }
> 
> static class Usage<T, G extends Getters<T>> {
>     public T test(G.Getter getter) {
>         return getter.get(); // incompatible types: Object cannot be converted to T
>     }
> }
> 
> 
> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.

isn't this test case similar and we get the same error message:

abstract class Getters<T> {
    abstract class Getter {
        abstract T get();
    }
}

class G2<K> extends Getters<K> {}

class Usage<M, L> {
    M test(G2<L>.Getter getter) {
        return getter.get(); 
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/25346#issuecomment-2898805446

From liach at openjdk.org  Wed May 21 18:08:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 18:08:51 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
Message-ID: <QmJ6iAHiypnsq96GRmEWXOnttRnVY6yvK8jEUmPN3Pw=.160fefe3-6568-441b-963a-e7e8a9f9bd0b@github.com>

On Wed, 21 May 2025 09:55:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
> 
> 
> static abstract class Getters<T> {
>     abstract class Getter {
>         abstract T get();
>     }
> }
> 
> static class Usage<T, G extends Getters<T>> {
>     public T test(G.Getter getter) {
>         return getter.get(); // incompatible types: Object cannot be converted to T
>     }
> }
> 
> 
> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.

L should be bounded by M in your example to have the types be compatible.

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

PR Comment: https://git.openjdk.org/jdk/pull/25346#issuecomment-2898812343

From vromero at openjdk.org  Wed May 21 18:21:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 May 2025 18:21:56 GMT
Subject: RFR: 8357361: Exception when compiling switch expression with
 inferred type
In-Reply-To: <0f92-CEJGKj0HqWwtFnxMk-9Hwivak74-kJT-MPPzhk=.43f8e19b-4ad1-41a0-ab8a-fc0e017537cf@github.com>
References: <0f92-CEJGKj0HqWwtFnxMk-9Hwivak74-kJT-MPPzhk=.43f8e19b-4ad1-41a0-ab8a-fc0e017537cf@github.com>
Message-ID: <AobOxCNfuYBaMeoG9k9QKivYEX89cEgJN_EbJ_wsYro=.eeee6e88-84f5-4595-94cf-375497896038@github.com>

On Wed, 21 May 2025 15:30:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There's a missing erasure in `TransTypes`, which eventually leads to an attempt to cast to a captured wildcard type (for the case shown in the bug report), which cannot be done. (In this case, `TransTypes` will report an error.)
> 
> (There's a unused/unnecessary code in the close vicinity of the added erasure, and a similar code in `visitSwitch`. I could resist deleting that unnecessary code.)

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25358#pullrequestreview-2858724712

From vromero at openjdk.org  Wed May 21 18:51:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 21 May 2025 18:51:55 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
Message-ID: <1BOIng-1yDCBaIFdwW5Twh4ATNBACdMp9P0s2yDH9r8=.d11caa84-4352-46c7-8228-7290e9849848@github.com>

On Wed, 21 May 2025 09:55:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
> 
> 
> static abstract class Getters<T> {
>     abstract class Getter {
>         abstract T get();
>     }
> }
> 
> static class Usage<T, G extends Getters<T>> {
>     public T test(G.Getter getter) {
>         return getter.get(); // incompatible types: Object cannot be converted to T
>     }
> }
> 
> 
> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.

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

> 1152:         public List<Type> allparams() {
> 1153:             if (allparams_field == null) {
> 1154:                 Type enclosingType = getEnclosingType();

I think the code here should follow with something like:

while (enclosingType.hasTag(TYPEVAR)) {
    enclosingType = enclosingType.getUpperBound();
}


we have Types::skipTypeVars for this, although not very handy in this case

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2100944100

From lancea at openjdk.org  Wed May 21 19:38:54 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 19:38:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <Bp4U2JkzCeZykmalvThoeOCO5XTdl7IrpP0SaZZGdaU=.d69d936b-57fc-4b6c-8b71-155b68c5b64d@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <Bp4U2JkzCeZykmalvThoeOCO5XTdl7IrpP0SaZZGdaU=.d69d936b-57fc-4b6c-8b71-155b68c5b64d@github.com>
Message-ID: <QwsEzNG9UTgwBrrGNcUriTdtUOSRuqauAjINIekCshQ=.e718a3d0-566c-4695-8cbe-082ba8f80324@github.com>

On Wed, 21 May 2025 16:45:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.

I don't have a preference but unix/MacOS commands vary:

-  ls command: The ls utility exits?0 on success, and?>0 if an error occurs.
- grep command: 

> The grep utility exits with one of the following values:

     0     One or more lines were selected.
     1     No lines were selected.
     >1    An error occurred.

- unzip command:

> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the
       following values, except under VMS:

              0      normal; no errors or warnings detected.

              1      one or more warning errors were encountered, but processing completed successfully
                     anyway.  This includes zipfiles where one or more files was skipped due to unsupported
                     compression method or encryption with an unknown password.

              2      a generic error in the zipfile format was detected.  Processing may have completed
                     successfully anyway; some broken zipfiles created by other archivers have simple work-
                     arounds.
              3      a severe error in the zipfile format was detected.  Processing probably failed
                     immediately.

              4      unzip was unable to allocate memory for one or more buffers during program
                     initialization.

              5      unzip was unable to allocate memory or unable to obtain a tty to read the decryption
                     password(s).

              6      unzip was unable to allocate memory during decompression to disk.

              7      unzip was unable to allocate memory during in-memory decompression.

              8      [currently not used]

              9      the specified zipfiles were not found.

              10     invalid options were specified on the command line.

              11     no matching files were found.

              50     the disk is (or was) full during extraction.

              51     the end of the ZIP archive was encountered prematurely.

              80     the user aborted unzip prematurely with control-C (or similar)

              81     testing or extraction of one or more files failed due to unsupported compression methods
                     or unsupported decryption.

              82     no files were found due to bad decryption password(s).  (If even one file is successfully
                     processed, however, the exit status is 1.)

So perhaps something along the lines of

> The jar tool exits with a status of 0 if there were no integrity issues encountered and >0 if an error/warning occurred

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101029665

From lancea at openjdk.org  Wed May 21 20:23:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 May 2025 20:23:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
Message-ID: <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>

On Wed, 21 May 2025 16:42:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Mismatched order is considered invalid
>
> src/jdk.jartool/share/man/jar.md line 223:
> 
>> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
>> 222: other than the `jar` command. The --validate option may be used to perform the following
>> 223: integrity checks against a jar archive:
> 
> Nit - "integrity checks against a JAR file:"

I think we have other inconsistencies that we can clean up at a later time in the help and man page for the jar tool in the usages of archive/file.

The man page description can use a further overhaul as we still reference applets.  So we can do this also as follow on work

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101097000

From henryjen at openjdk.org  Thu May 22 01:29:12 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 01:29:12 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@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:

  Validator to take a file, use term JAR file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/b0df54d2..52af70aa

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

  Stats: 27 lines in 3 files changed: 7 ins; 3 del; 17 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  Thu May 22 01:45:00 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 01:45:00 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>
Message-ID: <ISsFz3sMJMDu3sh5CfJWicigVorVDLsLpDIY8adVnq4=.804db444-277b-485b-981d-c154c15d07a3@github.com>

On Wed, 21 May 2025 16:53:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Mismatched order is considered invalid
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454:
> 
>> 452:                     new FileInputStream(file)))) {
>> 453: 
>> 454:             return Validator.validate(this, zf, zis);
> 
> I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate.
> 
> The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem.
> 
> It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR.

I keep File instead of Path to avoid unnecessary changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101460623

From henryjen at openjdk.org  Thu May 22 01:45:01 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 01:45:01 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
Message-ID: <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>

On Wed, 21 May 2025 20:21:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.jartool/share/man/jar.md line 223:
>> 
>>> 221: As a jar archive is based on ZIP format, it is possible to create a jar archive using tools
>>> 222: other than the `jar` command. The --validate option may be used to perform the following
>>> 223: integrity checks against a jar archive:
>> 
>> Nit - "integrity checks against a JAR file:"
>
> I think we have other inconsistencies that we can clean up at a later time in the help and man page for the jar tool in the usages of archive/file.
> 
> The man page description can use a further overhaul as we still reference applets.  So we can do this also as follow on work

I changed references in the new content and leave the retrofit to future works.

>> src/jdk.jartool/share/man/jar.md line 235:
>> 
>>> 233:   versions.
>>> 234: 
>>> 235: The jar tool returns a status code of 0 if there were no integrity issues encountered, otherwise
>> 
>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
>
>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
> 
> I don't have a preference but unix/MacOS commands vary:
> 
> -  ls command: The ls utility exits?0 on success, and?>0 if an error occurs.
> - grep command: 
> 
>> The grep utility exits with one of the following values:
> 
>      0     One or more lines were selected.
>      1     No lines were selected.
>      >1    An error occurred.
> 
> - unzip command:
> 
>> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the
>        following values, except under VMS:
> 
>               0      normal; no errors or warnings detected.
> 
>               1      one or more warning errors were encountered, but processing completed successfully
>                      anyway.  This includes zipfiles where one or more files was skipped due to unsupported
>                      compression method or encryption with an unknown password.
> 
>               2      a generic error in the zipfile format was detected.  Processing may have completed
>                      successfully anyway; some broken zipfiles created by other archivers have simple work-
>                      arounds.
>               3      a severe error in the zipfile format was detected.  Processing probably failed
>                      immediately.
> 
>               4      unzip was unable to allocate memory for one or more buffers during program
>                      initialization.
> 
>               5      unzip was unable to allocate memory or unable to obtain a tty to read the decryption
>                      password(s).
> 
>               6      unzip was unable to allocate memory during decompression to disk.
> 
>               7      unzip was unable to allocate memory during in-memory decompression.
> 
>               8      [currently not used]
> 
>               9      the specified zipfiles were not found.
> 
>               10     invalid options were specified on the command line.
> 
>               11     no matching files were found.
> 
>               50     the disk is (or was) full during extraction.
> 
>               51     the end of the ZIP archive was encountered prematurely.
> 
>               80     the user aborted unzip prematurely with control-C (or similar)
> 
>               81     testing or extraction of one or more files failed due to unsupported compression methods
>                      or unsupported decryption.
> 
>               82     no files were found due to bad decryption password(s).  (If even one file is successfully
>       ...

I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101457168
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101458911

From lancea at openjdk.org  Thu May 22 01:48:54 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 May 2025 01:48:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
 <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
Message-ID: <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>

On Thu, 22 May 2025 01:39:45 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>>> Nit - we should call it exit code instead of status code, both for 0 and non-zero exit codes.
>> 
>> I don't have a preference but unix/MacOS commands vary:
>> 
>> -  ls command: The ls utility exits?0 on success, and?>0 if an error occurs.
>> - grep command: 
>> 
>>> The grep utility exits with one of the following values:
>> 
>>      0     One or more lines were selected.
>>      1     No lines were selected.
>>      >1    An error occurred.
>> 
>> - unzip command:
>> 
>>> The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the
>>        following values, except under VMS:
>> 
>>               0      normal; no errors or warnings detected.
>> 
>>               1      one or more warning errors were encountered, but processing completed successfully
>>                      anyway.  This includes zipfiles where one or more files was skipped due to unsupported
>>                      compression method or encryption with an unknown password.
>> 
>>               2      a generic error in the zipfile format was detected.  Processing may have completed
>>                      successfully anyway; some broken zipfiles created by other archivers have simple work-
>>                      arounds.
>>               3      a severe error in the zipfile format was detected.  Processing probably failed
>>                      immediately.
>> 
>>               4      unzip was unable to allocate memory for one or more buffers during program
>>                      initialization.
>> 
>>               5      unzip was unable to allocate memory or unable to obtain a tty to read the decryption
>>                      password(s).
>> 
>>               6      unzip was unable to allocate memory during decompression to disk.
>> 
>>               7      unzip was unable to allocate memory during in-memory decompression.
>> 
>>               8      [currently not used]
>> 
>>               9      the specified zipfiles were not found.
>> 
>>               10     invalid options were specified on the command line.
>> 
>>               11     no matching files were found.
>> 
>>               50     the disk is (or was) full during extraction.
>> 
>>               51     the end of the ZIP archive was encountered prematurely.
>> 
>>               80     the user aborted unzip prematurely with control-C (or similar)
>> 
>>               81     testing or extraction of one or more files failed due to unsupported compression methods
>>                      or unsupported decryption.
>> 
>>     ...
>
> I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations.

Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2101463994

From jpai at openjdk.org  Thu May 22 02:21:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 02:21:04 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
Message-ID: <aCBIe8NiWcUc71cde_HZ7T8dEEujoOdzXoicwpGEQT0=.083899e6-79bb-4240-8e8a-233dcc5088b0@github.com>

On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry.
>> 
>> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance.
>> 
>> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file.
>> 
>> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html.
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and remove part of comment

Hello Jason, I'll just run this once in our CI today to make sure nothing fails against latest master. I'll add a comment here once that's complete and you can then integrate it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2899711012

From jlahoda at openjdk.org  Thu May 22 05:58:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 May 2025 05:58:56 GMT
Subject: Integrated: 8357361: Exception when compiling switch expression with
 inferred type
In-Reply-To: <0f92-CEJGKj0HqWwtFnxMk-9Hwivak74-kJT-MPPzhk=.43f8e19b-4ad1-41a0-ab8a-fc0e017537cf@github.com>
References: <0f92-CEJGKj0HqWwtFnxMk-9Hwivak74-kJT-MPPzhk=.43f8e19b-4ad1-41a0-ab8a-fc0e017537cf@github.com>
Message-ID: <-n4IRVY6w2JbKGxg7YkjntkrLciArQclHL9UwP_OcFI=.19096942-f8cf-4c82-95af-9f3cc4fcc13d@github.com>

On Wed, 21 May 2025 15:30:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There's a missing erasure in `TransTypes`, which eventually leads to an attempt to cast to a captured wildcard type (for the case shown in the bug report), which cannot be done. (In this case, `TransTypes` will report an error.)
> 
> (There's a unused/unnecessary code in the close vicinity of the added erasure, and a similar code in `visitSwitch`. I could resist deleting that unnecessary code.)

This pull request has now been integrated.

Changeset: ec670652
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec6706520b87eff3d87b3b65f3caa39db2d96581
Stats:     30 lines in 2 files changed: 21 ins; 6 del; 3 mod

8357361: Exception when compiling switch expression with inferred type

Reviewed-by: vromero

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

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

From jpai at openjdk.org  Thu May 22 06:50:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 06:50:54 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com>
 <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
Message-ID: <Vy414UoIgmiYePus1BZMzJuwnPaVootdf-_zKrm41PM=.7435135c-33ce-477c-a4db-05d287e8646d@github.com>

On Mon, 24 Mar 2025 22:33:56 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> Good catch, thanks! Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
>
>> Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
> 
> I tested this change [externally](https://github.com/retronym/jarcache/blob/ba7f5cdd5f7db976a6568855a0d517f52a1404bf/demo/src/test/scala/demo/JarCacheAgentTest.java#L75-L76) with [JFRUnit](https://github.com/moditect/jfrunit). 
> 
> If preferred, I could create a `jtreg` test along similar lines. It would use the JFR API directly to capture `jdk.FileRead` events. The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR.

tier1, tier2, tier3 testing of these changes against latest master branch has completed without any related failures. @retronym, you can go ahead and "/integrate" this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900107948

From duke at openjdk.org  Thu May 22 07:08:55 2025
From: duke at openjdk.org (duke)
Date: Thu, 22 May 2025 07:08:55 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance [v3]
In-Reply-To: <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <U5LJYS7yxDkt-d043HiYMoP2wOhCE7lX8Bg6zvQDbyA=.4e80780f-1f1c-4cd7-aab0-61a991cf0cbe@github.com>
Message-ID: <nEnWh-Bm0tq_ebvSiUsqWLN2q6Um3hMI6LzZPdlOP60=.38a2d2ff-a67a-429e-94a0-8a0223c26b7c@github.com>

On Sun, 20 Apr 2025 13:01:30 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry.
>> 
>> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance.
>> 
>> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file.
>> 
>> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html.
>
> Jason Zaugg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright and remove part of comment

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

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900148295

From jzaugg at openjdk.org  Thu May 22 07:29:02 2025
From: jzaugg at openjdk.org (Jason Zaugg)
Date: Thu, 22 May 2025 07:29:02 GMT
Subject: Integrated: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
Message-ID: <uAoKH0xdQ6NNJJu4MwkUJr_LlSvsMcCoZVSpsZ-uTL4=.0eacab9a-523f-41d1-b193-9a9128e75484@github.com>

On Sun, 23 Mar 2025 12:38:04 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

> zipfs has a (undocumented) property "zipinfo-time" which was introduced in https://bugs.openjdk.org/browse/JDK-8150496 to help improve performance of the ZipFileSystem. When a ZipFileSystem is created with this property's value set to "false", then the implementation in ZipFileSystem, while constructing the entries from the ZIP file will skip reading the access time and the creation time of each ZIP entry from the entry's LOC header. This improves the performance of zipfs, since when reading the CEN, it no longer has to traverse to individual LOC headers to find the access time and creation time values of each entry.
> 
> Setting "zipinfo-time" = false, thus implies that the ZipFileAttributes.creationTime() and ZipFileAttributes.lastAccessTime() APIs may not return the right values when used against Path(s) corresponding to the ZIP entries in that FileSystem. Not all usages of zipfs require or use the creationTime()/lastAccessTime() APIs. Such usages can set "zipinfo-time" = false and benefit from improved performance.
> 
> com.sun.tools.javac.file.JavacFileManager$ArchiveContainer is one such place where when constructing the FileSystem, it could pass this property. This is especially useful since this part of the code in practice can be dealing with large number of jar files in the classpath and creating one zipfs FileSystem for each such JAR file.
> 
> It has been reported in the compiler-dev mailing list, that an experiment to set "zipinfo-time" = false in this part of the code has shown very noticeable performance improvements, especially on Windows, when dealing with large classpath. Details in the thread here https://mail.openjdk.org/pipermail/compiler-dev/2025-March/029529.html.

This pull request has now been integrated.

Changeset: d9b6e4b1
Author:    Jason Zaugg <jzaugg at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9b6e4b13200684b69a161e288b9883ff0d96bec
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8352642: Set zipinfo-time=false when constructing zipfs FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for better performance

Reviewed-by: liach, jpai, jlahoda, lancea

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

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

From vklang at openjdk.org  Thu May 22 07:34:02 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 May 2025 07:34:02 GMT
Subject: RFR: 8352642: Set zipinfo-time=false when constructing zipfs
 FileSystem in com.sun.tools.javac.file.JavacFileManager$ArchiveContainer for
 better performance
In-Reply-To: <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
References: <HA_Tfzi84K-B8fhLMZQdYZ5Xj5GB0rE6HUh2jx99Stc=.5bc95d53-cee4-47aa-ab16-c193fa8b70c1@github.com>
 <2PjV5qPpliR71q_2HQRBychDHCFCTM4Pbw4xZDAIb7M=.329d3adf-a82e-47d8-9bd8-aab1ca897c38@github.com>
 <fjXxuXGIvezZ5aoE-a_ex4EQimfGGVQq2IqoWaie1IA=.39eaa16e-f074-4993-b10e-8d6175159951@github.com>
Message-ID: <jH-VmoWKQ_hcK6k_12K7-lsRjbA-zkoPqMu4pKDFIKw=.32ed2859-b729-4a28-8418-3d9fa2ec4a46@github.com>

On Mon, 24 Mar 2025 22:33:56 GMT, Jason Zaugg <jzaugg at openjdk.org> wrote:

>> Good catch, thanks! Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
>
>> Ordinarily, I would say a test is required, but I can't think up a viable test to verify the effect of this change in a test, so we probably need to do it without a test.
> 
> I tested this change [externally](https://github.com/retronym/jarcache/blob/ba7f5cdd5f7db976a6568855a0d517f52a1404bf/demo/src/test/scala/demo/JarCacheAgentTest.java#L75-L76) with [JFRUnit](https://github.com/moditect/jfrunit). 
> 
> If preferred, I could create a `jtreg` test along similar lines. It would use the JFR API directly to capture `jdk.FileRead` events. The test would construct a JAR that previously triggered one read per entry, and assert that after this change, only a single read is needed to initialize a compiler whose classpath includes that JAR.

@retronym Great to see you here, Jason! I hope all is well. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24176#issuecomment-2900199480

From abimpoudis at openjdk.org  Thu May 22 08:49:54 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 22 May 2025 08:49:54 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer
In-Reply-To: <qpUH2BcwoVg8Ft5ZaoKqQuCPhj2aW3rWZ670Xno4eJY=.3ca8eb99-ed4f-4692-8c02-6bb62627fb9b@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <qpUH2BcwoVg8Ft5ZaoKqQuCPhj2aW3rWZ670Xno4eJY=.3ca8eb99-ed4f-4692-8c02-6bb62627fb9b@github.com>
Message-ID: <p7uGd7ZDyvOhPwSc5v6D8IheEX6LMQwVz5qfcLbcvu0=.35e9b01f-bf78-4806-ac63-acb93ade53ba@github.com>

On Wed, 21 May 2025 18:03:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> isn't this test case similar and we get the same error message

We don't get an error message without the patch in your case. In `G2<L>.Getter`, `G2<L>` is not raw, neither is `Getter`.
However, in the case `G.Getter`, `G` was considered erroneously raw (`G extends Getters<T>`).

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

PR Comment: https://git.openjdk.org/jdk/pull/25346#issuecomment-2900408687

From abimpoudis at openjdk.org  Thu May 22 09:10:39 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 22 May 2025 09:10:39 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer [v2]
In-Reply-To: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
Message-ID: <QVXylK7tYNymExgBuMqF3u207bx6Rem66zc8ESn7Bjw=.30b96cf6-54b1-4719-934b-d736abb78bb9@github.com>

> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
> 
> 
> static abstract class Getters<T> {
>     abstract class Getter {
>         abstract T get();
>     }
> }
> 
> static class Usage<T, G extends Getters<T>> {
>     public T test(G.Getter getter) {
>         return getter.get(); // incompatible types: Object cannot be converted to T
>     }
> }
> 
> 
> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.

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

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25346/files
  - new: https://git.openjdk.org/jdk/pull/25346/files/d2d59f9a..e228c004

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

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

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

From jpai at openjdk.org  Thu May 22 10:41:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 10:41:59 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <ISsFz3sMJMDu3sh5CfJWicigVorVDLsLpDIY8adVnq4=.804db444-277b-485b-981d-c154c15d07a3@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <6F_2GSLLN0ajSO73JcYDd0wXvTthdFjgfxXDQ8XndYU=.c3ad4280-fcc3-4eaf-a658-2d5212009260@github.com>
 <ISsFz3sMJMDu3sh5CfJWicigVorVDLsLpDIY8adVnq4=.804db444-277b-485b-981d-c154c15d07a3@github.com>
Message-ID: <Au9pwB-seNATiUg03WTMKvOh3bpM83Y1PRANG9OCMNc=.77689a4a-e1fb-4025-a844-40d44b4f6946@github.com>

On Thu, 22 May 2025 01:41:51 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 454:
>> 
>>> 452:                     new FileInputStream(file)))) {
>>> 453: 
>>> 454:             return Validator.validate(this, zf, zis);
>> 
>> I think it might be better to change the `Validator.validate()` method to accept a `java.nio.file.Path` instead of accepting a ZipFile instance and a ZipInputStream instance. In its current form it feels odd that the call site (like here) needs to pass ZipFile and ZipInputStream to a validator. The checks using a ZipFile and a ZipInputStream for the same file is more an internal detail of the validator, so it would be good to let it construct those instances internally as appropriate.
>> 
>> The `Validator` class itself belongs to an internal package of this tool, so changing the signature of this method to accept a `Path` wouldn't be a problem.
>> 
>> It also looks like the Validator uses this `Main` instance merely for error reporting. So maybe in a future update we could remove the need to pass along this `Main` instance to the validator. That one doesn't have to be done in this PR.
>
> I keep File instead of Path to avoid unnecessary changes.

Thank you for the update to this method, Henry. Retaining the use of `File` is fine. We have a separate plan for future to use `java.nio.file.Path` for the code in the jar tool and this can be revisited at that time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102239606

From jpai at openjdk.org  Thu May 22 10:51:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 10:51:07 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <AUS1zszlE8wi3Qc1o7T77qgSubwf0DMSlySq_njCQXg=.56746d64-248a-4aaa-8684-da18cdaf727e@github.com>

On Thu, 22 May 2025 01:29:12 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:
> 
>   Validator to take a file, use term JAR file

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

> 139:      * NOTE: In order to check the encounter order based on the CEN listing,
> 140:      *       this implementation assumes CEN entries are to be added before
> 141:      *       add any LOC entries. That is, addCenEntry should be called before

This looks like a typo. Should have been "adding any ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102254941

From jpai at openjdk.org  Thu May 22 11:11:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:11:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <nnfwV5PrNKiLCfn9dzqvqKj5z5Zt92rZRmxDXuhiZiU=.b8233954-22ed-4530-bbb4-7e6ae12b5f5f@github.com>

On Thu, 22 May 2025 01:29:12 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:
> 
>   Validator to take a file, use term JAR file

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

> 145:     private class EntryValidator {
> 146:         // A place holder when an entry is not yet seen in the directory
> 147:         static EntryEncounter PLACE_HOLDER = new EntryEncounter(0, 0);

It looks like this could be `final`? And then `isPlaceHolder()` could just return `this == PLACE_HOLDER`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102292540

From jpai at openjdk.org  Thu May 22 11:26:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:26:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <OvTPJhEKFBendHavmBWOYTmqG1IyFHvebu0L03MXq8g=.18218b2c-d594-4b5d-8caf-46bbeee02f7f@github.com>

On Thu, 22 May 2025 01:29:12 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:
> 
>   Validator to take a file, use term JAR file

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

> 183:         // Encounter order in CEN, step by 1 on each new entry
> 184:         int cenEncounterOrder = 0;
> 185:         // Encounter order in LOC, step by 1 for new LOC entry exist in CEN

Nit - "for new LOC entry that exists in CEN"

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

> 206:         /**
> 207:          * Record an entry apperance in LOC
> 208:          * We compare entry order based on the CEN. Thus do not step LOC

Nit - would "Thus do not increment LOC ..." be easier to understand? You don't have to do the change if you prefer it this way (I see that we use the same term on the comment of the `cenEncounterOrder` and `locEncounterOrder` fields.

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

> 236:         /**
> 237:          * Validation per entry observed.
> 238:          * Each entry must appeared at least oncee in CEN or LOC.

A couple of typos - "Each entry must appear at least once in the CEN or LOC"

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

> 263: 
> 264:         /**
> 265:          * Validate the jar entries by check each entry in encounter order

Typo - "by checking ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102312203
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102312688
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102316444
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102321661

From jpai at openjdk.org  Thu May 22 11:44:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:44:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <OvTPJhEKFBendHavmBWOYTmqG1IyFHvebu0L03MXq8g=.18218b2c-d594-4b5d-8caf-46bbeee02f7f@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
 <OvTPJhEKFBendHavmBWOYTmqG1IyFHvebu0L03MXq8g=.18218b2c-d594-4b5d-8caf-46bbeee02f7f@github.com>
Message-ID: <6Hk0ojFnclvLTaykOsVJBhZ3WmFw2AwJZWCbjob25xY=.6d79d9f6-a6b4-48ba-a6a6-22cd0e9447d5@github.com>

On Thu, 22 May 2025 11:20:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Validator to take a file, use term JAR file
>
> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 185:
> 
>> 183:         // Encounter order in CEN, step by 1 on each new entry
>> 184:         int cenEncounterOrder = 0;
>> 185:         // Encounter order in LOC, step by 1 for new LOC entry exist in CEN
> 
> Nit - "for new LOC entry that exists in CEN"

I think the way you have implemented this is correct, but can you explain why we don't increment the `locEncounterOrder` for each LOC entry? I'm pretty sure I'll keep asking myself that question every time I see this code in future, so it would be good to have this clarified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102350306

From jpai at openjdk.org  Thu May 22 11:44:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:44:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com>

On Thu, 22 May 2025 01:29:12 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:
> 
>   Validator to take a file, use term JAR file

test/jdk/tools/jar/ValidatorTest.java line 60:

> 58: import jdk.test.lib.util.FileUtils;
> 59: 
> 60: @TestInstance(Lifecycle.PER_CLASS)

I haven't seen this used commonly in our tests. Is there something specific in this test that requires this usage?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102353416

From jpai at openjdk.org  Thu May 22 11:49:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:49:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <9UV7peR74Nase0cMQ7evBn-99r_aGMlGjyF-0apfTRo=.0363580c-e520-46c6-88e3-dd0cece21294@github.com>

On Thu, 22 May 2025 01:29:12 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:
> 
>   Validator to take a file, use term JAR file

test/jdk/tools/jar/ValidatorTest.java line 224:

> 222: 
> 223:     @Test
> 224:     public void testValidateJar() throws IOException {

Perhaps rename the method to `testValidJar()`?

test/jdk/tools/jar/ValidatorTest.java line 230:

> 228:             jar("--validate --file " + zip.toString());
> 229:         } catch (IOException e) {
> 230:             fail("Expecting zero exit code");

I think we should remove the try/catch block and let the IOException propagate. That way, if htis fails for whatever reason, we get the entire exception stacktrace. A comment before the `jar("--validate --file ...)` line can say that we except the `jar()` call to succeed with a zero exit code.

test/jdk/tools/jar/ValidatorTest.java line 235:

> 233: 
> 234:     @Test
> 235:     public void testValidate() throws IOException {

Perhaps rename to `testMultiManifestJar()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102361183
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102359049
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102361579

From jpai at openjdk.org  Thu May 22 11:59:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 11:59:02 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <-RuOE8u98OK_ruRjXFgPQsWhOnB1aPSeh_0TeOVqmlQ=.4fc88805-062c-4619-8da2-81f9a026af0d@github.com>

On Thu, 22 May 2025 01:29:12 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:
> 
>   Validator to take a file, use term JAR file

test/jdk/tools/jar/ValidatorTest.java line 293:

> 291:         } catch (IOException e) {
> 292:             var err = e.getMessage();
> 293:             assertTrue(err.contains("Warning: Central directory and local file header entries are not in the same order"));

Unlike in other tests, we are missing a `System.out.println(err)` before the assert here.

test/jdk/tools/jar/ValidatorTest.java line 308:

> 306:             System.out.println(err);
> 307:             for (var entryName : invalidEntryNames) {
> 308:                 assertTrue(err.contains("Warning: entry name " + entryName + " is not valid"));

To help debug any failures, it might be better to include the entryName that failed the assert, something like:


assertTrue(err.contains("Warning: entry name " + entryName + " is not valid"), "missing warning for " + entryName);

test/jdk/tools/jar/ValidatorTest.java line 325:

> 323:         try {
> 324:             int rc = JAR_TOOL.run(jarOut, err, cmdline.split(" +"));
> 325:             if (rc != 0) {

Nit - should we add a `System.out.println("exit code: " + rc);`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102370169
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102374499
PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102379182

From jpai at openjdk.org  Thu May 22 12:07:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 May 2025 12:07:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
Message-ID: <RUyLs4AwH_FS7xWpby1AcVIGD5qelx9JlK-kY-L0npE=.a3323f76-79e5-4f52-b7cc-d6e73beb7366@github.com>

On Thu, 22 May 2025 01:29:12 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:
> 
>   Validator to take a file, use term JAR file

Hello Henry, thank you for this enhancement. Overall this looks very good to me, especially because the validation code is concise and very cleanly done. I only had some nits and minor clarifications in this review.

Some parts of the test (like the usage of ISO_8859_1 charset) isn't clear to me, so I'll come back to that later. I'll focus on the CSR review now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24430#issuecomment-2900987846

From lancea at openjdk.org  Thu May 22 12:27:56 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 May 2025 12:27:56 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
 <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
 <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>
Message-ID: <FdmZ0Yn1Kb7B9wbxj2Opih3t77PRtdhzOpHYSI8hYB0=.7fac95dc-f972-4777-b63c-6958df66a6d4@github.com>

On Thu, 22 May 2025 01:46:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I use exit code, but still keep non-zero instead of > 0. Leave that to future work if we want to have more specific value for exit code for different situations.
>
> Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate

We are somewhat inconsistent in documenting the exit code from our commands as many do not include any mention

A few for reference

**java command**:

> The following exit values are typically returned by the launcher when the launcher is called with the wrong arguments, serious errors, or exceptions thrown by the JVM. However, a Java application may choose to return any value by using the API call System.exit(exitValue). The values are:

    0: Successful completion

    >0: An error occurred

**jarsigner command**:

>  If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0.

See https://docs.oracle.com/en/java/javase/24/docs/specs/man/jarsigner.html#errors-and-warnings for the full details

**jshell command**:

> /exit [integer-expression-snippet]
>     Exits the tool. If no snippet is entered, the exit status is zero. If a snippet is entered and the result of the snippet is an integer, the result is used as the exit status. If an error occurs, or the result of the snippet is not an integer, an error is displayed and the tool remains active. 

`% jshell
|  Welcome to JShell -- Version 22.0.1
|  For an introduction type: /help intro

jshell> System.out.print("hi");
hi
jshell> /exit 1
|  Goodbye (1)
 % echo $?
1
`
So,  currently, the jdk commands use either:

- exit code
- exit value
- exit status
- exit with code

I would probably go with either "exit status" or "exit value"

And as I mentioned in a prior comment we should move away from non-zero and use either '>0' as java and several unix based commands do or use "greater than 0"

**Note:**
Other several commands such as jdeperscan do not specify the exit status value and I think we need to document the possible exit status values for the jdk commands and perhaps target this for jdk 26

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102431539

From aph at openjdk.org  Thu May 22 15:09:12 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 22 May 2025 15:09:12 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8]
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@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 11 commits:

 - Merge from JDK head
 - Fix merge
 - 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
 - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd

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

Changes: https://git.openjdk.org/jdk/pull/24923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24923&range=07
  Stats: 21 lines in 6 files changed: 3 ins; 12 del; 6 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 vromero at openjdk.org  Thu May 22 15:10:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 22 May 2025 15:10:54 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer [v2]
In-Reply-To: <QVXylK7tYNymExgBuMqF3u207bx6Rem66zc8ESn7Bjw=.30b96cf6-54b1-4719-934b-d736abb78bb9@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <QVXylK7tYNymExgBuMqF3u207bx6Rem66zc8ESn7Bjw=.30b96cf6-54b1-4719-934b-d736abb78bb9@github.com>
Message-ID: <pLekS2VAwp6KLYr4zlXbzammvY8Y36Czt4KAl1LbPhg=.72afb374-537a-41c4-a677-4cdb9b2ee33a@github.com>

On Thu, 22 May 2025 09:10:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
>> 
>> 
>> static abstract class Getters<T> {
>>     abstract class Getter {
>>         abstract T get();
>>     }
>> }
>> 
>> static class Usage<T, G extends Getters<T>> {
>>     public T test(G.Getter getter) {
>>         return getter.get(); // incompatible types: Object cannot be converted to T
>>     }
>> }
>> 
>> 
>> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25346#pullrequestreview-2861619723

From henryjen at openjdk.org  Thu May 22 15:29:36 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 15:29:36 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v13]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <7jkcv3sSX-L6EA-0JGC4cJE-u-_0cOzrwRJJ0ZTK2N4=.969da667-e338-44ec-9f93-7c989c47c9b9@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:

  Assure >0 exit code and fix typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/52af70aa..5118aba4

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

  Stats: 18 lines in 3 files changed: 2 ins; 4 del; 12 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  Thu May 22 16:33:53 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 16:33:53 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v11]
In-Reply-To: <FdmZ0Yn1Kb7B9wbxj2Opih3t77PRtdhzOpHYSI8hYB0=.7fac95dc-f972-4777-b63c-6958df66a6d4@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <mce5Fld8cUFibGUB0TBKJBlWQRh0ZqGFpT449ynSVVA=.39e22bdb-daa0-41f1-ba3f-5605b05a4e4e@github.com>
 <n8AVnZgFi-yV_dQL5eYZziuYRjTbIlImqi9NIMXQR1E=.62a1b4e4-7007-4416-8c03-e214585cb0d1@github.com>
 <LpPzYllXtGll6AEKQKoDBDbLswCKJR8rX399QEN_io0=.47f59052-f118-4638-8a45-b3b99846e897@github.com>
 <XrVT-vsFLSEx-ksEcz3Ss5km3jdoGiltBwQLhMVwHPg=.f42a0192-9194-45c8-bb1f-7bbc8fa70775@github.com>
 <Y6YssGqbUHJfl3FqvtPzcyYTW4_XTFrcOZPKkuxgkT4=.e6063750-748a-48f6-97cc-bddfdf3ab345@github.com>
 <FdmZ0Yn1Kb7B9wbxj2Opih3t77PRtdhzOpHYSI8hYB0=.7fac95dc-f972-4777-b63c-6958df66a6d4@github.com>
Message-ID: <QUVrTBpKTKhxqc8eB2cW5D47FbCE3JjKTypbUYs-dog=.64c39624-5b44-4f2c-b047-d7d75959c06f@github.com>

On Thu, 22 May 2025 12:25:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Non-zero could also mean negative which we currently do not do nor do,I see that going forward as part of future additions to validate
>
> We are somewhat inconsistent in documenting the exit code from our commands as many do not include any mention
> 
> A few for reference
> 
> **java command**:
> 
>> The following exit values are typically returned by the launcher when the launcher is called with the wrong arguments, serious errors, or exceptions thrown by the JVM. However, a Java application may choose to return any value by using the API call System.exit(exitValue). The values are:
> 
>     0: Successful completion
> 
>     >0: An error occurred
> 
> **jarsigner command**:
> 
>>  If there is a failure, the jarsigner command exits with code 1. If there is no failure, but there are one or more severe warnings, the jarsigner command exits with code 0 when the -strict option is not specified, or exits with the OR-value of the warning codes when the -strict is specified. If there is only informational warnings or no warning at all, the command always exits with code 0.
> 
> See https://docs.oracle.com/en/java/javase/24/docs/specs/man/jarsigner.html#errors-and-warnings for the full details
> 
> **jshell command**:
> 
>> /exit [integer-expression-snippet]
>>     Exits the tool. If no snippet is entered, the exit status is zero. If a snippet is entered and the result of the snippet is an integer, the result is used as the exit status. If an error occurs, or the result of the snippet is not an integer, an error is displayed and the tool remains active. 
> 
> `% jshell
> |  Welcome to JShell -- Version 22.0.1
> |  For an introduction type: /help intro
> 
> jshell> System.out.print("hi");
> hi
> jshell> /exit 1
> |  Goodbye (1)
>  % echo $?
> 1
> `
> So,  currently, the jdk commands use either:
> 
> - exit code
> - exit value
> - exit status
> - exit with code
> 
> I would probably go with either "exit status" or "exit value"
> 
> And as I mentioned in a prior comment we should move away from non-zero and use either '>0' as java and several unix based commands do or use "greater than 0"
> 
> **Note:**
> Other several commands such as jdeperscan do not specify the exit status value and I think we need to document the possible exit status values for the jdk commands and perhaps target this for jdk 26

For noun and verb, seems we have exit code and exit with code. Do we want to use status instead of code?
I don't have a preference as long as we can agree to one.
exit status and exit with status?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2102974569

From liach at openjdk.org  Thu May 22 16:44:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 16:44:56 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8]
In-Reply-To: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
Message-ID: <xxXxqXoD0dD9lqjG4ywuuqk60O02tiUBj5dABZW8R78=.85f07e31-9cef-4acd-a471-6afa006cc4d9@github.com>

On Thu, 22 May 2025 15:09:12 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 with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge from JDK head
>  - Fix merge
>  - 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
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd

The latest master merge looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2861915865

From henryjen at openjdk.org  Thu May 22 17:08:58 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 17:08:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v12]
In-Reply-To: <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <1Fesq2hQvm9iwMP5cR6Er8yHeITGlxJTTgoE8zM11U4=.f7a4eab7-2059-4ddd-9685-7d72ebb6e4f8@github.com>
 <9eBVY2wfBH5n4aochz0yfDxWub3LmS_nVW0LlUugzkw=.bccb2195-704f-4b95-8fb1-3070a3174090@github.com>
Message-ID: <OmcAMI0zi3jVHHqpJA09UtEFddb22ZaIyBCi4hYOF14=.4023b9b4-f03c-417f-b964-afb2da98abf3@github.com>

On Thu, 22 May 2025 11:42:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Validator to take a file, use term JAR file
>
> test/jdk/tools/jar/ValidatorTest.java line 60:
> 
>> 58: import jdk.test.lib.util.FileUtils;
>> 59: 
>> 60: @TestInstance(Lifecycle.PER_CLASS)
> 
> I haven't seen this used commonly in our tests. Is there something specific in this test that requires this usage?

I take this in as other jar tests. I think it's because we used to share the ZIP file between tests. I believe I can remove it for this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2103031299

From henryjen at openjdk.org  Thu May 22 17:22:54 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 17:22:54 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v6]
In-Reply-To: <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@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>
 <BCRh35_h9tPnYU1KvHxTj7VpT4k7hfA9gTA9VdTfrrk=.5d8804f5-acfd-4e6c-b65a-cd8dbbfe5208@github.com>
 <0880cZA9IZKMn3ctbmhkEYw_1TkFjQ6hnDQhXVq7e7E=.43ea3a53-dc89-47c6-9710-2a99d7cbf598@github.com>
Message-ID: <gMQ9CguqZcifWzsRdD3V7Jbrltwikb7wB_i0zmPUYLk=.afd17030-97e3-4fe5-9fb0-650b30549ecb@github.com>

On Wed, 14 May 2025 17:27:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> UTF-8 messed up the index, we don't want any conversion to happen.
>> Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory
>> Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory
>> Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header
>> Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header
>
>> UTF-8 messed up the index, we don't want any conversion to happen. Warning: Entry META-INFMAANIFEST.MF in local file header is not in central directory Warning: Entry META-INF/BANIFEST.MF in local file header is not in central directory Warning: Entry METAMINF/AANIFEST.MF in central directory is not in local file header Warning: Entry METAMINF/BANIFEST.MF in central directory is not in local file header
> 
> Without looking into this in finer detail I am not sure what the issue is and is why the other tests typically use the actual offset to modify.

Simply put, a byte in the bytearray could be extend to more than one byte with UTF-8. The base we start to looking for the character is recorded as in the bytearray. Thus could lead we start looking at wrong place. I didn't look into exactly how this happens.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2103056825

From henryjen at openjdk.org  Thu May 22 17:51:43 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 22 May 2025 17:51:43 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v14]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <Xt0Q1aw4NmuzkXXJYvBOdXJroiSn5o1vyb9cityXG5U=.3b89c4a0-517c-49e5-b4b3-23120f42aa8c@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:

  Minor tweaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/5118aba4..bf82d668

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

  Stats: 7 lines in 3 files changed: 3 ins; 1 del; 3 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 prr at openjdk.org  Thu May 22 21:45:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:45:52 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:

> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
> 48:  * <p>
> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>

This is javadoc inJava SE specification. As is the Action case below.
I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:

> 61: 
> 62:     private static final String INSTRUCTIONS =
> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "

I really don't like these tests being changed. It isn't part of the JDK build.
People compile these in all sorts of locales.
Please revert all the changes in the client tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874

From jlahoda at openjdk.org  Fri May 23 04:38:04 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 23 May 2025 04:38:04 GMT
Subject: Integrated: 8356894: Adjust CreateSymbols to properly handle the newly
 added @jdk.internal.RequiresIdentity
In-Reply-To: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
References: <ogbpeirpMdaU76tosO9UtbDBGIq6iqagiQBPIXDBHcU=.cb2c366e-26f3-46f8-8b76-66b1d3c7150e@github.com>
Message-ID: <55TogwCOwcByQgs-FtTKTZOna2XMkJtr4tIkrLym2B4=.34352836-195c-4a44-8061-5d6c567b0743@github.com>

On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`.
> 
> Important parts of the patch:
> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations
> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations.
> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation`
> - for type variables, the synthetic annotation is filtered out in the API method

This pull request has now been integrated.

Changeset: 9d9e41f5
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d9e41f5b4ea70a32871ea6f03a21e3d77212289
Stats:     543 lines in 12 files changed: 513 ins; 14 del; 16 mod

8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity

Reviewed-by: vromero, liach

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

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

From alanb at openjdk.org  Fri May 23 08:21:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 May 2025 08:21:58 GMT
Subject: RFR: 8355022: Implement JEP 506: Scoped Values [v8]
In-Reply-To: <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
 <-C0JVzsxoQlBvSZWfee6q1s18AkI0NVQVEMvEhkN5Og=.96872ba4-4d2e-450a-8c10-b789911b45fc@github.com>
Message-ID: <Gh8p5Gwv5on4_WbiMwMctJ8Jxow8OTo5Ze2FNpbIlGU=.259a08ec-564b-4db2-b898-7d1f034dd10f@github.com>

On Thu, 22 May 2025 15:09:12 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 with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge from JDK head
>  - Fix merge
>  - 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
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/12efc1fe...460d82bd

CSR is approved, I think this update is ready to integrate.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24923#pullrequestreview-2863611886

From abimpoudis at openjdk.org  Fri May 23 09:11:02 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 23 May 2025 09:11:02 GMT
Subject: Integrated: 8343580: Type error with inner classes of generic classes
 in functions generic by outer
In-Reply-To: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
Message-ID: <ywDAZ8boNpDg57_MlxprBI5h_AeZGrC1ztklrHBzW-Q=.3aabfe13-e238-41c5-85b4-18fc5d8e481c@github.com>

On Wed, 21 May 2025 09:55:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
> 
> 
> static abstract class Getters<T> {
>     abstract class Getter {
>         abstract T get();
>     }
> }
> 
> static class Usage<T, G extends Getters<T>> {
>     public T test(G.Getter getter) {
>         return getter.get(); // incompatible types: Object cannot be converted to T
>     }
> }
> 
> 
> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.

This pull request has now been integrated.

Changeset: 02995887
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02995887b2a2554631f3d2bce03f8e3af6d0bafc
Stats:     67 lines in 2 files changed: 66 ins; 0 del; 1 mod

8343580: Type error with inner classes of generic classes in functions generic by outer

Reviewed-by: vromero

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

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

From mcimadamore at openjdk.org  Fri May 23 10:33:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 23 May 2025 10:33:57 GMT
Subject: RFR: 8343580: Type error with inner classes of generic classes in
 functions generic by outer [v2]
In-Reply-To: <QVXylK7tYNymExgBuMqF3u207bx6Rem66zc8ESn7Bjw=.30b96cf6-54b1-4719-934b-d736abb78bb9@github.com>
References: <8oXKqDhANPU2l1TYxB4iec2NYIxrnKNLk8fzHZng75o=.9e9ac31d-2ab4-4956-a122-8440a38f2fd4@github.com>
 <QVXylK7tYNymExgBuMqF3u207bx6Rem66zc8ESn7Bjw=.30b96cf6-54b1-4719-934b-d736abb78bb9@github.com>
Message-ID: <A0ldKpCxZVoEsIkG9QWo8q2nA5PRbtnnM8Njpb71Sao=.7e58a62f-016b-4f05-9a5c-8580dc213987@github.com>

On Thu, 22 May 2025 09:10:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> javac determines erroneously that `getter` has a raw type (`G.Getter`). The type of `getter` is deduced as the raw type `Getters<T>.Getter` by javac. Thus, the `Object` in the following example. The question is whether it should be treated as raw or not in the scenario where the qualifying type *is* a type parameter, as in `G.Getter`. In this case `Getter` is inherited from the supertype `Getters<T>`:
>> 
>> 
>> static abstract class Getters<T> {
>>     abstract class Getter {
>>         abstract T get();
>>     }
>> }
>> 
>> static class Usage<T, G extends Getters<T>> {
>>     public T test(G.Getter getter) {
>>         return getter.get(); // incompatible types: Object cannot be converted to T
>>     }
>> }
>> 
>> 
>> It seems that this is a compiler bug. According to 4.8 Raw Types a ?rare? type occurs when the inner is a partially raw type but the definition of Getter doesn?t take any type variables, so this is not a case of a "rare" type. `G.Getter` describes a type with a qualifying type being a type parameter which is not raw and moreover there is an instantiation of its bound. Simply not looking into the bounds of `G` seems like a compiler bug.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

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

> 1153:             if (allparams_field == null) {
> 1154:                 Type enclosingType = getEnclosingType();
> 1155:                 while (enclosingType.hasTag(TYPEVAR)) {

Note we can also use `Types::skipTypeVars` here (which brings up the question whether we should stop at regular tvars, or also keep going for captured tvars)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25346#discussion_r2104304045

From abimpoudis at openjdk.org  Fri May 23 14:59:30 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 23 May 2025 14:59:30 GMT
Subject: Integrated: 8357654: [BACKOUT] JDK-8343580: Type error with inner
 classes of generic classes in functions generic by outer
Message-ID: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>

While the original fix, addresses the type checking issue, we believe its worth-backing out this change to investigate the implications of the fix to the generated code.

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

Commit messages:
 - 8357654: [BACKOUT] JDK-8343580: Type error with inner classes of generic classes in functions generic by outer

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

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

From mcimadamore at openjdk.org  Fri May 23 14:59:30 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 23 May 2025 14:59:30 GMT
Subject: Integrated: 8357654: [BACKOUT] JDK-8343580: Type error with inner
 classes of generic classes in functions generic by outer
In-Reply-To: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
References: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
Message-ID: <tVYU6XVlU9eMeucOu7HTdu3dhBQYDQ5-DxNwcmR7ook=.cef40f8c-41da-44a4-864b-fd715d2ca446@github.com>

On Fri, 23 May 2025 14:50:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the original fix, addresses the type checking issue, we believe its worth-backing out this change to investigate the implications of the fix to the generated code.

Looks good - thanks

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25417#pullrequestreview-2864709019

From liach at openjdk.org  Fri May 23 14:59:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 14:59:30 GMT
Subject: Integrated: 8357654: [BACKOUT] JDK-8343580: Type error with inner
 classes of generic classes in functions generic by outer
In-Reply-To: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
References: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
Message-ID: <rMNTqamRoKjPiBK7nKIfvrgnTvm3C77ev_sjFAxBmsI=.c05e0615-5609-4747-89e7-d4f381e20489@github.com>

On Fri, 23 May 2025 14:50:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the original fix, addresses the type checking issue, we believe its worth-backing out this change to investigate the implications of the fix to the generated code.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25417#pullrequestreview-2864710867

From vromero at openjdk.org  Fri May 23 14:59:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 May 2025 14:59:30 GMT
Subject: Integrated: 8357654: [BACKOUT] JDK-8343580: Type error with inner
 classes of generic classes in functions generic by outer
In-Reply-To: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
References: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
Message-ID: <9CCWYDm9wEIi0HoSnhBURVsls_rG6qsPufcJViI1GnE=.ceb1e303-c95f-43c1-9c19-e1fd12dbd4a7@github.com>

On Fri, 23 May 2025 14:50:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the original fix, addresses the type checking issue, we believe its worth-backing out this change to investigate the implications of the fix to the generated code.

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25417#pullrequestreview-2864715367

From abimpoudis at openjdk.org  Fri May 23 14:59:30 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 23 May 2025 14:59:30 GMT
Subject: Integrated: 8357654: [BACKOUT] JDK-8343580: Type error with inner
 classes of generic classes in functions generic by outer
In-Reply-To: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
References: <SBSKJvsjs9FKyrSqWajE4dRnFWlUy2yvuMcT6sfNOC8=.8e6f75ab-3451-483b-a5a1-8fa19180833b@github.com>
Message-ID: <pvX8GWer5PY1pa6hbwgzD22XNopCuX_EdnriYJOBfhk=.38e7005d-38ff-4e62-8a05-628a34816e3a@github.com>

On Fri, 23 May 2025 14:50:45 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> While the original fix, addresses the type checking issue, we believe its worth-backing out this change to investigate the implications of the fix to the generated code.

This pull request has now been integrated.

Changeset: 90e076b2
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90e076b2a1ee5f91317157911e2c62a37978e93e
Stats:     67 lines in 2 files changed: 0 ins; 66 del; 1 mod

8357654: [BACKOUT] JDK-8343580: Type error with inner classes of generic classes in functions generic by outer

Reviewed-by: mcimadamore, liach, vromero

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

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

From liach at openjdk.org  Sun May 25 05:42:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 05:42:51 GMT
Subject: RFR: 8355004: Apply java.io.Serial annotations in java.compiler
In-Reply-To: <EjYU0xWKXOtcYBMvj_ln9hlQJoPDmG3BnH_GW-TXQ7s=.5d4cbe78-82e7-44e6-8398-456f614c3e71@github.com>
References: <EjYU0xWKXOtcYBMvj_ln9hlQJoPDmG3BnH_GW-TXQ7s=.5d4cbe78-82e7-44e6-8398-456f614c3e71@github.com>
Message-ID: <fapjyrIU-vZnKy3DPE6aos5CTeoW_Tv4uIAV8mwzeMo=.e367b6df-d856-4bba-88c4-7cb8cbd2c386@github.com>

On Fri, 25 Apr 2025 22:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the compiler module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.
> 
> This annotation can be applied to these methods in the module:
> 
> private void writeObject(java.io.ObjectOutputStream stream) throws IOException
> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
> private void readObjectNoData() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
> private static final ObjectStreamField[] serialPersistentFields
> private static final long serialVersionUID
> 
> Any feedback or suggestions are welcome!

I think this addition looks fine. Please wait till next week for someone else to review too.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24891#pullrequestreview-2866730028

From 333alaamo at gmail.com  Sun May 25 11:26:37 2025
From: 333alaamo at gmail.com (Alaa Mohamed)
Date: Sun, 25 May 2025 14:26:37 +0300
Subject: =?UTF-8?Q?Fwd=3A_=22Scoped_Mutable_Variables=22=E2=80=8F?=
In-Reply-To: <CAHwS11zaY7KYB2N+L71umyk1ieuGE6fe65Sbcb+JDCK7UgJGKA@mail.gmail.com>
References: <CAHwS11zaY7KYB2N+L71umyk1ieuGE6fe65Sbcb+JDCK7UgJGKA@mail.gmail.com>
Message-ID: <CAHwS11zscsHwAB2gSkbjy37JVvF9kd3ouGya8irvEX5kASWyZw@mail.gmail.com>

---------- Forwarded message ---------
??: Alaa Mohamed <333alaamo at gmail.com>
?Date: ?????? 24 ???? 2025 ?? 6:31 ??
?Subject: "Scoped Mutable Variables"??
To: <compiler-dev at openjdk.org>


Dear OpenJDK Reviewers and Community,

I hope this message finds you well.

Please find attached my draft Java Enhancement Proposal (JEP) titled
"Scoped Mutable Variables" (JEP XXXX), which introduces a new variable
declaration modifier scoped. This modifier allows variables to be mutable
exclusively within a limited lexical scope (such as inside if, for, or
while blocks) without affecting the variable?s value in the enclosing or
global scope.

This proposal aims to reduce unintended side effects caused by variable
mutations in nested blocks, thereby improving code safety and readability
in large-scale Java projects.

I would appreciate any feedback or suggestions you may have on the design,
naming, integration approach, or any other aspect of the proposal.

Please find the full proposal text attached (or below).

Thank you very much for your time and consideration.

Best regards,
Alaa Mohamed
[ GitHub - alaa-333/scoped-variable-jep
<https://github.com/alaa-333/scoped-variable-jep.git> ]

[ LinkedIn :
https://www.linkedin.com/in/alaa-mohamed-1468a3304?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BOH8SwytOQoO2HCH0VxvdBA%3D%3D
]
Also for more details : Java Enhancement Proposal (JEP) (1).pdf
<
https://drive.google.com/file/d/1P-k9XfpRzLdnuOYUpBUFfPaHBGWHjM9z/view?usp=sharing
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250525/c8a48fac/attachment.htm>

From ihse at openjdk.org  Mon May 26 07:47:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 07:47:02 GMT
Subject: RFR: 8356977: UTF-8 cleanups
In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
Message-ID: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>

On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
> 
>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
> 
> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 

However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160

From ihse at openjdk.org  Mon May 26 08:20:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:19 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685

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

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

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

From ihse at openjdk.org  Mon May 26 08:20:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:46 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>

On Thu, 22 May 2025 21:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:
> 
>> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
>> 48:  * <p>
>> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>
> 
> This is javadoc inJava SE specification. As is the Action case below.
> I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. 

I did this since I thought it increased readability of the source code, but I can just as well revert it.

> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
> 
>> 61: 
>> 62:     private static final String INSTRUCTIONS =
>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
> 
> I really don't like these tests being changed. It isn't part of the JDK build.
> People compile these in all sorts of locales.
> Please revert all the changes in the client tests.

Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.

The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?

Let me know if you still want me to revert it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184

From ihse at openjdk.org  Mon May 26 08:21:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:21:16 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>

On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:

> 88:                 printKey(e);
> 89:                 int keychar = e.getKeyChar();
> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b

@prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:

> 186:                     +          "\"After\" lists.\n"
> 187:                     + "              Added printers are highlighted with "
> 188:                     +               "green color, removed ones \u2014 with "

@prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.

Do you still want me to revert it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974

From nbenalla at openjdk.org  Mon May 26 13:07:06 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 May 2025 13:07:06 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v4]
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: <Y-US_zsDrvpXFTDX_K06PCjmzy6GVc6Vra1zRUaO3CE=.bab51f96-780a-44b3-9416-7780435ed4c0@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 14 commits:

 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - 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
 - ... and 4 more: https://git.openjdk.org/jdk/compare/bd095896...b79e5022

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=03
  Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 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 abimpoudis at openjdk.org  Mon May 26 16:10:33 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 26 May 2025 16:10:33 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw types in
 signatures
Message-ID: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>

In the following example, `G.Getter` is erroneously treated as a raw type by javac:


static abstract class Getters<X> {
  abstract class Getter {
      abstract X get();
  }
}

static class Usage1<T, G extends Getters<T>> {
  public T test(G.Getter getter) {
      return getter.get();
  }
}


The (now reverted) https://github.com/openjdk/jdk/pull/25346 attempted to fix this by skipping type variables in the calculation of `allparams()`. 

While that seemed to fix the type checking error, it was a fragile solution in a number of ways. 

- `allparams()` is passed to a method that calculates substitutions. This signals that the method adheres to invariants during substitutions where lists of type parameters are expected to be of the same length (for the from and to parts). Affecting directly the `allparams_field` seems not the right approach. 
- Another observation (thx @liach) was that in the generated bytecode, the fully qualified type of the inner class `G` still appeared as if it originated from a raw type. `assembleClassSig` independently examines `outer` to detect whether it is raw or not.
- Finally, there is already a proper area in javac, earlier in the pipeline, where javac handles/detects "rare types" (`test/langtools/tools/javac/generics/rare`): That method is `checkId` and specifically `checkIdInternal`. While in the general case the type of an identifier is the symbol's type, `checkIdInternal` computes a new type in two occasions. In one of those occasions, `checkIdInternal` is computing the type when the symbol's type is an inner class. Here, we can start normalizing (by skipping the type variables).

Moreover, it has been observed that `asEnclosingSuper` is a generalization of `asOuterSuper` and additionally the former is used only in `checkIdInternal`. As a result, this PR performs two simplifications:

As a first simplification this PR replaces `asOuterSuper` with `asEnclosingSuper`.
As a second simplification this PR relies only on the owner's `enclClass()` based on the following subsequent observations:
- An `enclosingType()` call returns the `outer_field` directly and `Type.noType` otherwise (in the case of an inner class it refers to the type of its enclosing instance class.)
- An `enclClass()` call returns the closest enclosing class and the behavior in `asEnclosingSuper` containing a loop with the condition `t.hasTag(CLASS)` combined with `asSuper(t, sym)` is believed to be the same.

The test now includes bytecode tests additionally to the reflection-based reproducer and the original test case.

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

Commit messages:
 - 8357653: Inner classes of type parameters emitted as raw types in signatures

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

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

From mcimadamore at openjdk.org  Mon May 26 17:13:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 May 2025 17:13:51 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <eckbWGs2pJgJNligzHJ35Pw7snCPO0f7ByjGBvr-5wk=.3799a028-37f8-4331-9551-ed52213540f8@github.com>

On Mon, 26 May 2025 15:51:06 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In the following example, `G.Getter` is erroneously treated as a raw type by javac:
> 
> 
> static abstract class Getters<X> {
>   abstract class Getter {
>       abstract X get();
>   }
> }
> 
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> 
> The (now reverted) https://github.com/openjdk/jdk/pull/25346 attempted to fix this by skipping type variables in the calculation of `allparams()`. 
> 
> While that seemed to fix the type checking error, it was a fragile solution in a number of ways. 
> 
> - `allparams()` is passed to a method that calculates substitutions. This signals that the method adheres to invariants during substitutions where lists of type parameters are expected to be of the same length (for the from and to parts). Affecting directly the `allparams_field` seems not the right approach. 
> - Another observation (thx @liach) was that in the generated bytecode, the fully qualified type of the inner class `G` still appeared as if it originated from a raw type. `assembleClassSig` independently examines `outer` to detect whether it is raw or not.
> - Finally, there is already a proper area in javac, earlier in the pipeline, where javac handles/detects "rare types" (`test/langtools/tools/javac/generics/rare`): That method is `checkId` and specifically `checkIdInternal`. While in the general case the type of an identifier is the symbol's type, `checkIdInternal` computes a new type in two occasions. In one of those occasions, `checkIdInternal` is computing the type when the symbol's type is an inner class. Here, we can start normalizing (by skipping the type variables).
> 
> Moreover, it has been observed that `asEnclosingSuper` is a generalization of `asOuterSuper` and additionally the former is used only in `checkIdInternal`. As a result, this PR performs two simplifications:
> 
> As a first simplification this PR replaces `asOuterSuper` with `asEnclosingSuper`.
> As a second simplification this PR relies only on the owner's `enclClass()` based on the following subsequent observations:
> - An `enclosingType()` call returns the `outer_field` directly and `Type.noType` otherwise (in the case of an inner class it refers to the type of its enclosing instance class.)
> - An `enclClass()` call returns the closest enclosing class and the behavior in `asEnclosingSuper` containing a loop with the condition `t.hasTag(CLASS)` combined with `asSuper(t, sym)` is believed to be the same.
> 
> The test now includes bytecode tests additionally t...

Looks good - I'm unsure whether we should unify the two routines as part of this fix, or if we wanna keep that for a separate PR (given that might be a potential extra risk)

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

PR Comment: https://git.openjdk.org/jdk/pull/25451#issuecomment-2910293331

From henryjen at openjdk.org  Tue May 27 16:23:47 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 27 May 2025 16:23:47 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into open
 - Merge remote-tracking branch 'openjdk/master' into open
 - Minor tweaks
 - Assure >0 exit code and fix typos
 - Validator to take a file, use term JAR file
 - Mismatched order is considered invalid
 - Adapt review feedback
 - Address review feedback
 - Adjust message based on review feedback
 - Move all validation into EntryValidator, update the document
 - ... and 7 more: https://git.openjdk.org/jdk/compare/e7422102...2690e69f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/bf82d668..2690e69f

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

  Stats: 130765 lines in 2801 files changed: 79963 ins; 35168 del; 15634 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 naoto at openjdk.org  Tue May 27 16:37:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:37:56 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
 <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
Message-ID: <rUvIFs4xs4inLQJ40ELv5mF0_MjWmQMrZ5VTSmltBnk=.80b73a56-2930-4ce3-ace5-c25766698954@github.com>

On Mon, 26 May 2025 07:44:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
>> 
>>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
>> 
>> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.
>
> ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 
> 
> However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

Thanks. Filed an issue to change the encoding in the test to UTF-8: https://bugs.openjdk.org/browse/JDK-8357882

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2109668481

From vromero at openjdk.org  Tue May 27 19:46:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 27 May 2025 19:46:50 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <dlwidNn6RF0VhDY9ogPcmCjLik9vR3i5jnY9OnYO67I=.9bcf80cb-ae2f-42ea-b8bd-e2e076f95953@github.com>

On Mon, 26 May 2025 15:51:06 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In the following example, `G.Getter` is erroneously treated as a raw type by javac:
> 
> 
> static abstract class Getters<X> {
>   abstract class Getter {
>       abstract X get();
>   }
> }
> 
> static class Usage1<T, G extends Getters<T>> {
>   public T test(G.Getter getter) {
>       return getter.get();
>   }
> }
> 
> 
> The (now reverted) https://github.com/openjdk/jdk/pull/25346 attempted to fix this by skipping type variables in the calculation of `allparams()`. 
> 
> While that seemed to fix the type checking error, it was a fragile solution in a number of ways. 
> 
> - `allparams()` is passed to a method that calculates substitutions. This signals that the method adheres to invariants during substitutions where lists of type parameters are expected to be of the same length (for the from and to parts). Affecting directly the `allparams_field` seems not the right approach. 
> - Another observation (thx @liach) was that in the generated bytecode, the fully qualified type of the inner class `G` still appeared as if it originated from a raw type. `assembleClassSig` independently examines `outer` to detect whether it is raw or not.
> - Finally, there is already a proper area in javac, earlier in the pipeline, where javac handles/detects "rare types" (`test/langtools/tools/javac/generics/rare`): That method is `checkId` and specifically `checkIdInternal`. While in the general case the type of an identifier is the symbol's type, `checkIdInternal` computes a new type in two occasions. In one of those occasions, `checkIdInternal` is computing the type when the symbol's type is an inner class. Here, we can start normalizing (by skipping the type variables).
> 
> Moreover, it has been observed that `asEnclosingSuper` is a generalization of `asOuterSuper` and additionally the former is used only in `checkIdInternal`. As a result, this PR performs two simplifications:
> 
> As a first simplification this PR replaces `asOuterSuper` with `asEnclosingSuper`.
> As a second simplification this PR relies only on the owner's `enclClass()` based on the following subsequent observations:
> - An `enclosingType()` call returns the `outer_field` directly and `Type.noType` otherwise (in the case of an inner class it refers to the type of its enclosing instance class.)
> - An `enclClass()` call returns the closest enclosing class and the behavior in `asEnclosingSuper` containing a loop with the condition `t.hasTag(CLASS)` combined with `asSuper(t, sym)` is believed to be the same.
> 
> The test now includes bytecode tests additionally t...

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-2872391074

From aph at openjdk.org  Wed May 28 09:43:57 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 28 May 2025 09:43:57 GMT
Subject: Integrated: 8355022: Implement JEP 506: Scoped Values
In-Reply-To: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
References: <DtNEkijtR0hMkQ7CFEoGYu4njVYULCG7BtzUhkapeys=.c2db64c6-23ea-4e74-9e5d-c0691b7fc5f9@github.com>
Message-ID: <jyAtAbsUnBoPqw9O9MS0Ch9QpLy_tjDYPXWbbLrQmHQ=.2edb17a9-9892-4407-aacd-ef945fdcc319@github.com>

On Mon, 28 Apr 2025 14:32:04 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.

This pull request has now been integrated.

Changeset: 4e1878ca
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e1878ca452d1e781eb61610a94064c0c4798073
Stats:     21 lines in 6 files changed: 3 ins; 12 del; 6 mod

8355022: Implement JEP 506: Scoped Values

Reviewed-by: liach, alanb

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

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

From nbenalla at openjdk.org  Wed May 28 11:16:53 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 28 May 2025 11:16:53 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v4]
In-Reply-To: <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@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>
 <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@github.com>
Message-ID: <kJU-qnTMin0UfPHOcncu9cjt5dCCIfYRvckREpE46fw=.a93b3e4c-cae1-4400-a8e9-15901aa5afde@github.com>

On Thu, 8 May 2025 13:15:35 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

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

Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`.

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

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

From jpai at openjdk.org  Wed May 28 11:35:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 11:35:01 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
Message-ID: <dlxl8C_RYXiE2N1t6T2wIYGb1o5TNjNjKLl4PaLugKk=.6f0e6ec3-9985-44ae-9ee6-ca3c8e2d6b98@github.com>

On Tue, 27 May 2025 16:23:47 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - Adjust message based on review feedback
>  - Move all validation into EntryValidator, update the document
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/c5449eae...2690e69f

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

> 237:         /**
> 238:          * Validation per entry observed.
> 239:          * Each entry must appeare at least once in the CEN or LOC.

Typo - should have been "appear"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24430#discussion_r2111620712

From jpai at openjdk.org  Wed May 28 11:38:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 11:38:03 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
Message-ID: <rnKlvXRyXi9QDsx1w1lYr4ccaCSRo7JfCdcE6_Aqu38=.d2d72a2b-1a16-4550-846e-a169cb0bec87@github.com>

On Tue, 27 May 2025 16:23:47 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - Adjust message based on review feedback
>  - Move all validation into EntryValidator, update the document
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7b533d89...2690e69f

The CSR has been approved and the current changes in this PR look good to me. 
There's a typo in a comment which I've added as a review comment.
There's a test-only addition where I don't fully understand the use of ISO_8859_1 charset. I haven't had a chance to look deeper at that but we can look into it separately at a later date since it doesn't directly relate to this enhancement nor does it introduce an issue.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2874653370

From cstein at openjdk.org  Wed May 28 11:38:53 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 28 May 2025 11:38:53 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v4]
In-Reply-To: <kJU-qnTMin0UfPHOcncu9cjt5dCCIfYRvckREpE46fw=.a93b3e4c-cae1-4400-a8e9-15901aa5afde@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>
 <NZS8nG9pke2VR2jVtRZLeDMYst9ziR3FqvYdLxFOL14=.509579cd-046f-4c71-8cfa-952ffd787ca2@github.com>
 <kJU-qnTMin0UfPHOcncu9cjt5dCCIfYRvckREpE46fw=.a93b3e4c-cae1-4400-a8e9-15901aa5afde@github.com>
Message-ID: <3Ins14V5M3PnLXVBHH3sgqydHdmtaxrAERYbfG7egLc=.5ec6d31c-f442-482c-9f50-aa67f8e0f454@github.com>

On Wed, 28 May 2025 11:14:22 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I'll split the releases over  two lines in the next update. The line is a little too long.
>
> Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`.

Another variant:

        Supported releases:
            8, 9, 10, ..., 24, 25, 26

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

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

From lancea at openjdk.org  Wed May 28 14:16:03 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 May 2025 14:16:03 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v15]
In-Reply-To: <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <R2XmRmH21H4_GJDcM6Vb1W5eieDnJL5k7jP3q5jbU6E=.384615d4-266c-49d7-8289-08446f77f190@github.com>
Message-ID: <9K-ioqtKQX7ZFka8tIm8IdzSUolbK2ggmO6wSpCLL4s=.9ee58d7e-3f97-464d-a63a-1458dec47170@github.com>

On Tue, 27 May 2025 16:23:47 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - Adjust message based on review feedback
>  - Move all validation into EntryValidator, update the document
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/5b580735...2690e69f

Thank you Henry on your efforts here.

I think you are in good shape overall

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2875285938

From henryjen at openjdk.org  Wed May 28 14:53:39 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 28 May 2025 14:53:39 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v16]
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@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 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 19 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into open
 - Fix typo
 - Merge remote-tracking branch 'openjdk/master' into open
 - Merge remote-tracking branch 'openjdk/master' into open
 - Minor tweaks
 - Assure >0 exit code and fix typos
 - Validator to take a file, use term JAR file
 - Mismatched order is considered invalid
 - Adapt review feedback
 - Address review feedback
 - ... and 9 more: https://git.openjdk.org/jdk/compare/55443096...a0ebb6d6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24430/files
  - new: https://git.openjdk.org/jdk/pull/24430/files/2690e69f..a0ebb6d6

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

  Stats: 2813 lines in 126 files changed: 1269 ins; 1101 del; 443 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 lancea at openjdk.org  Wed May 28 15:22:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 May 2025 15:22:58 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v16]
In-Reply-To: <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
Message-ID: <MgGgWNeaNBRkGMTDMVPzM4dssIuhAsinaZ7nha8T794=.e1c9fc18-cd7c-49de-8dcb-ff81645eedb2@github.com>

On Wed, 28 May 2025 14:53:39 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 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 19 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Fix typo
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/3a5be830...a0ebb6d6

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2875523868

From jpai at openjdk.org  Wed May 28 15:44:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 May 2025 15:44:57 GMT
Subject: RFR: 8345431: Improve jar --validate to detect duplicate or
 invalid entries [v16]
In-Reply-To: <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
 <otkR4SEwHoevAGCQ6Bfg25tIq40iHP2V9s_Pvj6S-Sk=.2179e6a0-8cb9-4cd9-b942-8f2262563401@github.com>
Message-ID: <02AMYQvFlloCH8I4wcpHunxObA15KhVI9N4OHTtgczQ=.80e2abab-931d-4596-aa3f-a4892c3b9330@github.com>

On Wed, 28 May 2025 14:53:39 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 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 19 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Fix typo
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Merge remote-tracking branch 'openjdk/master' into open
>  - Minor tweaks
>  - Assure >0 exit code and fix typos
>  - Validator to take a file, use term JAR file
>  - Mismatched order is considered invalid
>  - Adapt review feedback
>  - Address review feedback
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/950811e8...a0ebb6d6

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24430#pullrequestreview-2875596948

From henryjen at openjdk.org  Wed May 28 17:26:01 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 28 May 2025 17:26:01 GMT
Subject: Integrated: 8345431: Improve jar --validate to detect duplicate or
 invalid entries
In-Reply-To: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
References: <rhvn8UHhwQftUs5re0LtICFDJzbaQ3wh_85ZwVpOyBk=.ad975e4f-5f64-4b61-967f-f4a8a71ff145@github.com>
Message-ID: <5syKoPg8rti1oBn5bVi8Um_6jZ493GNp6QudvhhhWwM=.6fa9cfbd-d91e-49c3-b6f5-1d7eebd84435@github.com>

On Fri, 4 Apr 2025 00:39:04 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.

This pull request has now been integrated.

Changeset: cd052c72
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd052c72cdb62186e66c1d2ecf9216f3df61b242
Stats:     599 lines in 5 files changed: 584 ins; 3 del; 12 mod

8345431: Improve jar --validate to detect duplicate or invalid entries

Reviewed-by: lancea, jpai

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

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

From duke at openjdk.org  Wed May 28 18:15:58 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 18:15:58 GMT
Subject: Withdrawn: 8349847: Support configuring individual lint categories as
 errors
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: <x5_NYLhTV-4zCNLhh2QkraUEcbvx44QX5JYu0yvagtI=.f38b1171-e8c1-497a-afd8-b3d5db5a3b7c@github.com>

On Thu, 13 Feb 2025 20:52:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> 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

This pull request has been closed without being integrated.

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

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

From prr at openjdk.org  Wed May 28 20:55:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
 <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
Message-ID: <Dq8Agr8pnvykN7oNGPzTQnNO77rhD_M8j1caxF-mY4M=.867b19b6-ce18-4656-b52b-4fd5ec84d834@github.com>

On Mon, 26 May 2025 07:55:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:
> 
>> 88:                 printKey(e);
>> 89:                 int keychar = e.getKeyChar();
>> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b
> 
> @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

You are right, that's a typo. Keep your change.
And I don't know why the code uses literal 27 instead of KeyEvent.VK_ESCAPE .. but that's not your problem.

https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.event.KeyEvent.VK_ESCAPE

> test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:
> 
>> 186:                     +          "\"After\" lists.\n"
>> 187:                     + "              Added printers are highlighted with "
>> 188:                     +               "green color, removed ones \u2014 with "
> 
> @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.
> 
> Do you still want me to revert it?

I agree. Keep your change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112722311
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112731040

From prr at openjdk.org  Wed May 28 20:55:04 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:04 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
 <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
Message-ID: <BW-jmv0CMo_qRngDZcLpY3s8yH_WYkD_YyhGiDyDeVU=.5292f832-a0ab-4a8f-9792-6c8005697e45@github.com>

On Mon, 26 May 2025 08:07:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
>> 
>>> 61: 
>>> 62:     private static final String INSTRUCTIONS =
>>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
>> 
>> I really don't like these tests being changed. It isn't part of the JDK build.
>> People compile these in all sorts of locales.
>> Please revert all the changes in the client tests.
>
> Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.
> 
> The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?
> 
> Let me know if you still want me to revert it.

I'd like this reverted.
People *build* these tests in their local repos using javac and whatever their locale is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112728971

From nbenalla at openjdk.org  Thu May 29 13:42:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 29 May 2025 13:42:34 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v5]
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: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@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 16 commits:

 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - Update release date
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=04
  Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 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 mcimadamore at openjdk.org  Thu May 29 14:32:54 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 29 May 2025 14:32:54 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: <MVstc1eZjs-2uKocTt2D3Y_lO8YeN8Or80mb_selPvM=.1da5d58e-b822-4280-a63b-160bb944ac61@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <sFPzk753a6n7_uC-xcQNyXhRkXTgCyevyr56g5O2HeY=.a6635ed5-3756-4b68-8430-28848e62a381@github.com>
 <I6THxHpl81BfBrlQYq6g4LS_gtQNa5FoCZVTUltt5aI=.15b52769-8f4a-45be-b917-193fb5db637b@github.com>
 <MVstc1eZjs-2uKocTt2D3Y_lO8YeN8Or80mb_selPvM=.1da5d58e-b822-4280-a63b-160bb944ac61@github.com>
Message-ID: <yibTsPV2LthPlElLEeDbFyKkCagYcTQQ7ljTATFNiSM=.505f53cc-da21-4ae9-8d7a-a9bc1d9dae4a@github.com>

On Thu, 10 Apr 2025 20:45:21 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> In the sketch I was doing a few days back, I was peeking at forcing some kind of `EndPosTable` argument to `TreeInfo.endPos`, but I shied away as it seemed to complicate things. Here I see it is not as bad as I thought, but still it spreads a bit.
>> 
>> I see the value in avoiding special field and code path for the AST nodes for which the end pos is mandatory, in addition to the optional EndPosTable.
>> 
>> I think I would still slightly prefer the specialized fields, esp. if the impact on mostly unrelated outside code (like TransPatterns and Gen) could be eliminated. I would like to investigate if we can drop the EndPosTable altogether, although that is unlikely to happen before JDK 25 RPD1 (maybe 2). But, there is, of course, a possibility that the removal of EndPosTable won't happen, at which point we would have the duplication.
>> 
>> But, I can live with a patch long the lines here adding EndPosTable to `TreeInfo.endPos` if needed. Should we drop the EndPosTable as some point, we can drop the new EndPosTable argument. If not, we would preserve it. It is not what I would do, but I don't think either of the solutions is clearly wrong.
>
> @lahodaj, thanks for your thoughts.
> 
> I agree it's not ideal either way. The thing that kindof pushes it in the `EndPosTable` direction for me is this: As long as we have `DiagnosticListener`'s and `-Xjcov`, we have a (sometimes) requirement to track the ending positions of _every_ node. So as long as we are required to have code that does that, why not just use it? Then we have only one mechanism for doing something, instead of two.
> 
> Practically speaking: @mcimadamore are you OK to proceed with the current approach?
> 
> In any case, it's not a tragedy if we change our minds in the future - removing `EndPosTable` or switching back to the previous approach is easy to do (and I'm happy to volunteer if needed).
> 
> Thanks.

Hi @archiecobbs. I took another look at how javac is structured in this area (with the help of @lahodaj). `TreeInfo` has two slightly different methods (maybe this is all obvious to you, but repeating here just in case):

* `TreeInfo::endPos` -- this is an internal method, only used by javac which, in reality, doesn't have a lot to do with end positions. It is mostly used as a way to retrieve the position at the end of a block (e.g. where a new statement should be appended), and is used mostly for code generation purposes (e.g. tells javac where synthetic code should be added), or where errors should be emitted -- this is especially the case in `Flow`, which uses `TreeInfo::diagEndPos` which uses this. This method does NOT depend on an `EndPosTable` -- it does all it needs by using a couple of dedicated fields in `JCBlock` and `JCSwitch`/`JCSwitchExpression`.
* `TreeInfo::getEndPos` -- this is the method that accesses the `EndPosTable`, looking for the end position of a given tree. This method is used by `JavacTrees`, so used also externally. If there's no `EndPosTable` (e.g. the table is set to null), this method delegates to `TreeInfo::endPos`, but I'm not sure this ever happens, given that when we don't want end positions we tend to use the `EmptyEndPosTable` -- which simply disregards end pos information. In other words, the end pos table is never `null`, which means this method returns `NOPOS` when the end pos table is not in effect.

Now, it seems to me that the changes you are after have nothing to do with the first method. You want extra end pos information for modules, packages, classes, methods, fields -- e.g. places where a `@SuppressWarnings` annotation might go. As such, I think this PR should not touch `TreeInfo::endPos` at all. It should only define the minimal end pos table to make sure that enough end positions are captured _at all times_, but no more than that. More specifically, the part where we replace fields in `JCTree` with the use of the minimal end pos table seems bad, as the fields are there to support `TreeInfo::endPos` which strictly speaking, has nothing to do with warning suppression (not now, not in the future).

If you want to rename the `endPos` fields in the AST nodes to `bracePos` that's fine -- but I think `TreeInfo::endPos` should remain unchanged, and that your other code that needs end position information should instead use `TreeInfo.getEndPos`, which will be augmented thanks to your new minimal end pos table. Again, optionally, we might want to rename `TreeInfo::endPos` to something like `TreeInfo::blockLastPos` or something like that.

In the future, we might revisit, at some point, whether storing end positions in a separate side-table is still the most effective way to do things -- but that discussion can happen separately from this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2919583647

From coleenp at openjdk.org  Thu May 29 15:50:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 May 2025 15:50:54 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v5]
In-Reply-To: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com>
Message-ID: <oIv_bpXjTGEX1E8uH7xSeklJlxq9I3guFzqsN3pUxA4=.cdc58dd4-bcbd-4619-b0c4-05423d517a10@github.com>

On Thu, 29 May 2025 13:42:34 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 16 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - Update release date
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6

Hotspot changes look good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2878772498

From serb at openjdk.org  Thu May 29 15:58:15 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 29 May 2025 15:58:15 GMT
Subject: RFR: 8355004: Apply java.io.Serial annotations in java.compiler
 [v2]
In-Reply-To: <EjYU0xWKXOtcYBMvj_ln9hlQJoPDmG3BnH_GW-TXQ7s=.5d4cbe78-82e7-44e6-8398-456f614c3e71@github.com>
References: <EjYU0xWKXOtcYBMvj_ln9hlQJoPDmG3BnH_GW-TXQ7s=.5d4cbe78-82e7-44e6-8398-456f614c3e71@github.com>
Message-ID: <ZxcYLW0svvjawTqVnbHuqiAZtSSMKiJ63hxK_Wo5VEg=.a8a4320d-3385-467d-a8dd-c0c850b435b9@github.com>

> Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the compiler module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.
> 
> This annotation can be applied to these methods in the module:
> 
> private void writeObject(java.io.ObjectOutputStream stream) throws IOException
> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
> private void readObjectNoData() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
> private static final ObjectStreamField[] serialPersistentFields
> private static final long serialVersionUID
> 
> Any feedback or suggestions are welcome!

Sergey Bylokhov 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 'openjdk:master' into serial_compiler
 - use long literals
 - Apply java.io.Serial annotations in java.compiler

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24891/files
  - new: https://git.openjdk.org/jdk/pull/24891/files/af94d056..9dfe7802

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

  Stats: 200451 lines in 4118 files changed: 134696 ins; 45967 del; 19788 mod
  Patch: https://git.openjdk.org/jdk/pull/24891.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24891/head:pull/24891

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

From vromero at openjdk.org  Thu May 29 17:52:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 May 2025 17:52:52 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field
In-Reply-To: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
Message-ID: <D-YBylQkGVW33IWoDoZwj2zhWhrFF2eeSk1eUVkMZeU=.edb62b42-3314-4367-a97e-98d5512a2170@github.com>

On Mon, 28 Apr 2025 17:08:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
> 
> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
> 
> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 387:

> 385:         // Sort warnings so redundant warnings immediately follow whatever they are redundant for, then remove them
> 386:         warningList.sort(Warning::sortByStackFrames);
> 387:         AtomicReference<Warning> previousRef = new AtomicReference<>();

just curious: why do we need to deal with AtomicReference here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114462853

From vromero at openjdk.org  Thu May 29 19:01:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 May 2025 19:01:53 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field
In-Reply-To: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
Message-ID: <mT39xjG28qGK0eBvJzma2PtKUln8TLBgHdp6b5ap35k=.9089fc89-d7b2-41bf-bd20-448e22229cb7@github.com>

On Mon, 28 Apr 2025 17:08:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
> 
> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
> 
> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.

test/langtools/tools/javac/warnings/ThisEscape.java line 779:

> 777: 
> 778:         @SuppressWarnings("this-escape")
> 779:         private SuppressedIndirectLeakViaField(String s) {

what if there is another constructor not annotated with @SuppressWarnings? I guess we should include a test case for that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114565229

From prr at openjdk.org  Thu May 29 19:08:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:08:54 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <dVw-4Yl3AI2y1kYAwY1rgjjRrqCSiIVv2UN-UHuJtB0=.81a20509-7795-4ad7-b7c9-f42970d65318@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

Approving client changes

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2879326497

From vromero at openjdk.org  Thu May 29 19:24:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 May 2025 19:24:52 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field
In-Reply-To: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
Message-ID: <uSv0l0ZwSiMFWmgZViNqs1eBi10n-uMWrz98L0Ls6R8=.41d3b67d-0409-446a-baee-3b5e6bd8c96d@github.com>

On Mon, 28 Apr 2025 17:08:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
> 
> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
> 
> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.

test/langtools/tools/javac/warnings/ThisEscape.java line 769:

> 767:     }
> 768: 
> 769:     // JDK-8355753 - @SuppressWarnings("this-escape") not respected for indirect leak via field

nit: consider adding a similar test case with an additional constructor that is not annotated with the @SuppressAnnotations annotation so that the warning is issued

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114606353

From vromero at openjdk.org  Thu May 29 19:50:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 May 2025 19:50:53 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field
In-Reply-To: <uSv0l0ZwSiMFWmgZViNqs1eBi10n-uMWrz98L0Ls6R8=.41d3b67d-0409-446a-baee-3b5e6bd8c96d@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <uSv0l0ZwSiMFWmgZViNqs1eBi10n-uMWrz98L0Ls6R8=.41d3b67d-0409-446a-baee-3b5e6bd8c96d@github.com>
Message-ID: <vWQVTvLQBtSR0utNPLeTmMPhsV1KLdTd8OEK5he5xhk=.7adaf276-bed4-4e34-be5b-b257ee519598@github.com>

On Thu, 29 May 2025 19:22:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> nit: consider adding a similar test case with an additional constructor that is not annotated with the @SuppressAnnotations annotation so that the warning is issued

and probably another variation doing something like:

        private int x;

        {
            x = this.mightLeak();
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114642905

From acobbs at openjdk.org  Thu May 29 21:25:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 29 May 2025 21:25:38 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v2]
In-Reply-To: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
Message-ID: <SnuVd-GnSJ1Y57odmal2X2xvAYHgOKWOdEx7iTpuuvo=.ff639295-7927-4c37-98de-3a38d1819eda@github.com>

> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
> 
> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
> 
> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.

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

 - Add additional tests for warnings generated from fields.
 - Merge branch 'master' into JDK-8355753
 - Refactor ThisEscapeAnalyzer to correct bug in suppression logic.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24932/files
  - new: https://git.openjdk.org/jdk/pull/24932/files/5ef9606f..65e2679e

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

  Stats: 163376 lines in 3307 files changed: 106119 ins; 39542 del; 17715 mod
  Patch: https://git.openjdk.org/jdk/pull/24932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24932/head:pull/24932

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

From acobbs at openjdk.org  Thu May 29 21:25:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 29 May 2025 21:25:38 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v2]
In-Reply-To: <D-YBylQkGVW33IWoDoZwj2zhWhrFF2eeSk1eUVkMZeU=.edb62b42-3314-4367-a97e-98d5512a2170@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <D-YBylQkGVW33IWoDoZwj2zhWhrFF2eeSk1eUVkMZeU=.edb62b42-3314-4367-a97e-98d5512a2170@github.com>
Message-ID: <NEwidsqjRAJ8lnFO1_VFMbZhqHniKiKLrnE3qipSFWA=.0608decd-f38a-46c3-a2f2-9e095e336d8c@github.com>

On Thu, 29 May 2025 17:50:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Add additional tests for warnings generated from fields.
>>  - Merge branch 'master' into JDK-8355753
>>  - Refactor ThisEscapeAnalyzer to correct bug in suppression logic.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 387:
> 
>> 385:         // Sort warnings so redundant warnings immediately follow whatever they are redundant for, then remove them
>> 386:         warningList.sort(Warning::sortByStackFrames);
>> 387:         AtomicReference<Warning> previousRef = new AtomicReference<>();
> 
> just curious: why do we need to deal with AtomicReference here?

Hi @vicente-romero-oracle, thanks for taking a look.

The reason for the `AtomicReference` is that this lamba needs to be stateful (it needs to remember the most recent previous `Warning` that was also retained, if any), so if it wants to remain a lambda (i.e., and not a more verbose inner class) that state needs to be declared outside the lamba, and therefore it must be effectively final, which means there must be an extra level of indirection, etc. I guess it's a verbosity vs. clarity trade-off.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114770332

From acobbs at openjdk.org  Thu May 29 21:25:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 29 May 2025 21:25:38 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v2]
In-Reply-To: <vWQVTvLQBtSR0utNPLeTmMPhsV1KLdTd8OEK5he5xhk=.7adaf276-bed4-4e34-be5b-b257ee519598@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <uSv0l0ZwSiMFWmgZViNqs1eBi10n-uMWrz98L0Ls6R8=.41d3b67d-0409-446a-baee-3b5e6bd8c96d@github.com>
 <vWQVTvLQBtSR0utNPLeTmMPhsV1KLdTd8OEK5he5xhk=.7adaf276-bed4-4e34-be5b-b257ee519598@github.com>
Message-ID: <RFwBvw-0Bpe9pbEuUoMUgzl_TIzKZFEQduCHDyH5MoU=.8003d36c-6b3f-467c-a0b7-426448551739@github.com>

On Thu, 29 May 2025 19:48:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> test/langtools/tools/javac/warnings/ThisEscape.java line 769:
>> 
>>> 767:     }
>>> 768: 
>>> 769:     // JDK-8355753 - @SuppressWarnings("this-escape") not respected for indirect leak via field
>> 
>> nit: consider adding a similar test case with an additional constructor that is not annotated with the @SuppressAnnotations annotation so that the warning is issued
>
>> nit: consider adding a similar test case with an additional constructor that is not annotated with the @SuppressAnnotations annotation so that the warning is issued
> 
> and probably another variation doing something like:
> 
>         private int x;
> 
>         {
>             x = this.mightLeak();
>         }

Hi @vicente-romero-oracle, thanks for the suggestions. They should be implemented in 65e2679e0ed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114770567

From acobbs at openjdk.org  Thu May 29 21:55:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 29 May 2025 21:55:56 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: <yibTsPV2LthPlElLEeDbFyKkCagYcTQQ7ljTATFNiSM=.505f53cc-da21-4ae9-8d7a-a9bc1d9dae4a@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <sFPzk753a6n7_uC-xcQNyXhRkXTgCyevyr56g5O2HeY=.a6635ed5-3756-4b68-8430-28848e62a381@github.com>
 <I6THxHpl81BfBrlQYq6g4LS_gtQNa5FoCZVTUltt5aI=.15b52769-8f4a-45be-b917-193fb5db637b@github.com>
 <MVstc1eZjs-2uKocTt2D3Y_lO8YeN8Or80mb_selPvM=.1da5d58e-b822-4280-a63b-160bb944ac61@github.com>
 <yibTsPV2LthPlElLEeDbFyKkCagYcTQQ7ljTATFNiSM=.505f53cc-da21-4ae9-8d7a-a9bc1d9dae4a@github.com>
Message-ID: <votKfztUpIC87z6pKh_CBaCl0Rde6Yo9Kte-qhzkB8w=.83b03f7e-37f7-45be-8a70-1aca1302984a@github.com>

On Thu, 29 May 2025 14:28:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> @lahodaj, thanks for your thoughts.
>> 
>> I agree it's not ideal either way. The thing that kindof pushes it in the `EndPosTable` direction for me is this: As long as we have `DiagnosticListener`'s and `-Xjcov`, we have a (sometimes) requirement to track the ending positions of _every_ node. So as long as we are required to have code that does that, why not just use it? Then we have only one mechanism for doing something, instead of two.
>> 
>> Practically speaking: @mcimadamore are you OK to proceed with the current approach?
>> 
>> In any case, it's not a tragedy if we change our minds in the future - removing `EndPosTable` or switching back to the previous approach is easy to do (and I'm happy to volunteer if needed).
>> 
>> Thanks.
>
> Hi @archiecobbs. I took another look at how javac is structured in this area (with the help of @lahodaj). `TreeInfo` has two slightly different methods (maybe this is all obvious to you, but repeating here just in case):
> 
> * `TreeInfo::endPos` -- this is an internal method, only used by javac which, in reality, doesn't have a lot to do with end positions. It is mostly used as a way to retrieve the position at the end of a block (e.g. where a new statement should be appended), and is used mostly for code generation purposes (e.g. tells javac where synthetic code should be added), or where errors should be emitted -- this is especially the case in `Flow`, which uses `TreeInfo::diagEndPos` which uses this. This method does NOT depend on an `EndPosTable` -- it does all it needs by using a couple of dedicated fields in `JCBlock` and `JCSwitch`/`JCSwitchExpression`.
> * `TreeInfo::getEndPos` -- this is the method that accesses the `EndPosTable`, looking for the end position of a given tree. This method is used by `JavacTrees`, so used also externally. If there's no `EndPosTable` (e.g. the table is set to null), this method delegates to `TreeInfo::endPos`, but I'm not sure this ever happens, given that when we don't want end positions we tend to use the `EmptyEndPosTable` -- which simply disregards end pos information. In other words, the end pos table is never `null`, which means this method returns `NOPOS` when the end pos table is not in effect.
> 
> Now, it seems to me that the changes you are after have nothing to do with the first method. You want extra end pos information for modules, packages, classes, methods, fields -- e.g. places where a `@SuppressWarnings` annotation might go. As such, I think this PR should not touch `TreeInfo::endPos` at all. It should only define the minimal end pos table to make sure that enough end positions are captured _at all times_, but no more than that. More specifically, the part where we replace fields in `JCTree` with the use of the minimal end pos table seems bad, as the fields are there to support `TreeInfo::endPos` which strictly speaking, has nothing to do with warning suppression (not now, not in the future).
> 
> If you want to rename the `endPos` fields in the AST nodes to `bracePos` that's fine -- but I think `TreeInfo::endPos` should remain unchanged, and that your other code that needs end position information should instead use `TreeInfo.getEndPos`, which will be augmented thanks to your new minimal end pos table. Again,...

Hi @mcimadamore,

Thanks for taking a look and for the clarifying comments.

> If there's no EndPosTable (e.g. the table is set to null), this method delegates to TreeInfo::endPos, but I'm not sure this ever happens...

>From what I could tell, the `EndPosTable` is never null in the existing code. Assuming that's the case, there's no point in optimizing any code to avoid the use of `EndPosTable` just because it might not be there. So my patch includes some cleanups along these lines, for example, adding a new `EndPosTable` to the `TreeInfo.endPos()` method, thereby making it "safe" to use with any node type.

While I was at first thinking that would be a useful simplification, as you point out, given that `TreeInfo.endPos()` actually only needs to work for a handful of node types, that refactoring is unnecessary and is obscuring the goal of this PR so I'm happy to remove it.

> If you want to rename the endPos fields in the AST nodes to bracePos that's fine -- but I think `TreeInfo::endPos` should remain unchanged, and that your other code that needs end position information should instead use `TreeInfo.getEndPos`, 

Sounds good, that will make things more straightforward. I'll work on it.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2920671566

From acobbs at openjdk.org  Fri May 30 01:51:40 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 01:51:40 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v7]
In-Reply-To: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
Message-ID: <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@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 eight commits:

 - Revert TreeInfo.endPos() refactoring except for "bracePos" renaming.
 - Merge branch 'master' into JDK-8350212
 - 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=06
  Stats: 333 lines in 11 files changed: 176 ins; 83 del; 74 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 acobbs at openjdk.org  Fri May 30 02:01:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 02:01:51 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: <votKfztUpIC87z6pKh_CBaCl0Rde6Yo9Kte-qhzkB8w=.83b03f7e-37f7-45be-8a70-1aca1302984a@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <sFPzk753a6n7_uC-xcQNyXhRkXTgCyevyr56g5O2HeY=.a6635ed5-3756-4b68-8430-28848e62a381@github.com>
 <I6THxHpl81BfBrlQYq6g4LS_gtQNa5FoCZVTUltt5aI=.15b52769-8f4a-45be-b917-193fb5db637b@github.com>
 <MVstc1eZjs-2uKocTt2D3Y_lO8YeN8Or80mb_selPvM=.1da5d58e-b822-4280-a63b-160bb944ac61@github.com>
 <yibTsPV2LthPlElLEeDbFyKkCagYcTQQ7ljTATFNiSM=.505f53cc-da21-4ae9-8d7a-a9bc1d9dae4a@github.com>
 <votKfztUpIC87z6pKh_CBaCl0Rde6Yo9Kte-qhzkB8w=.83b03f7e-37f7-45be-8a70-1aca1302984a@github.com>
Message-ID: <9ceB5_M06kwU6EvTf-pPAV2wsbehnI2uTSD45yGnQ-0=.10022d75-738a-47e8-a0ec-e5f34375531b@github.com>

On Thu, 29 May 2025 21:53:42 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Sounds good, that will make things more straightforward. I'll work on it.

@mcimadamore please see 0898c557f78 and let me know if that is more in line with what you were thinking. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2921016793

From darcy at openjdk.org  Fri May 30 02:27:53 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 May 2025 02:27:53 GMT
Subject: RFR: 8355004: Apply java.io.Serial annotations in java.compiler
 [v2]
In-Reply-To: <ZxcYLW0svvjawTqVnbHuqiAZtSSMKiJ63hxK_Wo5VEg=.a8a4320d-3385-467d-a8dd-c0c850b435b9@github.com>
References: <EjYU0xWKXOtcYBMvj_ln9hlQJoPDmG3BnH_GW-TXQ7s=.5d4cbe78-82e7-44e6-8398-456f614c3e71@github.com>
 <ZxcYLW0svvjawTqVnbHuqiAZtSSMKiJ63hxK_Wo5VEg=.a8a4320d-3385-467d-a8dd-c0c850b435b9@github.com>
Message-ID: <ravmEXY8tE9nEDJQ8jmPd44sJDdmQAoXhUYYluDLCzs=.7850177e-1069-438d-afbe-cf892403e2e3@github.com>

On Thu, 29 May 2025 15:58:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the compiler module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.
>> 
>> This annotation can be applied to these methods in the module:
>> 
>> private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>> private void readObjectNoData() throws ObjectStreamException
>> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>> private static final ObjectStreamField[] serialPersistentFields
>> private static final long serialVersionUID
>> 
>> Any feedback or suggestions are welcome!
>
> Sergey Bylokhov 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 'openjdk:master' into serial_compiler
>  - use long literals
>  - Apply java.io.Serial annotations in java.compiler

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24891#pullrequestreview-2880035761

From vromero at openjdk.org  Fri May 30 03:31:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 May 2025 03:31:51 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v2]
In-Reply-To: <NEwidsqjRAJ8lnFO1_VFMbZhqHniKiKLrnE3qipSFWA=.0608decd-f38a-46c3-a2f2-9e095e336d8c@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <D-YBylQkGVW33IWoDoZwj2zhWhrFF2eeSk1eUVkMZeU=.edb62b42-3314-4367-a97e-98d5512a2170@github.com>
 <NEwidsqjRAJ8lnFO1_VFMbZhqHniKiKLrnE3qipSFWA=.0608decd-f38a-46c3-a2f2-9e095e336d8c@github.com>
Message-ID: <Z5RRhjrcOaZYgCfbduqaGfieRWLQT7NyeZGgSuL9Pd8=.62e6d5b0-39f8-484c-9127-28924e81d062@github.com>

On Thu, 29 May 2025 21:22:06 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 387:
>> 
>>> 385:         // Sort warnings so redundant warnings immediately follow whatever they are redundant for, then remove them
>>> 386:         warningList.sort(Warning::sortByStackFrames);
>>> 387:         AtomicReference<Warning> previousRef = new AtomicReference<>();
>> 
>> just curious: why do we need to deal with AtomicReference here?
>
> Hi @vicente-romero-oracle, thanks for taking a look.
> 
> The reason for the `AtomicReference` is that this lamba needs to be stateful (it needs to remember the most recent previous `Warning` that was also retained, if any), so if it wants to remain a lambda (i.e., and not a more verbose inner class) that state needs to be declared outside the lamba, and therefore it must be effectively final, which means there must be an extra level of indirection, etc. I guess it's a verbosity vs. clarity trade-off.

right, would an array be less heavy? not beautiful either

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2115079303

From vromero at openjdk.org  Fri May 30 03:31:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 May 2025 03:31:56 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v2]
In-Reply-To: <SnuVd-GnSJ1Y57odmal2X2xvAYHgOKWOdEx7iTpuuvo=.ff639295-7927-4c37-98de-3a38d1819eda@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <SnuVd-GnSJ1Y57odmal2X2xvAYHgOKWOdEx7iTpuuvo=.ff639295-7927-4c37-98de-3a38d1819eda@github.com>
Message-ID: <Pno2ZdWYd1hc3mr66NgsCFEn3IQnr6WjL_QFZjJ1qjc=.5e42ed97-67aa-4c5f-a923-9b7ff76ecce7@github.com>

On Thu, 29 May 2025 21:25:38 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
>> 
>> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
>> 
>> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add additional tests for warnings generated from fields.
>  - Merge branch 'master' into JDK-8355753
>  - Refactor ThisEscapeAnalyzer to correct bug in suppression logic.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1794:

> 1792:               IntStream.range(0, that.stack.size())
> 1793:                 .allMatch(index -> this.stack.get(numExtra + index).comparePos(that.stack.get(index)) == 0);
> 1794:         };

Suggestion:

        }

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1814:

> 1812:                     return diff;
> 1813:             }
> 1814:         };

Suggestion:

        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114679004
PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2114678422

From mcimadamore at openjdk.org  Fri May 30 10:15:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 May 2025 10:15:53 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v4]
In-Reply-To: <votKfztUpIC87z6pKh_CBaCl0Rde6Yo9Kte-qhzkB8w=.83b03f7e-37f7-45be-8a70-1aca1302984a@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <sFPzk753a6n7_uC-xcQNyXhRkXTgCyevyr56g5O2HeY=.a6635ed5-3756-4b68-8430-28848e62a381@github.com>
 <I6THxHpl81BfBrlQYq6g4LS_gtQNa5FoCZVTUltt5aI=.15b52769-8f4a-45be-b917-193fb5db637b@github.com>
 <MVstc1eZjs-2uKocTt2D3Y_lO8YeN8Or80mb_selPvM=.1da5d58e-b822-4280-a63b-160bb944ac61@github.com>
 <yibTsPV2LthPlElLEeDbFyKkCagYcTQQ7ljTATFNiSM=.505f53cc-da21-4ae9-8d7a-a9bc1d9dae4a@github.com>
 <votKfztUpIC87z6pKh_CBaCl0Rde6Yo9Kte-qhzkB8w=.83b03f7e-37f7-45be-8a70-1aca1302984a@github.com>
Message-ID: <G-y9pPFLNcnXyZRGbY9zgxG0wBuw75LGSXeohZnd-pA=.a09d0e02-3b73-4603-bbb2-fbd98c100ad2@github.com>

On Thu, 29 May 2025 21:53:42 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> From what I could tell, the `EndPosTable` is never null in the existing code. Assuming that's the case, there's no point in optimizing any code to avoid the use of `EndPosTable` just because it might not be there. So my patch includes some cleanups along these lines, for example, adding a new `EndPosTable` to the `TreeInfo.endPos()` method, thereby making it "safe" to use with any node type.

Note, I still think we're mixing up the functions: `TreeInfo::endPos` doesn't even look at the end pos table before this PR! It's `TreeInfo::getEndPos` that does. The difference in method name is maddeningly subtle, but the two methods are rather different beasts -- as you point out `TreeInfo::endPos` is really a special method that only works on a subset of block-like nodes -- and that has nothing to do with the problem you are trying to solve.

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2921908921

From mcimadamore at openjdk.org  Fri May 30 10:33:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 May 2025 10:33:00 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v7]
In-Reply-To: <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
Message-ID: <B64D2cz7tebnxc4NQ3N2Pv1U5F11oT6SaWw-8b6P7NE=.db2a8647-6dcc-4bb1-926a-b5d57c9099d0@github.com>

On Fri, 30 May 2025 01:51:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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 eight commits:
> 
>  - Revert TreeInfo.endPos() refactoring except for "bracePos" renaming.
>  - Merge branch 'master' into JDK-8350212
>  - 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.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/EndPosTable.java line 72:

> 70:      * @param errPos The error position
> 71:      */
> 72:     void setErrorEndPos(int errPos);

Why was this added to the interface? (separately, I think interface + abstract class + concrete impl is a bit of an overkill here -- but that's for another day)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2115623353

From mcimadamore at openjdk.org  Fri May 30 10:40:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 May 2025 10:40:59 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v7]
In-Reply-To: <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
Message-ID: <pMzBwlm5dte1bIPvE0_1xIDBW7Po_Wh0Q04WzooZCDk=.735705ba-b896-4197-8680-ba8f40f3c3c7@github.com>

On Fri, 30 May 2025 01:51:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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 eight commits:
> 
>  - Revert TreeInfo.endPos() refactoring except for "bracePos" renaming.
>  - Merge branch 'master' into JDK-8350212
>  - 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.

Overall the changes look great, and much more minimal, thanks. I left few questions around for you to consider.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2063:

> 2061:             make_at(tree.pos());
> 2062:             T result = super.translate(tree);
> 2063:             if (endPosTable != null && result != null && result != tree) {

I wonder how this extra check for `result != null` was added. I mean, of course calling `replaceTree` with a null parameter seems suspicious -- should we add more formal null checks in the various end pos table methods? (it's ok if we do that in a separate PR)

test/langtools/tools/javac/parser/extend/TrialParser.java line 142:

> 140:         }
> 141:         toplevel.lineMap = S.getLineMap();
> 142:         this.endPosTable.setParser(null); // remove reference to parser

Not sure about these changes -- e.g. what was the test trying to do in the first place?

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

PR Review: https://git.openjdk.org/jdk/pull/23669#pullrequestreview-2880922602
PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2115631276
PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2115635388

From jlahoda at openjdk.org  Fri May 30 12:06:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 30 May 2025 12:06:55 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v7]
In-Reply-To: <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
Message-ID: <zGKOYBrl08l9cjDSQVNWjb-20Dd6INLlSRKNs0BuW60=.916383c1-c515-4543-a08b-0ac96af504ac@github.com>

On Fri, 30 May 2025 01:51:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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 eight commits:
> 
>  - Revert TreeInfo.endPos() refactoring except for "bracePos" renaming.
>  - Merge branch 'master' into JDK-8350212
>  - 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.

Seems sensible to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2922209929

From acobbs at openjdk.org  Fri May 30 13:27:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 13:27:29 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v3]
In-Reply-To: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
Message-ID: <uWHus8BDtvajul7cpXyHrOMuOA6MoaojOUDyxPG8Sa0=.a4a8eca2-263d-4daf-89ab-bca1e805c856@github.com>

> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
> 
> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
> 
> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.

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

  Remove extraneous semicolons.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24932/files
  - new: https://git.openjdk.org/jdk/pull/24932/files/65e2679e..f79e35f8

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

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

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

From acobbs at openjdk.org  Fri May 30 13:27:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 13:27:29 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v3]
In-Reply-To: <Z5RRhjrcOaZYgCfbduqaGfieRWLQT7NyeZGgSuL9Pd8=.62e6d5b0-39f8-484c-9127-28924e81d062@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <D-YBylQkGVW33IWoDoZwj2zhWhrFF2eeSk1eUVkMZeU=.edb62b42-3314-4367-a97e-98d5512a2170@github.com>
 <NEwidsqjRAJ8lnFO1_VFMbZhqHniKiKLrnE3qipSFWA=.0608decd-f38a-46c3-a2f2-9e095e336d8c@github.com>
 <Z5RRhjrcOaZYgCfbduqaGfieRWLQT7NyeZGgSuL9Pd8=.62e6d5b0-39f8-484c-9127-28924e81d062@github.com>
Message-ID: <HPrEarbh6tsBxTo_5BRshEYesBbzZOopKCAtUGteE2E=.1cd2e018-397d-46c2-96e9-b3189536573e@github.com>

On Fri, 30 May 2025 03:29:21 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> right, would an array be less heavy? not beautiful either

If by "heavy" you mean optimization/efficiency, honestly I have no idea about that... that gets into a level of JVM optimization granularity beyond my knowledge.

As for "beauty", yes using an array is a common trick for this, but IMHO doing so is more obscure than using `AtomicReference` because there is no "arrayness" here. You are just using the array as a thing that contains a single mutable reference - i.e., exactly what `AtomicReference` does. Of course, we don't care about the "atomic" part, so that's slightly confusing too.

There's no perfect answer. It makes me wonder... maybe someday we could make stateful lambdas easier, e.g.:

Runnable r = () -> {
    static int count;
    System.out.println("Invoked " + ++count + " times");
};

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2115924315

From acobbs at openjdk.org  Fri May 30 13:27:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 13:27:29 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v3]
In-Reply-To: <Pno2ZdWYd1hc3mr66NgsCFEn3IQnr6WjL_QFZjJ1qjc=.5e42ed97-67aa-4c5f-a923-9b7ff76ecce7@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <SnuVd-GnSJ1Y57odmal2X2xvAYHgOKWOdEx7iTpuuvo=.ff639295-7927-4c37-98de-3a38d1819eda@github.com>
 <Pno2ZdWYd1hc3mr66NgsCFEn3IQnr6WjL_QFZjJ1qjc=.5e42ed97-67aa-4c5f-a923-9b7ff76ecce7@github.com>
Message-ID: <9lAKnDzMCIHfSbWLxMDZgj0Nn6frjY68UGFB2yT8nog=.fcb9c2bc-fa6b-4acc-959b-f412d3a184fc@github.com>

On Thu, 29 May 2025 20:13:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extraneous semicolons.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1794:
> 
>> 1792:               IntStream.range(0, that.stack.size())
>> 1793:                 .allMatch(index -> this.stack.get(numExtra + index).comparePos(that.stack.get(index)) == 0);
>> 1794:         };
> 
> Suggestion:
> 
>         }

Thanks - fixed in f79e35f8ee6.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1814:
> 
>> 1812:                     return diff;
>> 1813:             }
>> 1814:         };
> 
> Suggestion:
> 
>         }

Thanks - fixed in f79e35f8ee6.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2115924911
PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2115924750

From vromero at openjdk.org  Fri May 30 13:43:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 May 2025 13:43:53 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v3]
In-Reply-To: <uWHus8BDtvajul7cpXyHrOMuOA6MoaojOUDyxPG8Sa0=.a4a8eca2-263d-4daf-89ab-bca1e805c856@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <uWHus8BDtvajul7cpXyHrOMuOA6MoaojOUDyxPG8Sa0=.a4a8eca2-263d-4daf-89ab-bca1e805c856@github.com>
Message-ID: <POqW1oT6u936fL1VJ4IVjQwbKUCJZ5_M4dGVdSmop1c=.3c2aefcf-6090-49e9-844e-b3ab8f57a470@github.com>

On Fri, 30 May 2025 13:27:29 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
>> 
>> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
>> 
>> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extraneous semicolons.

lgtm

@archiecobbs thanks for the updates

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24932#pullrequestreview-2881401897
PR Comment: https://git.openjdk.org/jdk/pull/24932#issuecomment-2922433145

From vromero at openjdk.org  Fri May 30 13:43:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 May 2025 13:43:54 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v3]
In-Reply-To: <HPrEarbh6tsBxTo_5BRshEYesBbzZOopKCAtUGteE2E=.1cd2e018-397d-46c2-96e9-b3189536573e@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <D-YBylQkGVW33IWoDoZwj2zhWhrFF2eeSk1eUVkMZeU=.edb62b42-3314-4367-a97e-98d5512a2170@github.com>
 <NEwidsqjRAJ8lnFO1_VFMbZhqHniKiKLrnE3qipSFWA=.0608decd-f38a-46c3-a2f2-9e095e336d8c@github.com>
 <Z5RRhjrcOaZYgCfbduqaGfieRWLQT7NyeZGgSuL9Pd8=.62e6d5b0-39f8-484c-9127-28924e81d062@github.com>
 <HPrEarbh6tsBxTo_5BRshEYesBbzZOopKCAtUGteE2E=.1cd2e018-397d-46c2-96e9-b3189536573e@github.com>
Message-ID: <tUP3iFhILW5ZDLdjMcr6hKquRXcoX9Uni_YNH17Ze-o=.a605be9a-eeca-4c87-8b4d-8c3178220efb@github.com>

On Fri, 30 May 2025 13:23:24 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> right, would an array be less heavy? not beautiful either
>
>> right, would an array be less heavy? not beautiful either
> 
> If by "heavy" you mean optimization/efficiency, honestly I have no idea about that... that gets into a level of JVM optimization granularity beyond my knowledge.
> 
> As for "beauty", yes using an array is a common trick for this, but IMHO doing so is more obscure than using `AtomicReference` because there is no "arrayness" here. You are just using the array as a thing that contains a single mutable reference - i.e., exactly what `AtomicReference` does. Of course, we don't care about the "atomic" part, so that's slightly confusing too.
> 
> There's no perfect answer. It makes me wonder... maybe someday we could make stateful lambdas easier, e.g.:
> 
> Runnable r = () -> {
>     static int count;
>     System.out.println("Invoked " + ++count + " times");
> };

right, definitely there is a need for stateful lambdas

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24932#discussion_r2115948713

From acobbs at openjdk.org  Fri May 30 14:44:56 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 14:44:56 GMT
Subject: RFR: 8355753: @SuppressWarnings("this-escape") not respected for
 indirect leak via field [v3]
In-Reply-To: <uWHus8BDtvajul7cpXyHrOMuOA6MoaojOUDyxPG8Sa0=.a4a8eca2-263d-4daf-89ab-bca1e805c856@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
 <uWHus8BDtvajul7cpXyHrOMuOA6MoaojOUDyxPG8Sa0=.a4a8eca2-263d-4daf-89ab-bca1e805c856@github.com>
Message-ID: <apeGZPBAgCcK_nXxx-P8Q5IcxCF8xamWYFKm34l4Fq4=.878ab257-665a-416e-af4b-6e9167b89931@github.com>

On Fri, 30 May 2025 13:27:29 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
>> 
>> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
>> 
>> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extraneous semicolons.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/24932#issuecomment-2922589138

From acobbs at openjdk.org  Fri May 30 14:44:58 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 14:44:58 GMT
Subject: Integrated: 8355753: @SuppressWarnings("this-escape") not respected
 for indirect leak via field
In-Reply-To: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
References: <XQWcPm4VtOtc7AvQCJSBKFfUtG9y5QsGB48oY0391_8=.efdcb347-58bf-421e-8460-f67f38db42b8@github.com>
Message-ID: <-AlDcYHdRnhJ4XQ6JBAML76gQUeOahoH9RPyI8Dvs8E=.091134a4-1ee3-4fd7-ad1b-8c52636e7420@github.com>

On Mon, 28 Apr 2025 17:08:40 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR corrects a bug in the logic for handling `@SuppressWarnings("this-escape")` when the leak is from a field initializer.
> 
> The `ThisEscapeAnalyzer` has to do some custom handling for `@SuppressWarnings("this-escape")` because when a constructor executes, the actual path of execution can jump around between multiple constructors, field initializers, and initialization blocks. The previous logic was somewhat ad hoc and contained at least one bug (this one), so this PR refactors it to fix the bug and also make the code clearer.
> 
> Now we "execute" field initializers and initialization blocks when we encounter `super()` invocations, just like the actual JVM does, and we move the logics for (a) applying suppression and (b) the "at most one warning per constructor or initializer" rule until after the analysis, so they are part of the existing warning filtering and de-duplication step.

This pull request has now been integrated.

Changeset: 26275a10
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26275a10b2aa75f0d4ff49248a3309f9d7b19bf3
Stats:     405 lines in 3 files changed: 209 ins; 99 del; 97 mod

8355753: @SuppressWarnings("this-escape") not respected for indirect leak via field

Reviewed-by: vromero

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

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

From acobbs at openjdk.org  Fri May 30 20:14:30 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 20:14:30 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v8]
In-Reply-To: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
Message-ID: <MDIhfEMzPGcgzHGNEqrft64icVFXrmR9eTJYdMLUTQI=.11cdb7ab-214b-4114-9598-f2188f49b7ac@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 incrementally with one additional commit since the last revision:

  Update EndPosTable.replaceTree() to handle a new node equal to null.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23669/files
  - new: https://git.openjdk.org/jdk/pull/23669/files/0898c557..205f77e9

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

  Stats: 5 lines in 3 files changed: 0 ins; 1 del; 4 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 acobbs at openjdk.org  Fri May 30 20:14:32 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 20:14:32 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v7]
In-Reply-To: <pMzBwlm5dte1bIPvE0_1xIDBW7Po_Wh0Q04WzooZCDk=.735705ba-b896-4197-8680-ba8f40f3c3c7@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
 <pMzBwlm5dte1bIPvE0_1xIDBW7Po_Wh0Q04WzooZCDk=.735705ba-b896-4197-8680-ba8f40f3c3c7@github.com>
Message-ID: <4b55jh2FrqfrHeU3zABwTAHHEj08ur9gIPcPzXTxkag=.266d4587-82b1-464f-91a3-aacbc96bd371@github.com>

On Fri, 30 May 2025 10:34:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Revert TreeInfo.endPos() refactoring except for "bracePos" renaming.
>>  - Merge branch 'master' into JDK-8350212
>>  - 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.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2063:
> 
>> 2061:             make_at(tree.pos());
>> 2062:             T result = super.translate(tree);
>> 2063:             if (endPosTable != null && result != null && result != tree) {
> 
> I wonder how this extra check for `result != null` was added. I mean, of course calling `replaceTree` with a null parameter seems suspicious -- should we add more formal null checks in the various end pos table methods? (it's ok if we do that in a separate PR)

I added this check to fix NPE's (e.g., in `tools/javac/warnings/suppress/PackageInfo.java`) that started to occur after the refactoring of `EndPosTable.replaceTree()`, which assumes that the replacement is not null.

Of couse a null node can't have an ending position, but it does happen sometimes that nodes are replaced with nulls. In that case, it makes sense for `replaceTree()` to just remove the old tree from `EndPosTable`. I've updated the patch accordingly in 205f77e9d53.

> Why was this added to the interface? 

It wasn't strictly necessary, but as long as `EndPosTable` is going to be a proper interface, it seemed like the right thing to do.

The other cleanups were based on the following observations:

1. There is no need for the `EndPosTable` to refer back to the parser. This reference was so it could have access to `parser.S` and `parser.token` in order to infer the ending position for the node in `to()` and `toP()`, but that calculation should just be done by the parser itself, before ever accessing `EndPosTable` (via what is now a single method, `storeEnd()`). The `EndPosTable` should simply be a standalone repository for the mappings from node to ending position. But really this change made the new subclass `MinimalEndPosTable` more straightforward to implement, which is what prompted the refactoring in the first place.
1. Having `attach()` and `storeEnd()` return the node instead of `void` makes the code more fluent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2116571327
PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2116571098

From acobbs at openjdk.org  Fri May 30 20:14:32 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 20:14:32 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v8]
In-Reply-To: <pMzBwlm5dte1bIPvE0_1xIDBW7Po_Wh0Q04WzooZCDk=.735705ba-b896-4197-8680-ba8f40f3c3c7@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
 <pMzBwlm5dte1bIPvE0_1xIDBW7Po_Wh0Q04WzooZCDk=.735705ba-b896-4197-8680-ba8f40f3c3c7@github.com>
Message-ID: <0qTfw_S_3xcwAU_E0mMqQXJYuMlVgsP07tKOW9ln0KY=.63ac3eae-5310-48a7-b666-50aadf262953@github.com>

On Fri, 30 May 2025 10:37:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update EndPosTable.replaceTree() to handle a new node equal to null.
>
> test/langtools/tools/javac/parser/extend/TrialParser.java line 142:
> 
>> 140:         }
>> 141:         toplevel.lineMap = S.getLineMap();
>> 142:         this.endPosTable.setParser(null); // remove reference to parser
> 
> Not sure about these changes -- e.g. what was the test trying to do in the first place?

This line to be removed simply because `EndPosTable` no longer has this back-reference to the parser. This file is used in a test for [JDK-8067384](https://bugs.openjdk.org/browse/JDK-8067384) which verifies that it's possible to subclass `JavacParser`.

My assumption was that this line was just a cut & paste copy of [this line](https://github.com/openjdk/jdk/blob/94039e22bbe943888e858d8ae278145e2668526a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java#L4144) and has no significance to the actual test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2116571804

From acobbs at openjdk.org  Fri May 30 20:30:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 20:30:53 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v8]
In-Reply-To: <MDIhfEMzPGcgzHGNEqrft64icVFXrmR9eTJYdMLUTQI=.11cdb7ab-214b-4114-9598-f2188f49b7ac@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <MDIhfEMzPGcgzHGNEqrft64icVFXrmR9eTJYdMLUTQI=.11cdb7ab-214b-4114-9598-f2188f49b7ac@github.com>
Message-ID: <LdyWLTIqTQjQgLnWbji0BAUv284E9PsiqrZmVPOZWSQ=.66bf9609-6fd4-46be-a78e-4be72ff809e8@github.com>

On Fri, 30 May 2025 20:14:30 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   Update EndPosTable.replaceTree() to handle a new node equal to null.

Forgot to follow-up on this comment:

> Note, I still think we're mixing up the functions...

Yep, it was part of a misguided attempt to consolidate the two ?end position? methods into a common mechanism. I was misled by the names. Instead (someday) we should change the method names to make them more distinct. Short of that, this patch now just updates the field names and the comment above the `endPos` method.

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2923415694

From acobbs at openjdk.org  Fri May 30 21:31:09 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 21:31:09 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as errors
Message-ID: <lg3gSEwwuAZzHkvy6YkfSvkvWxWrmec8h75PVlWhck0=.fb0e12fc-f9aa-4742-b8c4-395f975be592@github.com>

(Note: this is a resubmission of #23622 which was closed accidentally due to a [bot bug](https://bugs.openjdk.org/browse/SKARA-2510) and which I'm not allowed to reopen.)

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` ca[tegory. 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

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

Commit messages:
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Update man page.
 - Merge branch 'master' into JDK-8349847 to fix conflicts.
 - Add support for -Werror:key.

Changes: https://git.openjdk.org/jdk/pull/25558/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25558&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349847
  Stats: 196 lines in 13 files changed: 140 ins; 34 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25558.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25558/head:pull/25558

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

From mcimadamore at openjdk.org  Fri May 30 21:55:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 May 2025 21:55:02 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v8]
In-Reply-To: <MDIhfEMzPGcgzHGNEqrft64icVFXrmR9eTJYdMLUTQI=.11cdb7ab-214b-4114-9598-f2188f49b7ac@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <MDIhfEMzPGcgzHGNEqrft64icVFXrmR9eTJYdMLUTQI=.11cdb7ab-214b-4114-9598-f2188f49b7ac@github.com>
Message-ID: <GQFqgBfQdBVfUZJ6u_CjT13zswSoQL3zD__FvAKmJvM=.9ba0d265-9c0e-4a0c-a08d-f46bd6a2f999@github.com>

On Fri, 30 May 2025 20:14:30 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   Update EndPosTable.replaceTree() to handle a new node equal to null.

Looks good. But please wait a week or so before integrating (e.g. the JDK 26 fork) -- I think better not to rush this at this stage of the release cycle Thanks!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23669#pullrequestreview-2882628417

From mcimadamore at openjdk.org  Fri May 30 21:55:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 May 2025 21:55:03 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v7]
In-Reply-To: <4b55jh2FrqfrHeU3zABwTAHHEj08ur9gIPcPzXTxkag=.266d4587-82b1-464f-91a3-aacbc96bd371@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <WD9hGC7pBE1qcYed3KRiXTSqAPvl1DBFqUk3c2-VTes=.9c1f5ad2-ca67-4803-85fb-7190826e3f7d@github.com>
 <pMzBwlm5dte1bIPvE0_1xIDBW7Po_Wh0Q04WzooZCDk=.735705ba-b896-4197-8680-ba8f40f3c3c7@github.com>
 <4b55jh2FrqfrHeU3zABwTAHHEj08ur9gIPcPzXTxkag=.266d4587-82b1-464f-91a3-aacbc96bd371@github.com>
Message-ID: <xRRYbil801nNn_tuj_Djw9AlStLQvtLOAL2n-9GsQVw=.a34adab6-bd10-47d2-9187-248b1ca9327d@github.com>

On Fri, 30 May 2025 20:11:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2063:
>> 
>>> 2061:             make_at(tree.pos());
>>> 2062:             T result = super.translate(tree);
>>> 2063:             if (endPosTable != null && result != null && result != tree) {
>> 
>> I wonder how this extra check for `result != null` was added. I mean, of course calling `replaceTree` with a null parameter seems suspicious -- should we add more formal null checks in the various end pos table methods? (it's ok if we do that in a separate PR)
>
> I added this check to fix NPE's (e.g., in `tools/javac/warnings/suppress/PackageInfo.java`) that started to occur after the refactoring of `EndPosTable.replaceTree()`, which assumes that the replacement is not null.
> 
> Of couse a null node can't have an ending position, but it does happen sometimes that nodes are replaced with nulls. In that case, it makes sense for `replaceTree()` to just remove the old tree from `EndPosTable`. I've updated the patch accordingly in 205f77e9d53.

I see -- so this started to happen now because before we used to just do nothing if the empty end pos table was set. Makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23669#discussion_r2116709721

From acobbs at openjdk.org  Fri May 30 23:24:55 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 30 May 2025 23:24:55 GMT
Subject: RFR: 8350212: Track source end positions of declarations that
 support @SuppressWarnings [v8]
In-Reply-To: <GQFqgBfQdBVfUZJ6u_CjT13zswSoQL3zD__FvAKmJvM=.9ba0d265-9c0e-4a0c-a08d-f46bd6a2f999@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
 <MDIhfEMzPGcgzHGNEqrft64icVFXrmR9eTJYdMLUTQI=.11cdb7ab-214b-4114-9598-f2188f49b7ac@github.com>
 <GQFqgBfQdBVfUZJ6u_CjT13zswSoQL3zD__FvAKmJvM=.9ba0d265-9c0e-4a0c-a08d-f46bd6a2f999@github.com>
Message-ID: <4WLREpu2wIGg63s0V7TFOFZrW_L-zqMamvXsXSdzr2o=.578f661a-1833-49b7-874c-52d7b6c90039@github.com>

On Fri, 30 May 2025 21:52:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks good. But please wait a week or so before integrating (e.g. the JDK 26 fork) -- I think better not to rush this at this stage of the release cycle Thanks!

Will do. Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23669#issuecomment-2923706623

From serb at openjdk.org  Sat May 31 00:19:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 00:19:56 GMT
Subject: Integrated: 8355004: Apply java.io.Serial annotations in java.compiler
In-Reply-To: <EjYU0xWKXOtcYBMvj_ln9hlQJoPDmG3BnH_GW-TXQ7s=.5d4cbe78-82e7-44e6-8398-456f614c3e71@github.com>
References: <EjYU0xWKXOtcYBMvj_ln9hlQJoPDmG3BnH_GW-TXQ7s=.5d4cbe78-82e7-44e6-8398-456f614c3e71@github.com>
Message-ID: <9oef41fuXaS1h2iisFXFU86Lv9ycY7oTcbbUNwiN2So=.4cd5bb0a-f6d6-4884-94c8-c45de44d055b@github.com>

On Fri, 25 Apr 2025 22:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the compiler module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.
> 
> This annotation can be applied to these methods in the module:
> 
> private void writeObject(java.io.ObjectOutputStream stream) throws IOException
> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
> private void readObjectNoData() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
> private static final ObjectStreamField[] serialPersistentFields
> private static final long serialVersionUID
> 
> Any feedback or suggestions are welcome!

This pull request has now been integrated.

Changeset: 5ad02c98
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ad02c98f1d9227bb6abdd37126f2a351d4e1a50
Stats:     46 lines in 8 files changed: 29 ins; 4 del; 13 mod

8355004: Apply java.io.Serial annotations in java.compiler

Reviewed-by: liach, darcy

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

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

From duke at openjdk.org  Sat May 31 15:16:49 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 31 May 2025 15:16:49 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors
In-Reply-To: <lg3gSEwwuAZzHkvy6YkfSvkvWxWrmec8h75PVlWhck0=.fb0e12fc-f9aa-4742-b8c4-395f975be592@github.com>
References: <lg3gSEwwuAZzHkvy6YkfSvkvWxWrmec8h75PVlWhck0=.fb0e12fc-f9aa-4742-b8c4-395f975be592@github.com>
Message-ID: <mXi5xNR9ogyfl5ogUC7YBGKlPZMOQ-qBRotDgyvKS50=.44305871-6243-4c63-9917-24b361a0a7fa@github.com>

On Fri, 30 May 2025 21:26:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> (Note: this is a resubmission of #23622 which was closed accidentally due to a [bot bug](https://bugs.openjdk.org/browse/SKARA-2510) and which I'm not allowed to reopen.)

`/touch` is?for already?open pull?requests, `/open` is?for?re?opening bot?closed pull?requests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25558#issuecomment-2925320051

From acobbs at openjdk.org  Sat May 31 19:32:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 31 May 2025 19:32:53 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors
In-Reply-To: <mXi5xNR9ogyfl5ogUC7YBGKlPZMOQ-qBRotDgyvKS50=.44305871-6243-4c63-9917-24b361a0a7fa@github.com>
References: <lg3gSEwwuAZzHkvy6YkfSvkvWxWrmec8h75PVlWhck0=.fb0e12fc-f9aa-4742-b8c4-395f975be592@github.com>
 <mXi5xNR9ogyfl5ogUC7YBGKlPZMOQ-qBRotDgyvKS50=.44305871-6243-4c63-9917-24b361a0a7fa@github.com>
Message-ID: <4QQJERXcjl8vxgAXnrMwINtGgJmCobmkk2xxy9uK888=.fd61bde2-c3ab-42b7-a051-bfc8e3f046e2@github.com>

On Sat, 31 May 2025 15:13:59 GMT, ExE Boss <duke at openjdk.org> wrote:

> `/touch` is for already open pull requests, `/open` is for re?opening bot?closed pull requests.

Ah, didn't know about`/open`... I was trying to use the github controls. I will try that. Thanks!

Closing this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25558#issuecomment-2925635763

From acobbs at openjdk.org  Sat May 31 19:32:54 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 31 May 2025 19:32:54 GMT
Subject: Withdrawn: 8349847: Support configuring individual lint categories as
 errors
In-Reply-To: <lg3gSEwwuAZzHkvy6YkfSvkvWxWrmec8h75PVlWhck0=.fb0e12fc-f9aa-4742-b8c4-395f975be592@github.com>
References: <lg3gSEwwuAZzHkvy6YkfSvkvWxWrmec8h75PVlWhck0=.fb0e12fc-f9aa-4742-b8c4-395f975be592@github.com>
Message-ID: <p6dm97cTgSQUT0y5c2Sdtcll09bSHhM7P5cycRIR620=.4e3f9781-3066-4c72-9b59-89fda49c2ec3@github.com>

On Fri, 30 May 2025 21:26:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> (Note: this is a resubmission of #23622 which was closed accidentally due to a [bot bug](https://bugs.openjdk.org/browse/SKARA-2510) and which I'm not allowed to reopen.)
> 
> 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` ca[tegory. 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

This pull request has been closed without being integrated.

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

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