From hgreule at openjdk.org  Sun Jun  1 06:08:29 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Sun, 1 Jun 2025 06:08:29 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
Message-ID: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>

This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

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

Commit messages:
 - fix
 - test

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

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

From liach at openjdk.org  Mon Jun  2 00:59:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 00:59:58 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <mgexeHo_EQZG4VII-fp7HjtfGQ6H5RkYnvSXeBlBDnw=.b1516902-2df4-4b14-a3af-63a81182bc90@github.com>

On Sun, 1 Jun 2025 04:53:46 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

I recommend we fallback to use CFFV.latest() explicitly for now. FYI we will likely add a new CFFV for all preview features, which we will likely use as the default if we encounter an old preview class file. We can then swap latest() with that preview cffv.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2928241509

From hgreule at openjdk.org  Mon Jun  2 06:12:51 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 06:12:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <mgexeHo_EQZG4VII-fp7HjtfGQ6H5RkYnvSXeBlBDnw=.b1516902-2df4-4b14-a3af-63a81182bc90@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <mgexeHo_EQZG4VII-fp7HjtfGQ6H5RkYnvSXeBlBDnw=.b1516902-2df4-4b14-a3af-63a81182bc90@github.com>
Message-ID: <XclSyIJ-nDMEkUri-wrYeBj2VM0yZvjTjZwCOJ9dR78=.38b60551-9b38-49dc-b36f-b7e3f43b4d1f@github.com>

On Mon, 2 Jun 2025 00:56:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> I recommend we fallback to use CFFV.latest() explicitly for now. FYI we will likely add a new CFFV for all preview features, which we will likely use as the default if we encounter an old preview class file. We can then swap latest() with that preview cffv.

Okay, sounds good. I guess that should be done in https://github.com/openjdk/jdk/blob/c5a1543ee3e68775f09ca29fb07efd9aebfdb33e/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java#L120-L123 directly? And also for both cases returning `null`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2928964395

From liach at openjdk.org  Mon Jun  2 13:00:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 13:00:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <_pcPENDOo2UK1hUIaUEe39a4uP94xmkHCJRXT3VNCRE=.46e88a2e-7c78-44d0-8d5d-3fe297b36238@github.com>

On Sun, 1 Jun 2025 04:53:46 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

That sounds right.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2930578390

From acobbs at openjdk.org  Mon Jun  2 14:27:08 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 14:27:08 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name"
Message-ID: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>

A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).

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

Commit messages:
 - Fix bug in Convert.utfNumChars().

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

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

From nbenalla at openjdk.org  Mon Jun  2 14:46:15 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 14:46:15 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
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: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@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 18 commits:

 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - 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/
 - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=05
  Stats: 1824 lines in 59 files changed: 1734 ins; 16 del; 74 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  Mon Jun  2 14:52:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 14:52:55 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <ipx1oPnsQNo4Anlo64ABbMwZoAeHFQk0bOIp4kyo5ew=.4b73443a-0ba4-48e7-bf77-ffe1e502ac10@github.com>

On Mon, 2 Jun 2025 14:46:15 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 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - 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/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

I have bumped the ASM version in [0dbdde7](https://github.com/openjdk/jdk/pull/25008/commits/0dbdde7bf6a0343acca74b284a8114c60919dd25) because various HotSpot tests use ASM fail under JDK 26 without this change.

This can be rolled back later after [JDK-8356548](https://bugs.openjdk.org/browse/JDK-8356548)

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

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

From nbenalla at openjdk.org  Mon Jun  2 15:05:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 15:05:54 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <-CUDiWjPLN2ywVxx5RQWUpmsjgkPLb0AmtnLi3MACP4=.d2aebd91-1220-4a2a-acf2-fb3dc953d908@github.com>

On Mon, 2 Jun 2025 14:46:15 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 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - 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/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

There were no API changes in JDK 25 build 25.

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

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

From hgreule at openjdk.org  Mon Jun  2 16:59:34 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 16:59:34 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v2]
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

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

  don't return null but latest as fallback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25569/files
  - new: https://git.openjdk.org/jdk/pull/25569/files/32da3621..487b85f1

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

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

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

From liach at openjdk.org  Mon Jun  2 17:32:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Jun 2025 17:32:54 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v2]
In-Reply-To: <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>
Message-ID: <3NtdD72C3NdAEhPOO6VL26fMjIUTRJLt5vMa9SG6QYI=.283834d3-c6d8-49a5-85de-8aa5b1f077f9@github.com>

On Mon, 2 Jun 2025 16:59:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't return null but latest as fallback

test/langtools/tools/javap/ClassFileVersionTest.java line 85:

> 83:     @ParameterizedTest
> 84:     @MethodSource("classFiles")
> 85:     void test(byte[] classFile, boolean shouldError) throws Throwable {

I recommend adding another String argument indicating the case name - otherwise, if junit fails, the error message reports the argument to string, which is not informative on which class file exactly is being tested.

An alternative approach can be inlining the arguments to `createClassFile` to the case arguments, like

void test(boolean shouldError, int major, int minor, AccessFlag... classFlags)

And junit provides a more useful error message for such arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2121764380

From jlahoda at openjdk.org  Mon Jun  2 18:06:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 2 Jun 2025 18:06:53 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name"
In-Reply-To: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
Message-ID: <jkZzMOI6NoEQ6Hq-Zu-dhHL709d6hGGLk8N-9M5QWdA=.ba3e6d65-42ac-490f-b188-0762cecec409@github.com>

On Sat, 31 May 2025 21:05:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).

Overall, looks sensible. Comments for consideration inline.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Convert.java line 231:

> 229:             off += nbytes;
> 230:             len -= nbytes;
> 231:             numChars++;

I wonder if it wouldn't be easier to simply ignore bytes from `buf` in the form of `0b10xxxxxx`? E.g. something along these lines:
Suggestion:

            int byte1 = buf[off++];
            if ((byte1 & 0b11000000) != 0b10000000) {
                //only count the first byte in every encoded sequence,
                //and ignore the other:
                numChars++;
            }

test/langtools/tools/javac/nametable/TestUtfNumChars.java line 42:

> 40: 
> 41:         // This is the string "ab?cd?ef?gh"
> 42:         String s = "ab\u00ABcd\u2264ef\ud83d\udd34gh";

Nit: not sure if there's a strong reason to use escapes in the string literal, esp. given the Unicode characters are used in the comment above. Given https://github.com/openjdk/jdk/pull/24574 is integrated, I would say, use UTF-8 in the string literal, and drop the comment?

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

PR Review: https://git.openjdk.org/jdk/pull/25567#pullrequestreview-2889427355
PR Review Comment: https://git.openjdk.org/jdk/pull/25567#discussion_r2121824627
PR Review Comment: https://git.openjdk.org/jdk/pull/25567#discussion_r2121820096

From acobbs at openjdk.org  Mon Jun  2 18:16:53 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 18:16:53 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name"
In-Reply-To: <jkZzMOI6NoEQ6Hq-Zu-dhHL709d6hGGLk8N-9M5QWdA=.ba3e6d65-42ac-490f-b188-0762cecec409@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <jkZzMOI6NoEQ6Hq-Zu-dhHL709d6hGGLk8N-9M5QWdA=.ba3e6d65-42ac-490f-b188-0762cecec409@github.com>
Message-ID: <Bsrxg_CcCEQkq503Fxr3iRiismsxJJfFejkgF9qI1Zg=.02fee963-c609-4da2-a6d4-0e83e7940f79@github.com>

On Mon, 2 Jun 2025 17:59:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).
>
> test/langtools/tools/javac/nametable/TestUtfNumChars.java line 42:
> 
>> 40: 
>> 41:         // This is the string "ab?cd?ef?gh"
>> 42:         String s = "ab\u00ABcd\u2264ef\ud83d\udd34gh";
> 
> Nit: not sure if there's a strong reason to use escapes in the string literal, esp. given the Unicode characters are used in the comment above. Given https://github.com/openjdk/jdk/pull/24574 is integrated, I would say, use UTF-8 in the string literal, and drop the comment?

I was aware of that recent change, but I don't understand the testing mechanics well enough to verify that `-encoding utf-8` is being added to the regression test compilation step on every possible platform (and wouldn't that be a jtreg thing, not an openjdk thing?)

So I was playing it safe, but if you say it's OK to assume compilation is always being done with `-encoding utf-8` then I'll take your word for it :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25567#discussion_r2121844932

From acobbs at openjdk.org  Mon Jun  2 19:05:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 19:05:37 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
Message-ID: <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>

> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).

Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Fix glitch in exception message.
 - Simplify code using review suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25567/files
  - new: https://git.openjdk.org/jdk/pull/25567/files/18f9c0c9..4967cac9

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

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

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

From acobbs at openjdk.org  Mon Jun  2 19:05:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 19:05:37 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <jkZzMOI6NoEQ6Hq-Zu-dhHL709d6hGGLk8N-9M5QWdA=.ba3e6d65-42ac-490f-b188-0762cecec409@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <jkZzMOI6NoEQ6Hq-Zu-dhHL709d6hGGLk8N-9M5QWdA=.ba3e6d65-42ac-490f-b188-0762cecec409@github.com>
Message-ID: <G-JbE8w3asVuI2wC7WtYu6lGEZtBlNdwKQ-a_TXcxPY=.3bb5be8c-25a2-4a6a-8389-3d11d54a4139@github.com>

On Mon, 2 Jun 2025 18:02:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix glitch in exception message.
>>  - Simplify code using review suggestion.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Convert.java line 231:
> 
>> 229:             off += nbytes;
>> 230:             len -= nbytes;
>> 231:             numChars++;
> 
> I wonder if it wouldn't be easier to simply ignore bytes from `buf` in the form of `0b10xxxxxx`? E.g. something along these lines:
> Suggestion:
> 
>             int byte1 = buf[off++];
>             if ((byte1 & 0b11000000) != 0b10000000) {
>                 //only count the first byte in every encoded sequence,
>                 //and ignore the other:
>                 numChars++;
>             }

Nice! Thanks, fixed in 91a9037f434. FYI I used `0x` instead of `0b` to stay consistent with the rest of the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25567#discussion_r2121942187

From hgreule at openjdk.org  Mon Jun  2 20:06:34 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 20:06:34 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

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

  make test failures easier to read

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25569/files
  - new: https://git.openjdk.org/jdk/pull/25569/files/487b85f1..379c892d

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

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

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

From hgreule at openjdk.org  Mon Jun  2 20:06:34 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 2 Jun 2025 20:06:34 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v2]
In-Reply-To: <3NtdD72C3NdAEhPOO6VL26fMjIUTRJLt5vMa9SG6QYI=.283834d3-c6d8-49a5-85de-8aa5b1f077f9@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <awuIAS0RLwt2RLf0b6mP8kWGqahDnR4rqYCUcJrqGrM=.ceb5469f-75f2-4a04-b731-7b9dbec1c73b@github.com>
 <3NtdD72C3NdAEhPOO6VL26fMjIUTRJLt5vMa9SG6QYI=.283834d3-c6d8-49a5-85de-8aa5b1f077f9@github.com>
Message-ID: <4JtP-QzIi6HHE6RAetfxa0fUynTQZjSQs-ly25vA8Z4=.5402ec04-30ab-4850-98b8-ae339eed2c50@github.com>

On Mon, 2 Jun 2025 17:30:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   don't return null but latest as fallback
>
> test/langtools/tools/javap/ClassFileVersionTest.java line 85:
> 
>> 83:     @ParameterizedTest
>> 84:     @MethodSource("classFiles")
>> 85:     void test(byte[] classFile, boolean shouldError) throws Throwable {
> 
> I recommend adding another String argument indicating the case name - otherwise, if junit fails, the error message reports the argument to string, which is not informative on which class file exactly is being tested.
> 
> An alternative approach can be inlining the arguments to `createClassFile` to the case arguments, like
> 
> void test(boolean shouldError, int major, int minor, AccessFlag... classFlags)
> 
> And junit provides a more useful error message for such arguments.

Good idea, I adjusted the test method signature. Seems like junit doesn't like the varargs, but that's okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2122046019

From duke at openjdk.org  Mon Jun  2 20:47:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 2 Jun 2025 20:47:53 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <-cK9P7CnB_QbXtN2B28S0mFhSg4NG7EsmzAbbJq7j5c=.1e7be39c-dbcc-4b90-97c4-fbb6918c9aba@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java line 122:

> 120:         if (major < JAVA_1_VERSION || major > ClassFile.latestMajorVersion())
> 121:             // something not representable by CFFV, let's fall back
> 122:             return ClassFileFormatVersion.latest();

For?`major <?JAVA_1_VERSION`, this?should?probably return?`ClassFileFormatVersion?.RELEASE_0`?instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2122121639

From acobbs at openjdk.org  Mon Jun  2 22:07:20 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 22:07:20 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v2]
In-Reply-To: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
Message-ID: <cgXIzUPcbaWfHjdYtU0g2CizuRPkwdT8iigwaV5zLb0=.471e58b2-5cd2-454a-ac01-1ba692ea4cad@github.com>

> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
> 
> Consider this example:
> 
> import java.util.*;
> import java.util.function.*;
> public class Example {
> 
>     @SuppressWarnings("deprecation")
>     List<Observable> m1() { return null; }
> 
>     void m2() {
>         for (var o : m1()) { }
>     }
> }
> 
> the compiler outputs this:
> 
> $ javac -Xlint:deprecation Example.java 
> warning: [deprecation] Observable in java.util has been deprecated
> 1 warning
> 
> but it should instead output this:
> 
> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>         for (var o : m1()) { }
>              ^
> 1 warning
> 
> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
> 
> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.

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

 - Merge branch 'master' into JDK-8329951
 - Fix bug where some warnings didn't have a source file position.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23683/files
  - new: https://git.openjdk.org/jdk/pull/23683/files/daacc44c..40ed15b1

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

  Stats: 635116 lines in 8619 files changed: 262319 ins; 320457 del; 52340 mod
  Patch: https://git.openjdk.org/jdk/pull/23683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23683/head:pull/23683

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

From vromero at openjdk.org  Mon Jun  2 23:14:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Jun 2025 23:14:56 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v2]
In-Reply-To: <cgXIzUPcbaWfHjdYtU0g2CizuRPkwdT8iigwaV5zLb0=.471e58b2-5cd2-454a-ac01-1ba692ea4cad@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <cgXIzUPcbaWfHjdYtU0g2CizuRPkwdT8iigwaV5zLb0=.471e58b2-5cd2-454a-ac01-1ba692ea4cad@github.com>
Message-ID: <1X8BZ1i38xvKx88ip9_LPiznHSEM8nvkdbhO61qJHys=.9c6f5c99-f109-48fb-aec3-39dd3a1e6a96@github.com>

On Mon, 2 Jun 2025 22:07:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
>> 
>> Consider this example:
>> 
>> import java.util.*;
>> import java.util.function.*;
>> public class Example {
>> 
>>     @SuppressWarnings("deprecation")
>>     List<Observable> m1() { return null; }
>> 
>>     void m2() {
>>         for (var o : m1()) { }
>>     }
>> }
>> 
>> the compiler outputs this:
>> 
>> $ javac -Xlint:deprecation Example.java 
>> warning: [deprecation] Observable in java.util has been deprecated
>> 1 warning
>> 
>> but it should instead output this:
>> 
>> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>>         for (var o : m1()) { }
>>              ^
>> 1 warning
>> 
>> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
>> 
>> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8329951
>  - Fix bug where some warnings didn't have a source file position.

test/langtools/tools/javac/tree/VarWarnPosition.java line 21:

> 19: 
> 20:         // Test 2
> 21:         Consumer<Depr> c = d -> { };

would it makes sense to add another test like this one?

Consumer<Depr> c2 = (var d) -> { };

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2122313868

From vromero at openjdk.org  Mon Jun  2 23:22:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Jun 2025 23:22:56 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v2]
In-Reply-To: <cgXIzUPcbaWfHjdYtU0g2CizuRPkwdT8iigwaV5zLb0=.471e58b2-5cd2-454a-ac01-1ba692ea4cad@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <cgXIzUPcbaWfHjdYtU0g2CizuRPkwdT8iigwaV5zLb0=.471e58b2-5cd2-454a-ac01-1ba692ea4cad@github.com>
Message-ID: <ofoqTrTJEF9A0EM0O3IkXNHAWpIRRFGL95Sbrzr4q8U=.71fc7609-dbeb-41e3-9821-1f4cb4e14827@github.com>

On Mon, 2 Jun 2025 22:07:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
>> 
>> Consider this example:
>> 
>> import java.util.*;
>> import java.util.function.*;
>> public class Example {
>> 
>>     @SuppressWarnings("deprecation")
>>     List<Observable> m1() { return null; }
>> 
>>     void m2() {
>>         for (var o : m1()) { }
>>     }
>> }
>> 
>> the compiler outputs this:
>> 
>> $ javac -Xlint:deprecation Example.java 
>> warning: [deprecation] Observable in java.util has been deprecated
>> 1 warning
>> 
>> but it should instead output this:
>> 
>> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>>         for (var o : m1()) { }
>>              ^
>> 1 warning
>> 
>> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
>> 
>> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8329951
>  - Fix bug where some warnings didn't have a source file position.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java line 369:

> 367: 
> 368:         boolean isImplicitlyTyped(JCVariableDecl decl) {
> 369:             return decl.declaredUsingVar();

an argument of an implicit lambda is implicitly typed but not declared using `var`, I guess we should at least add a note to this method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2122321290

From acobbs at openjdk.org  Mon Jun  2 23:28:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 23:28:37 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v3]
In-Reply-To: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
Message-ID: <4py36D2Fk7DsDj1A4-wE1FWQglJQVkQWlEgtAn_Adlo=.6bd41822-b84b-47c2-b51d-465bc199bd4a@github.com>

> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
> 
> Consider this example:
> 
> import java.util.*;
> import java.util.function.*;
> public class Example {
> 
>     @SuppressWarnings("deprecation")
>     List<Observable> m1() { return null; }
> 
>     void m2() {
>         for (var o : m1()) { }
>     }
> }
> 
> the compiler outputs this:
> 
> $ javac -Xlint:deprecation Example.java 
> warning: [deprecation] Observable in java.util has been deprecated
> 1 warning
> 
> but it should instead output this:
> 
> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>         for (var o : m1()) { }
>              ^
> 1 warning
> 
> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
> 
> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.

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

  Add another test variant per review suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23683/files
  - new: https://git.openjdk.org/jdk/pull/23683/files/40ed15b1..5b79fb2b

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

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

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

From acobbs at openjdk.org  Mon Jun  2 23:28:41 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 23:28:41 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v2]
In-Reply-To: <1X8BZ1i38xvKx88ip9_LPiznHSEM8nvkdbhO61qJHys=.9c6f5c99-f109-48fb-aec3-39dd3a1e6a96@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <cgXIzUPcbaWfHjdYtU0g2CizuRPkwdT8iigwaV5zLb0=.471e58b2-5cd2-454a-ac01-1ba692ea4cad@github.com>
 <1X8BZ1i38xvKx88ip9_LPiznHSEM8nvkdbhO61qJHys=.9c6f5c99-f109-48fb-aec3-39dd3a1e6a96@github.com>
Message-ID: <OmKVBbd3vtlyfcqpaPhZLNwMTxd62l_dKXE6vtyT_rM=.821d07cf-7eba-432d-9220-16d8bf1ef33c@github.com>

On Mon, 2 Jun 2025 23:11:32 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8329951
>>  - Fix bug where some warnings didn't have a source file position.
>
> test/langtools/tools/javac/tree/VarWarnPosition.java line 21:
> 
>> 19: 
>> 20:         // Test 2
>> 21:         Consumer<Depr> c = d -> { };
> 
> would it makes sense to add another test like this one?
> 
> Consumer<Depr> c2 = (var d) -> { };

Yes - thanks. Added in 5b79fb2b3e3.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2122326354

From acobbs at openjdk.org  Mon Jun  2 23:46:11 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 23:46:11 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
Message-ID: <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>

> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
> 
> Consider this example:
> 
> import java.util.*;
> import java.util.function.*;
> public class Example {
> 
>     @SuppressWarnings("deprecation")
>     List<Observable> m1() { return null; }
> 
>     void m2() {
>         for (var o : m1()) { }
>     }
> }
> 
> the compiler outputs this:
> 
> $ javac -Xlint:deprecation Example.java 
> warning: [deprecation] Observable in java.util has been deprecated
> 1 warning
> 
> but it should instead output this:
> 
> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>         for (var o : m1()) { }
>              ^
> 1 warning
> 
> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
> 
> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.

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

  Remove now-useless method RedundantLocalVarTypeAnalyzerBase.isImplicitlyTyped().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23683/files
  - new: https://git.openjdk.org/jdk/pull/23683/files/5b79fb2b..151d9882

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

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

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

From acobbs at openjdk.org  Mon Jun  2 23:46:16 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Jun 2025 23:46:16 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v2]
In-Reply-To: <ofoqTrTJEF9A0EM0O3IkXNHAWpIRRFGL95Sbrzr4q8U=.71fc7609-dbeb-41e3-9821-1f4cb4e14827@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <cgXIzUPcbaWfHjdYtU0g2CizuRPkwdT8iigwaV5zLb0=.471e58b2-5cd2-454a-ac01-1ba692ea4cad@github.com>
 <ofoqTrTJEF9A0EM0O3IkXNHAWpIRRFGL95Sbrzr4q8U=.71fc7609-dbeb-41e3-9821-1f4cb4e14827@github.com>
Message-ID: <Tq-TfM6kaL-uIlsrNKP0MTyzRicv8qzfOgw3hL1pg44=.e818ee8e-64c3-41e5-ba6f-4713cde7d75c@github.com>

On Mon, 2 Jun 2025 23:19:36 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8329951
>>  - Fix bug where some warnings didn't have a source file position.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java line 369:
> 
>> 367: 
>> 368:         boolean isImplicitlyTyped(JCVariableDecl decl) {
>> 369:             return decl.declaredUsingVar();
> 
> an argument of an implicit lambda is implicitly typed but not declared using `var`, I guess we should at least add a note to this method

In fact, this method `isImplicitlyTyped()` is misleadingly named - it appears to be simply testing for whether the variable is declared using `var` (and so maybe it should have been named `isDeclaredUsingVar()`).

But now that `JCVariableDecl.declaredUsingVar()` exists, we can just use that method directly and get rid of the intermediate method, which is not adding any value.

See if 151d9882bef looks better - thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2122342164

From vromero at openjdk.org  Tue Jun  3 01:52:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Jun 2025 01:52:51 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
Message-ID: <U8mKSfZWA3s_112gpO_cCXV365keHCvz1dziqrgPvnI=.47791179-6c77-4948-90dd-a9b577ce51e9@github.com>

On Mon, 2 Jun 2025 23:46:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
>> 
>> Consider this example:
>> 
>> import java.util.*;
>> import java.util.function.*;
>> public class Example {
>> 
>>     @SuppressWarnings("deprecation")
>>     List<Observable> m1() { return null; }
>> 
>>     void m2() {
>>         for (var o : m1()) { }
>>     }
>> }
>> 
>> the compiler outputs this:
>> 
>> $ javac -Xlint:deprecation Example.java 
>> warning: [deprecation] Observable in java.util has been deprecated
>> 1 warning
>> 
>> but it should instead output this:
>> 
>> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>>         for (var o : m1()) { }
>>              ^
>> 1 warning
>> 
>> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
>> 
>> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove now-useless method RedundantLocalVarTypeAnalyzerBase.isImplicitlyTyped().

lgtm, thanks for the changes

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23683#pullrequestreview-2890338583

From acobbs at openjdk.org  Tue Jun  3 02:37:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Jun 2025 02:37:52 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
Message-ID: <sh9PEGJxgPOLKW11aBoG-UmMj5AY2nz7FQJMP0prekI=.1ec77fae-c401-4c53-9ad6-f80dcdea15dd@github.com>

On Mon, 2 Jun 2025 23:46:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
>> 
>> Consider this example:
>> 
>> import java.util.*;
>> import java.util.function.*;
>> public class Example {
>> 
>>     @SuppressWarnings("deprecation")
>>     List<Observable> m1() { return null; }
>> 
>>     void m2() {
>>         for (var o : m1()) { }
>>     }
>> }
>> 
>> the compiler outputs this:
>> 
>> $ javac -Xlint:deprecation Example.java 
>> warning: [deprecation] Observable in java.util has been deprecated
>> 1 warning
>> 
>> but it should instead output this:
>> 
>> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>>         for (var o : m1()) { }
>>              ^
>> 1 warning
>> 
>> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
>> 
>> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove now-useless method RedundantLocalVarTypeAnalyzerBase.isImplicitlyTyped().

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23683#issuecomment-2933163167

From hgreule at openjdk.org  Tue Jun  3 05:56:55 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 3 Jun 2025 05:56:55 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <-cK9P7CnB_QbXtN2B28S0mFhSg4NG7EsmzAbbJq7j5c=.1e7be39c-dbcc-4b90-97c4-fbb6918c9aba@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
 <-cK9P7CnB_QbXtN2B28S0mFhSg4NG7EsmzAbbJq7j5c=.1e7be39c-dbcc-4b90-97c4-fbb6918c9aba@github.com>
Message-ID: <c6SFaL1fIIUu0dAFvGPvjt5cz67Fk4SdaYU5njR8r9M=.c7952553-a147-4ed8-9e15-53b6737197a4@github.com>

On Mon, 2 Jun 2025 20:44:44 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make test failures easier to read
>
> src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java line 122:
> 
>> 120:         if (major < JAVA_1_VERSION || major > ClassFile.latestMajorVersion())
>> 121:             // something not representable by CFFV, let's fall back
>> 122:             return ClassFileFormatVersion.latest();
> 
> For?`major <?JAVA_1_VERSION`, this?should?probably return?`ClassFileFormatVersion?.RELEASE_0`?instead.

I'm not sure if there is any better or worse default here, but for now, this just restores the semantics to what it was before javap was made CFFV-aware (instead of crashing). I think future improvements should be made separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25569#discussion_r2122784822

From nbenalla at openjdk.org  Tue Jun  3 11:14:36 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:14:36 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
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: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@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 20 commits:

 - Merge branch 'master' into jdk.8355746
 - Problemlist JavaBaseCheckSince
 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - 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
 - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=06
  Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 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  Tue Jun  3 11:14:37 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:14:37 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>

On Mon, 2 Jun 2025 14:46:15 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 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - 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/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind.

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

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

From jlahoda at openjdk.org  Tue Jun  3 11:44:59 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Jun 2025 11:44:59 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
Message-ID: <eeC8abUllQmxFKHDHnSAtnh-FCiHb-Rb2kKjrhxlzzo=.6b092298-8c2d-4b3c-9f7f-5ffe75a1b220@github.com>

On Mon, 2 Jun 2025 19:05:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix glitch in exception message.
>  - Simplify code using review suggestion.

Looks good to me. (I didn't run tests, please ask if you would want me to run them.)

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25567#pullrequestreview-2891958946

From acobbs at openjdk.org  Tue Jun  3 14:38:06 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Jun 2025 14:38:06 GMT
Subject: Integrated: 8329951: `var` emits deprecation warnings that do not
 point to the file or position
In-Reply-To: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
Message-ID: <Mgm6ZA86KL6FEbc9fyDUWFZyu7Ju69hqw9MFA9Zvxfc=.612bf037-47b5-4d6e-9ac0-deff3ec8f99e@github.com>

On Tue, 18 Feb 2025 23:49:10 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
> 
> Consider this example:
> 
> import java.util.*;
> import java.util.function.*;
> public class Example {
> 
>     @SuppressWarnings("deprecation")
>     List<Observable> m1() { return null; }
> 
>     void m2() {
>         for (var o : m1()) { }
>     }
> }
> 
> the compiler outputs this:
> 
> $ javac -Xlint:deprecation Example.java 
> warning: [deprecation] Observable in java.util has been deprecated
> 1 warning
> 
> but it should instead output this:
> 
> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>         for (var o : m1()) { }
>              ^
> 1 warning
> 
> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
> 
> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.

This pull request has now been integrated.

Changeset: e2f73665
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e2f736658fbd03d2dc2186dbd9ba9b13b1f1a8ac
Stats:     43 lines in 4 files changed: 35 ins; 4 del; 4 mod

8329951: `var` emits deprecation warnings that do not point to the file or position

Reviewed-by: vromero

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

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

From acobbs at openjdk.org  Tue Jun  3 14:48:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Jun 2025 14:48:52 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <eeC8abUllQmxFKHDHnSAtnh-FCiHb-Rb2kKjrhxlzzo=.6b092298-8c2d-4b3c-9f7f-5ffe75a1b220@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <eeC8abUllQmxFKHDHnSAtnh-FCiHb-Rb2kKjrhxlzzo=.6b092298-8c2d-4b3c-9f7f-5ffe75a1b220@github.com>
Message-ID: <duIyEBDz_Zl3xRiICnuI-qnSAFerPgg1hTlCuPRUWU4=.77f9dfbf-d37c-4a8a-8fb4-ff1247129800@github.com>

On Tue, 3 Jun 2025 11:42:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Looks good to me. (I didn't run tests, please ask if you would want me to run them.)

Thanks for the review!

Re: tests, to be honest I'm not sure what criteria to use to determine that. This change seems pretty innocuous but "seems" is a dangerous word. I'm happy to follow your advice on this... ? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2935689691

From duke at openjdk.org  Tue Jun  3 17:49:51 2025
From: duke at openjdk.org (Jens-Otto Larsen)
Date: Tue, 3 Jun 2025 17:49:51 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
Message-ID: <UBCP6QwzT1rqYlhEOybSaj-tmxNqZINvzh5LUxlpHJY=.2a6a1779-16a7-4924-abf7-deced1c3b1b8@github.com>

On Mon, 2 Jun 2025 19:05:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix glitch in exception message.
>  - Simplify code using review suggestion.

For what it's worth: I reported the issue, and the test I wrote - splitting a UTF-8 import statement into a list of package-parts and classname using lastIndexOfAscii('.') and utfNumChars - now works fine. 
Building javac and verifying the whole build is too big of a task for me.
This was a trip down memory lane as I did a 5 year stint at Sun Micro some 20 years ago :-) The times of AppServer 8 and start of GlassFish.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2936145150

From ihse at openjdk.org  Tue Jun  3 17:52:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:57 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: <DsuF98gTV85TRV5ofvmvH_-7fKmRNk28rI3RJV4e6Gk=.bc6bd102-147c-497e-9734-1bf6863060df@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

@naotoj Are you happy with the other changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/25228#issuecomment-2936435086

From naoto at openjdk.org  Tue Jun  3 17:52:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
Message-ID: <gah_JMPE3xHcudSsDq_iqqxmTfi3edTCv8NCbKznr1M=.67bfc258-b96f-4d60-b2f7-cda514b11b68@github.com>

On Tue, 3 Jun 2025 17:42:37 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into utf8-minor-cleanup
>  - Revert changes in RotFontBoundsTest.java
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java
>  - Replace uncessary unicode characters with ASCII in instructions, and fix typo
>  - Seems like typos in the comments
>  - Fix unicode sequences in comments (previously missed)

> @naotoj Are you happy with the other changes?

Yes. Thank you for the cleanup!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2893481166

From ihse at openjdk.org  Tue Jun  3 17:52:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into utf8-minor-cleanup
 - Revert changes in RotFontBoundsTest.java
 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java
 - 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:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/7184e685..c3027c1a

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

  Stats: 125596 lines in 1865 files changed: 71361 ins; 38692 del; 15543 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  Tue Jun  3 18:39:16 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Jun 2025 18:39:16 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <duIyEBDz_Zl3xRiICnuI-qnSAFerPgg1hTlCuPRUWU4=.77f9dfbf-d37c-4a8a-8fb4-ff1247129800@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <eeC8abUllQmxFKHDHnSAtnh-FCiHb-Rb2kKjrhxlzzo=.6b092298-8c2d-4b3c-9f7f-5ffe75a1b220@github.com>
 <duIyEBDz_Zl3xRiICnuI-qnSAFerPgg1hTlCuPRUWU4=.77f9dfbf-d37c-4a8a-8fb4-ff1247129800@github.com>
Message-ID: <VOFxok8qXsIXBQPSWMG66itAjcyqTyVAy-NuWGk0lSU=.9a3171dd-990b-401a-811b-3a5c1a714036@github.com>

On Tue, 3 Jun 2025 14:46:02 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > Looks good to me. (I didn't run tests, please ask if you would want me to run them.)
> 
> Thanks for the review!
> 
> Re: tests, to be honest I'm not sure what criteria to use to determine that. This change seems pretty innocuous but "seems" is a dangerous word. I'm happy to follow your advice on this... ? Thanks.

I've started a test run, the results will hopefully be tomorrow (my time, CEST). I think we should wait with the integration before they run.

Alternatively you could issue `/integrate delegate`, and I'd finish the integration if the tests are OK. But I think there's still time before RDP1, so there's not (yet) a need to do this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2936683820

From acobbs at openjdk.org  Tue Jun  3 18:44:16 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Jun 2025 18:44:16 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <VOFxok8qXsIXBQPSWMG66itAjcyqTyVAy-NuWGk0lSU=.9a3171dd-990b-401a-811b-3a5c1a714036@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <eeC8abUllQmxFKHDHnSAtnh-FCiHb-Rb2kKjrhxlzzo=.6b092298-8c2d-4b3c-9f7f-5ffe75a1b220@github.com>
 <duIyEBDz_Zl3xRiICnuI-qnSAFerPgg1hTlCuPRUWU4=.77f9dfbf-d37c-4a8a-8fb4-ff1247129800@github.com>
 <VOFxok8qXsIXBQPSWMG66itAjcyqTyVAy-NuWGk0lSU=.9a3171dd-990b-401a-811b-3a5c1a714036@github.com>
Message-ID: <MO5kfQkJO1xoGN70SrHHTa2AWv82va5AxD88twbvvnA=.e80ba28e-2eb6-40d0-9e31-e2bb512c5552@github.com>

On Tue, 3 Jun 2025 18:36:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I've started a test run, the results will hopefully be tomorrow (my time, CEST). I think we should wait with the integration before they run.

Sounds great - thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2936706306

From naoto at openjdk.org  Tue Jun  3 21:25:16 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 21:25:16 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
Message-ID: <-QQel1vpSF6SZ_puUqw9nqxFgNB8fzDl9xBaXfdbu-0=.1ccc228f-9fe6-4044-9349-98aebece94b7@github.com>

On Mon, 2 Jun 2025 19:05:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix glitch in exception message.
>  - Simplify code using review suggestion.

Just a drive-by comment, but should we check the validity of `off`? What if `off` points to the 2nd or 3rd byte in a character in the buffer?

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2937237378

From acobbs at openjdk.org  Tue Jun  3 21:37:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Jun 2025 21:37:22 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <-QQel1vpSF6SZ_puUqw9nqxFgNB8fzDl9xBaXfdbu-0=.1ccc228f-9fe6-4044-9349-98aebece94b7@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <-QQel1vpSF6SZ_puUqw9nqxFgNB8fzDl9xBaXfdbu-0=.1ccc228f-9fe6-4044-9349-98aebece94b7@github.com>
Message-ID: <TxqapgBv5S_mYQBedM8XoaiW8v_tcA7jFgJ1A6jW3Mc=.d3c4b723-1670-4df2-9732-936ff2311e01@github.com>

On Tue, 3 Jun 2025 21:21:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Just a drive-by comment, but should we check the validity of `off`? What if `off` points to the 2nd or 3rd byte in a character in the buffer?

Good question. This method is explicitly documented as assuming that the data is valid UTF-8. It's not trying to handle invalid data.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2937267766

From naoto at openjdk.org  Tue Jun  3 21:54:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 21:54:26 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <TxqapgBv5S_mYQBedM8XoaiW8v_tcA7jFgJ1A6jW3Mc=.d3c4b723-1670-4df2-9732-936ff2311e01@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <-QQel1vpSF6SZ_puUqw9nqxFgNB8fzDl9xBaXfdbu-0=.1ccc228f-9fe6-4044-9349-98aebece94b7@github.com>
 <TxqapgBv5S_mYQBedM8XoaiW8v_tcA7jFgJ1A6jW3Mc=.d3c4b723-1670-4df2-9732-936ff2311e01@github.com>
Message-ID: <VlrVqSLRybEQRdE39q-UPBFVIEXJAfWzPsjvyqekwfc=.14316203-b68c-4b8b-ac2b-903d557d2b5a@github.com>

On Tue, 3 Jun 2025 21:34:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > Just a drive-by comment, but should we check the validity of `off`? What if `off` points to the 2nd or 3rd byte in a character in the buffer?
> 
> Good question. This method is explicitly documented as assuming that the data is valid UTF-8. It's not trying to handle invalid data.

I meant the validity of `off`, not the UTF-8 data. For example in your test case, if the `off` is 16, it will return 3 chars although the first one is only the trailing byte. So I guess some comment may help here

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2937319888

From acobbs at openjdk.org  Tue Jun  3 23:15:26 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Jun 2025 23:15:26 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <VlrVqSLRybEQRdE39q-UPBFVIEXJAfWzPsjvyqekwfc=.14316203-b68c-4b8b-ac2b-903d557d2b5a@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <-QQel1vpSF6SZ_puUqw9nqxFgNB8fzDl9xBaXfdbu-0=.1ccc228f-9fe6-4044-9349-98aebece94b7@github.com>
 <TxqapgBv5S_mYQBedM8XoaiW8v_tcA7jFgJ1A6jW3Mc=.d3c4b723-1670-4df2-9732-936ff2311e01@github.com>
 <VlrVqSLRybEQRdE39q-UPBFVIEXJAfWzPsjvyqekwfc=.14316203-b68c-4b8b-ac2b-903d557d2b5a@github.com>
Message-ID: <XpMKJPAjex5EmpHqlrq125bJ77xr_1FnzoJGZg4WTa4=.fa17afef-2668-4411-a3a6-9d0e0f4fcfae@github.com>

On Tue, 3 Jun 2025 21:51:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > Good question. This method is explicitly documented as assuming that the data is valid UTF-8. It's not trying to handle invalid data.
> 
> I meant the validity of `off`, not the UTF-8 data. For example in your test case, if the `off` is 16, it will return 3 chars although the first one is only the trailing byte. So I guess some comment may help here

Well I guess to be more specific the method assumes that the given _range_ of bytes is valid UTF-8. But yes you are right, this could all be better (more precisely) documented. That's for another PR though, I am loath to further delay this one at this point since it's already approved and the JDK 25 lop off happens tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2937675168

From naoto at openjdk.org  Tue Jun  3 23:28:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 23:28:17 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
Message-ID: <ON2KuY_vsRfA_YMG2Vd1-LhdbONp_ge2C9QiB86SWSg=.97111710-5b49-401d-bafe-95b59b8c41db@github.com>

On Mon, 2 Jun 2025 19:05:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix glitch in exception message.
>  - Simplify code using review suggestion.

> That's for another PR though, I am loath to further delay this one at this point since it's already approved and the JDK 25 lop off happens tomorrow

Totally fine by me

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25567#pullrequestreview-2894373139

From jlahoda at openjdk.org  Wed Jun  4 05:01:19 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Jun 2025 05:01:19 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
Message-ID: <XagMylPJUuOdBSgoHJbL0E2a7HA5ANbGzIFOtOlfyLU=.fe95fa1b-50c0-4ddd-9532-e519b2def91b@github.com>

On Mon, 2 Jun 2025 19:05:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix glitch in exception message.
>  - Simplify code using review suggestion.

Tests (tier1-3) passed, so OK to integrate, I think. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2938534822

From ihse at openjdk.org  Wed Jun  4 08:14:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 4 Jun 2025 08:14:23 GMT
Subject: Integrated: 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: <At8VnpzuhZYQNUNMKjqDDQJWpn-95O-PP01qGcpOB20=.8371e2ec-5f36-4a13-b566-6482ac2b6667@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.

This pull request has now been integrated.

Changeset: edf92721
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edf92721c2db4cfba091cf4901af603db8486951
Stats:     15 lines in 13 files changed: 0 ins; 0 del; 15 mod

8356977: UTF-8 cleanups

Reviewed-by: naoto, prr

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

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

From acobbs at openjdk.org  Wed Jun  4 12:52:43 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Jun 2025 12:52:43 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <XagMylPJUuOdBSgoHJbL0E2a7HA5ANbGzIFOtOlfyLU=.fe95fa1b-50c0-4ddd-9532-e519b2def91b@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <XagMylPJUuOdBSgoHJbL0E2a7HA5ANbGzIFOtOlfyLU=.fe95fa1b-50c0-4ddd-9532-e519b2def91b@github.com>
Message-ID: <hl10DotB1WD1hlzDIUme-8ZMW4QM9SoTbp6Nnn5YidY=.804f2278-ed1e-4461-a0ff-096eddec59b0@github.com>

On Wed, 4 Jun 2025 04:58:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Tests (tier1-3) passed, so OK to integrate, I think. Thanks!

Awesome! Thanks for running the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2939921931

From acobbs at openjdk.org  Wed Jun  4 12:59:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Jun 2025 12:59:02 GMT
Subject: Integrated: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name"
In-Reply-To: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
Message-ID: <UaERvjHStLD0in8AwoUIL2BCNkf4vlRsg0NYBaMqBTM=.b3a0cbbe-fd19-4ef9-a05b-84fac454005e@github.com>

On Sat, 31 May 2025 21:05:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> A simple counting bug in `Convert.utfNumChars()` causes bogus compiler errors for `import` statements of non-ASCII class names when the compiler is configured to use one of the older UTF-8 based `Name` table implementations (e.g., by specifying the `-XDuseUnsharedTable=true` flag).

This pull request has now been integrated.

Changeset: 09ec4de7
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09ec4de74d495560ffb9ec529df7ec818c1d617c
Stats:     75 lines in 2 files changed: 70 ins; 2 del; 3 mod

8358066: Non-ascii package names gives compilation error "import requires canonical name"

Reviewed-by: jlahoda, naoto

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

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

From duke at openjdk.org  Wed Jun  4 13:19:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 4 Jun 2025 13:19:54 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>

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

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

Some pre-review comments.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java line 183:

> 181:      *                       {@code null} to ignore release versioning).
> 182:      */
> 183:     public static Map<String, ?> readOnlyJarFSEnv(String releaseVersion) {

I named this after the getJarFSProvider() method above, since they are used in close proximity, but would be happy to consider other names.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 577:

> 575:                 // Less common case is possible if the file manager was not initialized in JavacTask,
> 576:                 // or if non "*.jar" files are on the classpath. If this is not a ZIP/JAR file then it
> 577:                 // will ignore ZIP specific parameters in env, and may not end up being read-only.

Added comment just to pull out the fact that we might not be able to promise that all ArchiveContainer instances are backed by a read-only file system, and the compiler still has a duty not to attempt any modification.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java line 1463:

> 1461:                                 return null;
> 1462:                             }
> 1463:                             fs = jarFSProvider.newFileSystem(p, FSInfo.readOnlyJarFSEnv(null));

Happy to consider either commenting the null here (e.g. `readOnlyJarFSEnv(/* releaseVersion */ null)`), or adding a no-arg version of the method in FSInfo.

src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 98:

> 96: 
> 97:     // These must match attributes defined in ZipFileSystem.java.
> 98:     private static final Map<String, ?> CT_SYM_ZIP_ENV = Map.of(

Didn't use FSInfo here, even though it's mostly the same logic, because the symbol file is a ZIP, not a JAR, so naming gets a little muddled, and in this case there's no runtime info, so I can just make a constant map.

src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 120:

> 118:         Path ctSymFile = findCtSym();
> 119:         if (Files.exists(ctSymFile)) {
> 120:             try (FileSystem fs = FileSystems.newFileSystem(ctSymFile, (ClassLoader)null);

Several places in existing code pass "(ClassLoader) null", which by inspection makes no difference compared to simply not passing the parameter, so I took the decision to remove it for neatness.

src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 261:

> 259:                         // If for any reason this was not opened from a ZIP file,
> 260:                         // then the resulting file system would not be read-only.
> 261:                         assert fs.isReadOnly();

Not sure if an assert is the right thing here or if this should be an always-on runtime check (it can be provoked by having a non-ZIP symbol file, but it's not sanctioned in any way).

test/langtools/tools/javac/api/file/SJFM_TestBase.java line 164:

> 162:         if (zipfs == null) {
> 163:             Path testZip = createSourceZip();
> 164:             zipfs = FileSystems.newFileSystem(testZip, Map.of("accessMode", "readOnly"));

Not strictly necessary, but seems like a good idea to use read-only for testing.

test/langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java line 46:

> 44: 
> 45: public class ClassRefDupInConstantPoolTest {
> 46: 

This test was failing and needed to be compiling its own class file rather than reading the one in the test library.

test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 68:

> 66:         // Expected to always be a ZIP filesystem.
> 67:         try (FileSystem fs = FileSystems.newFileSystem(ctSym, FSInfo.readOnlyJarFSEnv(null))) {
> 68:             // Check that the file system is read only (not true if not a zip file system).

Another case where I'm not 100% sure if it should be an assert, or a runtime exception/error.

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

PR Review: https://git.openjdk.org/jdk/pull/25639#pullrequestreview-2896486601
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126444200
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126446371
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126449539
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126452047
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126454461
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126457316
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126458265
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126461426
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2126462843

From duke at openjdk.org  Wed Jun  4 13:19:43 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 4 Jun 2025 13:19:43 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
Message-ID: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>

This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.

Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
This will, of course, be thoroughly tested before integration.

It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.

I'm also happy to update the original bug description to include the timestamp related changes as necessary.

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

Commit messages:
 - restore JavaCompiler error change
 - Integrate read-only ZIP/JAR files into Javac.

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

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

From cushon at openjdk.org  Wed Jun  4 15:45:07 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 4 Jun 2025 15:45:07 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
Message-ID: <2iuQgoqdaiMsuA3GiTkRUpIGZBvQ58y8xm7Jz5zkNmE=.131e4513-e943-44e6-883a-9ec848446e22@github.com>

On Mon, 2 Jun 2025 23:46:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR fixes a bug that causes certain warnings to be emitted without source file location information.
>> 
>> Consider this example:
>> 
>> import java.util.*;
>> import java.util.function.*;
>> public class Example {
>> 
>>     @SuppressWarnings("deprecation")
>>     List<Observable> m1() { return null; }
>> 
>>     void m2() {
>>         for (var o : m1()) { }
>>     }
>> }
>> 
>> the compiler outputs this:
>> 
>> $ javac -Xlint:deprecation Example.java 
>> warning: [deprecation] Observable in java.util has been deprecated
>> 1 warning
>> 
>> but it should instead output this:
>> 
>> Example.java:9: warning: [deprecation] Observable in java.util has been deprecated
>>         for (var o : m1()) { }
>>              ^
>> 1 warning
>> 
>> The bug happens because the "synthetic" type that is installed dynamically for implicitly typed variables is not given a source code position. This makes some sense (?) because that type doesn't literally appear in the variable declaration; however, certain error messages expect to be able to point to the type portion of a variable declaration, so it also causes this bug (and presumably similar variants). To fix this, we just copy the position of the variable declaration itself to the synthetic type.
>> 
>> However, this change necessitated another change: The fix for [JDK-8200199](https://bugs.openjdk.org/browse/JDK-8200199) added back in 2018 relies on the fact that the position of an implicitly typed variable is always null, so this change breaks that fix. But since then, a new method `JCVariableDecl.declaredUsingVar()` was added, so we can just use that test instead. This also makes the code a little clearer.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove now-useless method RedundantLocalVarTypeAnalyzerBase.isImplicitlyTyped().

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

> 5719:             tree.vartype = make.at(tree.pos()).Erroneous();
> 5720:         } else {
> 5721:             tree.vartype = make.at(tree.pos()).Type(type);

@archiecobbs thanks for fixing this! IIUC this means that `var` now has a start position, but this is still not setting and end position. Do you think it would it make sense to record both start and end positions for `var`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2126918085

From acobbs at openjdk.org  Wed Jun  4 15:59:00 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Jun 2025 15:59:00 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <2iuQgoqdaiMsuA3GiTkRUpIGZBvQ58y8xm7Jz5zkNmE=.131e4513-e943-44e6-883a-9ec848446e22@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
 <2iuQgoqdaiMsuA3GiTkRUpIGZBvQ58y8xm7Jz5zkNmE=.131e4513-e943-44e6-883a-9ec848446e22@github.com>
Message-ID: <vqcNTPSp1h_E4Y7vH9YKfjMZqf4dNQ5oDVfjgxg6t60=.f048324d-7826-4292-bc5a-7d03884f854b@github.com>

On Wed, 4 Jun 2025 15:42:07 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> @archiecobbs thanks for fixing this! IIUC this means that `var` now has a start position, but this is still not setting and end position. Do you think it would it make sense to record both start and end positions for `var`?

I'm not sure (due to my own ignorance, not skepticism). How does the lack of ending position manifest? FWIW there appear to be lots of instances in the compiler where `make.at()` is used to create some AST node with a given start position, but where the end position is never being set. How is this case different? Etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2126945278

From cushon at openjdk.org  Wed Jun  4 16:13:00 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 4 Jun 2025 16:13:00 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <vqcNTPSp1h_E4Y7vH9YKfjMZqf4dNQ5oDVfjgxg6t60=.f048324d-7826-4292-bc5a-7d03884f854b@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
 <2iuQgoqdaiMsuA3GiTkRUpIGZBvQ58y8xm7Jz5zkNmE=.131e4513-e943-44e6-883a-9ec848446e22@github.com>
 <vqcNTPSp1h_E4Y7vH9YKfjMZqf4dNQ5oDVfjgxg6t60=.f048324d-7826-4292-bc5a-7d03884f854b@github.com>
Message-ID: <De0MZ_tdXmehW0rDVPi2W0Qinan_xgQFc-GyxUOjL98=.c8b55440-a110-48dc-aeb7-f401e584d307@github.com>

On Wed, 4 Jun 2025 15:55:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5721:
>> 
>>> 5719:             tree.vartype = make.at(tree.pos()).Erroneous();
>>> 5720:         } else {
>>> 5721:             tree.vartype = make.at(tree.pos()).Type(type);
>> 
>> @archiecobbs thanks for fixing this! IIUC this means that `var` now has a start position, but this is still not setting and end position. Do you think it would it make sense to record both start and end positions for `var`?
>
>> @archiecobbs thanks for fixing this! IIUC this means that `var` now has a start position, but this is still not setting and end position. Do you think it would it make sense to record both start and end positions for `var`?
> 
> I'm not sure (due to my own ignorance, not skepticism). How does the lack of ending position manifest? FWIW there appear to be lots of instances in the compiler where `make.at()` is used to create some AST node with a given start position, but where the end position is never being set. How is this case different? Etc.

I'm not sure if manifests in behaviour in javac, but it affects `com.sun.source.util.SourcePositions#getEndPosition`, so it's observable to plugins. Most local variables types generally have start/end positions, `var` is an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2126972119

From acobbs at openjdk.org  Wed Jun  4 16:21:59 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Jun 2025 16:21:59 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <De0MZ_tdXmehW0rDVPi2W0Qinan_xgQFc-GyxUOjL98=.c8b55440-a110-48dc-aeb7-f401e584d307@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
 <2iuQgoqdaiMsuA3GiTkRUpIGZBvQ58y8xm7Jz5zkNmE=.131e4513-e943-44e6-883a-9ec848446e22@github.com>
 <vqcNTPSp1h_E4Y7vH9YKfjMZqf4dNQ5oDVfjgxg6t60=.f048324d-7826-4292-bc5a-7d03884f854b@github.com>
 <De0MZ_tdXmehW0rDVPi2W0Qinan_xgQFc-GyxUOjL98=.c8b55440-a110-48dc-aeb7-f401e584d307@github.com>
Message-ID: <ZBYh4Q53ycCxmWReN_HDsb8Uwe2nLnrZuFHc41juloo=.9b5c4f10-b1f6-4c76-859c-59b2d1e193b3@github.com>

On Wed, 4 Jun 2025 16:10:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>>> @archiecobbs thanks for fixing this! IIUC this means that `var` now has a start position, but this is still not setting and end position. Do you think it would it make sense to record both start and end positions for `var`?
>> 
>> I'm not sure (due to my own ignorance, not skepticism). How does the lack of ending position manifest? FWIW there appear to be lots of instances in the compiler where `make.at()` is used to create some AST node with a given start position, but where the end position is never being set. How is this case different? Etc.
>
> I'm not sure if manifests in behaviour in javac, but it affects `com.sun.source.util.SourcePositions#getEndPosition`, so it's observable to plugins. Most local variables types generally have start/end positions, `var` is an exception.

Fair enough. Would you mind creating a JIRA issue (you can assign to me)? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2126988368

From cushon at openjdk.org  Wed Jun  4 16:32:56 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 4 Jun 2025 16:32:56 GMT
Subject: RFR: 8329951: `var` emits deprecation warnings that do not point
 to the file or position [v4]
In-Reply-To: <ZBYh4Q53ycCxmWReN_HDsb8Uwe2nLnrZuFHc41juloo=.9b5c4f10-b1f6-4c76-859c-59b2d1e193b3@github.com>
References: <S4NbU0c4rkoBtsxesFm3_8nsq50xUSsiSOMF3wBoQww=.5a188601-cab7-4bc1-bc2c-54429f8a2a58@github.com>
 <lobtc59Pl-8R-n93Nc9rP7V0-gq7hxAvaTBBqNHhUvA=.1233181b-16c8-49e8-a768-5407ba4da89b@github.com>
 <2iuQgoqdaiMsuA3GiTkRUpIGZBvQ58y8xm7Jz5zkNmE=.131e4513-e943-44e6-883a-9ec848446e22@github.com>
 <vqcNTPSp1h_E4Y7vH9YKfjMZqf4dNQ5oDVfjgxg6t60=.f048324d-7826-4292-bc5a-7d03884f854b@github.com>
 <De0MZ_tdXmehW0rDVPi2W0Qinan_xgQFc-GyxUOjL98=.c8b55440-a110-48dc-aeb7-f401e584d307@github.com>
 <ZBYh4Q53ycCxmWReN_HDsb8Uwe2nLnrZuFHc41juloo=.9b5c4f10-b1f6-4c76-859c-59b2d1e193b3@github.com>
Message-ID: <dORh6QccD5f-lg9G3SyAfgQgyj-pQHmRfjEjWvKLE2M=.1d88c0b5-13b5-44d3-a829-a8c7c13f4a19@github.com>

On Wed, 4 Jun 2025 16:19:25 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I'm not sure if manifests in behaviour in javac, but it affects `com.sun.source.util.SourcePositions#getEndPosition`, so it's observable to plugins. Most local variables types generally have start/end positions, `var` is an exception.
>
> Fair enough. Would you mind creating a JIRA issue (you can assign to me)? Thanks.

Thanks for considering it, I filed https://bugs.openjdk.org/browse/JDK-8358604

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23683#discussion_r2127006474

From hgreule at openjdk.org  Wed Jun  4 19:22:51 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 4 Jun 2025 19:22:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <_pcPENDOo2UK1hUIaUEe39a4uP94xmkHCJRXT3VNCRE=.46e88a2e-7c78-44d0-8d5d-3fe297b36238@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <_pcPENDOo2UK1hUIaUEe39a4uP94xmkHCJRXT3VNCRE=.46e88a2e-7c78-44d0-8d5d-3fe297b36238@github.com>
Message-ID: <a4r34MXHmlbCk-RjuVF0c6iJPwj9k5U9LVyHFX5-6fI=.a5702df0-636a-45d3-9de0-57e2d0d884a2@github.com>

On Mon, 2 Jun 2025 12:58:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> That sounds right.

@liach is there anything else to do? Please let me know.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2941172515

From darcy at openjdk.org  Wed Jun  4 20:13:56 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Jun 2025 20:13:56 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <TtJhT2d8gCxXyqE4Do-VMnz1G-4c4yZEw_Bmsw7UWog=.48da9ef3-ebd5-4f08-8ee6-d372d213fd32@github.com>

On Tue, 3 Jun 2025 11:14:36 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 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - 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
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2897980100

From iris at openjdk.org  Wed Jun  4 20:37:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 4 Jun 2025 20:37:51 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <35K5iPJmI7-SaswDGvLtPKD87st1QJcFgfka38TsImQ=.b8f56c80-d2c6-4282-8b85-eca97880dfe0@github.com>

On Tue, 3 Jun 2025 11:14:36 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 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - 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
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898034878

From kcr at openjdk.org  Wed Jun  4 20:37:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 20:37:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
 <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>
Message-ID: <_Vfw9XCw0xZe8UevwOD5UOW4dZHoT2VzKC4_PT5nIGI=.9f6c8119-c437-49b1-90f5-740793992c20@github.com>

On Tue, 3 Jun 2025 11:10:30 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind.

What is your plan for addressing this? In its current state, that problem list entry will prevent integration. If you intend to integrate this PR with that test problem listed, you will need to file a new bug and use that bug ID in the problem list.

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

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

From kcr at openjdk.org  Wed Jun  4 20:46:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 20:46:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>

On Tue, 3 Jun 2025 11:14:36 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 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - 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
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

test/jdk/ProblemList.txt line 843:

> 841: # jdk_since_checks
> 842: 
> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all

You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list.

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

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

From vromero at openjdk.org  Wed Jun  4 21:06:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Jun 2025 21:06:03 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of JavacTask::call
Message-ID: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>

Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.

TIA

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

Commit messages:
 - 8341778: Some javac tests ignore the result of task.call()

Changes: https://git.openjdk.org/jdk/pull/25645/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341778
  Stats: 136 lines in 33 files changed: 88 ins; 1 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/25645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25645/head:pull/25645

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

From nbenalla at openjdk.org  Wed Jun  4 21:36:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 21:36:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
 <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>
Message-ID: <LPUpmFAwsEr9okQ2_9nJfDQNXtD6VX6CI5qi8TEf_-k=.0d220f12-4685-4681-9ea6-ac6f5e8a1d0f@github.com>

On Wed, 4 Jun 2025 20:44:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge branch 'master' into jdk.8355746
>>  - Problemlist JavaBaseCheckSince
>>  - Revert "feedback: never bump ASM version"
>>    
>>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>>  - Merge branch 'master' into jdk.8355746
>>  - 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
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496
>
> test/jdk/ProblemList.txt line 843:
> 
>> 841: # jdk_since_checks
>> 842: 
>> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all
> 
> You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list.

Will update this in a couple of hours. Thanks Kevin.

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

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

From kcr at openjdk.org  Wed Jun  4 21:51:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 21:51:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <CT4PKK-7N0z92vGQulU36AwsHzHnASR0frsvU4kJUkM=.eb614b2e-51b2-437d-bbc0-a8d7ebdd7c84@github.com>

On Tue, 3 Jun 2025 11:14:36 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 20 commits:
> 
>  - Merge branch 'master' into jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - 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
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

test/jdk/ProblemList.txt line 843:

> 841: # jdk_since_checks
> 842: 
> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all

Suggestion:

tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8358627 generic-all


@nizarbenalla Per our offline discussion, I created [JDK-8358627](https://bugs.openjdk.org/browse/JDK-8358627) to track this.

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

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

From nbenalla at openjdk.org  Wed Jun  4 23:01:14 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 23:01:14 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v8]
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: <0wD_TZCgYfWRZurWBE_yoLoNtP7xlUUUPxJ3Stqi5Cs=.42b298e3-bbd7-4d9e-bdfd-ae9176ffc9b5@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 22 commits:

 - use a different bug ID to problemlist `kevinrushforth `
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Problemlist JavaBaseCheckSince
 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - 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
 - ... and 12 more: https://git.openjdk.org/jdk/compare/5b27e9c2...09df3b66

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=07
  Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 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 liach at openjdk.org  Wed Jun  4 23:03:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Jun 2025 23:03:50 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <43VTjEzkK3bCvuzs_O39TqLIPEYTy1kGDrpenF2iOrE=.cef539f8-8a57-4938-9fb9-4a314a241bf9@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25569#pullrequestreview-2898306324

From nbenalla at openjdk.org  Wed Jun  4 23:09:08 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 23:09:08 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v9]
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: <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>

> Get JDK 26 underway.

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

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25008/files
  - new: https://git.openjdk.org/jdk/pull/25008/files/09df3b66..9929da7b

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 iris at openjdk.org  Wed Jun  4 23:56:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 4 Jun 2025 23:56:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v9]
In-Reply-To: <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>
Message-ID: <SKr7_DxXZshmrjnCr9TN17KU-5ziqCGNDQCpFY4LmvM=.755c3425-adbb-48a0-8cb0-453601ae7c0e@github.com>

On Wed, 4 Jun 2025 23:09:08 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898378068

From liach at openjdk.org  Thu Jun  5 00:06:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Jun 2025 00:06:51 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
Message-ID: <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>

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

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java line 1463:
> 
>> 1461:                                 return null;
>> 1462:                             }
>> 1463:                             fs = jarFSProvider.newFileSystem(p, FSInfo.readOnlyJarFSEnv(null));
> 
> Happy to consider either commenting the null here (e.g. `readOnlyJarFSEnv(/* releaseVersion */ null)`), or adding a no-arg version of the method in FSInfo.

This seems like a fallback path, so don't think we should add a no-arg version to promote skipping the release version.

> test/langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java line 46:
> 
>> 44: 
>> 45: public class ClassRefDupInConstantPoolTest {
>> 46: 
> 
> This test was failing and needed to be compiling its own class file rather than reading the one in the test library.

The class file is from this test file instead of the test libraries, and this pattern of shipping additional classes in the same compilation unit for class file handling in tests is common in jdk/classfile and other packages. Could the `clean` directive be the culprit?

> test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 68:
> 
>> 66:         // Expected to always be a ZIP filesystem.
>> 67:         try (FileSystem fs = FileSystems.newFileSystem(ctSym, FSInfo.readOnlyJarFSEnv(null))) {
>> 68:             // Check that the file system is read only (not true if not a zip file system).
> 
> Another case where I'm not 100% sure if it should be an assert, or a runtime exception/error.

jtreg runs tests with -ea, so either works fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2127650560
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2127643194
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2127646760

From hgreule at openjdk.org  Thu Jun  5 01:35:51 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 5 Jun 2025 01:35:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <3gheiEAamKkwB_QE3Xx49ue7OBnt0R70kTyXnVLUrW8=.40b9509d-37f4-40be-8ccd-7ad2e8345ba8@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2942410190

From duke at openjdk.org  Thu Jun  5 01:35:51 2025
From: duke at openjdk.org (duke)
Date: Thu, 5 Jun 2025 01:35:51 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <phXoBLBbdZro4KmjlRcEPDYl_tiD28HyahpJQLBikvI=.8d3b9468-354b-4994-9026-cad7daf6907e@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2942411420

From liach at openjdk.org  Thu Jun  5 01:43:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Jun 2025 01:43:57 GMT
Subject: RFR: 8358078: javap crashes with NPE on preview class file [v3]
In-Reply-To: <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
 <qMfx2uZbuwG0AsPl4KL6NiIcgO5jHq4Pvp0JfE914ng=.cfa66747-2e99-45ad-b2a5-6a841f3ea4ad@github.com>
Message-ID: <hSgyQSOmHi-k4_JvVQzVu46ePcULtLlDhJZzMOu6gbY=.27dcce37-c106-4afd-a578-8287a9c6d71f@github.com>

On Mon, 2 Jun 2025 20:06:34 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make test failures easier to read

Thanks. Since this test is in tier1 langtools which is green, I think we can go ahead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25569#issuecomment-2942421568

From hgreule at openjdk.org  Thu Jun  5 01:43:58 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 5 Jun 2025 01:43:58 GMT
Subject: Integrated: 8358078: javap crashes with NPE on preview class file
In-Reply-To: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
References: <nqTvcHHSXWnfDEJmrkseSdkflEn2AYcGERS-Qk3_EAc=.46285c3b-c710-4ce0-b07e-2139536510da@github.com>
Message-ID: <5tWT2kiEgtGMukHjrp22pcWLRZRjLMljuQxQKismJgM=.1cedb4d7-56c5-4b87-a391-805481476e90@github.com>

On Sun, 1 Jun 2025 04:53:46 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This change addresses a NPE in javap when trying to print a class with minorVersion != 0. With this change, we fall back to the methods that don't take a `ClassFileFormatVersion` in such case.

This pull request has now been integrated.

Changeset: 575806c0
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/575806c0e5584ea24cda80158070579b88c477f7
Stats:     102 lines in 2 files changed: 100 ins; 0 del; 2 mod

8358078: javap crashes with NPE on preview class file

Reviewed-by: liach

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

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

From shade at openjdk.org  Thu Jun  5 06:20:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 06:20:52 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

Looks good, but I have question about hunks that are not about wrapping `call()`-s. Those look like fixing the actual test bugs?

test/langtools/tools/javac/T6361619.java line 53:

> 51:         final PrintWriter out = new PrintWriter(System.err, true);
> 52: 
> 53:         Iterable<String> flags = Arrays.asList("--add-exports", "jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED",

Why `--add-exports`? Did this test actually failed without us noticing?

test/langtools/tools/javac/api/8007344/Test.java line 79:

> 77:     }
> 78: 
> 79:     static final List<String> OPTIONS = List.of(

Same question here...

test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 37:

> 35: public class SOEDeeplyNestedBlocksTest {
> 36: 
> 37:     static final int NESTING_DEPTH = 500;

Same question here.

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

PR Review: https://git.openjdk.org/jdk/pull/25645#pullrequestreview-2898988500
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128026868
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128036046
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128036600

From duke at openjdk.org  Thu Jun  5 08:45:53 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 08:45:53 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
Message-ID: <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>

On Thu, 5 Jun 2025 06:17:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
>> 
>> TIA
>
> test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 37:
> 
>> 35: public class SOEDeeplyNestedBlocksTest {
>> 36: 
>> 37:     static final int NESTING_DEPTH = 500;
> 
> Same question here.

With a NESTING_DEPTH of 1000 javac will run into a StackOverflowError, but it still completes and task.call() returns false. Using 500 javac can compile without error. Not sure what this test wants to prove. If it wants to show that javac can complete without throwing an SOE then it should keep depth 1000 and test that task.call() returns false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128289861

From vromero at openjdk.org  Thu Jun  5 13:36:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 13:36:53 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
Message-ID: <s_N1iZWcuOYjZcizoH25T0-do9ofLtPP2PIzN7l6Rn8=.24911151-5c9c-4efb-b16a-1f0ab93aa26b@github.com>

On Thu, 5 Jun 2025 06:09:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
>> 
>> TIA
>
> test/langtools/tools/javac/T6361619.java line 53:
> 
>> 51:         final PrintWriter out = new PrintWriter(System.err, true);
>> 52: 
>> 53:         Iterable<String> flags = Arrays.asList("--add-exports", "jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED",
> 
> Why `--add-exports`? Did this test actually failed without us noticing?

correct

> test/langtools/tools/javac/api/8007344/Test.java line 79:
> 
>> 77:     }
>> 78: 
>> 79:     static final List<String> OPTIONS = List.of(
> 
> Same question here...

same answer here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128873770
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128874248

From vromero at openjdk.org  Thu Jun  5 13:40:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 13:40:50 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
 <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
Message-ID: <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>

On Thu, 5 Jun 2025 08:43:04 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 37:
>> 
>>> 35: public class SOEDeeplyNestedBlocksTest {
>>> 36: 
>>> 37:     static final int NESTING_DEPTH = 500;
>> 
>> Same question here.
>
> With a NESTING_DEPTH of 1000 javac will run into a StackOverflowError, but it still completes and task.call() returns false. Using 500 javac can compile without error. Not sure what this test wants to prove. If it wants to show that javac can complete without throwing an SOE then it should keep depth 1000 and test that task.call() returns false.

yes this one was failing quietly, this test is stressing a code that was modified due to pattern matching. It is testing that javac can deal with deeply nested code without throwing SOE. 1000 depth was too much and the test was quietly failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128881821

From shade at openjdk.org  Thu Jun  5 14:47:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 14:47:53 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <smC66b1OtFEnSnoWRJz7SmNgdh-aweN-d9E98pWr_ws=.89cd6dd5-5ac1-44dc-9efa-c5114a9660c3@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25645#pullrequestreview-2900652359

From shade at openjdk.org  Thu Jun  5 14:57:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 14:57:52 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <qtVEVdzBqtyzn-FhvBPObmqZoV78pLBeesLy_onMI0o=.75d2b39a-5764-4b13-a161-7aa5709c6e92@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

I believe we are still not in RDP1? Do you want to get it in JDK 25? Put `Fix-Versions: 25` into the bug and integrate, if so.

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2944885496

From duke at openjdk.org  Thu Jun  5 15:33:07 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 15:33:07 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
 <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
 <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>
Message-ID: <psJrCA9Drc8jxurvsmYlMAp7fbzswjCpzuqAhVbmqjY=.e0c8f601-7a79-4a7f-934d-d283f3c7e55c@github.com>

On Thu, 5 Jun 2025 13:38:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> It is testing that javac can deal with deeply nested code without throwing SOE.

The current summary `Javac fails with StackOverflowError when compiling deeply nested synchronized blocks` is confusing and I don't know how it relates to your statement. Does it describe a bug or does it state the purpose of the test? Anyway, why not test with nesting levels of 500 and 1000, assert that task.call() returns true (500) and false (1000), but in the later case does not panic and terminate with a SOE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2129132057

From vromero at openjdk.org  Thu Jun  5 15:46:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 15:46:55 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <qtVEVdzBqtyzn-FhvBPObmqZoV78pLBeesLy_onMI0o=.75d2b39a-5764-4b13-a161-7aa5709c6e92@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <qtVEVdzBqtyzn-FhvBPObmqZoV78pLBeesLy_onMI0o=.75d2b39a-5764-4b13-a161-7aa5709c6e92@github.com>
Message-ID: <ELd5ZJQjxyktNWTvuvX9A1dlqoBw4ten8RXZcX9ghF4=.8434c8dc-bd45-424b-89ab-ed589378d855@github.com>

On Thu, 5 Jun 2025 14:55:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I believe we are still not in RDP1? Do you want to get it in JDK 25? Put `Fix-Versions: 25` into the bug and integrate, if so.

I prefer to wait until 26, this is not a high priority issue

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2945037398

From kvn at openjdk.org  Thu Jun  5 15:50:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 5 Jun 2025 15:50:52 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <zdd_y_bOXb3iSCYx5cfH62GrC_VX4HoVA5rmXeP4TiI=.a1e9a5fd-0618-41e1-a4d5-1386947f2ed5@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

Tests P1-P5 can be fixed during RDP1 and RDP2: https://openjdk.org/jeps/3#rdp-2

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2945058626

From nbenalla at openjdk.org  Thu Jun  5 16:03:58 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Jun 2025 16:03:58 GMT
Subject: Integrated: 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: <-TeQIT9Gmt8CLUcMmPfOQzcPTIGyMpqqVsuEloBx6x8=.55986278-6168-4eff-9784-d91ed7768650@github.com>

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

> Get JDK 26 underway.

This pull request has now been integrated.

Changeset: af87035b
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af87035b713f8bfe05a007a4d4670cefc6a6aaf2
Stats:     1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod

8355746: Start of release updates for JDK 26
8355748: Add SourceVersion.RELEASE_26
8355751: Add source 26 and target 26 to javac

Co-authored-by: Joe Darcy <darcy at openjdk.org>
Reviewed-by: iris, coleenp, darcy

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

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

From vromero at openjdk.org  Thu Jun  5 17:00:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 17:00:50 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <psJrCA9Drc8jxurvsmYlMAp7fbzswjCpzuqAhVbmqjY=.e0c8f601-7a79-4a7f-934d-d283f3c7e55c@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
 <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
 <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>
 <psJrCA9Drc8jxurvsmYlMAp7fbzswjCpzuqAhVbmqjY=.e0c8f601-7a79-4a7f-934d-d283f3c7e55c@github.com>
Message-ID: <imSAmt4PvkDKbw9KD6B9TEP4ysPjif1ezOS2Su6_yqQ=.e6e74503-9b04-41ff-9658-b07e21d3aad4@github.com>

On Thu, 5 Jun 2025 15:30:30 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> yes this one was failing quietly, this test is stressing a code that was modified due to pattern matching. It is testing that javac can deal with deeply nested code without throwing SOE. 1000 depth was too much and the test was quietly failing
>
>> It is testing that javac can deal with deeply nested code without throwing SOE.
> 
> The current summary `Javac fails with StackOverflowError when compiling deeply nested synchronized blocks` is confusing and I don't know how it relates to your statement. Does it describe a bug or does it state the purpose of the test? Anyway, why not test with nesting levels of 500 and 1000, assert that task.call() returns true (500) and false (1000), but in the later case does not panic and terminate with a SOE.

the original version of the test was included as part of the fix for [1] as you can see in the related PR [2] method com.sun.tools.javac.jvm.Gen::visitBlock was being visiting every block assuming that every one of them had pattern matching expressions in it. This implied a visitBlock with a higher number of local variables even for 90-98% of blocks that didn't have any pattern matching in them. So the test is checking that javac is not failing with SOE while generating code for a method with deeply nested blocks. Testing that javac will produce SOE after a given threshold is passed adds no information as there always be resource limit for any process. This is why I don't see the value of having a test that passes that threshold, which by the way could move over time and then we will need to go back and fix the test. While on the other hand having a test that will keep javac in check, as in being able to still compile without issues a nested enough code, seems more valuable to me.

[1] https://bugs.openjdk.org/browse/JDK-8322992
[2] https://github.com/openjdk/jdk/pull/18832

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2129342988

From acobbs at openjdk.org  Thu Jun  5 21:59:59 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 5 Jun 2025 21:59:59 GMT
Subject: Integrated: 8350212: Track source end positions of declarations that
 support @SuppressWarnings
In-Reply-To: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
References: <M8ihrVWYHnm0BmLyRhDz0aUl0yrLuxFoL003Z1Ad2iE=.febc3d92-f285-4dff-b955-ecf5c473ccf7@github.com>
Message-ID: <VsBobeEQOtujjFPbzxPgFeZ9-Y9lrn2mdqjQ_VjTTck=.cd3bb2b5-88da-4808-8874-7ea8a7ddfe62@github.com>

On Tue, 18 Feb 2025 02:39:37 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.

This pull request has now been integrated.

Changeset: c793de98
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c793de989facdb532021e1d5ddd01eb0e089b8e6
Stats:     336 lines in 11 files changed: 176 ins; 84 del; 76 mod

8350212: Track source end positions of declarations that support @SuppressWarnings

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: mcimadamore

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

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

From vromero at openjdk.org  Fri Jun  6 14:14:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 6 Jun 2025 14:14:56 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <y6J0-1CWYt8Q48BL5g8plhbKxTCPBSjvUt3Olrkhd_s=.4594fff1-7b4c-4850-95f9-55f7aff92ea7@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2949388176

From vromero at openjdk.org  Fri Jun  6 14:14:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 6 Jun 2025 14:14:57 GMT
Subject: Integrated: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <jvckILM3CMCuJfcEoSbR9ASnJ5w9YecYkKz-tF5DvrA=.b4cee1d2-b5b1-4fa7-b7b7-41dca24fe01b@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

This pull request has now been integrated.

Changeset: 8adb052b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8adb052b46f90e8a0605cfc5ddc667acb7c61952
Stats:     136 lines in 33 files changed: 88 ins; 1 del; 47 mod

8341778: Some javac tests ignore the result of JavacTask::call

Reviewed-by: shade

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

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

From duke at openjdk.org  Fri Jun  6 23:07:57 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 6 Jun 2025 23:07:57 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <8DGz3JE2S5_mnRHPZ20F4H1yF4XHHjjtowdR3_IlWo4=.9be3a569-7992-43ce-b2c5-d9dbdd55b54e@github.com>

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

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

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 565:

> 563:             this.archivePath = archivePath;
> 564:             // Common parameters for opening ZIP/JAR file systems in Javac.
> 565:             Map<String, ?> env = FSInfo.readOnlyJarFSEnv(multiReleaseValue);

Note?that this?will now?cause `.zip`?files to?be?treated the?same as?`.jar`?files when?`multiReleaseValue???null` (previously, this?was?ignored for?`.zip`?files)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2133046832

From stephan.herrmann at berlin.de  Sun Jun  8 21:53:26 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Sun, 8 Jun 2025 23:53:26 +0200
Subject: binary form of local class produces strange error
Message-ID: <03e116ea-d133-4067-b48d-a8d7e38ddf7c@berlin.de>

We (ecj) have a test case relating to 
https://bugs.java.com/bugdatabase/view_bug?bug_id=4094180 where historically we 
expect javac to accept the following classes in separate invocations (despite 
the obvious problem in X):

public class Y {
     public static void main(String[] args) {
          class Local {}
          System.out.println("SUCCESS");
     }
}

public class X {
     public static void main(String argv[]) {
          Object a = new Y$1Local();
     }
}

Since 24 I see javac complaining:

X.java:3: error: an enclosing instance that contains Local is required
                 Object a = new Y$1Local();
                            ^
1 error


This doesn't look right to me :)

best
Stephan

From stephan.herrmann at berlin.de  Sun Jun  8 22:22:19 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Mon, 9 Jun 2025 00:22:19 +0200
Subject: strange choice of method
Message-ID: <aa8b254f-91b8-4817-b2ef-8068c4129674@berlin.de>

In the following code javac raises exactly one error:

//--------------
public class X {
         void a() {}
         private static void a(String s) {}
         private void c() {}
         private static void c(String s) {}
         static class M1 extends X {
                 public void x() {
                         a(null);
                         c(null);
                 }
         }
         static class M2 {
                 public void x() {
                         a(null);
                         c(null);
                 }
         }
}
//----------------

The first call "a(null)" is rejected, because the no-arg instance method is 
selected, whereas the second such call is accepted, targeting the static method.

Also both calls "c(null)" are accepted.

Is there any intention behind this?

thanks,
Stephan

PS: These observations hold for version 5 through 25 ea. javac 1.4 actually 
accepts the program. Not sure if it helps understanding the why of it.

From jan.lahoda at oracle.com  Mon Jun  9 05:48:25 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 9 Jun 2025 07:48:25 +0200
Subject: strange choice of method
In-Reply-To: <aa8b254f-91b8-4817-b2ef-8068c4129674@berlin.de>
References: <aa8b254f-91b8-4817-b2ef-8068c4129674@berlin.de>
Message-ID: <d61e41ea-bd81-4b2c-adf1-968c7741881a@oracle.com>

Hello,


This is what I think happens:

- for M1, the `a(String)`, `c()` and `c(String)` are not members of the 
class, while `a()` is (as per JLS 8.2, private members are not inherited)

- for M1, when seeing `a(null)`, the determined type to search (JLS 
15.12.1) is M1, as there's a method called `a` in this class (note that 
arity does not play a role in this step). Hence `a()` is the only candidate.

- for M1, when seeing `c(null)`, there's no `c(...)` in `M1`, so the 
search goes to the enclosing/outer scope (i.e. the determined type to 
search is X), where it finds `c()` and `c(String)`, where the second one 
is resolved.

- for M2, neither `a(..)`, nor `c(...)` are in M2, so the search goes to 
the enclosing/outer scope in both cases, and the resolution finds 
`a(String)` and `c(String)` respectively, from the enclosing scope.


Do I miss something?


Jan


On 09. 06. 25 0:22, Stephan Herrmann wrote:
> In the following code javac raises exactly one error:
>
> //--------------
> public class X {
> ??????? void a() {}
> ??????? private static void a(String s) {}
> ??????? private void c() {}
> ??????? private static void c(String s) {}
> ??????? static class M1 extends X {
> ??????????????? public void x() {
> ??????????????????????? a(null);
> ??????????????????????? c(null);
> ??????????????? }
> ??????? }
> ??????? static class M2 {
> ??????????????? public void x() {
> ??????????????????????? a(null);
> ??????????????????????? c(null);
> ??????????????? }
> ??????? }
> }
> //----------------
>
> The first call "a(null)" is rejected, because the no-arg instance 
> method is selected, whereas the second such call is accepted, 
> targeting the static method.
>
> Also both calls "c(null)" are accepted.
>
> Is there any intention behind this?
>
> thanks,
> Stephan
>
> PS: These observations hold for version 5 through 25 ea. javac 1.4 
> actually accepts the program. Not sure if it helps understanding the 
> why of it.

From stephan.herrmann at berlin.de  Mon Jun  9 21:51:12 2025
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Mon, 9 Jun 2025 23:51:12 +0200
Subject: strange choice of method
In-Reply-To: <mailman.9542.1749448116.324.compiler-dev@openjdk.org>
References: <mailman.9542.1749448116.324.compiler-dev@openjdk.org>
Message-ID: <4d441dd7-ff24-44ee-9405-2f48399961fb@berlin.de>

Thanks, Jan, for clarifying.

I was confused by a discussion among Eclipse committers from 2008, who had 
observed some back-and-forth in the behavior of javac between 1.4, 1.5, claiming 
that 1.7ea went back to the 1.4 behavior (accept). Obviously, after 2008 nobody 
had rechecked their assessment.

Your explanation makes sense, and we will have to fix ecj in this regard.

Stephan

> This is what I think happens:
> 
> - for M1, the `a(String)`, `c()` and `c(String)` are not members of the
> class, while `a()` is (as per JLS 8.2, private members are not inherited)
> 
> - for M1, when seeing `a(null)`, the determined type to search (JLS
> 15.12.1) is M1, as there's a method called `a` in this class (note that
> arity does not play a role in this step). Hence `a()` is the only candidate.
> 
> - for M1, when seeing `c(null)`, there's no `c(...)` in `M1`, so the
> search goes to the enclosing/outer scope (i.e. the determined type to
> search is X), where it finds `c()` and `c(String)`, where the second one
> is resolved.
> 
> - for M2, neither `a(..)`, nor `c(...)` are in M2, so the search goes to
> the enclosing/outer scope in both cases, and the resolution finds
> `a(String)` and `c(String)` respectively, from the enclosing scope.
> 
> 
> Do I miss something?
> 
> 
> Jan
> 
> 
> On 09. 06. 25 0:22, Stephan Herrmann wrote:
>> In the following code javac raises exactly one error:
>>
>> //--------------
>> public class X {
>> ??????? void a() {}
>> ??????? private static void a(String s) {}
>> ??????? private void c() {}
>> ??????? private static void c(String s) {}
>> ??????? static class M1 extends X {
>> ??????????????? public void x() {
>> ??????????????????????? a(null);
>> ??????????????????????? c(null);
>> ??????????????? }
>> ??????? }
>> ??????? static class M2 {
>> ??????????????? public void x() {
>> ??????????????????????? a(null);
>> ??????????????????????? c(null);
>> ??????????????? }
>> ??????? }
>> }
>> //----------------
>>
>> The first call "a(null)" is rejected, because the no-arg instance
>> method is selected, whereas the second such call is accepted,
>> targeting the static method.
>>
>> Also both calls "c(null)" are accepted.
>>
>> Is there any intention behind this?
>>
>> thanks,
>> Stephan
>>
>> PS: These observations hold for version 5 through 25 ea. javac 1.4
>> actually accepts the program. Not sure if it helps understanding the
>> why of it.



From acobbs at openjdk.org  Mon Jun  9 23:01:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 9 Jun 2025 23:01:35 GMT
Subject: RFR: 8358604: Trees for `var` do not have end positions
Message-ID: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>

The compiler replaces `var` nodes with synthetic tree nodes representing the inferred type. Previously, these new synthetic nodes were not being assigned either starting or ending source code positions.

[JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) added starting positions, but not ending positions. This PR adds ending positions, and fixes some related bugs discovered in the research process:

* For a declaration like `final var x`, the fix for [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) was returning a starting position incorrectly pointing to `final` instead of `var`.
* A declaration like `final var x` was correctly starting at `final` for normal declarations, but incorrectly starting at `var` for a lambda parameter declarations.
* `JCVariableDecl.declaredUsingVar()` was incorrectly returning `false` for `var` variable declarations in record deconstruction patterns (thanks to @cushon for reporting this)

Background: When a `var`is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null. Previously there was a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there _were_ modifiers, which is wrong. Etc.

This patch attempts to clarify things and includes the following changes:

* Make a `var`'s starting source position properly recoverable from a `JCVariableDecl` even while `vartype` is null.
* Fix the three bugs mentioned above.
* Make `TreeMaker.at()` capable of configuring both the starting and ending position; do some minor cleanup/refactoring.
* Set ending positions for the synthetic tree nodes that replace `var`
* Pretty print `var` as `var` instead of `/*missing*/` (drive-by improvement)
* Add more regression test coverage

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

Commit messages:
 - Unbreak two regression tests (one jshell, one javadoc).
 - Refactor to fix more bugs and increase regression test coverage.
 - Fix declaredUsingVar() bug with record patterns like "R(var x)".
 - Merge branch 'master' into JDK-8358604 to fix conflict.
 - Fix bug where "var" end position was off by one.
 - Add a regression test for the glitch leftover by JDK-8329951.
 - Set an ending position for the synthetic tree node that replaces "var".
 - Make TreeMaker.at() also capable of handling ending positions.
 - Make "var" starting source positions recoverable.
 - Pretty print "var" as "var" instead of "/*missing*/".

Changes: https://git.openjdk.org/jdk/pull/25664/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358604
  Stats: 443 lines in 13 files changed: 149 ins; 153 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/25664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25664/head:pull/25664

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

From jlahoda at openjdk.org  Tue Jun 10 06:46:27 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 10 Jun 2025 06:46:27 GMT
Subject: RFR: 8358604: Trees for `var` do not have end positions
In-Reply-To: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
References: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
Message-ID: <X5vGamtdm3tVlv_hhTOBSMkH1aOpYC5fL0Ol3Ui9Brw=.4927fc7d-9449-4f54-96e0-3e4b7ed1738d@github.com>

On Thu, 5 Jun 2025 21:14:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler replaces `var` nodes with synthetic tree nodes representing the inferred type. Previously, these new synthetic nodes were not being assigned either starting or ending source code positions.
> 
> [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) added starting positions, but not ending positions. This PR adds ending positions, and fixes some related bugs discovered in the research process:
> 
> * For a declaration like `final var x`, the fix for [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) was returning a starting position incorrectly pointing to `final` instead of `var`.
> * A declaration like `final var x` was correctly starting at `final` for normal declarations, but incorrectly starting at `var` for a lambda parameter declarations.
> * `JCVariableDecl.declaredUsingVar()` was incorrectly returning `false` for `var` variable declarations in record deconstruction patterns (thanks to @cushon for reporting this)
> 
> Background: When a `var`is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null. Previously there was a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there _were_ modifiers, which is wrong. Etc.
> 
> This patch attempts to clarify things and includes the following changes:
> 
> * Make a `var`'s starting source position properly recoverable from a `JCVariableDecl` even while `vartype` is null.
> * Fix the three bugs mentioned above.
> * Make `TreeMaker.at()` capable of configuring both the starting and ending position; do some minor cleanup/refactoring.
> * Set ending positions for the synthetic tree nodes that replace `var`
> * Pretty print `var` as `var` instead of `/*missing*/` (drive-by improvement)
> * Add more regression test coverage

I guess I would like to understand the rationale for adding the end position for the type. Generally, when javac synthesizes trees, the new trees don't have an end position (like for the synthetic constructor, and several other cases). So, I think there's a question why this specific synthetic tree should have an end position, while the other shouldn't.

Also, currently the missing end position is used as a "marker" for synthetic trees. Not particularly nice, but given the synthetic trees are/were (I think) considered a workaround. When the tree has an end position, how will the Trees API clients find out this tree is synthetic?

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

PR Comment: https://git.openjdk.org/jdk/pull/25664#issuecomment-2957865902

From duke at openjdk.org  Tue Jun 10 13:32:34 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 10 Jun 2025 13:32:34 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <8DGz3JE2S5_mnRHPZ20F4H1yF4XHHjjtowdR3_IlWo4=.9be3a569-7992-43ce-b2c5-d9dbdd55b54e@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <8DGz3JE2S5_mnRHPZ20F4H1yF4XHHjjtowdR3_IlWo4=.9be3a569-7992-43ce-b2c5-d9dbdd55b54e@github.com>
Message-ID: <6mbVbWZf7mqmY1U5hPy-9DjzYn0-eNKfToQkwkzka9A=.5743eb95-287a-43b8-8b2d-9285628aa4d9@github.com>

On Fri, 6 Jun 2025 23:03:31 GMT, ExE Boss <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 565:
> 
>> 563:             this.archivePath = archivePath;
>> 564:             // Common parameters for opening ZIP/JAR file systems in Javac.
>> 565:             Map<String, ?> env = FSInfo.readOnlyJarFSEnv(multiReleaseValue);
> 
> Note?that this?will now?cause `.zip`?files to?be?treated the?same as?`.jar`?files when?`multiReleaseValue???null` (previously, this?was?ignored for?`.zip`?files)

That's an excellent point. I will be sure to ask people if that looks acceptable and revert to the original behaviour otherwise. Thank you for spotting it and saying something.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2137914138

From duke at openjdk.org  Tue Jun 10 13:36:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 10 Jun 2025 13:36:32 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
Message-ID: <3dqpBxBqg3tZyqrL5dXJIgcp7IpFVdC_OTdvZImNRCE=.10ef42b5-1c05-4104-b8a2-7edb4579fb49@github.com>

On Thu, 5 Jun 2025 00:01:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javac/jvm/ClassRefDupInConstantPoolTest.java line 46:
>> 
>>> 44: 
>>> 45: public class ClassRefDupInConstantPoolTest {
>>> 46: 
>> 
>> This test was failing and needed to be compiling its own class file rather than reading the one in the test library.
>
> The class file is from this test file instead of the test libraries, and this pattern of shipping additional classes in the same compilation unit for class file handling in tests is common in jdk/classfile and other packages. Could the `clean` directive be the culprit?

It's possible. I remember having to change this when I prototyped the new code a while ago, but I'm not sure I remember exactly why. I can try reverting it if the original style is acceptable (personally I prefer to compile on-the-fly since it can test the compiler with different options - which is probably why I changed it originally).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2137921970

From liach at openjdk.org  Tue Jun 10 13:52:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Jun 2025 13:52:27 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <3dqpBxBqg3tZyqrL5dXJIgcp7IpFVdC_OTdvZImNRCE=.10ef42b5-1c05-4104-b8a2-7edb4579fb49@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
 <3dqpBxBqg3tZyqrL5dXJIgcp7IpFVdC_OTdvZImNRCE=.10ef42b5-1c05-4104-b8a2-7edb4579fb49@github.com>
Message-ID: <vEWUCpbY8ZWFy3FN-NLg9tHfBh9zX1ABvY2ve3ekpGs=.d7dc8936-a519-43d0-963f-b3c271815c1f@github.com>

On Tue, 10 Jun 2025 13:33:28 GMT, David Beaumont <duke at openjdk.org> wrote:

>> The class file is from this test file instead of the test libraries, and this pattern of shipping additional classes in the same compilation unit for class file handling in tests is common in jdk/classfile and other packages. Could the `clean` directive be the culprit?
>
> It's possible. I remember having to change this when I prototyped the new code a while ago, but I'm not sure I remember exactly why. I can try reverting it if the original style is acceptable (personally I prefer to compile on-the-fly since it can test the compiler with different options - which is probably why I changed it originally).

Also for compile on-the-fly, I usually use `InMemoryJavaCompiler` and `ByteCodeLoader` available with `/test/lib` library. `InMemoryJavaCompiler` conveniently returns a list of all class files, and its one-class-file version throws an exception if a compilation unit generates more than one class, which is not usually checked by manual invocations to javac task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2137961069

From acobbs at openjdk.org  Tue Jun 10 14:34:28 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Jun 2025 14:34:28 GMT
Subject: RFR: 8358604: Trees for `var` do not have end positions
In-Reply-To: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
References: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
Message-ID: <1beQdGolEMfxJzVRuPN3mud2KTdGalOS0vD1PVG2SBQ=.9e8e52e3-c974-4df0-bb6d-fcafb50c4928@github.com>

On Thu, 5 Jun 2025 21:14:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler replaces `var` nodes with synthetic tree nodes representing the inferred type. Previously, these new synthetic nodes were not being assigned either starting or ending source code positions.
> 
> [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) added starting positions, but not ending positions. This PR adds ending positions, and fixes some related bugs discovered in the research process:
> 
> * For a declaration like `final var x`, the fix for [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) was returning a starting position incorrectly pointing to `final` instead of `var`.
> * A declaration like `final var x` was correctly starting at `final` for normal declarations, but incorrectly starting at `var` for a lambda parameter declarations.
> * `JCVariableDecl.declaredUsingVar()` was incorrectly returning `false` for `var` variable declarations in record deconstruction patterns (thanks to @cushon for reporting this)
> 
> Background: When a `var`is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null. Previously there was a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there _were_ modifiers, which is wrong. Etc.
> 
> This patch attempts to clarify things and includes the following changes:
> 
> * Make a `var`'s starting source position properly recoverable from a `JCVariableDecl` even while `vartype` is null.
> * Fix the three bugs mentioned above.
> * Make `TreeMaker.at()` capable of configuring both the starting and ending position; do some minor cleanup/refactoring.
> * Set ending positions for the synthetic tree nodes that replace `var`
> * Pretty print `var` as `var` instead of `/*missing*/` (drive-by improvement)
> * Add more regression test coverage

> I guess I would like to understand the rationale for adding the end position for the type....there's a question why this specific synthetic tree should have an end position, while the other shouldn't.

@cushon is better positioned (no pun intended) to answer that question than me. In the issue, this rationale is given:

> The end positions can be retrieved using `com.sun.source.util.SourcePositions#getEndPosition` (e.g. by javac plugins), and end positions are available for explicitly typed local variables, so it would be helpful if these synthetic types also recorded an end position for consistency.

Re:

> Also, currently the missing end position is used as a "marker" for synthetic trees. Not particularly nice, but given the synthetic trees are/were (I think) considered a workaround.

I didn't realize that lack of end position was being overloaded in that way. But overloaded by whom? Is this an "official" thing per the API, or just a workaround currently being used in practice by some 3rd party tools?

>  When the tree has an end position, how will the Trees API clients find out this tree is synthetic?

I don't know how frozen the Trees API is, but it seems like the most straightforward answer to that would be for us to expose the type of declaration (explicit, implicit, or `var`) directly via this API via some new property. Is that an option?

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

PR Comment: https://git.openjdk.org/jdk/pull/25664#issuecomment-2959490988

From cushon at openjdk.org  Tue Jun 10 15:20:29 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 10 Jun 2025 15:20:29 GMT
Subject: RFR: 8358604: Trees for `var` do not have end positions
In-Reply-To: <1beQdGolEMfxJzVRuPN3mud2KTdGalOS0vD1PVG2SBQ=.9e8e52e3-c974-4df0-bb6d-fcafb50c4928@github.com>
References: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
 <1beQdGolEMfxJzVRuPN3mud2KTdGalOS0vD1PVG2SBQ=.9e8e52e3-c974-4df0-bb6d-fcafb50c4928@github.com>
Message-ID: <uyIAt_2xn8241DWbbXJMmmCRH2CELMClOj3wfzjAb5M=.d410449b-cc0b-47e2-922b-2d31d237673f@github.com>

On Tue, 10 Jun 2025 14:32:06 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > I guess I would like to understand the rationale for adding the end position for the type....there's a question why this specific synthetic tree should have an end position, while the other shouldn't.
> 
> @cushon is better positioned (no pun intended) to answer that question than me. In the issue, this rationale is given:

The position information is useful for Tree API clients that want to do refactorings (e.g. to replace the type of a particular variable, even if it's `var`), or emit diagnostics. I've seen the specific example of `var` come up a number of times, it seems to be more common that other synthetic trees, perhaps because historically none of the nodes contained in a `VariableTree` were ever synthetic and now the type is but only for some trees.

As a general approach I think it's helpful if javac provides a post-flow AST to clients with minimal rewriting/lowering, so it's possible to map back to the original source code, while still exposing information from flow to clients (e.g. the inferred types of local variables).

I think this is closely related to discussion in https://bugs.openjdk.org/browse/JDK-8024098, and looking at that bug again I see there's an issue specifically about `var` that I'd forgotten about: https://bugs.openjdk.org/browse/JDK-8268850

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

PR Comment: https://git.openjdk.org/jdk/pull/25664#issuecomment-2959670396

From maurizio.cimadamore at oracle.com  Tue Jun 10 16:03:04 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 10 Jun 2025 17:03:04 +0100
Subject: javac confused by generics on class?
In-Reply-To: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
References: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
Message-ID: <139deef9-88bc-44c8-8584-d4bf6ae28c40@oracle.com>

(Adding compiler-dev and dropping core-libs-dev)

I think the compiler is correct here.

In the first example, you call List::stream() on a raw List (because "c" 
has the raw type Child, so "c.getValues()" returns a raw list). This 
gives you a raw stream (Stream), which means the Stream::collect is also 
erased, meaning it just returns Object. But since the method return type 
is String, you get an error as Object cannot be returned if a String 
type is expected.

In the second example you also first stash the result of "c.getValues()" 
(again, a raw list) into a variable of type List<String>. This is an 
unchecked operation -- as you are unsafely adding generic type 
parameters to raw type. The compiler lets you do it, with a warning. 
 From that point on, it's as if there's no raw types. You have a 
List<String>, so calling List::stream gives you a Stream<String>. Which 
means Stream::collect no longer has an erased type, and a String is 
returned from the collect call, as expected. So you get a warning for 
the unchecked operation above, but then no errors.

I hope this helps understanding what is going on.

Maurizio

On 10/06/2025 16:50, Jean-No?l Rouvignac wrote:
> Hello,
>
> When doing refactorings to take advantage of newer Java features, I 
> hit a new?and weird edge case. I trimmed down the code several times, 
> and ended up with the following tiny reproducer,?and I don't 
> understand what javac is complaining about even with javac 24:
>
> (Note: unlike the original code,?this reproducer is very contrived, so 
> there's no need to make comments on how bad it is: I fully agree)
>
> ```java
> 1 import java.util.ArrayList;
> import java.util.List;
> import java.util.stream.Collectors;
>
> public class Main {
> ? ? private static final class Child<T> {
> ? ? ? ? public List<String> getValues() {
> ? ? ? ? ? ? return new ArrayList<>();
> ? ? ? ? }
> ? ? }
>
> ? ? @SuppressWarnings("unchecked")
> ? ? private static String getString1(Child c) {
> ? ? ? ? // Compilation error:
> ? ? ? ? // Main.java:16: error: incompatible types: Object cannot be 
> converted to String
> ? ? ? ? return c.getValues().stream().collect(Collectors.joining());
> ? ? }
>
> ? ? private static String getString2(Child c) {
> ? ? ? ? // Compilation error:
> ? ? ? ? // Main.java:27: warning: [unchecked] unchecked conversion
> ? ? ? ? // ? ? ? ?List<String> values = c.getValues();
> ? ? ? ? // ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
> ? ? ? ? // ?required: List<String>
> ? ? ? ? // ?found: ? ?List
> ? ? ? ? //1 warning
> ? ? ? ? List<String> values = c.getValues();
> ? ? ? ? return values.stream().collect(Collectors.joining());
> ? ? }
> }
> ```
>
> It turns out IntelliJ is a bit more eloquent than javac, and when 
> hovering over the warning on `c.getValues()` at the line with 
> `List<String> values = c.getValues();`, it reports the following:
>
> >? ? Unchecked assignment: 'java.util.List' to 
> 'java.util.List<java.lang.String>'. Reason: 'c' has raw type, so 
> result of getValues is erased
>
> Is it possible that javac is doing early type erasure when analysing 
> this code, erasing a bit too much? Even if the code uses `Child` 
> without type argument, I would expect the return type of `getValues()` 
> to be well defined as `List<String>`?
>
> What do you think?
> I am sure?there?is some rational explanation that I missed for this 
> behaviour. I could not find a JBS issue showing the same case as here.
>
> Thank you,
> Jean-No?l?Rouvignac
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.? If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250610/11903c64/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Tue Jun 10 16:03:56 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 10 Jun 2025 17:03:56 +0100
Subject: javac confused by generics on class?
In-Reply-To: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
References: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
Message-ID: <b84e228a-793c-46e8-bd23-445ca1cb6766@oracle.com>

(Adding compiler-dev and dropping core-libs-dev)

I think the compiler is correct here.

In the first example, you call List::stream() on a raw List (because "c" 
has the raw type Child, so "c.getValues()" returns a raw list). This 
gives you a raw stream (Stream), which means the Stream::collect is also 
erased, meaning it just returns Object. But since the method return type 
is String, you get an error as Object cannot be returned if a String 
type is expected.

In the second example you also first stash the result of "c.getValues()" 
(again, a raw list) into a variable of type List<String>. This is an 
unchecked operation -- as you are unsafely adding generic type 
parameters to raw type. The compiler lets you do it, with a warning. 
 From that point on, it's as if there's no raw types. You have a 
List<String>, so calling List::stream gives you a Stream<String>. Which 
means Stream::collect no longer has an erased type, and a String is 
returned from the collect call, as expected. So you get a warning for 
the unchecked operation above, but then no errors.

I hope this helps understanding what is going on.

Maurizio

On 10/06/2025 16:50, Jean-No?l Rouvignac wrote:
> Hello,
>
> When doing refactorings to take advantage of newer Java features, I 
> hit a new?and weird edge case. I trimmed down the code several times, 
> and ended up with the following tiny reproducer,?and I don't 
> understand what javac is complaining about even with javac 24:
>
> (Note: unlike the original code,?this reproducer is very contrived, so 
> there's no need to make comments on how bad it is: I fully agree)
>
> ```java
> 1 import java.util.ArrayList;
> import java.util.List;
> import java.util.stream.Collectors;
>
> public class Main {
> ? ? private static final class Child<T> {
> ? ? ? ? public List<String> getValues() {
> ? ? ? ? ? ? return new ArrayList<>();
> ? ? ? ? }
> ? ? }
>
> ? ? @SuppressWarnings("unchecked")
> ? ? private static String getString1(Child c) {
> ? ? ? ? // Compilation error:
> ? ? ? ? // Main.java:16: error: incompatible types: Object cannot be 
> converted to String
> ? ? ? ? return c.getValues().stream().collect(Collectors.joining());
> ? ? }
>
> ? ? private static String getString2(Child c) {
> ? ? ? ? // Compilation error:
> ? ? ? ? // Main.java:27: warning: [unchecked] unchecked conversion
> ? ? ? ? // ? ? ? ?List<String> values = c.getValues();
> ? ? ? ? // ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
> ? ? ? ? // ?required: List<String>
> ? ? ? ? // ?found: ? ?List
> ? ? ? ? //1 warning
> ? ? ? ? List<String> values = c.getValues();
> ? ? ? ? return values.stream().collect(Collectors.joining());
> ? ? }
> }
> ```
>
> It turns out IntelliJ is a bit more eloquent than javac, and when 
> hovering over the warning on `c.getValues()` at the line with 
> `List<String> values = c.getValues();`, it reports the following:
>
> >? ? Unchecked assignment: 'java.util.List' to 
> 'java.util.List<java.lang.String>'. Reason: 'c' has raw type, so 
> result of getValues is erased
>
> Is it possible that javac is doing early type erasure when analysing 
> this code, erasing a bit too much? Even if the code uses `Child` 
> without type argument, I would expect the return type of `getValues()` 
> to be well defined as `List<String>`?
>
> What do you think?
> I am sure?there?is some rational explanation that I missed for this 
> behaviour. I could not find a JBS issue showing the same case as here.
>
> Thank you,
> Jean-No?l?Rouvignac
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.? If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250610/28fc93c0/attachment.htm>

From archie.cobbs at gmail.com  Tue Jun 10 16:07:30 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 10 Jun 2025 11:07:30 -0500
Subject: javac confused by generics on class?
In-Reply-To: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
References: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
Message-ID: <CANSoFxv8TKMQ4S-CMFpdHrq0=q5LcDPrrqUxj2EP6-6vBW8M0Q@mail.gmail.com>

Following up on what Maurizio said. There is an important difference
between Foo and Foo<?>.  The use of raw type like Foo "rawifies" all the
methods in class Foo.

Here's a simpler reproducer:

import java.net.http.HttpResponse;
import java.util.Optional;
import javax.net.ssl.SSLSession;

public class Main2 {
    void m1(HttpResponse r) {
        Optional<SSLSession> s = r.sslSession();  // unchecked warning here
    }
    void m2(HttpResponse<?> r) {
        Optional<SSLSession> s = r.sslSession();  // no warning here
    }
}

See also this stackoverflow answer
<https://stackoverflow.com/a/11007894/263801>.

-Archie

On Tue, Jun 10, 2025 at 10:51?AM Jean-No?l Rouvignac <
jean-noel.rouvignac at pingidentity.com> wrote:

> Hello,
>
> When doing refactorings to take advantage of newer Java features, I hit a
> new and weird edge case. I trimmed down the code several times, and ended
> up with the following tiny reproducer, and I don't understand what javac is
> complaining about even with javac 24:
>
> (Note: unlike the original code, this reproducer is very contrived, so
> there's no need to make comments on how bad it is: I fully agree)
>
> ```java
> 1 import java.util.ArrayList;
> import java.util.List;
> import java.util.stream.Collectors;
>
> public class Main {
>     private static final class Child<T> {
>         public List<String> getValues() {
>             return new ArrayList<>();
>         }
>     }
>
>     @SuppressWarnings("unchecked")
>     private static String getString1(Child c) {
>         // Compilation error:
>         // Main.java:16: error: incompatible types: Object cannot be
> converted to String
>         return c.getValues().stream().collect(Collectors.joining());
>     }
>
>     private static String getString2(Child c) {
>         // Compilation error:
>         // Main.java:27: warning: [unchecked] unchecked conversion
>         //        List<String> values = c.getValues();
>         //                                         ^
>         //  required: List<String>
>         //  found:    List
>         //1 warning
>         List<String> values = c.getValues();
>         return values.stream().collect(Collectors.joining());
>     }
> }
> ```
>
> It turns out IntelliJ is a bit more eloquent than javac, and when hovering
> over the warning on `c.getValues()` at the line with `List<String> values =
> c.getValues();`, it reports the following:
>
> >    Unchecked assignment: 'java.util.List' to
> 'java.util.List<java.lang.String>'. Reason: 'c' has raw type, so result of
> getValues is erased
>
> Is it possible that javac is doing early type erasure when analysing this
> code, erasing a bit too much? Even if the code uses `Child` without type
> argument, I would expect the return type of `getValues()` to be well
> defined as `List<String>`?
>
> What do you think?
> I am sure there is some rational explanation that I missed for this
> behaviour. I could not find a JBS issue showing the same case as here.
>
> Thank you,
> Jean-No?l Rouvignac
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*



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

From jean-noel.rouvignac at pingidentity.com  Tue Jun 10 16:25:13 2025
From: jean-noel.rouvignac at pingidentity.com (=?UTF-8?Q?Jean=2DNo=C3=ABl_Rouvignac?=)
Date: Tue, 10 Jun 2025 18:25:13 +0200
Subject: javac confused by generics on class?
In-Reply-To: <CANSoFxv8TKMQ4S-CMFpdHrq0=q5LcDPrrqUxj2EP6-6vBW8M0Q@mail.gmail.com>
References: <CABw-sUJXEOm2AMkKT2Dp3sPDS=up3jgzRG4Rcd6rZ+wZB69JiQ@mail.gmail.com>
 <CANSoFxv8TKMQ4S-CMFpdHrq0=q5LcDPrrqUxj2EP6-6vBW8M0Q@mail.gmail.com>
Message-ID: <CABw-sUKWFBWttC+suFiNCw5MLhv_gNUbRJQk+5orb5ovBzYZDA@mail.gmail.com>

OK, that's another edge case then.

> The use of raw type like Foo "rawifies" all the methods in class Foo.

I can't help but think this is a weird default but I am sure there are
excellent reasons why this solution was chosen, so I am not going to argue
about it.
At least, this is a good nudge to make people write the right code since
it's easy to work around :)

Thank you!


On Tue, Jun 10, 2025 at 6:07?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Following up on what Maurizio said. There is an important difference
> between Foo and Foo<?>.  The use of raw type like Foo "rawifies" all the
> methods in class Foo.
>
> Here's a simpler reproducer:
>
> import java.net.http.HttpResponse;
> import java.util.Optional;
> import javax.net.ssl.SSLSession;
>
> public class Main2 {
>     void m1(HttpResponse r) {
>         Optional<SSLSession> s = r.sslSession();  // unchecked warning here
>     }
>     void m2(HttpResponse<?> r) {
>         Optional<SSLSession> s = r.sslSession();  // no warning here
>     }
> }
>
> See also this stackoverflow answer
> <https://stackoverflow.com/a/11007894/263801>.
>
> -Archie
>
> On Tue, Jun 10, 2025 at 10:51?AM Jean-No?l Rouvignac <
> jean-noel.rouvignac at pingidentity.com> wrote:
>
>> Hello,
>>
>> When doing refactorings to take advantage of newer Java features, I hit a
>> new and weird edge case. I trimmed down the code several times, and ended
>> up with the following tiny reproducer, and I don't understand what javac is
>> complaining about even with javac 24:
>>
>> (Note: unlike the original code, this reproducer is very contrived, so
>> there's no need to make comments on how bad it is: I fully agree)
>>
>> ```java
>> 1 import java.util.ArrayList;
>> import java.util.List;
>> import java.util.stream.Collectors;
>>
>> public class Main {
>>     private static final class Child<T> {
>>         public List<String> getValues() {
>>             return new ArrayList<>();
>>         }
>>     }
>>
>>     @SuppressWarnings("unchecked")
>>     private static String getString1(Child c) {
>>         // Compilation error:
>>         // Main.java:16: error: incompatible types: Object cannot be
>> converted to String
>>         return c.getValues().stream().collect(Collectors.joining());
>>     }
>>
>>     private static String getString2(Child c) {
>>         // Compilation error:
>>         // Main.java:27: warning: [unchecked] unchecked conversion
>>         //        List<String> values = c.getValues();
>>         //                                         ^
>>         //  required: List<String>
>>         //  found:    List
>>         //1 warning
>>         List<String> values = c.getValues();
>>         return values.stream().collect(Collectors.joining());
>>     }
>> }
>> ```
>>
>> It turns out IntelliJ is a bit more eloquent than javac, and when
>> hovering over the warning on `c.getValues()` at the line with `List<String>
>> values = c.getValues();`, it reports the following:
>>
>> >    Unchecked assignment: 'java.util.List' to
>> 'java.util.List<java.lang.String>'. Reason: 'c' has raw type, so result of
>> getValues is erased
>>
>> Is it possible that javac is doing early type erasure when analysing this
>> code, erasing a bit too much? Even if the code uses `Child` without type
>> argument, I would expect the return type of `getValues()` to be well
>> defined as `List<String>`?
>>
>> What do you think?
>> I am sure there is some rational explanation that I missed for this
>> behaviour. I could not find a JBS issue showing the same case as here.
>>
>> Thank you,
>> Jean-No?l Rouvignac
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
>
>
> --
> Archie L. Cobbs
>


-- 
<https://www.pingidentity.com/> <https://www.pingidentity.com/>[image: Ping
Identity] <https://www.pingidentity.com/>
Jean-Noel Rouvignac
Senior Principal Software Engineer
jean-noel.rouvignac at pingidentity.com

<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/gartner-magic-quadrant-access-management.html?utm_medium=email>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/youniverse.html>
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[image:
LinkedIn logo] <https://www.linkedin.com/company/21870>[image: Twitter logo]
<https://twitter.com/pingidentity>[image: YouTube logo]
<https://www.youtube.com/user/PingIdentityTV>[image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
To view our privacy policy, click here
<https://www.pingidentity.com/en/legal/privacy.html>
To stop receiving these emails, click here
<https://4.pingidentity.com/PreferenceCenter.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.? If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250610/04e20be4/attachment-0001.htm>

From jlahoda at openjdk.org  Tue Jun 10 17:47:29 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 10 Jun 2025 17:47:29 GMT
Subject: RFR: 8358604: Trees for `var` do not have end positions
In-Reply-To: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
References: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
Message-ID: <v0fO86e2pCSEn5QkVfCdaAgxqWQ5uxZTHX17DE2tz_s=.953173f4-2dd9-48a6-9df6-e4a5aad8f0e9@github.com>

On Thu, 5 Jun 2025 21:14:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler replaces `var` nodes with synthetic tree nodes representing the inferred type. Previously, these new synthetic nodes were not being assigned either starting or ending source code positions.
> 
> [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) added starting positions, but not ending positions. This PR adds ending positions, and fixes some related bugs discovered in the research process:
> 
> * For a declaration like `final var x`, the fix for [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) was returning a starting position incorrectly pointing to `final` instead of `var`.
> * A declaration like `final var x` was correctly starting at `final` for normal declarations, but incorrectly starting at `var` for a lambda parameter declarations.
> * `JCVariableDecl.declaredUsingVar()` was incorrectly returning `false` for `var` variable declarations in record deconstruction patterns (thanks to @cushon for reporting this)
> 
> Background: When a `var`is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null. Previously there was a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there _were_ modifiers, which is wrong. Etc.
> 
> This patch attempts to clarify things and includes the following changes:
> 
> * Make a `var`'s starting source position properly recoverable from a `JCVariableDecl` even while `vartype` is null.
> * Fix the three bugs mentioned above.
> * Make `TreeMaker.at()` capable of configuring both the starting and ending position; do some minor cleanup/refactoring.
> * Set ending positions for the synthetic tree nodes that replace `var`
> * Pretty print `var` as `var` instead of `/*missing*/` (drive-by improvement)
> * Add more regression test coverage

Yes, that is related to JDK-8024098, I've fixed a few of the modelling issues in the past, but many of them are quite difficult.

While I don't doubt the end position is sometimes useful,  the ability to detect the tree is synthetic is also sometimes useful (and it may be that one client would desire to know both these properties depending on the context - like imagine you would want to add something that detects `var` and allows to replace it with the inferred type - you need to be able to detect the variable's type is inferred. Or, imagine a rename refactoring for a class - the tool surely does not want to re-write an inferred type.)

Overall, I think just putting an end position to one of the synthetic trees we create is not very helpful, and is going to cause trouble. The options I see are roughly:
1. (the usual:) keep things as they are. The clients that need an end position can check for `-1` end pos, and compute the real end pos from the original text. Not very helpful, but not breaking anything either.
2. avoid exposing the synthetic tree through the API (i.e. solving JDK8268850), see below. It is actually probably not that difficult, although the clients will need to adjust.
3. accepting that we generate some synthetic trees, exposing a method that allows to detect them, and add sensible end positions to other synthetic trees. This is a bit tricky for some cases, like `@SuppressWarnings("...")`, which generates a highly-problematic synthetic assignment.

For 2. - the question is, what is the right model that closely models the original code. One possibly truthful model would be:
- for `var v`, the `VariableTree.getType()` would return an `IdentifierTree` holding `var` with both the start and end positions
- for `v` in `(v) -> {}`, `VariableTree.getType()` would return `null`
- possibly, there would be a method on `VariableTree`, which would permit the check if the type is inferred or not. (So that the clients don't need to second-guess what `var` means.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25664#issuecomment-2960127102

From acobbs at openjdk.org  Tue Jun 10 18:59:32 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Jun 2025 18:59:32 GMT
Subject: RFR: 8354447: Missing test for retroactive
 @SuppressWarnings("dangling-doc-comments") behavior
In-Reply-To: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
References: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
Message-ID: <inOVA3MYVIxi3lTvNsSMtDljnHONTn55MWGnlM5gTcw=.94d7c989-8ba0-4dd7-a984-db24fb9c2c04@github.com>

On Fri, 11 Apr 2025 19:55:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a regression test for the "retroactive" behavior of `@SuppressWarnings("dangling-doc-comments")`, that is,  the warning suppression applies to comments preceding the declaration that the annotation annotates, even though those comments are not within the lexical scope of that declaration. Previously there was no test for this behavior.

Now that JDK 25 has been split off, are there any reviewers available to review this simple change? Thanks in advance.

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

PR Comment: https://git.openjdk.org/jdk/pull/24600#issuecomment-2959724983

From acobbs at openjdk.org  Tue Jun 10 19:00:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Jun 2025 19:00:33 GMT
Subject: RFR: 8358604: Trees for `var` do not have end positions
In-Reply-To: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
References: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
Message-ID: <Hq3qFg4UhQ8-fhT2Vy1qECWK4r4RNXGIZasntXDPDts=.ec38d7b5-7f79-4130-9ae8-0508d1611985@github.com>

On Thu, 5 Jun 2025 21:14:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler replaces `var` nodes with synthetic tree nodes representing the inferred type. Previously, these new synthetic nodes were not being assigned either starting or ending source code positions.
> 
> [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) added starting positions, but not ending positions. This PR adds ending positions, and fixes some related bugs discovered in the research process:
> 
> * For a declaration like `final var x`, the fix for [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) was returning a starting position incorrectly pointing to `final` instead of `var`.
> * A declaration like `final var x` was correctly starting at `final` for normal declarations, but incorrectly starting at `var` for a lambda parameter declarations.
> * `JCVariableDecl.declaredUsingVar()` was incorrectly returning `false` for `var` variable declarations in record deconstruction patterns (thanks to @cushon for reporting this)
> 
> Background: When a `var`is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null. Previously there was a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there _were_ modifiers, which is wrong. Etc.
> 
> This patch attempts to clarify things and includes the following changes:
> 
> * Make a `var`'s starting source position properly recoverable from a `JCVariableDecl` even while `vartype` is null.
> * Fix the three bugs mentioned above.
> * Make `TreeMaker.at()` capable of configuring both the starting and ending position; do some minor cleanup/refactoring.
> * Set ending positions for the synthetic tree nodes that replace `var`
> * Pretty print `var` as `var` instead of `/*missing*/` (drive-by improvement)
> * Add more regression test coverage

> 2. avoid exposing the synthetic tree through the API (i.e. solving JDK8268850), see below. It is actually probably not that difficult, although the clients will need to adjust.
> 
> ... the question is, what is the right model that closely models the original code. One possibly truthful model would be:
> 
> * for `var v`, the `VariableTree.getType()` would return an `IdentifierTree` holding `var` with both the start and end positions
> * for `v` in `(v) -> {}`, `VariableTree.getType()` would return `null`

I think this? option makes the most sense.

> * possibly, there would be a method on `VariableTree`, which would permit the check if the type is inferred or not. (So that the clients don't need to second-guess what `var` means.)

Just to clarify, it would only be second guessing for `--release` ? 9, correct? Because `as of release 10, 'var' is a restricted type name and cannot be used for type declarations`.

I think it would be nice to add such a method. But perhaps that can come later as a separate enhancement.

@lahodaj what do you think about this plan? I'm happy to prototype it if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25664#issuecomment-2960301927

From jlahoda at openjdk.org  Wed Jun 11 06:04:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 11 Jun 2025 06:04:28 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <tZwERwFn1_QXh5aiHK8Tjw1VSRaYPVVRiLYuNjZK8AA=.424dd971-628d-4c4c-92c4-c367472f942b@github.com>

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

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

Overall seems like a reasonable direction. Please see some comments inline.

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

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

From jlahoda at openjdk.org  Wed Jun 11 06:04:29 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 11 Jun 2025 06:04:29 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
Message-ID: <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>

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

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java line 183:
> 
>> 181:      *                       {@code null} to ignore release versioning).
>> 182:      */
>> 183:     public static Map<String, ?> readOnlyJarFSEnv(String releaseVersion) {
> 
> I named this after the getJarFSProvider() method above, since they are used in close proximity, but would be happy to consider other names.

I am a bit uneasy about having the method static, as this class's API is normally instance methods. I think that an instance of FSInfo (`fsInfo`) is available in both `JavacFileManager` and `Locations`, so it would be better to simply have an instance method. (The static field is OK, that's not an API.)

> src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 261:
> 
>> 259:                         // If for any reason this was not opened from a ZIP file,
>> 260:                         // then the resulting file system would not be read-only.
>> 261:                         assert fs.isReadOnly();
> 
> Not sure if an assert is the right thing here or if this should be an always-on runtime check (it can be provoked by having a non-ZIP symbol file, but it's not sanctioned in any way).

We typically don't use `assert` in javac anymore, as it can be disabled. Either the condition is important, then we typically use `com.sun.tools.javac.util.Assert.check`, or we don't do the check. I think using `Assert` here would be appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2139255923
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2139263454

From jlahoda at openjdk.org  Wed Jun 11 06:04:30 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 11 Jun 2025 06:04:30 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <6mbVbWZf7mqmY1U5hPy-9DjzYn0-eNKfToQkwkzka9A=.5743eb95-287a-43b8-8b2d-9285628aa4d9@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <8DGz3JE2S5_mnRHPZ20F4H1yF4XHHjjtowdR3_IlWo4=.9be3a569-7992-43ce-b2c5-d9dbdd55b54e@github.com>
 <6mbVbWZf7mqmY1U5hPy-9DjzYn0-eNKfToQkwkzka9A=.5743eb95-287a-43b8-8b2d-9285628aa4d9@github.com>
Message-ID: <npT3xWdShBHMZg7i1-Tuz3F571w69cYg5YY6bKIouL8=.fd1ee85d-0dc2-4ac0-9954-becb984b3f9e@github.com>

On Tue, 10 Jun 2025 13:29:50 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 565:
>> 
>>> 563:             this.archivePath = archivePath;
>>> 564:             // Common parameters for opening ZIP/JAR file systems in Javac.
>>> 565:             Map<String, ?> env = FSInfo.readOnlyJarFSEnv(multiReleaseValue);
>> 
>> Note?that this?will now?cause `.zip`?files to?be?treated the?same as?`.jar`?files when?`multiReleaseValue???null` (previously, this?was?ignored for?`.zip`?files)
>
> That's an excellent point. I will be sure to ask people if that looks acceptable and revert to the original behaviour otherwise. Thank you for spotting it and saying something.

I think I would prefer to no send the multi release value for non-jar files - possibly there's no observable difference at this time, but the multi-release jar is for jars only.

(Also the comment above the variable seems a bit superfluous.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2139258325

From jlahoda at openjdk.org  Wed Jun 11 06:04:32 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 11 Jun 2025 06:04:32 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
Message-ID: <ODhtG897tIKEscihyIBRPvuvJ76o9h2Emcj9Z5XxUco=.7af3e222-5304-47d1-8486-ca15699f792a@github.com>

On Thu, 5 Jun 2025 00:03:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java line 1463:
>> 
>>> 1461:                                 return null;
>>> 1462:                             }
>>> 1463:                             fs = jarFSProvider.newFileSystem(p, FSInfo.readOnlyJarFSEnv(null));
>> 
>> Happy to consider either commenting the null here (e.g. `readOnlyJarFSEnv(/* releaseVersion */ null)`), or adding a no-arg version of the method in FSInfo.
>
> This seems like a fallback path, so don't think we should add a no-arg version to promote skipping the release version.

I think just `readOnlyJarFSEnv(null)` is OK.

>> test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 68:
>> 
>>> 66:         // Expected to always be a ZIP filesystem.
>>> 67:         try (FileSystem fs = FileSystems.newFileSystem(ctSym, FSInfo.readOnlyJarFSEnv(null))) {
>>> 68:             // Check that the file system is read only (not true if not a zip file system).
>> 
>> Another case where I'm not 100% sure if it should be an assert, or a runtime exception/error.
>
> jtreg runs tests with -ea, so either works fine.

For me: not relying on `assert` is preferred, esp. in tests. I.e. what is here currently seems good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2139261006
PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2139265131

From jlahoda at openjdk.org  Wed Jun 11 06:04:33 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 11 Jun 2025 06:04:33 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <vEWUCpbY8ZWFy3FN-NLg9tHfBh9zX1ABvY2ve3ekpGs=.d7dc8936-a519-43d0-963f-b3c271815c1f@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
 <3dqpBxBqg3tZyqrL5dXJIgcp7IpFVdC_OTdvZImNRCE=.10ef42b5-1c05-4104-b8a2-7edb4579fb49@github.com>
 <vEWUCpbY8ZWFy3FN-NLg9tHfBh9zX1ABvY2ve3ekpGs=.d7dc8936-a519-43d0-963f-b3c271815c1f@github.com>
Message-ID: <qDmAteIL8rb8qlVWat6Lr7yMMOHbse5cjkpbiabOdlA=.de38522c-666e-4b9f-ab1e-95107d2cb51a@github.com>

On Tue, 10 Jun 2025 13:49:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It's possible. I remember having to change this when I prototyped the new code a while ago, but I'm not sure I remember exactly why. I can try reverting it if the original style is acceptable (personally I prefer to compile on-the-fly since it can test the compiler with different options - which is probably why I changed it originally).
>
> Also for compile on-the-fly, I usually use `InMemoryJavaCompiler` and `ByteCodeLoader` available with `/test/lib` library. `InMemoryJavaCompiler` conveniently returns a list of all class files, and its one-class-file version throws an exception if a compilation unit generates more than one class, which is not usually checked by manual invocations to javac task.

For new tests, I would often prefer to use on-the-fly compilation (although javac has its own frameworks to do that, like the `ToolBox` used here).

For existing tests, I generally prefer to restrict changes to a minimum (although opinions may differ on that).

But here, I wonder: why is the test failing? I didn't see anything in the patch that would seem to be an obvious cause of a breakage of a test like this. So, I think it deserves a good look to find out what's the cause of the test failing, rather than just adjusting the test to pass.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2139275769

From abimpoudis at openjdk.org  Wed Jun 11 09:54:17 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Jun 2025 09:54:17 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v2]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <_k90i1xCH5JtlJrNxjsQFDxkL33fFT_zFVPmE69EE5M=.78fb0706-f332-42a7-94a2-d5bbafbea16e@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 t...

Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:

 - Restore formatting of asOuterSuper
 - Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/f33753bf..6cec56aa

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

  Stats: 32 lines in 3 files changed: 27 ins; 0 del; 5 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 duke at openjdk.org  Wed Jun 11 10:29:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 11 Jun 2025 10:29:32 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <ODhtG897tIKEscihyIBRPvuvJ76o9h2Emcj9Z5XxUco=.7af3e222-5304-47d1-8486-ca15699f792a@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
 <ODhtG897tIKEscihyIBRPvuvJ76o9h2Emcj9Z5XxUco=.7af3e222-5304-47d1-8486-ca15699f792a@github.com>
Message-ID: <4Y1XUTBDyE1VHbdiYJczMkuunFsGg6ryfS2P3LcXAPE=.dda31ee9-a9ca-4a7f-a0ef-43055680b5b1@github.com>

On Wed, 11 Jun 2025 05:51:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> jtreg runs tests with -ea, so either works fine.
>
> For me: not relying on `assert` is preferred, esp. in tests. I.e. what is here currently seems good to me.

But you would be okay with this assert, or just happy to shrug and leave it as read-write if it somehow wasn't a ZIP file system? Alternately we could do what I see done elsewhere and extract the ZIP file system provider and use it directly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2139779444

From mcimadamore at openjdk.org  Wed Jun 11 12:07:35 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Jun 2025 12:07:35 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v2]
In-Reply-To: <_k90i1xCH5JtlJrNxjsQFDxkL33fFT_zFVPmE69EE5M=.78fb0706-f332-42a7-94a2-d5bbafbea16e@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <_k90i1xCH5JtlJrNxjsQFDxkL33fFT_zFVPmE69EE5M=.78fb0706-f332-42a7-94a2-d5bbafbea16e@github.com>
Message-ID: <vlRlNiod5vbsVnQkgH8M79xOHtHcHOz8Z1tLJdz-zqo=.4560ad4c-9e8b-47e2-b15c-8d8eb7bbc32f@github.com>

On Wed, 11 Jun 2025 09:54:17 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 th...
>
> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore formatting of asOuterSuper
>  - Address review

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-2916859013

From vromero at openjdk.org  Wed Jun 11 14:50:29 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Jun 2025 14:50:29 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v2]
In-Reply-To: <_k90i1xCH5JtlJrNxjsQFDxkL33fFT_zFVPmE69EE5M=.78fb0706-f332-42a7-94a2-d5bbafbea16e@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <_k90i1xCH5JtlJrNxjsQFDxkL33fFT_zFVPmE69EE5M=.78fb0706-f332-42a7-94a2-d5bbafbea16e@github.com>
Message-ID: <0FU8T61wgkDR7s_Tp903xVjTZkYXY3IyVebrH4PDn_I=.6491487d-30ee-4268-a108-2f53bd9a25eb@github.com>

On Wed, 11 Jun 2025 09:54:17 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 th...
>
> Aggelos Biboudis has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore formatting of asOuterSuper
>  - Address review

looks good

test/langtools/tools/javac/T8357653.java line 46:

> 44: public class T8357653 extends TestRunner {
> 45:     private ToolBox tb;
> 46:     private static final String SOURCE_VERSION = System.getProperty("java.specification.version");

this constant, SOURCE_VERSION, is not used below

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-2917564621
PR Review Comment: https://git.openjdk.org/jdk/pull/25451#discussion_r2140316024

From abimpoudis at openjdk.org  Wed Jun 11 14:56:24 2025
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Jun 2025 14:56:24 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v3]
In-Reply-To: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
Message-ID: <2DjQ7MlMm-D4rLQvz3DeiweScikQtFbyHp45bkugqJo=.6f1db873-ab62-4195-9bfc-8181b92ae6c8@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 t...

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

  Remove unused field in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25451/files
  - new: https://git.openjdk.org/jdk/pull/25451/files/6cec56aa..68364b85

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 vromero at openjdk.org  Wed Jun 11 14:56:24 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Jun 2025 14:56:24 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v3]
In-Reply-To: <2DjQ7MlMm-D4rLQvz3DeiweScikQtFbyHp45bkugqJo=.6f1db873-ab62-4195-9bfc-8181b92ae6c8@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <2DjQ7MlMm-D4rLQvz3DeiweScikQtFbyHp45bkugqJo=.6f1db873-ab62-4195-9bfc-8181b92ae6c8@github.com>
Message-ID: <4XDWMHfpu9spOcV0z66FrpO1bg6bA17pnF0e71WvxfQ=.adec6095-1aa5-4466-a6b3-2795f9cad99c@github.com>

On Wed, 11 Jun 2025 14:52:42 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 th...
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused field in test

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-2917584611

From jlahoda at openjdk.org  Thu Jun 12 06:55:37 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 12 Jun 2025 06:55:37 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode
In-Reply-To: <4Y1XUTBDyE1VHbdiYJczMkuunFsGg6ryfS2P3LcXAPE=.dda31ee9-a9ca-4a7f-a0ef-43055680b5b1@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
 <ODhtG897tIKEscihyIBRPvuvJ76o9h2Emcj9Z5XxUco=.7af3e222-5304-47d1-8486-ca15699f792a@github.com>
 <4Y1XUTBDyE1VHbdiYJczMkuunFsGg6ryfS2P3LcXAPE=.dda31ee9-a9ca-4a7f-a0ef-43055680b5b1@github.com>
Message-ID: <uCBc3KI5P-trGMgoUms0uPwFdRcj9dFT5oz6TsrBMjI=.0ab290e1-6818-4468-93d1-634ee6c3a7a7@github.com>

On Wed, 11 Jun 2025 10:27:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> For me: not relying on `assert` is preferred, esp. in tests. I.e. what is here currently seems good to me.
>
> But you would be okay with this assert, or just happy to shrug and leave it as read-write if it somehow wasn't a ZIP file system? Alternately we could do what I see done elsewhere and extract the ZIP file system provider and use it directly?

I think this test is verifying `ct.sym` is sensible, and we can extend that to make sure the file can be opened in the correct way. I.e., I would keep the check at this place as you did.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2141856934

From acobbs at openjdk.org  Thu Jun 12 18:56:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 12 Jun 2025 18:56:33 GMT
Subject: RFR: 8358604: Trees for `var` do not have end positions
In-Reply-To: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
References: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
Message-ID: <MI8Kma5OJNx87iTbVBcov2bI5AM10nnMdzFdIT4hSZw=.819eacf7-2be7-4356-8e08-21803ab3cba2@github.com>

On Thu, 5 Jun 2025 21:14:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler replaces `var` nodes with synthetic tree nodes representing the inferred type. Previously, these new synthetic nodes were not being assigned either starting or ending source code positions.
> 
> [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) added starting positions, but not ending positions. This PR adds ending positions, and fixes some related bugs discovered in the research process:
> 
> * For a declaration like `final var x`, the fix for [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) was returning a starting position incorrectly pointing to `final` instead of `var`.
> * A declaration like `final var x` was correctly starting at `final` for normal declarations, but incorrectly starting at `var` for a lambda parameter declarations.
> * `JCVariableDecl.declaredUsingVar()` was incorrectly returning `false` for `var` variable declarations in record deconstruction patterns (thanks to @cushon for reporting this)
> 
> Background: When a `var`is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null. Previously there was a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there _were_ modifiers, which is wrong. Etc.
> 
> This patch attempts to clarify things and includes the following changes:
> 
> * Make a `var`'s starting source position properly recoverable from a `JCVariableDecl` even while `vartype` is null.
> * Fix the three bugs mentioned above.
> * Make `TreeMaker.at()` capable of configuring both the starting and ending position; do some minor cleanup/refactoring.
> * Set ending positions for the synthetic tree nodes that replace `var`
> * Pretty print `var` as `var` instead of `/*missing*/` (drive-by improvement)
> * Add more regression test coverage

Thinking about this more...

First let's clarify that there are three separate issues floating around here:

1. Whether `VariableTree.getType()` should more accurately reflect the original source for implicitly typed variables ([JDK-8268850](https://bugs.openjdk.org/browse/JDK-8268850) and [JDK-8024098](https://bugs.openjdk.org/browse/JDK-8024098))
2. Whether `VariableTree.getType()` should return something that has an ending position ([JDK-8358604](https://bugs.openjdk.org/browse/JDK-8358604))
3. The "related bugs" described above re: starting positions for `var` declarations with/without modifiers

My current thinking on each of these:
1. **Postpone** ? Change would be somewhat disruptive and probably requires more thought/research
2. **Won't Do** ? As Jan points out, would be a "one-off" that doesn't help that much (almost all tree nodes don't have ending positions). Instead, we can help things by fixing `JCVariableDecl` so it's possible to disambiguate implicitly typed variables
3. **Create a new issue and fix separately** ? These are just simple bugs independent from the above, but fixing them will also disambiguate implicitly typed variables as a side-effect. Created [JDK-8359383](https://bugs.openjdk.org/browse/JDK-8359383).

So I am closing this PR and will open a new one for JDK-8359383.

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

PR Comment: https://git.openjdk.org/jdk/pull/25664#issuecomment-2967853006

From acobbs at openjdk.org  Thu Jun 12 18:56:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 12 Jun 2025 18:56:33 GMT
Subject: Withdrawn: 8358604: Trees for `var` do not have end positions
In-Reply-To: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
References: <ROD6fqhjO3Paqcq7aId_urG_Azuak_gWbT5tzdg3K2M=.6a89d7bc-0e7c-4959-b0ff-689f2b2f2799@github.com>
Message-ID: <XFswOAE3p4KpeuEOWBklGYnRDGCNYaVlDRppW1kdp7w=.1b4f3280-cb36-45b6-bdaa-b6ca90b6cf84@github.com>

On Thu, 5 Jun 2025 21:14:03 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler replaces `var` nodes with synthetic tree nodes representing the inferred type. Previously, these new synthetic nodes were not being assigned either starting or ending source code positions.
> 
> [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) added starting positions, but not ending positions. This PR adds ending positions, and fixes some related bugs discovered in the research process:
> 
> * For a declaration like `final var x`, the fix for [JDK-8329951](https://bugs.openjdk.org/browse/JDK-8329951) was returning a starting position incorrectly pointing to `final` instead of `var`.
> * A declaration like `final var x` was correctly starting at `final` for normal declarations, but incorrectly starting at `var` for a lambda parameter declarations.
> * `JCVariableDecl.declaredUsingVar()` was incorrectly returning `false` for `var` variable declarations in record deconstruction patterns (thanks to @cushon for reporting this)
> 
> Background: When a `var`is parsed or a variable is implicitly typed such as a lambda parameter, `JCVariableDecl.vartype` is set to null until the type can be inferred. This causes various problems when trying to determine the starting position of (a) the declaration's type, when `var` is used, because the source position of the `var` has been lost forever (especially if there are also modifiers); and (b) the starting position of the declaration itself, when there are no modifiers, because normally that's computed from the start position of `JCVariableDecl.vartype`, which is (sometimes) null. Previously there was a field `JCVariableDecl.startPos` which was put there to workaround problem (b), but that workaround was being applied even when there _were_ modifiers, which is wrong. Etc.
> 
> This patch attempts to clarify things and includes the following changes:
> 
> * Make a `var`'s starting source position properly recoverable from a `JCVariableDecl` even while `vartype` is null.
> * Fix the three bugs mentioned above.
> * Make `TreeMaker.at()` capable of configuring both the starting and ending position; do some minor cleanup/refactoring.
> * Set ending positions for the synthetic tree nodes that replace `var`
> * Pretty print `var` as `var` instead of `/*missing*/` (drive-by improvement)
> * Add more regression test coverage

This pull request has been closed without being integrated.

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

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

From acobbs at openjdk.org  Thu Jun 12 19:50:03 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 12 Jun 2025 19:50:03 GMT
Subject: RFR: 8359383: Incorrect starting positions for implicitly typed
 variables
Message-ID: <DalHVpmhVqCE8vn2ePdsP0P5mPsL6mflttjK0NkG7nY=.b2ee068c-e4e5-4549-b519-b53112167969@github.com>

This fixes starting position bugs relating to implicitly typed variables; see the linked issue for details.

This also makes it possible to recover the declaration type (explicit, implicit, or `var`) from a `JCVariableDecl` and, in the case of `var` declarations, the starting position of the `var`; previously this wasn't possible.

Finally, as a minor drive-by improvement, we can now pretty print `var` as `var` instead of `/*missing*/`.

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

Commit messages:
 - Fix various starting position bugs relating to implicitly typed variables.

Changes: https://git.openjdk.org/jdk/pull/25786/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25786&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359383
  Stats: 151 lines in 12 files changed: 91 ins; 10 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/25786.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25786/head:pull/25786

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

From darcy at openjdk.org  Fri Jun 13 21:38:30 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Jun 2025 21:38:30 GMT
Subject: RFR: 8354447: Missing test for retroactive
 @SuppressWarnings("dangling-doc-comments") behavior
In-Reply-To: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
References: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
Message-ID: <3wtFEr8lwSKsvE8YChmS7PQ31BP5hqtCzWHa284Fwrs=.f0ee510f-36b3-4f10-bb8d-e84fe19cd0d2@github.com>

On Fri, 11 Apr 2025 19:55:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a regression test for the "retroactive" behavior of `@SuppressWarnings("dangling-doc-comments")`, that is,  the warning suppression applies to comments preceding the declaration that the annotation annotates, even though those comments are not within the lexical scope of that declaration. Previously there was no test for this behavior.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24600#pullrequestreview-2926491036

From acobbs at openjdk.org  Fri Jun 13 21:38:19 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 13 Jun 2025 21:38:19 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are handled
 in the compiler
Message-ID: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>

The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.

The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.

This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

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

Commit messages:
 - Refactor MandatoryWarningHandler to just be an aggregator.

Changes: https://git.openjdk.org/jdk/pull/25810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359493
  Stats: 834 lines in 10 files changed: 378 ins; 428 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/25810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25810/head:pull/25810

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

From acobbs at openjdk.org  Fri Jun 13 21:45:35 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 13 Jun 2025 21:45:35 GMT
Subject: RFR: 8354447: Missing test for retroactive
 @SuppressWarnings("dangling-doc-comments") behavior
In-Reply-To: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
References: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
Message-ID: <cRlm7n8IWMzrziIjPJTZffryVhgXgTM3I89cC5pkLHo=.ccf44801-122b-4791-b3ef-c7386619795c@github.com>

On Fri, 11 Apr 2025 19:55:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a regression test for the "retroactive" behavior of `@SuppressWarnings("dangling-doc-comments")`, that is,  the warning suppression applies to comments preceding the declaration that the annotation annotates, even though those comments are not within the lexical scope of that declaration. Previously there was no test for this behavior.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/24600#issuecomment-2971769650

From acobbs at openjdk.org  Fri Jun 13 21:45:36 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 13 Jun 2025 21:45:36 GMT
Subject: Integrated: 8354447: Missing test for retroactive
 @SuppressWarnings("dangling-doc-comments") behavior
In-Reply-To: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
References: <JOcpKQszQWUmNJY5e7VhdGu3zCRGiqLiBy4Ab6k_oHk=.8f74c357-b216-4b3e-86eb-2e237f294a42@github.com>
Message-ID: <qF1pOvYV9ofI00lqe4mQ0436kMNBBLx99z_zYIXztqI=.7282f344-61d4-428f-9856-cc1ba8794649@github.com>

On Fri, 11 Apr 2025 19:55:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds a regression test for the "retroactive" behavior of `@SuppressWarnings("dangling-doc-comments")`, that is,  the warning suppression applies to comments preceding the declaration that the annotation annotates, even though those comments are not within the lexical scope of that declaration. Previously there was no test for this behavior.

This pull request has now been integrated.

Changeset: 0e725c6f
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e725c6fb1f324b0fd17d206806b4104dc7ba767
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

8354447: Missing test for retroactive @SuppressWarnings("dangling-doc-comments") behavior

Reviewed-by: darcy

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

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

From duke at openjdk.org  Mon Jun 16 12:43:39 2025
From: duke at openjdk.org (Sven Palberg)
Date: Mon, 16 Jun 2025 12:43:39 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <hl10DotB1WD1hlzDIUme-8ZMW4QM9SoTbp6Nnn5YidY=.804f2278-ed1e-4461-a0ff-096eddec59b0@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <XagMylPJUuOdBSgoHJbL0E2a7HA5ANbGzIFOtOlfyLU=.fe95fa1b-50c0-4ddd-9532-e519b2def91b@github.com>
 <hl10DotB1WD1hlzDIUme-8ZMW4QM9SoTbp6Nnn5YidY=.804f2278-ed1e-4461-a0ff-096eddec59b0@github.com>
Message-ID: <q1sEmLSeWMxPBy8Z1Cc2fZoUx7oqnMFPV7EGLziGSiM=.3ef9244c-1af1-46e2-934b-ed7554ba086a@github.com>

On Wed, 4 Jun 2025 12:50:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Tests (tier1-3) passed, so OK to integrate, I think. Thanks!
>
>> Tests (tier1-3) passed, so OK to integrate, I think. Thanks!
> 
> Awesome! Thanks for running the tests.

@archiecobbs Thanks for the fix! Is there any chance that it will be backported to jdk 22, 23 or 24?

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2976494946

From acobbs at openjdk.org  Mon Jun 16 19:46:34 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Jun 2025 19:46:34 GMT
Subject: RFR: 8358066: Non-ascii package names gives compilation error
 "import requires canonical name" [v2]
In-Reply-To: <hl10DotB1WD1hlzDIUme-8ZMW4QM9SoTbp6Nnn5YidY=.804f2278-ed1e-4461-a0ff-096eddec59b0@github.com>
References: <Xy4VTIvDOqkLP_JIDJA1KeCzgiSALdBPeeX7Z_zS5WU=.da18df84-23c0-4c74-83be-032612fc2a3a@github.com>
 <a4MkqTGRYyvYQlVTw5JJlyh5HaWBo52_VNaMB9U07E8=.cb97e932-eb2a-4233-8144-793e470c9802@github.com>
 <XagMylPJUuOdBSgoHJbL0E2a7HA5ANbGzIFOtOlfyLU=.fe95fa1b-50c0-4ddd-9532-e519b2def91b@github.com>
 <hl10DotB1WD1hlzDIUme-8ZMW4QM9SoTbp6Nnn5YidY=.804f2278-ed1e-4461-a0ff-096eddec59b0@github.com>
Message-ID: <2s08j60dByqEodsRWC3WGxLEX5YjIT-aka_rq01Ml8Y=.d4f161a3-8a61-4233-82ea-8534a6d3a31e@github.com>

On Wed, 4 Jun 2025 12:50:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Tests (tier1-3) passed, so OK to integrate, I think. Thanks!
>
>> Tests (tier1-3) passed, so OK to integrate, I think. Thanks!
> 
> Awesome! Thanks for running the tests.

> @archiecobbs Thanks for the fix! Is there any chance that it will be backported to jdk 22, 23 or 24?

Sure, I'll look into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25567#issuecomment-2977883183

From jlahoda at openjdk.org  Tue Jun 17 10:06:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 17 Jun 2025 10:06:46 GMT
Subject: RFR: 8358801: javac produces class that does not pass verifier.
Message-ID: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>

Consider code like:


public class Main {

    private boolean test(String s, int i) {
        if (s.subSequence(0, 1) instanceof Runnable r) {
            return true;
        }

        Integer dummy;
        switch (i) {
            case 0:
                String clashing = null;
                return true;
            default:
                return true;
        }
    }

    public static void main(String[] args) {
    }
}


javac will produce code that won't (rightfully) pass the verifier:


$ java Main.java
Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 49
Exception Details:
  Location:
    Main.test(Ljava/lang/String;I)Z @49: iconst_1
  Reason:
    Type top (current frame, locals[4]) is not assignable to 'java/lang/String' (stack map, locals[4])
  Current Frame:
    bci: @25
    flags: { }
    locals: { 'Main', 'java/lang/String', integer }
    stack: { integer }
  Stackmap Frame:
    bci: @49
    flags: { }
    locals: { 'Main', 'java/lang/String', integer, top, 'java/lang/String' }
    stack: { }
  Bytecode:
    0000000: 2b03 04b6 0007 3a04 1904 c100 0d99 000b
    0000010: 1904 c000 0d4e 04ac 1cab 0000 0000 0018
    0000020: 0000 0001 0000 0000 0000 0013 013a 0404
    0000030: ac04 ac
  Stackmap Table:
    same_frame(@24)
    same_frame(@44)
    append_frame(@49,Top,Object[#8])

        at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
        at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3035)
        at java.base/java.lang.Class.getMethodsRecursive(Class.java:3177)
        at java.base/java.lang.Class.findMethod(Class.java:2465)
        at java.base/java.lang.System$1.findMethod(System.java:1980)
        at java.base/jdk.internal.misc.MethodFinder.findMainMethod(MethodFinder.java:86)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:194)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)



Now, the problem, as far as I can tell, is this: javac will desugar the pattern matching instanceof along the lines of:


if (... (var $temp = s.subSequence(0, 1) in ... && ...) ...) {
    return true;
}


(`$temp` is register/local variable number 4)
specifically, note the `&&` in the middle of the let expression, and that the expression is in the conditional position. What happens here is that at the position of the `&&` will basically generate a jump to skip the if (i.e. a jump whose target is just behind the if, for the case where the `...` left to it evaluates to false). The problem here is that at the source position of the jump, the variable `$temp` is defined/has value. And the set of variables which are defined/have value is stored at the moment of jump, and restored at the target place of the jump. I.e. in this case, javac will think variable number 4 has a value.

This, by itself, while it does not seem right, but does not lead to a breakage, as the variable is not in `code.lvar`, and hence javac will ignore it.

The problem is that inside the first case, variable number 4 is declared, and `lvar` is filled for it. In the first case, it is still not problematic, as the variable is defined/has value there as well. But, for the default case, the variable still has an `lvar` entry (as the variable is still declared, just should be unassigned), but the defined/has value flag stored earlier is restored again. So, javac thinks the variable is fully valid, and generates a bogus StackMapTable entry listing the variable, leading to the verifier failure.

I think the source of all trouble is the wrong "defined" flag. The solution in this PR is to make sure the variables declared by the let expression are removed from the `defined` variables stored in the conditional jump chains.

Note this only applies to jumps that go outside of the left expression (and hence outside of the scope of the variable), internal jumps inside the let expression, if there would be any, shouldn't be affected.

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

Commit messages:
 - 8358801: javac produces class that does not pass verifier.

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

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

From acobbs at openjdk.org  Tue Jun 17 14:05:45 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 17 Jun 2025 14:05:45 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given
Message-ID: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>

My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.

Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 

Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.

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

Commit messages:
 - No need for /nodynamiccopyright/ with this test.
 - Restore behavior when both -Xlint:options and -Xlint:-options are given.

Changes: https://git.openjdk.org/jdk/pull/25840/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359596
  Stats: 80 lines in 3 files changed: 46 ins; 26 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25840/head:pull/25840

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

From nbenalla at openjdk.org  Tue Jun 17 15:27:03 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 17 Jun 2025 15:27:03 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25 build
 27
Message-ID: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>

Usual symbol file update for a new JDK build.

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

Commit messages:
 - Update --release 25 symbol information for JDK 25 build 27

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

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

From liach at openjdk.org  Tue Jun 17 15:59:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Jun 2025 15:59:27 GMT
Subject: RFR: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
Message-ID: <5KblOeF1zKNi-suuCaVVnqKyLBeu5Res8VyYJv7iYTs=.5415f272-d574-4ac3-bc6b-d64e2b75ef9e@github.com>

On Tue, 17 Jun 2025 10:01:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> 
> public class Main {
> 
>     private boolean test(String s, int i) {
>         if (s.subSequence(0, 1) instanceof Runnable r) {
>             return true;
>         }
> 
>         Integer dummy;
>         switch (i) {
>             case 0:
>                 String clashing = null;
>                 return true;
>             default:
>                 return true;
>         }
>     }
> 
>     public static void main(String[] args) {
>     }
> }
> 
> 
> javac will produce code that won't (rightfully) pass the verifier:
> 
> 
> $ java Main.java
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 49
> Exception Details:
>   Location:
>     Main.test(Ljava/lang/String;I)Z @49: iconst_1
>   Reason:
>     Type top (current frame, locals[4]) is not assignable to 'java/lang/String' (stack map, locals[4])
>   Current Frame:
>     bci: @25
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer }
>     stack: { integer }
>   Stackmap Frame:
>     bci: @49
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer, top, 'java/lang/String' }
>     stack: { }
>   Bytecode:
>     0000000: 2b03 04b6 0007 3a04 1904 c100 0d99 000b
>     0000010: 1904 c000 0d4e 04ac 1cab 0000 0000 0018
>     0000020: 0000 0001 0000 0000 0000 0013 013a 0404
>     0000030: ac04 ac
>   Stackmap Table:
>     same_frame(@24)
>     same_frame(@44)
>     append_frame(@49,Top,Object[#8])
> 
>         at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>         at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3035)
>         at java.base/java.lang.Class.getMethodsRecursive(Class.java:3177)
>         at java.base/java.lang.Class.findMethod(Class.java:2465)
>         at java.base/java.lang.System$1.findMethod(System.java:1980)
>         at java.base/jdk.internal.misc.MethodFinder.findMainMethod(MethodFinder.java:86)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:194)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> 
> 
> 
> Now, the problem, as far as I can tell, is this: javac will desugar the pattern matching instanceof along the lines of:
> 
> 
> if (... (var $temp = s.subSequence(0, 1) in ... && ...) ...) {
>     return true;
> }
> 
> 
> (`$temp` is register/local variable number 4)
> specifically, note the `&&` in the middle of the let expression, and that the expression is in the conditional position. What happens here is...

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 763:

> 761:             //expression:
> 762:             undefineVariablesInChain(result.falseJumps, limit);
> 763:             undefineVariablesInChain(result.trueJumps, limit);

Should we move this truncation of variables to CondItem itself? I moved the truncation of continue/break to GenContext and found that helpful, maybe we can require an extra int arg for `makeCondItem(int, Chain, Chain)` for the limit?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25849#discussion_r2152632288

From darcy at openjdk.org  Tue Jun 17 16:27:31 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 17 Jun 2025 16:27:31 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 27
In-Reply-To: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
Message-ID: <pfPIA-i8Q9k5bZmAxMvM5RVwJmKZwY-Cyz_FvSEQhdU=.4aa1b9f9-cd5d-44d1-86ce-c51dcb9b49aa@github.com>

On Tue, 17 Jun 2025 15:20:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

src/jdk.compiler/share/data/symbols/java.base-P.sym.txt line 54:

> 52: -method name readln descriptor ()Ljava/lang/String;
> 53: 
> 54: class name java/io/Reader

Seeing this is surprising since JDK-8354724: "Methods in java.io.Reader to read all characters and all lines" which added these methods was add in JDK 25 build _26_ while, presumably many other changes from build 26 are already present in the symbol file.

src/jdk.compiler/share/data/symbols/java.base-P.sym.txt line 137:

> 135: method name powExact descriptor (JI)J flags 9
> 136: method name unsignedPowExact descriptor (JI)J flags 9
> 137: method name cbrt descriptor (D)D flags 9 runtimeAnnotations @Ljdk/internal/vm/annotation/IntrinsicCandidate;

Presumably this is from JDK-8353686: "Optimize Math.cbrt for x86 64 bit platforms", which was also present in build 26.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25854#discussion_r2152688667
PR Review Comment: https://git.openjdk.org/jdk/pull/25854#discussion_r2152690551

From acobbs at openjdk.org  Tue Jun 17 17:29:52 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 17 Jun 2025 17:29:52 GMT
Subject: RFR: 8349847: Support configuring individual lint categories as
 errors [v5]
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: <_SqzPSApOTijV6HzlsXWlP6ompEzrUs-kxozGOkTAvw=.78ce81ad-fb5d-42fe-8926-f0252564cb88@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
> 
> This PR includes the following PR as a dependency/prerequisite:
> * #25840

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

 - Minor naming and Javadoc tweaks.
 - Merge branch 'JDK-8359596' into JDK-8349847
 - No need for /nodynamiccopyright/ with this test.
 - Restore behavior when both -Xlint:options and -Xlint:-options are given.
 - Merge branch 'master' into JDK-8349847
 - 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=04
  Stats: 268 lines in 15 files changed: 180 ins; 47 del; 41 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 Jun 17 18:53:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 17 Jun 2025 18:53:28 GMT
Subject: RFR: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <5KblOeF1zKNi-suuCaVVnqKyLBeu5Res8VyYJv7iYTs=.5415f272-d574-4ac3-bc6b-d64e2b75ef9e@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
 <5KblOeF1zKNi-suuCaVVnqKyLBeu5Res8VyYJv7iYTs=.5415f272-d574-4ac3-bc6b-d64e2b75ef9e@github.com>
Message-ID: <FjW7q5XeeSZT9Dcrg3Xx22y7OASf9AlUHuWxlPXs1nM=.bed2124e-78dc-4c3f-943c-335e703fb402@github.com>

On Tue, 17 Jun 2025 15:57:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Consider code like:
>> 
>> 
>> public class Main {
>> 
>>     private boolean test(String s, int i) {
>>         if (s.subSequence(0, 1) instanceof Runnable r) {
>>             return true;
>>         }
>> 
>>         Integer dummy;
>>         switch (i) {
>>             case 0:
>>                 String clashing = null;
>>                 return true;
>>             default:
>>                 return true;
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>     }
>> }
>> 
>> 
>> javac will produce code that won't (rightfully) pass the verifier:
>> 
>> 
>> $ java Main.java
>> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 49
>> Exception Details:
>>   Location:
>>     Main.test(Ljava/lang/String;I)Z @49: iconst_1
>>   Reason:
>>     Type top (current frame, locals[4]) is not assignable to 'java/lang/String' (stack map, locals[4])
>>   Current Frame:
>>     bci: @25
>>     flags: { }
>>     locals: { 'Main', 'java/lang/String', integer }
>>     stack: { integer }
>>   Stackmap Frame:
>>     bci: @49
>>     flags: { }
>>     locals: { 'Main', 'java/lang/String', integer, top, 'java/lang/String' }
>>     stack: { }
>>   Bytecode:
>>     0000000: 2b03 04b6 0007 3a04 1904 c100 0d99 000b
>>     0000010: 1904 c000 0d4e 04ac 1cab 0000 0000 0018
>>     0000020: 0000 0001 0000 0000 0000 0013 013a 0404
>>     0000030: ac04 ac
>>   Stackmap Table:
>>     same_frame(@24)
>>     same_frame(@44)
>>     append_frame(@49,Top,Object[#8])
>> 
>>         at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>>         at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3035)
>>         at java.base/java.lang.Class.getMethodsRecursive(Class.java:3177)
>>         at java.base/java.lang.Class.findMethod(Class.java:2465)
>>         at java.base/java.lang.System$1.findMethod(System.java:1980)
>>         at java.base/jdk.internal.misc.MethodFinder.findMainMethod(MethodFinder.java:86)
>>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:194)
>>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
>> 
>> 
>> 
>> Now, the problem, as far as I can tell, is this: javac will desugar the pattern matching instanceof along the lines of:
>> 
>> 
>> if (... (var $temp = s.subSequence(0, 1) in ... && ...) ...) {
>>     return true;
>> }
>> 
>> 
>> (`$temp` is register/local variable...
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 763:
> 
>> 761:             //expression:
>> 762:             undefineVariablesInChain(result.falseJumps, limit);
>> 763:             undefineVariablesInChain(result.trueJumps, limit);
> 
> Should we move this truncation of variables to CondItem itself? I moved the truncation of continue/break to GenContext and found that helpful, maybe we can require an extra int arg for `makeCondItem(int, Chain, Chain)` for the limit?

To me, personally: while doing it here is not perfect (mostly because I would prefer if we didn't have to do this bookkeeping at all), it seems to me like a fairly local property - the let expr starts, and then does its own cleanup. It already calls `code.endScopes(limit);` above this change, so this is basically an extension to that. If we did it at `makeCondItem` time, we would need to pass the limit everywhere `makeCondItem` is called, making it non-local. Many parts of the code would now suddenly have to care whether the node is inside a let expression. That feels to me like increasing complexity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25849#discussion_r2152954768

From liach at openjdk.org  Tue Jun 17 19:25:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Jun 2025 19:25:30 GMT
Subject: RFR: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <FjW7q5XeeSZT9Dcrg3Xx22y7OASf9AlUHuWxlPXs1nM=.bed2124e-78dc-4c3f-943c-335e703fb402@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
 <5KblOeF1zKNi-suuCaVVnqKyLBeu5Res8VyYJv7iYTs=.5415f272-d574-4ac3-bc6b-d64e2b75ef9e@github.com>
 <FjW7q5XeeSZT9Dcrg3Xx22y7OASf9AlUHuWxlPXs1nM=.bed2124e-78dc-4c3f-943c-335e703fb402@github.com>
Message-ID: <d5IXq0lF_any9X5JjWCevzwg3_2OmGUoRgrspo1F0Qo=.353ce80a-1206-4e1e-9c23-7425135397ee@github.com>

On Tue, 17 Jun 2025 18:50:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 763:
>> 
>>> 761:             //expression:
>>> 762:             undefineVariablesInChain(result.falseJumps, limit);
>>> 763:             undefineVariablesInChain(result.trueJumps, limit);
>> 
>> Should we move this truncation of variables to CondItem itself? I moved the truncation of continue/break to GenContext and found that helpful, maybe we can require an extra int arg for `makeCondItem(int, Chain, Chain)` for the limit?
>
> To me, personally: while doing it here is not perfect (mostly because I would prefer if we didn't have to do this bookkeeping at all), it seems to me like a fairly local property - the let expr starts, and then does its own cleanup. It already calls `code.endScopes(limit);` above this change, so this is basically an extension to that. If we did it at `makeCondItem` time, we would need to pass the limit everywhere `makeCondItem` is called, making it non-local. Many parts of the code would now suddenly have to care whether the node is inside a let expression. That feels to me like increasing complexity.

Sounds reasonable. I asked this because I could see `undefineVariablesInChain` being used elsewhere, such as `GenContext::addCont/addExit`. We should probably update those two sites, as I didn't consider a linked list chain being used in those sites.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25849#discussion_r2153012589

From liach at openjdk.org  Tue Jun 17 19:25:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Jun 2025 19:25:30 GMT
Subject: RFR: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <d5IXq0lF_any9X5JjWCevzwg3_2OmGUoRgrspo1F0Qo=.353ce80a-1206-4e1e-9c23-7425135397ee@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
 <5KblOeF1zKNi-suuCaVVnqKyLBeu5Res8VyYJv7iYTs=.5415f272-d574-4ac3-bc6b-d64e2b75ef9e@github.com>
 <FjW7q5XeeSZT9Dcrg3Xx22y7OASf9AlUHuWxlPXs1nM=.bed2124e-78dc-4c3f-943c-335e703fb402@github.com>
 <d5IXq0lF_any9X5JjWCevzwg3_2OmGUoRgrspo1F0Qo=.353ce80a-1206-4e1e-9c23-7425135397ee@github.com>
Message-ID: <DWUyxiprIxhJEaVyVgT4sEcuiTEs3qpWFoBjjprfkKA=.34011c5a-0d03-4c0c-88c3-92468a3c327b@github.com>

On Tue, 17 Jun 2025 19:21:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> To me, personally: while doing it here is not perfect (mostly because I would prefer if we didn't have to do this bookkeeping at all), it seems to me like a fairly local property - the let expr starts, and then does its own cleanup. It already calls `code.endScopes(limit);` above this change, so this is basically an extension to that. If we did it at `makeCondItem` time, we would need to pass the limit everywhere `makeCondItem` is called, making it non-local. Many parts of the code would now suddenly have to care whether the node is inside a let expression. That feels to me like increasing complexity.
>
> Sounds reasonable. I asked this because I could see `undefineVariablesInChain` being used elsewhere, such as `GenContext::addCont/addExit`. We should probably update those two sites, as I didn't consider a linked list chain being used in those sites.

Or you can even make it an instance method on Chain - the limit can be considered an intrinsic property to where the chain leads to, except this information is not available when a chain is constructed (should it be?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25849#discussion_r2153016100

From achung at openjdk.org  Tue Jun 17 23:11:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:11:15 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

Commit messages:
 - empty commit
 - redo ws fixes, add manual changes

Changes: https://git.openjdk.org/jdk/pull/25839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1574 lines in 76 files changed: 810 ins; 93 del; 671 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

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

From achung at openjdk.org  Tue Jun 17 23:18:27 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:18:27 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <-07gTVUiE_k1Kfc5m2OgDlX6fj1hUMYWZqsSK2YFlYc=.0fc07185-3be2-4f7c-b24f-fca061924170@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

whitespace changes are fixed, PR is ready for review

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2982077742

From jlu at openjdk.org  Tue Jun 17 23:18:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:18:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 2:

> 1: #
> 2: # Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved.

Same as my comment in `src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java`

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] ''{dir|jar|class}'' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Extra quotes, applies to other localized versions as well. (Usual change we revert)

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:

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

Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314389
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153313105
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314152

From jlu at openjdk.org  Tue Jun 17 23:24:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:24:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <41BnI9ePFiQiYk_COU-Rrpz0qzr33GN0p9AfF38Fkmk=.0d9c1020-d538-41b2-a939-f7e296029ae0@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 30:

> 28: STARNN=*******************************************\n\n
> 29: # keytool: Help part
> 30: .OPTION.=\ [OPTION]...

We spoke about this offline. This is fine, property file values need to either start with a `\ `or `\u0020` to denote intentional leading white space. In this case, since we convert to UTF-8 native characters from escape sequences this gets included as well. Functionally, they are equivalent and the new form works well with the translation process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153321343

From achung at openjdk.org  Tue Jun 17 23:34:52 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:34:52 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

  fix unicode escapes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/2dfac379..d8027691

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

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

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

From almatvee at openjdk.org  Tue Jun 17 23:43:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 17 Jun 2025 23:43:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <uLYnpuvdWyGcO615myaP0lHZ9HMiX9Ag27OnViwh5Ik=.cb34bbec-542b-40a6-98ab-270e2b63bcae@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

jdk.jpackage changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2937331933

From naoto at openjdk.org  Wed Jun 18 01:56:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 01:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:

> 1: #

Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153463170

From nbenalla at openjdk.org  Wed Jun 18 08:28:28 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 08:28:28 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 27
In-Reply-To: <pfPIA-i8Q9k5bZmAxMvM5RVwJmKZwY-Cyz_FvSEQhdU=.4aa1b9f9-cd5d-44d1-86ce-c51dcb9b49aa@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
 <pfPIA-i8Q9k5bZmAxMvM5RVwJmKZwY-Cyz_FvSEQhdU=.4aa1b9f9-cd5d-44d1-86ce-c51dcb9b49aa@github.com>
Message-ID: <c7k85YiuDIc3ecHLTWLCDn4q9uvshGKX6Ow8K9l-JIs=.8b1734c7-8747-405c-8202-a2d99f128f70@github.com>

On Tue, 17 Jun 2025 16:24:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Usual symbol file update for a new JDK build.
>
> src/jdk.compiler/share/data/symbols/java.base-P.sym.txt line 54:
> 
>> 52: -method name readln descriptor ()Ljava/lang/String;
>> 53: 
>> 54: class name java/io/Reader
> 
> Seeing this is surprising since JDK-8354724: "Methods in java.io.Reader to read all characters and all lines" which added these methods was add in JDK 25 build _26_ while, presumably many other changes from build 26 are already present in the symbol file.

I used "build 27" in the JBS/PR title because I did not update the symbol changes for build 26, and 27 was the latest I could find on `https://jdk.java.net/25/ `
I will update this with only changes that were in that build.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25854#discussion_r2153981116

From nbenalla at openjdk.org  Wed Jun 18 09:08:29 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 09:08:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <xcSAVqLxI2phW8UCEHcDpUMeFySiy0zigXx-MPkt5aU=.0c203d6f-60e1-41d1-82d5-a93bba898f5f@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

I'm unable to confirm the accuracy of the translations, since I don't speak the target languages. I've only reviewed the `jdk.javadoc` sources.

All keys in the English property files match one-to-one with those in the non-English files: there are no missing or extra entries. The only changes are to the `.properties` files, exactly as the PR title suggests.

>From the `jdk.javadoc` perspective, this looks good, so I'm happy to approve this PR.

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

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2938377311

From jsikstro at openjdk.org  Wed Jun 18 09:50:30 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 18 Jun 2025 09:50:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2983504760

From darcy at openjdk.org  Wed Jun 18 15:45:28 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Jun 2025 15:45:28 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 27
In-Reply-To: <c7k85YiuDIc3ecHLTWLCDn4q9uvshGKX6Ow8K9l-JIs=.8b1734c7-8747-405c-8202-a2d99f128f70@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
 <pfPIA-i8Q9k5bZmAxMvM5RVwJmKZwY-Cyz_FvSEQhdU=.4aa1b9f9-cd5d-44d1-86ce-c51dcb9b49aa@github.com>
 <c7k85YiuDIc3ecHLTWLCDn4q9uvshGKX6Ow8K9l-JIs=.8b1734c7-8747-405c-8202-a2d99f128f70@github.com>
Message-ID: <CKB8i7UUZjY6OdRUuqrYtZ1-rP-XHzVQ_UjjySV_Igw=.20b16197-ec2b-4793-833e-6ae65a41c5e8@github.com>

On Wed, 18 Jun 2025 08:25:41 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/jdk.compiler/share/data/symbols/java.base-P.sym.txt line 54:
>> 
>>> 52: -method name readln descriptor ()Ljava/lang/String;
>>> 53: 
>>> 54: class name java/io/Reader
>> 
>> Seeing this is surprising since JDK-8354724: "Methods in java.io.Reader to read all characters and all lines" which added these methods was add in JDK 25 build _26_ while, presumably many other changes from build 26 are already present in the symbol file.
>
> I used "build 27" in the JBS/PR title because I did not update the symbol changes for build 26, and 27 was the latest I could find on `https://jdk.java.net/25/ `
> I will update this with only changes that were in that build.

It is fine if the changeset contains information from multiple builds, but I'd expect many more symbol changes for build 26 as there were approx. 250 bug fixes in that build so I wanted to check what build was intended.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25854#discussion_r2154948566

From aivanov at openjdk.org  Wed Jun 18 16:15:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:15:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:

> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.

Shall the copyright year be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:

> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
> 459: SliderDemo.majorticks=Grobteilungen
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen

Should the translation of `SliderDemo.majorticks` also be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

The following description uses different words now:

Feinteilungen -> Teilstrichen
Teilungen -> Teilstrichen

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:

> 181: size.bit.alg=%1$d-Bit-%2$s
> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}

It feels as if there's something missing after _?einem?_.

src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46:

> 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben
> 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben
> 46: Subject.=Subject:\n

Is it correct? German usually uses `k`.

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:

> 54: 
> 55: # javax.security.auth.login.AppConfigurationEntry
> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020

Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:

> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:

Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:

> 227: doclet.search_in_documentation=In Dokumentation suchen
> 228: doclet.search_reset=Zur?cksetzen
> 229: doclet.Member=Member

Is `Member` translated? Should it be _?Mitglied?_?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154931256
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154807291
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154813672
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154907979
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154905960
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154915395
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154968902
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154985100

From jlu at openjdk.org  Wed Jun 18 16:24:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:24:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <epU16E3XQ7BNcECTdZbJJpdFw05jYxEZ8Kt1yRx34nY=.a5624636-51ea-4466-83c2-6e0f7aa6aca1@github.com>

On Wed, 18 Jun 2025 15:28:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
> 
>> 54: 
>> 55: # javax.security.auth.login.AppConfigurationEntry
>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
> 
> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155032074

From nbenalla at openjdk.org  Wed Jun 18 16:26:43 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 16:26:43 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 26 [v2]
In-Reply-To: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
Message-ID: <9e4lpuzQgaUx4FzFViyYsCueupHsL5boy4Vrv8GPDVM=.41fa0344-6b19-454c-9c49-f7c8682ed867@github.com>

> Usual symbol file update for a new JDK build.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - Update --release 25 symbol information for JDK 25 build 26
   The macOS/AArch64 build 26 was taken from https://jdk.java.net/25/
 - Revert "Update --release 25 symbol information for JDK 25 build 27"
   
   This reverts commit e576baf674dc58e6727c9d56613d177f2a0f919c.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25854/files
  - new: https://git.openjdk.org/jdk/pull/25854/files/e576baf6..9ec49c40

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

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

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

From jlu at openjdk.org  Wed Jun 18 16:28:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:28:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>

On Wed, 18 Jun 2025 15:34:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
> 
>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Shall the copyright year be updated?

In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155038247

From nbenalla at openjdk.org  Wed Jun 18 16:30:27 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 16:30:27 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 26 [v2]
In-Reply-To: <CKB8i7UUZjY6OdRUuqrYtZ1-rP-XHzVQ_UjjySV_Igw=.20b16197-ec2b-4793-833e-6ae65a41c5e8@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
 <pfPIA-i8Q9k5bZmAxMvM5RVwJmKZwY-Cyz_FvSEQhdU=.4aa1b9f9-cd5d-44d1-86ce-c51dcb9b49aa@github.com>
 <c7k85YiuDIc3ecHLTWLCDn4q9uvshGKX6Ow8K9l-JIs=.8b1734c7-8747-405c-8202-a2d99f128f70@github.com>
 <CKB8i7UUZjY6OdRUuqrYtZ1-rP-XHzVQ_UjjySV_Igw=.20b16197-ec2b-4793-833e-6ae65a41c5e8@github.com>
Message-ID: <kL7fKWTJzqVXJgWYNLgNZei-ZchlgjFO3a1QGctr62w=.2d9002d2-54a9-4c7e-8351-acda5a4ed66d@github.com>

On Wed, 18 Jun 2025 15:42:27 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I used "build 27" in the JBS/PR title because I did not update the symbol changes for build 26, and 27 was the latest I could find on `https://jdk.java.net/25/ `
>> I will update this with only changes that were in that build.
>
> It is fine if the changeset contains information from multiple builds, but I'd expect many more symbol changes for build 26 as there were approx. 250 bug fixes in that build so I wanted to check what build was intended.

There were no symbol changes in build 27.
I generated the symbol info using build 26 and updated the PR/JBS title to be accurate.
You will see that I reverted e576baf674dc58e6727c9d56613d177f2a0f919c and then regenerated the symbols using build 26, but the code changes remain the same.

These are all the symbols changes for build 26, even though there were many fixes in that build.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25854#discussion_r2155042195

From darcy at openjdk.org  Wed Jun 18 16:42:29 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Jun 2025 16:42:29 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 26 [v2]
In-Reply-To: <9e4lpuzQgaUx4FzFViyYsCueupHsL5boy4Vrv8GPDVM=.41fa0344-6b19-454c-9c49-f7c8682ed867@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
 <9e4lpuzQgaUx4FzFViyYsCueupHsL5boy4Vrv8GPDVM=.41fa0344-6b19-454c-9c49-f7c8682ed867@github.com>
Message-ID: <BlpGfoWqPK0wrcl8XLrp9eWIuLhA6BapVoE63VCwmoc=.2ea70301-172f-4c8b-bd7b-38f00953d7f2@github.com>

On Wed, 18 Jun 2025 16:26:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Usual symbol file update for a new JDK build.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update --release 25 symbol information for JDK 25 build 26
>    The macOS/AArch64 build 26 was taken from https://jdk.java.net/25/
>  - Revert "Update --release 25 symbol information for JDK 25 build 27"
>    
>    This reverts commit e576baf674dc58e6727c9d56613d177f2a0f919c.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25854#pullrequestreview-2939988452

From aivanov at openjdk.org  Wed Jun 18 16:45:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:45:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
Message-ID: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>

On Wed, 18 Jun 2025 16:25:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
>> 
>>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Shall the copyright year be updated?
>
> In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

This is weird? Usually, the copyright year is bumped up whenever the file is edited.

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
>> 
>>> 54: 
>>> 55: # javax.security.auth.login.AppConfigurationEntry
>>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
>> 
>> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.
>
> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

Thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071387
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071915

From iris at openjdk.org  Wed Jun 18 16:55:30 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Jun 2025 16:55:30 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 26 [v2]
In-Reply-To: <9e4lpuzQgaUx4FzFViyYsCueupHsL5boy4Vrv8GPDVM=.41fa0344-6b19-454c-9c49-f7c8682ed867@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
 <9e4lpuzQgaUx4FzFViyYsCueupHsL5boy4Vrv8GPDVM=.41fa0344-6b19-454c-9c49-f7c8682ed867@github.com>
Message-ID: <ZD6eGF0yb3ZGzPqCViYO5eMFB3Teb1IwlPp8UX0oaQ0=.6b26b3a6-c6eb-4a34-9ade-602cff74e524@github.com>

On Wed, 18 Jun 2025 16:26:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Usual symbol file update for a new JDK build.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update --release 25 symbol information for JDK 25 build 26
>    The macOS/AArch64 build 26 was taken from https://jdk.java.net/25/
>  - Revert "Update --release 25 symbol information for JDK 25 build 27"
>    
>    This reverts commit e576baf674dc58e6727c9d56613d177f2a0f919c.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25854#pullrequestreview-2940029535

From naoto at openjdk.org  Wed Jun 18 16:58:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 16:58:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
Message-ID: <GMreFXOIVIHSDY6c8Vcze6uvKnnsOAaNIH6G5rBfkQA=.507f3521-b8a6-4024-a1ed-d41f71a9c1e1@github.com>

On Wed, 18 Jun 2025 09:47:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

Those languages (de/ja/zh-CN) are the ones we (Oracle) support. Other entities would be welcome to provide l10n for other languages (not a sporadic l10n, but commit to update/maintain).

> 
> Edit: I see that the other localizations haven't been updated for the last few releases, so maybe this is intentional. Still interested to know why we have the other localizations if they aren't updated.

Usuallly l10n resource updates are additions, so those old l10ns still have values for those languages. New additions will simply fall back to English.

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2985038815

From achung at openjdk.org  Wed Jun 18 18:42:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 18 Jun 2025 18:42:54 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <3Sb_Nj53MtMZRoKypbBFn0yumsFtiGJzY5fv60CilwA=.4ee9201b-0657-484b-8e69-01306c131b39@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

  remove double quotes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d8027691..66c34e7d

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

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

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

From dnguyen at openjdk.org  Wed Jun 18 18:50:29 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 18 Jun 2025 18:50:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
Message-ID: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>

On Tue, 17 Jun 2025 23:15:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove double quotes
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155272483

From duke at openjdk.org  Wed Jun 18 19:25:43 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 19:25:43 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v2]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <Jg0vnfClBHbsDn5YxZO_3K-Jm6EPnMfOuz7lyob1Ll0=.6086906d-0c3a-461b-916d-a2fbe5f0b4bd@github.com>

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

David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Applying read-only configuration for Javac internal use of ZIP/JAR file systems.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/94f36b15..bc2f5232

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

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

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

From duke at openjdk.org  Wed Jun 18 20:08:28 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 20:08:28 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v2]
In-Reply-To: <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>
Message-ID: <cbYOgZ3a5V6igjdDgjbai_97o4UZExy2YIee33V7dk4=.4d62db33-1ff4-4baf-873e-a28c0b64bde8@github.com>

On Wed, 11 Jun 2025 05:43:31 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java line 183:
>> 
>>> 181:      *                       {@code null} to ignore release versioning).
>>> 182:      */
>>> 183:     public static Map<String, ?> readOnlyJarFSEnv(String releaseVersion) {
>> 
>> I named this after the getJarFSProvider() method above, since they are used in close proximity, but would be happy to consider other names.
>
> I am a bit uneasy about having the method static, as this class's API is normally instance methods. I think that an instance of FSInfo (`fsInfo`) is available in both `JavacFileManager` and `Locations`, so it would be better to simply have an instance method. (The static field is OK, that's not an API.)

Interesting idea since it permits per instance changes (e.g. due to flags/environment) later.
However there's no instance (yet) in VerifyCTSymClassFiles. I could mint one though.
Thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2155405134

From duke at openjdk.org  Wed Jun 18 20:19:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 20:19:29 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v2]
In-Reply-To: <ODhtG897tIKEscihyIBRPvuvJ76o9h2Emcj9Z5XxUco=.7af3e222-5304-47d1-8486-ca15699f792a@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
 <ODhtG897tIKEscihyIBRPvuvJ76o9h2Emcj9Z5XxUco=.7af3e222-5304-47d1-8486-ca15699f792a@github.com>
Message-ID: <9SI2Z7TCvCj8WKxUGD1da8E85eTbaF_uItE8u9cW9QI=.60b568ad-743f-4e25-ac78-d6830148fc3e@github.com>

On Wed, 11 Jun 2025 05:48:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This seems like a fallback path, so don't think we should add a no-arg version to promote skipping the release version.
>
> I think just `readOnlyJarFSEnv(null)` is OK.

Left it using `readOnlyJarFSEnv(null)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2155421915

From duke at openjdk.org  Wed Jun 18 20:22:30 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 20:22:30 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v2]
In-Reply-To: <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>
Message-ID: <Pw7n09QuUK-yFrvX4d8u05Uqu7EAjV8qNw4f9NO0ADQ=.be75cf67-24b2-41a5-89ba-d2b86ddf434a@github.com>

On Wed, 11 Jun 2025 05:50:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java line 261:
>> 
>>> 259:                         // If for any reason this was not opened from a ZIP file,
>>> 260:                         // then the resulting file system would not be read-only.
>>> 261:                         assert fs.isReadOnly();
>> 
>> Not sure if an assert is the right thing here or if this should be an always-on runtime check (it can be provoked by having a non-ZIP symbol file, but it's not sanctioned in any way).
>
> We typically don't use `assert` in javac anymore, as it can be disabled. Either the condition is important, then we typically use `com.sun.tools.javac.util.Assert.check`, or we don't do the check. I think using `Assert` here would be appropriate.

Hmmm .... question:

The other place using FSInfo static method was the cySym verifier. And this is the cySym code. So it feels like it would be good to be consistent between both these cases. So is this a place for FSInfo as well, or not?

The advantage of FSInfo is that you can get the JAR provider (which we know is the ZIP provider too) and not have to worry about mismatches between given file and "discovered" file system type. You just only use the JAR provider and you're done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2155427539

From duke at openjdk.org  Wed Jun 18 20:32:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 20:32:12 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v3]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <RYnTSLXp40VfIt6_fWEBgnI2XHEhXyxc3J2OwumtI8s=.69433eef-0034-439d-823b-1d0a917f27b9@github.com>

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

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

  Some (not all) feedback addressed. Still open questions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/bc2f5232..a18a12d3

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

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

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

From duke at openjdk.org  Wed Jun 18 20:32:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 20:32:13 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v2]
In-Reply-To: <Jg0vnfClBHbsDn5YxZO_3K-Jm6EPnMfOuz7lyob1Ll0=.6086906d-0c3a-461b-916d-a2fbe5f0b4bd@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <Jg0vnfClBHbsDn5YxZO_3K-Jm6EPnMfOuz7lyob1Ll0=.6086906d-0c3a-461b-916d-a2fbe5f0b4bd@github.com>
Message-ID: <kbESx9I8m_gk0uiy1LTj5uJ6QPbWwZw4rqan2NV70bo=.b065b027-3745-48b6-bb00-7679148cd0a5@github.com>

On Wed, 18 Jun 2025 19:25:43 GMT, David Beaumont <duke at openjdk.org> wrote:

>> This PR seeks to integrate the new ZipFileSystem "accessMode" parameter to open internal ZIP/JAR files as read only, to act as defense in-depth against accidental modification.
>> 
>> Note that this currently also propagates the (currently undocumented) "zipinfo-time" parameter to several other places where ZIP/JAR files are opened, which is likely to improve performance. This was discussed and is expected to be safe (but it's something to be careful about).
>> This will, of course, be thoroughly tested before integration.
>> 
>> It also unifies several places to use a common helper method to obtain the environment map, adds more comments, and changes a small number of affected tests.
>> 
>> I'm also happy to update the original bug description to include the timestamp related changes as necessary.
>
> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Applying read-only configuration for Javac internal use of ZIP/JAR file systems.

Apologies for the recent force push. I'm having to switch laptops and this is common from a different local repo.

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

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

From duke at openjdk.org  Wed Jun 18 20:32:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 20:32:13 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v3]
In-Reply-To: <npT3xWdShBHMZg7i1-Tuz3F571w69cYg5YY6bKIouL8=.fd1ee85d-0dc2-4ac0-9954-becb984b3f9e@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <8DGz3JE2S5_mnRHPZ20F4H1yF4XHHjjtowdR3_IlWo4=.9be3a569-7992-43ce-b2c5-d9dbdd55b54e@github.com>
 <6mbVbWZf7mqmY1U5hPy-9DjzYn0-eNKfToQkwkzka9A=.5743eb95-287a-43b8-8b2d-9285628aa4d9@github.com>
 <npT3xWdShBHMZg7i1-Tuz3F571w69cYg5YY6bKIouL8=.fd1ee85d-0dc2-4ac0-9954-becb984b3f9e@github.com>
Message-ID: <f-KmLvLt4VTg9sKK6Z7AC_JPykQK_WSpSOv8DURj96c=.ef812114-c458-4ea5-b4c1-bbad996f935b@github.com>

On Wed, 11 Jun 2025 05:45:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> That's an excellent point. I will be sure to ask people if that looks acceptable and revert to the original behaviour otherwise. Thank you for spotting it and saying something.
>
> I think I would prefer to no send the multi release value for non-jar files - possibly there's no observable difference at this time, but the multi-release jar is for jars only.
> 
> (Also the comment above the variable seems a bit superfluous.)

Done. Though the more times I write `readOnlyJarFSEnv(null)` the more I think a no-arg version of that method might carry its weight.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2155432740

From duke at openjdk.org  Wed Jun 18 20:32:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 20:32:13 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v3]
In-Reply-To: <RYnTSLXp40VfIt6_fWEBgnI2XHEhXyxc3J2OwumtI8s=.69433eef-0034-439d-823b-1d0a917f27b9@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <RYnTSLXp40VfIt6_fWEBgnI2XHEhXyxc3J2OwumtI8s=.69433eef-0034-439d-823b-1d0a917f27b9@github.com>
Message-ID: <ploTx5jNn5lQQr25WFI6cOowhRR95C1RIsVC-ixpG28=.f0c365f5-a24b-42d0-a4bd-0e6f1c6ef5d1@github.com>

On Wed, 18 Jun 2025 20:28:25 GMT, David Beaumont <duke at openjdk.org> wrote:

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

test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 60:

> 58:     }
> 59: 
> 60:     private final FSInfo fsInfo = FSInfo.instance(new Context());

I don't think this is actually right unless we make the other cySym code use FSInfo. Happy to hear people's thoughts on this. One benefit here is that we know we've matched the expected ZIP file with the ZIP file system provider, so no need to worry if the environment was going to be honoured.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2155438731

From prr at openjdk.org  Wed Jun 18 20:40:29 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jun 2025 20:40:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>

On Wed, 18 Jun 2025 14:45:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
> 
>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>> 459: SliderDemo.majorticks=Grobteilungen
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 
> Should the translation of `SliderDemo.majorticks` also be updated?

I agree. I'd expect consistency here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155451453

From acobbs at openjdk.org  Wed Jun 18 21:12:12 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 18 Jun 2025 21:12:12 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
Message-ID: <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>

> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
> 
> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
> 
> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.

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

  Ensure that "-Xlint:none" still works for the affected warnings.
  
  The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
  which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
  which allowed the affected warnings to get away with skipping that check.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25840/files
  - new: https://git.openjdk.org/jdk/pull/25840/files/8dcea700..9e788319

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

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

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

From duke at openjdk.org  Thu Jun 19 08:49:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 19 Jun 2025 08:49:03 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v3]
In-Reply-To: <Pw7n09QuUK-yFrvX4d8u05Uqu7EAjV8qNw4f9NO0ADQ=.be75cf67-24b2-41a5-89ba-d2b86ddf434a@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <Gmcr99RgapPay0ZTjtdTG_jdtcdOt2yL9biiNdAL3_Y=.cce8debc-6cdd-45fe-81f0-07a83cdf45de@github.com>
 <Pw7n09QuUK-yFrvX4d8u05Uqu7EAjV8qNw4f9NO0ADQ=.be75cf67-24b2-41a5-89ba-d2b86ddf434a@github.com>
Message-ID: <lQfhDfO90UB4_oFKDcU4dxRD1g6ml4QSfILkQVoWS8o=.734b745d-d758-44a8-8d92-b9d183bd1017@github.com>

On Wed, 18 Jun 2025 20:20:19 GMT, David Beaumont <duke at openjdk.org> wrote:

>> We typically don't use `assert` in javac anymore, as it can be disabled. Either the condition is important, then we typically use `com.sun.tools.javac.util.Assert.check`, or we don't do the check. I think using `Assert` here would be appropriate.
>
> Hmmm .... question:
> 
> The other place using FSInfo static method was the cySym verifier. And this is the cySym code. So it feels like it would be good to be consistent between both these cases. So is this a place for FSInfo as well, or not?
> 
> The advantage of FSInfo is that you can get the JAR provider (which we know is the ZIP provider too) and not have to worry about mismatches between given file and "discovered" file system type. You just only use the JAR provider and you're done.

I removed the FSInfo use in the test, just not worth the dependency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2156481223

From duke at openjdk.org  Thu Jun 19 10:03:35 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 19 Jun 2025 10:03:35 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v3]
In-Reply-To: <ploTx5jNn5lQQr25WFI6cOowhRR95C1RIsVC-ixpG28=.f0c365f5-a24b-42d0-a4bd-0e6f1c6ef5d1@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <RYnTSLXp40VfIt6_fWEBgnI2XHEhXyxc3J2OwumtI8s=.69433eef-0034-439d-823b-1d0a917f27b9@github.com>
 <ploTx5jNn5lQQr25WFI6cOowhRR95C1RIsVC-ixpG28=.f0c365f5-a24b-42d0-a4bd-0e6f1c6ef5d1@github.com>
Message-ID: <Km69bMPc7fiAkfYs8XbwfniRverRqOUvIfRaIqDdzJg=.91f0ea45-1b95-455b-836e-50e9dc8692fe@github.com>

On Wed, 18 Jun 2025 20:28:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some (not all) feedback addressed. Still open questions.
>
> test/langtools/tools/javac/platform/VerifyCTSymClassFiles.java line 60:
> 
>> 58:     }
>> 59: 
>> 60:     private final FSInfo fsInfo = FSInfo.instance(new Context());
> 
> I don't think this is actually right unless we make the other cySym code use FSInfo. Happy to hear people's thoughts on this. One benefit here is that we know we've matched the expected ZIP file with the ZIP file system provider, so no need to worry if the environment was going to be honoured.

I changed both case (test and code) to NOT use FSInfo now. The dependency and extra code (esp. now the method is an instance method) just doesn't seem worth it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2156621191

From duke at openjdk.org  Thu Jun 19 10:03:34 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 19 Jun 2025 10:03:34 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v3]
In-Reply-To: <qDmAteIL8rb8qlVWat6Lr7yMMOHbse5cjkpbiabOdlA=.de38522c-666e-4b9f-ab1e-95107d2cb51a@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
 <3dqpBxBqg3tZyqrL5dXJIgcp7IpFVdC_OTdvZImNRCE=.10ef42b5-1c05-4104-b8a2-7edb4579fb49@github.com>
 <vEWUCpbY8ZWFy3FN-NLg9tHfBh9zX1ABvY2ve3ekpGs=.d7dc8936-a519-43d0-963f-b3c271815c1f@github.com>
 <qDmAteIL8rb8qlVWat6Lr7yMMOHbse5cjkpbiabOdlA=.de38522c-666e-4b9f-ab1e-95107d2cb51a@github.com>
Message-ID: <ubihJuwAIzbK3hUuxA_fY4Pf9GgKAN48fgnPksmpknk=.eff7fc3e-41c5-4710-843b-ffdd5629ac03@github.com>

On Wed, 11 Jun 2025 06:01:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Also for compile on-the-fly, I usually use `InMemoryJavaCompiler` and `ByteCodeLoader` available with `/test/lib` library. `InMemoryJavaCompiler` conveniently returns a list of all class files, and its one-class-file version throws an exception if a compilation unit generates more than one class, which is not usually checked by manual invocations to javac task.
>
> For new tests, I would often prefer to use on-the-fly compilation (although javac has its own frameworks to do that, like the `ToolBox` used here).
> 
> For existing tests, I generally prefer to restrict changes to a minimum (although opinions may differ on that).
> 
> But here, I wonder: why is the test failing? I didn't see anything in the patch that would seem to be an obvious cause of a breakage of a test like this. So, I think it deserves a good look to find out what's the cause of the test failing, rather than just adjusting the test to pass.

When I revert to the original code, I get:


java.lang.NullPointerException: Cannot invoke "java.io.InputStream.readAllBytes()" because the return value of "java.lang.Class.getResourceAsStream(String)" is null
	at ClassRefDupInConstantPoolTest.main(ClassRefDupInConstantPoolTest.java:40)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)

JavaTest Message: Test threw exception: java.lang.NullPointerException: Cannot invoke "java.io.InputStream.readAllBytes()" because the return value of "java.lang.Class.getResourceAsStream(String)" is null
JavaTest Message: shutting down test


when running via IntelliJ, but it passes when running via make. So there's some fragility with the environment.

I probably didn't realize originally that this was conditionally failing, so just changed it on the assumption that it was failing everywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2156617412

From uschindler at openjdk.org  Thu Jun 19 10:06:45 2025
From: uschindler at openjdk.org (Uwe Schindler)
Date: Thu, 19 Jun 2025 10:06:45 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
Message-ID: <4aNvlXdaqRGTIpcPu0jTaVh8iazGgw847cC2b3UaJZk=.9451508c-c2f0-4f50-99b7-adb76765e3a3@github.com>

On Wed, 18 Jun 2025 21:12:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure that "-Xlint:none" still works for the affected warnings.
>   
>   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>   which allowed the affected warnings to get away with skipping that check.

Marked as reviewed by uschindler (Author).

Adding `isDisabled()` looks fine to me.

Possibly at a later stage we should centralize all the handling using an EnumSet which is populated only once before the compiler is invoked.

The behaviour should be documented in the javac documentation.

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

PR Review: https://git.openjdk.org/jdk/pull/25840#pullrequestreview-2942371244
PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2987502404

From duke at openjdk.org  Thu Jun 19 10:25:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 19 Jun 2025 10:25:32 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v3]
In-Reply-To: <ubihJuwAIzbK3hUuxA_fY4Pf9GgKAN48fgnPksmpknk=.eff7fc3e-41c5-4710-843b-ffdd5629ac03@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <LWyIc7p0RElDUCYyaN5TnC8E0kokDH6lsPy-RSQwMmg=.3b64bb73-2216-40c4-af0e-2e0fcc6c6bb4@github.com>
 <0jERTZaUS1hHHjN-dI06DBX6LAUR2BOUHGCs_fB7w78=.bc754112-9edf-4fb4-affe-f9740654f35a@github.com>
 <3dqpBxBqg3tZyqrL5dXJIgcp7IpFVdC_OTdvZImNRCE=.10ef42b5-1c05-4104-b8a2-7edb4579fb49@github.com>
 <vEWUCpbY8ZWFy3FN-NLg9tHfBh9zX1ABvY2ve3ekpGs=.d7dc8936-a519-43d0-963f-b3c271815c1f@github.com>
 <qDmAteIL8rb8qlVWat6Lr7yMMOHbse5cjkpbiabOdlA=.de38522c-666e-4b9f-ab1e-95107d2cb51a@github.com>
 <ubihJuwAIzbK3hUuxA_fY4Pf9GgKAN48fgnPksmpknk=.eff7fc3e-41c5-4710-843b-ffdd5629ac03@github.com>
Message-ID: <5IYapq2-4W6S11OzlQ_mduDNIUsNC61oOl2Y1eva3y0=.35a840bb-24e4-497d-bbef-07dd9332a777@github.com>

On Thu, 19 Jun 2025 09:56:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> For new tests, I would often prefer to use on-the-fly compilation (although javac has its own frameworks to do that, like the `ToolBox` used here).
>> 
>> For existing tests, I generally prefer to restrict changes to a minimum (although opinions may differ on that).
>> 
>> But here, I wonder: why is the test failing? I didn't see anything in the patch that would seem to be an obvious cause of a breakage of a test like this. So, I think it deserves a good look to find out what's the cause of the test failing, rather than just adjusting the test to pass.
>
> When I revert to the original code, I get:
> 
> 
> java.lang.NullPointerException: Cannot invoke "java.io.InputStream.readAllBytes()" because the return value of "java.lang.Class.getResourceAsStream(String)" is null
> 	at ClassRefDupInConstantPoolTest.main(ClassRefDupInConstantPoolTest.java:40)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1474)
> 
> JavaTest Message: Test threw exception: java.lang.NullPointerException: Cannot invoke "java.io.InputStream.readAllBytes()" because the return value of "java.lang.Class.getResourceAsStream(String)" is null
> JavaTest Message: shutting down test
> 
> 
> when running via IntelliJ, but it passes when running via make. So there's some fragility with the environment.
> 
> I probably didn't realize originally that this was conditionally failing, so just changed it on the assumption that it was failing everywhere.

I have just verified that syncing back to master causes this test to fail when run via IntelliJ, so it's been "broken" for a while (whether it is at fault, or something in the way IntelliJ runs tests is at fault, I'm not sure). I'll revert it in this PR then, since it's not related to my change (I guess I just stumbled over the break and thought it was, so fixed it). Thanks for getting me to dig deeper.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25639#discussion_r2156667328

From duke at openjdk.org  Thu Jun 19 10:31:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 19 Jun 2025 10:31:00 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v4]
In-Reply-To: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
Message-ID: <3HXp5UsuYa3TjzqYNHEBi3hX0KETQHPvpwXWkRIdAB8=.ae147e5d-440d-485b-9ed0-1a3245f7c838@github.com>

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

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

  Reverted test (not caused by this PR).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25639/files
  - new: https://git.openjdk.org/jdk/pull/25639/files/a18a12d3..ab5e98da

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

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

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

From nbenalla at openjdk.org  Thu Jun 19 10:53:01 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 19 Jun 2025 10:53:01 GMT
Subject: RFR: 8358769: Update --release 25 symbol information for JDK 25
 build 26 [v2]
In-Reply-To: <9e4lpuzQgaUx4FzFViyYsCueupHsL5boy4Vrv8GPDVM=.41fa0344-6b19-454c-9c49-f7c8682ed867@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
 <9e4lpuzQgaUx4FzFViyYsCueupHsL5boy4Vrv8GPDVM=.41fa0344-6b19-454c-9c49-f7c8682ed867@github.com>
Message-ID: <vLOygUsA70UIj9DfB87fVI4BaaFWt19yNWON2tqmsM0=.edce6c9b-2bc7-49ce-a7c0-2e5fb82e9f53@github.com>

On Wed, 18 Jun 2025 16:26:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Usual symbol file update for a new JDK build.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update --release 25 symbol information for JDK 25 build 26
>    The macOS/AArch64 build 26 was taken from https://jdk.java.net/25/
>  - Revert "Update --release 25 symbol information for JDK 25 build 27"
>    
>    This reverts commit e576baf674dc58e6727c9d56613d177f2a0f919c.

Thanks Joe, Iris.

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

PR Comment: https://git.openjdk.org/jdk/pull/25854#issuecomment-2987600074

From nbenalla at openjdk.org  Thu Jun 19 10:53:02 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 19 Jun 2025 10:53:02 GMT
Subject: Integrated: 8358769: Update --release 25 symbol information for JDK 25
 build 26
In-Reply-To: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
References: <DhcT9Ps1OIw3DRT1SatdNc4kwyhqXAhL41_NbxPy87M=.0c476938-8569-4d16-a8af-74ebfbf81a31@github.com>
Message-ID: <_qRryK2XiccNY5SomroqUHtwoBCbFG0hwCJ-BR5U7Ao=.ca669d60-2729-497b-b3d6-9c222229c0d4@github.com>

On Tue, 17 Jun 2025 15:20:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

This pull request has now been integrated.

Changeset: c4fb00a7
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf
Stats:     110 lines in 4 files changed: 110 ins; 0 del; 0 mod

8358769: Update --release 25 symbol information for JDK 25 build 26

Reviewed-by: darcy, iris

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

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

From duke at openjdk.org  Thu Jun 19 11:24:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 19 Jun 2025 11:24:54 GMT
Subject: RFR: 8356645: Javac should utilize new ZIP file system read-only
 access mode [v4]
In-Reply-To: <3HXp5UsuYa3TjzqYNHEBi3hX0KETQHPvpwXWkRIdAB8=.ae147e5d-440d-485b-9ed0-1a3245f7c838@github.com>
References: <5yjDLWBE6n-ohHaVDKP_tNK25zwYFbvyfQlF3RfAdtQ=.8577edc0-4978-42e0-851a-2e72a3c529b4@github.com>
 <3HXp5UsuYa3TjzqYNHEBi3hX0KETQHPvpwXWkRIdAB8=.ae147e5d-440d-485b-9ed0-1a3245f7c838@github.com>
Message-ID: <yApKaSvGpRh6agcE1GY3IuJC2CP8RsrGFMBK1T_lSJ0=.b1089a71-2713-4f69-a964-6fcc46cd5b2f@github.com>

On Thu, 19 Jun 2025 10:31:00 GMT, David Beaumont <duke at openjdk.org> wrote:

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

Opened https://bugs.openjdk.org/browse/JDK-8360022 for the weird failing test thing (it was @cleanup, good call whoever suggested that!).

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

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

From duke at openjdk.org  Thu Jun 19 17:42:30 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 19 Jun 2025 17:42:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>

On Wed, 18 Jun 2025 15:25:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
> 
>> 181: size.bit.alg=%1$d-Bit-%2$s
>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
> 
> It feels as if there's something missing after _?einem?_.

seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2157444024

From davidalayachew at gmail.com  Fri Jun 20 23:00:29 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 20 Jun 2025 19:00:29 -0400
Subject: Can we get compiler warnings for empty catch blocks?
Message-ID: <CAA9v-_MzD4JT+Je-kJgiqM=cf5ufkFxuvSfo8zosAA=8EWfq1Q@mail.gmail.com>

I got burned pretty bad today because of a large number of empty catch
blocks.

If a compiler warning is not feasible or not a good idea, that's fine.

But please let me know -- whether yes, no, or otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250620/bfdf2576/attachment.htm>

From chen.l.liang at oracle.com  Fri Jun 20 23:11:23 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 20 Jun 2025 23:11:23 +0000
Subject: Can we get compiler warnings for empty catch blocks?
In-Reply-To: <CAA9v-_MzD4JT+Je-kJgiqM=cf5ufkFxuvSfo8zosAA=8EWfq1Q@mail.gmail.com>
References: <CAA9v-_MzD4JT+Je-kJgiqM=cf5ufkFxuvSfo8zosAA=8EWfq1Q@mail.gmail.com>
Message-ID: <SJ2PR10MB766983BADFCE63E32569557AA27CA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Empty catch blocks serve a purpose: They aim to catch the type of exception from the try block, and continue execution from immediately after the try-catch statement. As Brian Goetz often says, let's first look at the problem instead of a solution. What prompted you to write those empty catch blocks at first?
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Friday, June 20, 2025 6:00 PM
To: compiler-dev <compiler-dev at openjdk.org>
Subject: Can we get compiler warnings for empty catch blocks?

I got burned pretty bad today because of a large number of empty catch blocks.

If a compiler warning is not feasible or not a good idea, that's fine.

But please let me know -- whether yes, no, or otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250620/9f90c405/attachment-0001.htm>

From davidalayachew at gmail.com  Fri Jun 20 23:18:25 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 20 Jun 2025 19:18:25 -0400
Subject: Can we get compiler warnings for empty catch blocks?
In-Reply-To: <SJ2PR10MB766983BADFCE63E32569557AA27CA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CAA9v-_MzD4JT+Je-kJgiqM=cf5ufkFxuvSfo8zosAA=8EWfq1Q@mail.gmail.com>
 <SJ2PR10MB766983BADFCE63E32569557AA27CA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_MA7x0vjOgr46-feXtv_LMgnwaFugXm41pkLYqh6xWC6w@mail.gmail.com>

Oh I agree they serve a purpose. But I think the default is on the wrong
side. I think it should warn by default, and let me supress warnings if it
indeed is intentional. That's why I am suggesting this compiler warning --
to allow me to opt-in to switching the default.

I was not the one who wrote the empty catches. But I am finding that each
one was a mistake of some sort. For almost every one, we could have logged
it at least. Leaving them empty was wrong in almost every single instance I
found.

And the folks who committed most of these were intern-level devs -- devs
who don't know the difference between static and instance.

Now that I am playing clean up, I wanted to make it easier to just bring
all these (likely) problematic empty catch blocks to the surface, then put
a SuppressWarnings on each one that actually SHOULD be empty (yet to find
one, but I concede that is possible).

On Fri, Jun 20, 2025, 7:11?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Empty catch blocks serve a purpose: They aim to catch the type of
> exception from the try block, and continue execution from immediately after
> the try-catch statement. As Brian Goetz often says, let's first look at the
> problem instead of a solution. What prompted you to write those empty catch
> blocks at first?
> ------------------------------
> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Friday, June 20, 2025 6:00 PM
> *To:* compiler-dev <compiler-dev at openjdk.org>
> *Subject:* Can we get compiler warnings for empty catch blocks?
>
> I got burned pretty bad today because of a large number of empty catch
> blocks.
>
> If a compiler warning is not feasible or not a good idea, that's fine.
>
> But please let me know -- whether yes, no, or otherwise.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250620/fa241fd7/attachment.htm>

From davidalayachew at gmail.com  Sat Jun 21 01:53:18 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 20 Jun 2025 21:53:18 -0400
Subject: Can we get compiler warnings for empty catch blocks?
In-Reply-To: <CAFXXopMXKoKpsaSXy3yY2UHsf2LJm9vkiAOqE9Yroxa8JuhAuA@mail.gmail.com>
References: <CAA9v-_MzD4JT+Je-kJgiqM=cf5ufkFxuvSfo8zosAA=8EWfq1Q@mail.gmail.com>
 <SJ2PR10MB766983BADFCE63E32569557AA27CA@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_MA7x0vjOgr46-feXtv_LMgnwaFugXm41pkLYqh6xWC6w@mail.gmail.com>
 <CAFXXopMXKoKpsaSXy3yY2UHsf2LJm9vkiAOqE9Yroxa8JuhAuA@mail.gmail.com>
Message-ID: <CAA9v-_OWC5cZO0Uo0ybR2u7AFdy+=LmwcCg6__fkoho0KYUfoQ@mail.gmail.com>

Thanks Manu. I do have a few ways around this, but I like your idea the
best.

Still, I think this problem is significant enough and common enough that we
are justified by putting it in the compiler warning list.


On Fri, Jun 20, 2025, 9:50?PM Manu Sridharan <manu at sridharan.net> wrote:

> Hi David, FYI Error Prone has a check for this:
>
> https://errorprone.info/bugpattern/EmptyCatch
>
> Best,
> Manu
>
> On Jun 21, 2025 at 08:18:25, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Oh I agree they serve a purpose. But I think the default is on the wrong
>> side. I think it should warn by default, and let me supress warnings if it
>> indeed is intentional. That's why I am suggesting this compiler warning --
>> to allow me to opt-in to switching the default.
>>
>> I was not the one who wrote the empty catches. But I am finding that each
>> one was a mistake of some sort. For almost every one, we could have logged
>> it at least. Leaving them empty was wrong in almost every single instance I
>> found.
>>
>> And the folks who committed most of these were intern-level devs -- devs
>> who don't know the difference between static and instance.
>>
>> Now that I am playing clean up, I wanted to make it easier to just bring
>> all these (likely) problematic empty catch blocks to the surface, then put
>> a SuppressWarnings on each one that actually SHOULD be empty (yet to find
>> one, but I concede that is possible).
>>
>> On Fri, Jun 20, 2025, 7:11?PM Chen Liang <chen.l.liang at oracle.com> wrote:
>>
>>> Empty catch blocks serve a purpose: They aim to catch the type of
>>> exception from the try block, and continue execution from immediately after
>>> the try-catch statement. As Brian Goetz often says, let's first look at the
>>> problem instead of a solution. What prompted you to write those empty catch
>>> blocks at first?
>>> ------------------------------
>>> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David
>>> Alayachew <davidalayachew at gmail.com>
>>> *Sent:* Friday, June 20, 2025 6:00 PM
>>> *To:* compiler-dev <compiler-dev at openjdk.org>
>>> *Subject:* Can we get compiler warnings for empty catch blocks?
>>>
>>> I got burned pretty bad today because of a large number of empty catch
>>> blocks.
>>>
>>> If a compiler warning is not feasible or not a good idea, that's fine.
>>>
>>> But please let me know -- whether yes, no, or otherwise.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250620/f2015642/attachment.htm>

From henryjen at openjdk.org  Mon Jun 23 07:34:32 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Jun 2025 07:34:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
Message-ID: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>

On Wed, 18 Jun 2025 01:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
> 
>> 1: #
> 
> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
If that was intentionally left out, I don't see new reason to add them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2160914804

From mcimadamore at openjdk.org  Mon Jun 23 09:26:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 09:26:29 GMT
Subject: RFR: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
Message-ID: <eoW7f4AAzSUpAxBV8EfSTha5qQ_EeCX6wvb35ibbA_w=.13974ecf-b069-4dec-9c65-d6156ce5dcb8@github.com>

On Tue, 17 Jun 2025 10:01:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> 
> public class Main {
> 
>     private boolean test(String s, int i) {
>         if (s.subSequence(0, 1) instanceof Runnable r) {
>             return true;
>         }
> 
>         Integer dummy;
>         switch (i) {
>             case 0:
>                 String clashing = null;
>                 return true;
>             default:
>                 return true;
>         }
>     }
> 
>     public static void main(String[] args) {
>     }
> }
> 
> 
> javac will produce code that won't (rightfully) pass the verifier:
> 
> 
> $ java Main.java
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 49
> Exception Details:
>   Location:
>     Main.test(Ljava/lang/String;I)Z @49: iconst_1
>   Reason:
>     Type top (current frame, locals[4]) is not assignable to 'java/lang/String' (stack map, locals[4])
>   Current Frame:
>     bci: @25
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer }
>     stack: { integer }
>   Stackmap Frame:
>     bci: @49
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer, top, 'java/lang/String' }
>     stack: { }
>   Bytecode:
>     0000000: 2b03 04b6 0007 3a04 1904 c100 0d99 000b
>     0000010: 1904 c000 0d4e 04ac 1cab 0000 0000 0018
>     0000020: 0000 0001 0000 0000 0000 0013 013a 0404
>     0000030: ac04 ac
>   Stackmap Table:
>     same_frame(@24)
>     same_frame(@44)
>     append_frame(@49,Top,Object[#8])
> 
>         at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>         at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3035)
>         at java.base/java.lang.Class.getMethodsRecursive(Class.java:3177)
>         at java.base/java.lang.Class.findMethod(Class.java:2465)
>         at java.base/java.lang.System$1.findMethod(System.java:1980)
>         at java.base/jdk.internal.misc.MethodFinder.findMainMethod(MethodFinder.java:86)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:194)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> 
> 
> 
> Now, the problem, as far as I can tell, is this: javac will desugar the pattern matching instanceof along the lines of:
> 
> 
> if (... (var $temp = s.subSequence(0, 1) in ... && ...) ...) {
>     return true;
> }
> 
> 
> (`$temp` is register/local variable number 4)
> specifically, note the `&&` in the middle of the let expression, and that the expression is in the conditional position. What happens here is...

Pesky issue and a relatively clean solution (given the circumstances). I tend to agree with how the fix decided to treat this as a special case for when let expressions are used inside a conditional, which seems to be where the issue really stems from.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25849#pullrequestreview-2949331976
PR Review: https://git.openjdk.org/jdk/pull/25849#pullrequestreview-2949333331

From mcimadamore at openjdk.org  Mon Jun 23 09:40:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 09:40:29 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <LcEoVsxAHJTghFEROpfBJsdkzKUQEVQua6DeJ0n_jj4=.15fad2c5-721d-4fc6-9dd3-e02223d51842@github.com>

On Fri, 13 Jun 2025 21:25:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

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

> 1: /*

The changes in this class are really really good! Lot of complex, coupled, stateful code disappears :-)

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

> 246:             }
> 247:         }
> 248:         Optional.ofNullable(warningKey)

I think I'd prefer a regular `if (warningKey != null) { log.mandatoryWarning(...) }`, as it seems generally "flatter".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161163126
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161161816

From mcimadamore at openjdk.org  Mon Jun 23 09:51:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 09:51:29 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>

On Fri, 13 Jun 2025 21:25:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractLog.java line 165:

> 163:      * @param flags      Any additional flags required
> 164:      */
> 165:     public void warning(Warning warningKey, DiagnosticFlag... flags) {

I'm not sure about these changes to the `warning` method. The reason being that this PR doesn't seem to require such changes. And note that, with this change, all calls to `Log.warning` become variadic -- meaning the compiler will have to at least allocate an empty array. I'm not sure if this is enough to cause a regression, but if not necessary, I'd prefer to revert these changes, also noting that `error` and `note` have variants that do not accept flags.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractLog.java line 197:

> 195:      *  @param flags         Any additional flags required
> 196:      */
> 197:     public void mandatoryWarning(DiagnosticPosition pos, Warning warningKey, DiagnosticFlag... flags) {

Note: this method is already some kind of special wrapper around `Log.warning` which always sets the mandatory flag. I wonder if, maybe, we could just tweak this method to take a boolean parameter telling whether to aggregate or not, and then deal with the flags internally?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161185696
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161188294

From mcimadamore at openjdk.org  Mon Jun 23 09:56:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 09:56:29 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <OigdjhBmlsSNRNTm7oXPvsJ8e7_Lw4mabrn9dzL9tj4=.979f435d-70a4-42bc-8de8-c705fc05e827@github.com>

On Fri, 13 Jun 2025 21:25:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

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

> 734:     private MandatoryWarningAggregator aggregatorFor(LintCategory lc) {
> 735:         return switch (lc) {
> 736:         case PREVIEW -> aggregators.computeIfAbsent(lc, c -> new MandatoryWarningAggregator(this, Source.instance(context), c));

Can we save `Source` as an instance variable? I'm mildly worried about using the `context` instance field (which is used for lazy init of lint) more generally. (In fact, I was even thinking if it would make sense to have a `Supplier<Lint>` field that we create at construction, so that we don't have to save the `context` field at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161196847

From mcimadamore at openjdk.org  Mon Jun 23 10:08:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 10:08:33 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <0pYP228v4Z4tuKG5hoBtin9GlqfWiMB88mdtwcW6iyU=.2f794453-5402-4187-84e0-01730c200a2c@github.com>

On Fri, 13 Jun 2025 21:25:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

Great work as usual. Moving the aggregation logic to `Log` seems generally a big win, both for clients and for us, as it seems generally easier, in the new code, to guarantee that all mandatory warnings get the same treatment.

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

> 729:           .flatMap(List::stream)
> 730:           .forEach(this::report);
> 731:         aggregators.clear();

Is there a "cleanup race" here? E.g. this method clears the aggregator enum map. But then Log.clear walks that map and calls `clear` on each aggregator -- but if the map is empty, nothing will get cleared?

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

PR Review: https://git.openjdk.org/jdk/pull/25810#pullrequestreview-2949469743
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161219923

From mcimadamore at openjdk.org  Mon Jun 23 10:09:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 10:09:32 GMT
Subject: RFR: 8357653: Inner classes of type parameters emitted as raw
 types in signatures [v3]
In-Reply-To: <2DjQ7MlMm-D4rLQvz3DeiweScikQtFbyHp45bkugqJo=.6f1db873-ab62-4195-9bfc-8181b92ae6c8@github.com>
References: <88WZWO6ABOT7C3R28rIU42iiusiMTUNVGqT4ghO_qwc=.ae506eca-2e06-45a1-a958-91232bd95704@github.com>
 <2DjQ7MlMm-D4rLQvz3DeiweScikQtFbyHp45bkugqJo=.6f1db873-ab62-4195-9bfc-8181b92ae6c8@github.com>
Message-ID: <DkwKH5TJjgDyR3NkYaibWdfJTnYr6iF0q5ez_bry9JA=.cc508275-5069-4a4b-9aeb-88c6543a3856@github.com>

On Wed, 11 Jun 2025 14:56:24 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 th...
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused field in test

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25451#pullrequestreview-2949472693

From mcimadamore at openjdk.org  Mon Jun 23 10:29:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 10:29:28 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
Message-ID: <1rWPe9ptxdXmPJP2nDKVMeKw5mmtg0kqxPEMMbB9Ls4=.915a3688-ec96-4e7a-ac37-9bcb99f7ddff@github.com>

On Wed, 18 Jun 2025 21:12:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure that "-Xlint:none" still works for the affected warnings.
>   
>   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>   which allowed the affected warnings to get away with skipping that check.

I generally agree with these changes, but I'm not sure that the code in `Lint` (which is not shown in this diff as it has not changed) really adheres to the policy described in the JBS issue that "last option should win". What Lint seems to do is to compute an *initial* set, like follows:

* if `none` is found, start from the empty set
* if `all` is found, start from the "everything" set
* if neither is found, start from a "predefined" set which contains some default categories

After that, the initial set is augmented (or reduced) based on the explicit enable/disable options.

I see at least two issues in this logic:

* how is the initial set determined if both `all` and `none` are specified? The "last win" policy might suggest that we use the last of these to determine the initial set, but the code doesn't do that, and I think it gives precedence to `all`.
* what if the same category is both enabled and disabled? Well, again, the code doesn't really apply a "last win" policy -- instead, for each category, we do this:


// Look for specific overrides
        for (LintCategory lc : LintCategory.values()) {
            if (options.isExplicitlyEnabled(Option.XLINT, lc)) {
                values.add(lc);
            } else if (options.isExplicitlyDisabled(Option.XLINT, lc)) {
                values.remove(lc);
            }
        }

That is, for each category we check if it's enabled -- if so we add it to the set. Otherwise if it's disabled, we remove it from the set. So, if a category is both enabled and disabled, it looks like the code should just treat it as enabled?

So, I'm not sure how this fix (or even the previous code, before we changed any of this) adheres/adhered to the "last win" policy?

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

PR Review: https://git.openjdk.org/jdk/pull/25840#pullrequestreview-2949529576

From mcimadamore at openjdk.org  Mon Jun 23 10:49:30 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 10:49:30 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
Message-ID: <3lLb1xUhmzIJkBosRf7n5GANdHlLFhcT726MoIi_oCk=.30612b8e-d644-40e7-8be6-aab03b9d1222@github.com>

On Wed, 18 Jun 2025 21:12:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure that "-Xlint:none" still works for the affected warnings.
>   
>   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>   which allowed the affected warnings to get away with skipping that check.

> I generally agree with these changes, but I'm not sure that the code in `Lint` (which is not shown in this diff as it has not changed) really adheres to the policy described in the JBS issue that "last option should win". What Lint seems to do is to compute an _initial_ set, like follows:
> 
>     * if `none` is found, start from the empty set
> 
>     * if `all` is found, start from the "everything" set
> 
>     * if neither is found, start from a "predefined" set which contains some default categories
> 
> 
> After that, the initial set is augmented (or reduced) based on the explicit enable/disable options.
> 
> I see at least two issues in this logic:
> 
>     * how is the initial set determined if both `all` and `none` are specified? The "last win" policy might suggest that we use the last of these to determine the initial set, but the code doesn't do that, and I think it gives precedence to `all`.
> 
>     * what if the same category is both enabled and disabled? Well, again, the code doesn't really apply a "last win" policy -- instead, for each category, we do this:
> 
> 
> ```
> // Look for specific overrides
>         for (LintCategory lc : LintCategory.values()) {
>             if (options.isExplicitlyEnabled(Option.XLINT, lc)) {
>                 values.add(lc);
>             } else if (options.isExplicitlyDisabled(Option.XLINT, lc)) {
>                 values.remove(lc);
>             }
>         }
> ```
> 
> That is, for each category we check if it's enabled -- if so we add it to the set. Otherwise if it's disabled, we remove it from the set. So, if a category is both enabled and disabled, it looks like the code should just treat it as enabled?
> 
> So, I'm not sure how this fix (or even the previous code, before we changed any of this) adheres/adhered to the "last win" policy?

Ok, I see that this change only really affects how `options` behave (and few other lint warnings). After debugging, I can clearly see that my analysis above is correct, and that the way in which the set of enabled lint warnings is computed does NOT conform to a "last win" policy. So, if you compile the code below with `-Xlint:unchecked -Xlint:-unchecked`:


class Test<X> {
    static void m(Test t) {
        Test<String> ts = t;
    }
}


It does print the lint warning (meaning that `Werror` would make this fail, even though the last `lint` command passed disables unchecked warnings).

So, the real fix of this PR is in using `isDisabled` instead of `isExplicitlyDisabled`. But I must notice that this carves out a special expection for `options` and `path` lint warnings -- whereas every other lint warning will not resolve "conflicts"  in the same way.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2995926729

From acobbs at openjdk.org  Mon Jun 23 13:30:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 13:30:29 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <3lLb1xUhmzIJkBosRf7n5GANdHlLFhcT726MoIi_oCk=.30612b8e-d644-40e7-8be6-aab03b9d1222@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
 <3lLb1xUhmzIJkBosRf7n5GANdHlLFhcT726MoIi_oCk=.30612b8e-d644-40e7-8be6-aab03b9d1222@github.com>
Message-ID: <jNu2UMjRCTSxV2qUfP2ySNbkfVcSY4cfaOV6xxRno0I=.916ff0c0-b45c-48ce-ac8d-14fa2aba0247@github.com>

On Mon, 23 Jun 2025 10:46:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, the real fix of this PR is in using `isDisabled` instead of `isExplicitlyDisabled`. But I must notice that this carves out a special expection for `options` and `path` lint warnings -- whereas every other lint warning will not resolve "conflicts" in the same way.

Correct - because that "carve out" was already there in the previous behavior, and the whole point of this patch is to restore that previous behavior.

Some lint warnings simply don't follow the normal enable/disable logic (which you normally get by using `Lint.logIfEnabled()`) and this is one of them. It would be nice to eliminate these special exceptions over time, but (as revealed by the associated bug) doing so breaks expectations that are built into various folks' build processes. So it's a nice thought but obviously outside of the scope of this PR.

Instead, what I'm trying to do now (in upcoming PR #24584) is simply make these special cases more explicit in the code using new `DiagnosticFlag`'s; see for example [this change](https://github.com/archiecobbs/jdk/blob/982d2b8589a96f83507e7821caf177b0ce51c306/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L580-L585).

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2996505310

From acobbs at openjdk.org  Mon Jun 23 13:50:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 13:50:29 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <OigdjhBmlsSNRNTm7oXPvsJ8e7_Lw4mabrn9dzL9tj4=.979f435d-70a4-42bc-8de8-c705fc05e827@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <OigdjhBmlsSNRNTm7oXPvsJ8e7_Lw4mabrn9dzL9tj4=.979f435d-70a4-42bc-8de8-c705fc05e827@github.com>
Message-ID: <onWoqe8gaKPfbMluxfi5ZZLBhN41_Yg8mldGQHbyqtE=.df8316da-97a5-4194-85e6-3f70a2bac532@github.com>

On Mon, 23 Jun 2025 09:52:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Can we save `Source` as an instance variable? I'm mildly worried about using the `context` instance field (which is used for lazy init of lint) more generally. (In fact, I was even thinking if it would make sense to have a `Supplier<Lint>` field that we create at construction, so that we don't have to save the `context` field at all.

I guess I don't understand the issue - isn't this kind of usage the whole point of having a `Context` singleton?

We can certainly grab the reference to `Source` eagerly (which means sometimes we would be grabbing it unnecessarily - i.e., any time there are no preview warnings) but beyond that I'm not sure what additional changes would buy us.

Put another way: what are you trying to optimize for with that question? How would `Supplier<Lint>` be better than a `Context` (plus `Lint.instance()`) which is the more standard way to achieve the same thing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161684795

From mcimadamore at openjdk.org  Mon Jun 23 14:19:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 14:19:29 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
Message-ID: <tS09dK0SdPQ6l8qwdCgPLiGbtBpyIy6P0JC-TpavFBc=.6de63d84-0f35-4e27-aa0b-7d8c9d28be75@github.com>

On Wed, 18 Jun 2025 21:12:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure that "-Xlint:none" still works for the affected warnings.
>   
>   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>   which allowed the affected warnings to get away with skipping that check.

Ok, I now see that https://github.com/openjdk/jdk/pull/24746 did essentially two things:
1. introduced aliases to lint categories -- this resulted in having a new method `Options:;isExplicilyEnabled/Disabled` to check all possible aliases for a lint option.
2. consequently replace calls to `options.isSet(Option.XLINT_CUSTOM, lc.option)` with `options.isExplicitlyEnabled(Option.XLINT, lc)`

Part (2) is what created the issue, because by replacing `isSet/Unset` with `isExplicitEnabled/Disabled` we ended up changing behavior: the `isExplicitEnabled/Disabled` methods depend on a new `Options::isSet` method that takes a default value, and also look into stuff like `-Xlint:none/all` (which didn't happen before).

So, this PR reverts the behavioral changes, by having `isExplicitEnabled/Disabled` behave more like `isSet/isUnset` used to work previously, which seems ok.

I have to admit I don't really get why `isExplicitEnabled/Disabled` takes an `Option` parameter -- I see them always invoked with `Option.XLINT`. Because of that, I'm not even sure they belong much in `Options` at all -- an instance method on `LintCategory` which accepts `Options` would perhaps look simpler for clients?

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2996677326

From mcimadamore at openjdk.org  Mon Jun 23 14:19:29 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 14:19:29 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <tS09dK0SdPQ6l8qwdCgPLiGbtBpyIy6P0JC-TpavFBc=.6de63d84-0f35-4e27-aa0b-7d8c9d28be75@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
 <tS09dK0SdPQ6l8qwdCgPLiGbtBpyIy6P0JC-TpavFBc=.6de63d84-0f35-4e27-aa0b-7d8c9d28be75@github.com>
Message-ID: <4EXL4LYVS8YnOql2bTPA3HV9IHa-QK6bYn-9Lyih6Y4=.3fd99414-e040-4f5c-8e78-9ed0ee7810ae@github.com>

On Mon, 23 Jun 2025 14:15:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I have to admit I don't really get why `isExplicitEnabled/Disabled` takes an `Option` parameter -- I see them always invoked with `Option.XLINT`. Because of that, I'm not even sure they belong much in `Options` at all -- an instance method on `LintCategory` which accepts `Options` would perhaps look simpler for clients?

Note: the same is true for the new methods `isEnabled`/`isDisabled` added in this PR -- they feel `Lint`-specific methods to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2996681845

From mcimadamore at openjdk.org  Mon Jun 23 14:26:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 14:26:28 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <onWoqe8gaKPfbMluxfi5ZZLBhN41_Yg8mldGQHbyqtE=.df8316da-97a5-4194-85e6-3f70a2bac532@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <OigdjhBmlsSNRNTm7oXPvsJ8e7_Lw4mabrn9dzL9tj4=.979f435d-70a4-42bc-8de8-c705fc05e827@github.com>
 <onWoqe8gaKPfbMluxfi5ZZLBhN41_Yg8mldGQHbyqtE=.df8316da-97a5-4194-85e6-3f70a2bac532@github.com>
Message-ID: <C1g5oE3bd4JgZOO0xtI3dmXhVnPBAV-dh5yZXjypc6s=.bf9d2946-dc98-45ae-b6a9-df67e995c62c@github.com>

On Mon, 23 Jun 2025 13:48:06 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 736:
>> 
>>> 734:     private MandatoryWarningAggregator aggregatorFor(LintCategory lc) {
>>> 735:         return switch (lc) {
>>> 736:         case PREVIEW -> aggregators.computeIfAbsent(lc, c -> new MandatoryWarningAggregator(this, Source.instance(context), c));
>> 
>> Can we save `Source` as an instance variable? I'm mildly worried about using the `context` instance field (which is used for lazy init of lint) more generally. (In fact, I was even thinking if it would make sense to have a `Supplier<Lint>` field that we create at construction, so that we don't have to save the `context` field at all.
>
>> Can we save `Source` as an instance variable? I'm mildly worried about using the `context` instance field (which is used for lazy init of lint) more generally. (In fact, I was even thinking if it would make sense to have a `Supplier<Lint>` field that we create at construction, so that we don't have to save the `context` field at all.
> 
> I guess I don't understand the issue - isn't this kind of usage the whole point of having a `Context` singleton?
> 
> We can certainly grab the reference to `Source` eagerly (which means sometimes we would be grabbing it unnecessarily - i.e., any time there are no preview warnings) but beyond that I'm not sure what additional changes would buy us.
> 
> Put another way: what are you trying to optimize for with that question? How would `Supplier<Lint>` be better than a `Context` (plus `Lint.instance()`) which is the more standard way to achieve the same thing?

What I mean is that, typically, javac components only use `context` as a constructor parameter, and they initialize all the context-dependent stuff they need from there. It is rather strange to see classes to "hold onto" their context parameter and use it later. Sometimes (as in this case) this is unavoidable (as initializing too early would lead to cycles) -- but I believe the status quo is to do this only where strictly necessary, and the `Source.instance(context)` does not feel necessary to me. (separately, each call to `instance` does a lookup on a map, so there's also an efficiency angle to try and limit this where possible).

`Supplier` is not better -- but it avoids the `context` field, which in turns avoid the "temptation" to use it when not necessary. It is not mandatory you change the code to use a supplier though, as we don't have precedents for that kind of thing -- but limiting context lookups as much as possible is defo how javac code generally works -- and the main thing I'm bringing up in this comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161759855

From jlu at openjdk.org  Mon Jun 23 14:45:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:45:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
 <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
Message-ID: <BVN8gdSxc54F_PWYYXyMoHt4FDCeFNtN_vMeMSxIGoI=.beedc45e-7447-4e77-9553-ad1420bc512e@github.com>

On Wed, 18 Jun 2025 18:48:04 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.
>
> Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

If this is committed, then the years will be synced and we won't have to change it back. This would be consistent with the way we receive l10n translations which sync the copyright years of localized files to the original. 

If we want to deviate from this then we could file a request asking them to not update copyright years and we could update them ourselves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161805058

From jlu at openjdk.org  Mon Jun 23 14:57:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:57:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>

On Wed, 18 Jun 2025 15:52:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
> 
>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
> 
> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161832785

From jlu at openjdk.org  Mon Jun 23 15:00:37 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 15:00:37 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <M5xHiXsy_RXNKRklp3u-Rc0JJiVmUyKDAdZgTmURWbo=.3c8874b7-ffda-4ffe-910f-381607b78e29@github.com>

On Wed, 18 Jun 2025 15:59:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:
> 
>> 227: doclet.search_in_documentation=In Dokumentation suchen
>> 228: doclet.search_reset=Zur?cksetzen
>> 229: doclet.Member=Member
> 
> Is `Member` translated? Should it be _?Mitglied?_?

Good catch. Usually, we file these issues with the translation team and make the appropriate updates in the second L10n drop. I think this one is fine to be updated now as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161839290

From acobbs at openjdk.org  Mon Jun 23 15:23:34 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 15:23:34 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <LcEoVsxAHJTghFEROpfBJsdkzKUQEVQua6DeJ0n_jj4=.15fad2c5-721d-4fc6-9dd3-e02223d51842@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <LcEoVsxAHJTghFEROpfBJsdkzKUQEVQua6DeJ0n_jj4=.15fad2c5-721d-4fc6-9dd3-e02223d51842@github.com>
Message-ID: <wfuzGVDNqGOK2YvCLZUavF5ooYLj_Ka7AIkJy047BVM=.97f5c9c0-87f3-44ba-bfe2-5864276a719b@github.com>

On Mon, 23 Jun 2025 09:36:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 248:
> 
>> 246:             }
>> 247:         }
>> 248:         Optional.ofNullable(warningKey)
> 
> I think I'd prefer a regular `if (warningKey != null) { log.mandatoryWarning(...) }`, as it seems generally "flatter".

It's a style thing and I'm happy either way. I'll fix.

> Is there a "cleanup race" here? E.g. this method clears the aggregator enum map. But then Log.clear walks that map and calls `clear` on each aggregator -- but if the map is empty, nothing will get cleared?

Yep - there is a bit of inconsistency here: `reportOutstandingNotes()` is treating aggregators as things that are created, used, and then discarded, whereas `log.clear()` is treating them as being created once and then used, cleared and re-used multiple times. Logically it's the same result but it looks weird. I'll fix to just clear the map in both cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161887478
PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161885108

From liach at openjdk.org  Mon Jun 23 15:29:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 23 Jun 2025 15:29:28 GMT
Subject: RFR: 8358801: javac produces class that does not pass verifier.
In-Reply-To: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
References: <mvyOqsq9sqxR0L2Q0hbPrGR3ffVmEAI_xnDto4-EVxc=.97784c09-4faf-4621-b570-104de120004b@github.com>
Message-ID: <nn02OgaLfqD1rY01KcG05OI0zZmILY-5UqSjOpHT5SU=.2c17de7d-de9c-46ed-bac7-85721a4fb8f7@github.com>

On Tue, 17 Jun 2025 10:01:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> 
> public class Main {
> 
>     private boolean test(String s, int i) {
>         if (s.subSequence(0, 1) instanceof Runnable r) {
>             return true;
>         }
> 
>         Integer dummy;
>         switch (i) {
>             case 0:
>                 String clashing = null;
>                 return true;
>             default:
>                 return true;
>         }
>     }
> 
>     public static void main(String[] args) {
>     }
> }
> 
> 
> javac will produce code that won't (rightfully) pass the verifier:
> 
> 
> $ java Main.java
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 49
> Exception Details:
>   Location:
>     Main.test(Ljava/lang/String;I)Z @49: iconst_1
>   Reason:
>     Type top (current frame, locals[4]) is not assignable to 'java/lang/String' (stack map, locals[4])
>   Current Frame:
>     bci: @25
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer }
>     stack: { integer }
>   Stackmap Frame:
>     bci: @49
>     flags: { }
>     locals: { 'Main', 'java/lang/String', integer, top, 'java/lang/String' }
>     stack: { }
>   Bytecode:
>     0000000: 2b03 04b6 0007 3a04 1904 c100 0d99 000b
>     0000010: 1904 c000 0d4e 04ac 1cab 0000 0000 0018
>     0000020: 0000 0001 0000 0000 0000 0013 013a 0404
>     0000030: ac04 ac
>   Stackmap Table:
>     same_frame(@24)
>     same_frame(@44)
>     append_frame(@49,Top,Object[#8])
> 
>         at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>         at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3035)
>         at java.base/java.lang.Class.getMethodsRecursive(Class.java:3177)
>         at java.base/java.lang.Class.findMethod(Class.java:2465)
>         at java.base/java.lang.System$1.findMethod(System.java:1980)
>         at java.base/jdk.internal.misc.MethodFinder.findMainMethod(MethodFinder.java:86)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:194)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> 
> 
> 
> Now, the problem, as far as I can tell, is this: javac will desugar the pattern matching instanceof along the lines of:
> 
> 
> if (... (var $temp = s.subSequence(0, 1) in ... && ...) ...) {
>     return true;
> }
> 
> 
> (`$temp` is register/local variable number 4)
> specifically, note the `&&` in the middle of the let expression, and that the expression is in the conditional position. What happens here is...

Good. We can update GenContext::addCont/addExit to use the new `undefineVariablesInChain` later.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25849#pullrequestreview-2950553793

From acobbs at openjdk.org  Mon Jun 23 15:45:28 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 15:45:28 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler
In-Reply-To: <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
Message-ID: <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>

On Mon, 23 Jun 2025 09:48:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
>> 
>> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
>> 
>> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractLog.java line 165:
> 
>> 163:      * @param flags      Any additional flags required
>> 164:      */
>> 165:     public void warning(Warning warningKey, DiagnosticFlag... flags) {
> 
> I'm not sure about these changes to the `warning` method. The reason being that this PR doesn't seem to require such changes. And note that, with this change, all calls to `Log.warning` become variadic -- meaning the compiler will have to at least allocate an empty array. I'm not sure if this is enough to cause a regression, but if not necessary, I'd prefer to revert these changes, also noting that `error` and `note` have variants that do not accept flags.

(This comment also applies to your question about `mandatoryWarning()`).

This PR is a precursor to #24584 which is going to add another flag (`DEFAULT_ENABLED`). The goal here is to encapsulate all the site-specific peculiarities of logging in these flags to make the code clearer.

Let me know how you'd prefer to approach this. E.g., if you're worried about useless empty array allocations, we could just have another method override (so we'd have one that takes flags and one that doesn't). If you're worried about consistency in the API we can add a flags option to all of the other log methods. Etc. I'm happy to do it however makes the most sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161934713

From acobbs at openjdk.org  Mon Jun 23 15:59:11 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 15:59:11 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
Message-ID: <cCdkSlHu-tXWRzGFMHJhcshsomvJ421VV8DyIqvIlxs=.995944d6-fc7e-4409-98ae-d7c987446856@github.com>

> The compiler's handling of the aggregation of mandatory warnings into "notes" at the end of compilation can be refactored to simplify the code.
> 
> The `JCDiagnostic` class supports flags that alter how warnings are handled, e.g., `MANDATORY`, `NON_DEFERRABLE`, etc. So instead of having to log aggregated mandatory warnings through a separate channel (the `MandatoryWarningHandler`), these warnings could instead be logged just like any other warning, but with an `AGGREGATED` flag added. The actual aggregation can then be handled "behind the scenes" by the logging subsystem.
> 
> This will also make it easier to implement `@SuppressAnnotations` support for parser/tokenizer warnings which require aggregated mandatory warning notes such as warnings for preview features.

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

  Apply some review suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25810/files
  - new: https://git.openjdk.org/jdk/pull/25810/files/75d9edf5..81670b14

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

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

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

From acobbs at openjdk.org  Mon Jun 23 15:59:12 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 15:59:12 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <C1g5oE3bd4JgZOO0xtI3dmXhVnPBAV-dh5yZXjypc6s=.bf9d2946-dc98-45ae-b6a9-df67e995c62c@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <OigdjhBmlsSNRNTm7oXPvsJ8e7_Lw4mabrn9dzL9tj4=.979f435d-70a4-42bc-8de8-c705fc05e827@github.com>
 <onWoqe8gaKPfbMluxfi5ZZLBhN41_Yg8mldGQHbyqtE=.df8316da-97a5-4194-85e6-3f70a2bac532@github.com>
 <C1g5oE3bd4JgZOO0xtI3dmXhVnPBAV-dh5yZXjypc6s=.bf9d2946-dc98-45ae-b6a9-df67e995c62c@github.com>
Message-ID: <mgFo-WUhD-O1_zpxb8s-POQAhr7rI4pdtWGO8sZ0bTE=.bc0929b7-0b1c-4d86-ad78-2de71b940804@github.com>

On Mon, 23 Jun 2025 14:21:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Can we save `Source` as an instance variable? I'm mildly worried about using the `context` instance field (which is used for lazy init of lint) more generally. (In fact, I was even thinking if it would make sense to have a `Supplier<Lint>` field that we create at construction, so that we don't have to save the `context` field at all.
>> 
>> I guess I don't understand the issue - isn't this kind of usage the whole point of having a `Context` singleton?
>> 
>> We can certainly grab the reference to `Source` eagerly (which means sometimes we would be grabbing it unnecessarily - i.e., any time there are no preview warnings) but beyond that I'm not sure what additional changes would buy us.
>> 
>> Put another way: what are you trying to optimize for with that question? How would `Supplier<Lint>` be better than a `Context` (plus `Lint.instance()`) which is the more standard way to achieve the same thing?
>
> What I mean is that, typically, javac components only use `context` as a constructor parameter, and they initialize all the context-dependent stuff they need from there. It is rather strange to see classes to "hold onto" their context parameter and use it later. Sometimes (as in this case) this is unavoidable (as initializing too early would lead to cycles) -- but I believe the status quo is to do this only where strictly necessary, and the `Source.instance(context)` does not feel necessary to me. (separately, each call to `instance` does a lookup on a map, so there's also an efficiency angle to try and limit this where possible).
> 
> `Supplier` is not better -- but it avoids the `context` field, which in turns avoid the "temptation" to use it when not necessary. It is not mandatory you change the code to use a supplier though, as we don't have precedents for that kind of thing -- but limiting context lookups as much as possible is defo how javac code generally works -- and the main thing I'm bringing up in this comment.

Thinking about this, I realized I have had this assumption in my head: "There is a certain set of types which are compiler singletons (`Resolve`, `Source`, etc.). We assume that for any `Context` instance, there is only one associated singleton of any of those types. So while it would not necessarily be correct for random objects in the compiler to hold `Context` references, it's OK for any of these singletons to hold on to `Context` references because they are all part of the same singleton blob/cluster."

By that logic, `Log` holding a `Context` reference and then using it later is OK. But I agree there's no need to gratuitously do this when it's not necessary.

However, it turns out it's necessary for both `Source` and `Lint` to avoid dependencies. E.g., for `Source` we get this error if we try to acquire it eagerly:

java.lang.AssertionError: ignored flag: --source
        at jdk.compiler.interim/com.sun.tools.javac.util.Assert.error(Assert.java:162)
        at jdk.compiler.interim/com.sun.tools.javac.util.Assert.check(Assert.java:104)
        at jdk.compiler.interim/com.sun.tools.javac.util.Options.lambda$computeIfReady$0(Options.java:296)
        at jdk.compiler.interim/com.sun.tools.javac.util.Options.notifyListeners(Options.java:265)
        at jdk.compiler.interim/com.sun.tools.javac.main.Arguments.processArgs(Arguments.java:367)
        at jdk.compiler.interim/com.sun.tools.javac.main.Arguments.init(Arguments.java:202)
        at jdk.compiler.interim/com.sun.tools.javac.main.Main.compile(Main.java:238)
        at jdk.compiler.interim/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler.interim/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:54)
        at javacserver.server.Server.runCompiler(Server.java:239)
        at javacserver.server.Server.handleRequest(Server.java:208)
        at javacserver.server.Server.lambda$start$0(Server.java:172)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1095)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:619)
        at java.base/java.lang.Thread.run(Thread.java:1447)


This is because `Log` is needed so early in the startup process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161960512

From mcimadamore at openjdk.org  Mon Jun 23 16:11:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 16:11:28 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
 <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
Message-ID: <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>

On Mon, 23 Jun 2025 15:43:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractLog.java line 165:
>> 
>>> 163:      * @param flags      Any additional flags required
>>> 164:      */
>>> 165:     public void warning(Warning warningKey, DiagnosticFlag... flags) {
>> 
>> I'm not sure about these changes to the `warning` method. The reason being that this PR doesn't seem to require such changes. And note that, with this change, all calls to `Log.warning` become variadic -- meaning the compiler will have to at least allocate an empty array. I'm not sure if this is enough to cause a regression, but if not necessary, I'd prefer to revert these changes, also noting that `error` and `note` have variants that do not accept flags.
>
> (This comment also applies to your question about `mandatoryWarning()`).
> 
> This PR is a precursor to #24584 which is going to add another flag (`DEFAULT_ENABLED`). The goal here is to encapsulate all the site-specific peculiarities of logging in these flags to make the code clearer.
> 
> Let me know how you'd prefer to approach this. E.g., if you're worried about useless empty array allocations, we could just have another method override (so we'd have one that takes flags and one that doesn't). If you're worried about consistency in the API we can add a flags option to all of the other log methods. Etc. I'm happy to do it however makes the most sense.

I'd prefer to address the `DEFAULT_ENABLED` in a separate (and standalone, if possible) PR, to make sure we're really going the right direction about this. My general feeling is that all these properties are ultimately tied to the lint category --- so, once you pick a category, you kind of know whether it's aggregated, or defaultEnabled, or whatever -- modelling this as a flag makes it look as if you can also emit a preview warning w/o the aggregation behavior, which I'm not sure makes sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2161984764

From achung at openjdk.org  Mon Jun 23 16:38:29 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
Message-ID: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>

On Wed, 18 Jun 2025 20:37:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
>> 
>>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>>> 459: SliderDemo.majorticks=Grobteilungen
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 
>> Should the translation of `SliderDemo.majorticks` also be updated?
>
> I agree. I'd expect consistency here.

What would be the correct translation of majorticks here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162027420

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>

On Wed, 18 Jun 2025 14:48:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
> 
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>> 462: SliderDemo.minorticks=Feinteilungen
> 
> The following description uses different words now:
> 
> Feinteilungen -> Teilstrichen
> Teilungen -> Teilstrichen

Just to clarify, does this mean

SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
SliderDemo.minorticks=Teilstrichen

is correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162030543

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
Message-ID: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>

On Mon, 23 Jun 2025 07:31:34 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
>> 
>>> 1: #
>> 
>> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.
>
> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
> If that was intentionally left out, I don't see new reason to add them.

This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162024606

From achung at openjdk.org  Mon Jun 23 16:44:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:44:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

  update to german translations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/66c34e7d..90bfd7bd

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

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

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

From naoto at openjdk.org  Mon Jun 23 16:44:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jun 2025 16:44:24 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
 <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
Message-ID: <i1GseMJyfCL5uo-smr3SLsDUVkvWzdQheIzvVr5PpKY=.1281d6d5-c07e-47cc-bacc-8ea1161a3df9@github.com>

On Mon, 23 Jun 2025 16:32:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
>> If that was intentionally left out, I don't see new reason to add them.
>
> This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

Thanks. I guess this was simply an overlook in the first place, as the process was manual back then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162038459

From duke at openjdk.org  Mon Jun 23 17:41:29 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Mon, 23 Jun 2025 17:41:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
Message-ID: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>

On Mon, 23 Jun 2025 16:34:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I agree. I'd expect consistency here.
>
> What would be the correct translation of majorticks here?

If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162131034

From acobbs at openjdk.org  Mon Jun 23 18:28:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 18:28:29 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
 <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
 <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>
Message-ID: <j5osPwIO0Ux0VRM47PIsVIH-fgK14U1DzChVRvsl4jY=.92af7b8e-377b-4435-a2fe-ec056f0d9da3@github.com>

On Mon, 23 Jun 2025 16:09:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> My general feeling is that all these properties are ultimately tied to the lint category --- so, once you pick a category, you kind of know whether it's aggregated, or defaultEnabled, or whatever -- modelling this as a flag makes it look as if you can also emit a preview warning w/o the aggregation behavior, which I'm not sure makes sense?

The flags can't always be tied to the category (for example, `compiler.warn.preview.feature.use.classfile` is logged with `MANDATORY` but not `DEFAULT_ENABLED`), but it looks like they could be tied to the specific warning.

This could use our existing property file comment mechanism.  What do you think about that idea? Example:

# 0: message segment (feature)
# lint: preview, mandatory, default-enabled, aggregate
compiler.warn.preview.feature.use=\
   {0} is a preview feature and may be removed in a future release.

# 0: file object (classfile), 1: string (expected version)
# lint: preview, mandatory, aggregate
compiler.warn.preview.feature.use.classfile=\
   class file for {0} uses preview features of Java SE {1}.


Then we could eliminate `Log.mandatoryWarning()` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2162266441

From acobbs at openjdk.org  Mon Jun 23 18:31:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 18:31:29 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <4EXL4LYVS8YnOql2bTPA3HV9IHa-QK6bYn-9Lyih6Y4=.3fd99414-e040-4f5c-8e78-9ed0ee7810ae@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
 <tS09dK0SdPQ6l8qwdCgPLiGbtBpyIy6P0JC-TpavFBc=.6de63d84-0f35-4e27-aa0b-7d8c9d28be75@github.com>
 <4EXL4LYVS8YnOql2bTPA3HV9IHa-QK6bYn-9Lyih6Y4=.3fd99414-e040-4f5c-8e78-9ed0ee7810ae@github.com>
Message-ID: <Lv7LtITSQe-q5dkcexoxwInW5GrhvdWfAzIhSikV3_s=.f4a24544-cdb6-4309-82ce-090558dfd6bd@github.com>

On Mon, 23 Jun 2025 14:17:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > I have to admit I don't really get why `isExplicitEnabled/Disabled` takes an `Option` parameter -- I see them always invoked with `Option.XLINT`. Because of that, I'm not even sure they belong much in `Options` at all -- an instance method on `LintCategory` which accepts `Options` would perhaps look simpler for clients?
> 
> Note: the same is true for the new methods `isEnabled`/`isDisabled` added in this PR -- they feel `Lint`-specific methods to me.

It's to allow for future customization of other lint-related options, in particular `-Werror` - see #23622.

Maybe that's a little too leading? I can remove it if you prefer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2997517662

From aivanov at openjdk.org  Mon Jun 23 18:45:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 18:45:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
Message-ID: <9FQIYMoH-HEi7ktEzRGxRsoWXGPsDyWPWk3Ds0Edjy0=.5dcab616-2713-441b-b363-350ea62505e3@github.com>

On Mon, 23 Jun 2025 14:55:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
>> 
>>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
>> 
>> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.
>
> I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

I see the entries for


jar.signed.=jar signed.
jar.verified.=jar verified.

don't have the word *?file?*, whereas `?via.jarfile.and.jarinputstream` has it: ?This JAR *file*??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162318454

From aivanov at openjdk.org  Mon Jun 23 19:07:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:07:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
Message-ID: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>

On Mon, 23 Jun 2025 17:38:58 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> What would be the correct translation of majorticks here?
>
> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162350461

From aivanov at openjdk.org  Mon Jun 23 19:36:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
Message-ID: <O9Co_nchUBZcx7IsEWV3BulBeBx49f1DCSSfMncRP9Y=.01ec06db-951c-4466-b07e-4f49e34c41ad@github.com>

On Mon, 23 Jun 2025 16:36:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
>> 
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>>> 462: SliderDemo.minorticks=Feinteilungen
>> 
>> The following description uses different words now:
>> 
>> Feinteilungen -> Teilstrichen
>> Teilungen -> Teilstrichen
>
> Just to clarify, does this mean
> 
> SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
> SliderDemo.minorticks=Teilstrichen
> 
> is correct?

Hm? I don't know. You should clarify with the translation team. They've changed the translation for the major ticks from *Grobteilungen* to *Hauptteilstriche*. Yet minor ticks remain *Feinteilungen*, which doesn't look right because the main word is different. (*Teilung* doesn't seem to be the right word, at least dictionaries translate it as ?division?.)

*Teilstrich* means *scale line*, the marks on a ruler, so it fits.

Microsoft documentation for [MinorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.minortickmark?view=openxml-3.0.1) uses *Kleinere Teilstriche*, yet I don't understand why there's ?-e? ending (plural?).


SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels

This one looks particularly incorrect; ?einrasten? is a verb with a separable prefix that means ?to lock?, and I can't find a usage as if it's a noun.

The English phrase is ?Minor Ticks, Snap-to-ticks and Labels?, and I don't know how to correctly translate it to German.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162394521

From aivanov at openjdk.org  Mon Jun 23 19:36:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
Message-ID: <Cnn1pTxh334i_8vCnBa3c3FWvblGyzCjASOEGJQTsw8=.eb5e76f7-e83b-416c-9fe6-361d772780af@github.com>

On Thu, 19 Jun 2025 17:39:38 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
>> 
>>> 181: size.bit.alg=%1$d-Bit-%2$s
>>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
>> 
>> It feels as if there's something missing after _?einem?_.
>
> seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162395125

From mcimadamore at openjdk.org  Mon Jun 23 20:57:31 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 20:57:31 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <Lv7LtITSQe-q5dkcexoxwInW5GrhvdWfAzIhSikV3_s=.f4a24544-cdb6-4309-82ce-090558dfd6bd@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
 <tS09dK0SdPQ6l8qwdCgPLiGbtBpyIy6P0JC-TpavFBc=.6de63d84-0f35-4e27-aa0b-7d8c9d28be75@github.com>
 <4EXL4LYVS8YnOql2bTPA3HV9IHa-QK6bYn-9Lyih6Y4=.3fd99414-e040-4f5c-8e78-9ed0ee7810ae@github.com>
 <Lv7LtITSQe-q5dkcexoxwInW5GrhvdWfAzIhSikV3_s=.f4a24544-cdb6-4309-82ce-090558dfd6bd@github.com>
Message-ID: <JwanZ3v80X-UzLlrCILouA_-Y0oSxmQUHy3GS1i6R-E=.97ee374e-d5fc-450f-abad-1640cae2f528@github.com>

On Mon, 23 Jun 2025 18:28:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> > > I have to admit I don't really get why `isExplicitEnabled/Disabled` takes an `Option` parameter -- I see them always invoked with `Option.XLINT`. Because of that, I'm not even sure they belong much in `Options` at all -- an instance method on `LintCategory` which accepts `Options` would perhaps look simpler for clients?
> > 
> > 
> > Note: the same is true for the new methods `isEnabled`/`isDisabled` added in this PR -- they feel `Lint`-specific methods to me.
> 
> It's to allow for future customization of other lint-related options, in particular `-Werror` - see #23622.
> 
> Maybe that's a little too leading? I can remove it if you prefer.

Yeah, I think for now I'd prefer that. I believe each PR should be relatively standalone -- maybe we will go ahead and follow up with the other PR, but I'd prefer to avoid adding more stuff here which is really needed to support that other task.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2997915926

From mcimadamore at openjdk.org  Mon Jun 23 21:03:31 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 21:03:31 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <j5osPwIO0Ux0VRM47PIsVIH-fgK14U1DzChVRvsl4jY=.92af7b8e-377b-4435-a2fe-ec056f0d9da3@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
 <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
 <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>
 <j5osPwIO0Ux0VRM47PIsVIH-fgK14U1DzChVRvsl4jY=.92af7b8e-377b-4435-a2fe-ec056f0d9da3@github.com>
Message-ID: <BH_jvaEwWbC7Y86T-6oQVsC0CGf9e2EnTbhdLzm2_SI=.643dea32-5981-45ad-9f7c-4d0c611ef2ca@github.com>

On Mon, 23 Jun 2025 18:26:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I'd prefer to address the `DEFAULT_ENABLED` in a separate (and standalone, if possible) PR, to make sure we're really going the right direction about this. My general feeling is that all these properties are ultimately tied to the lint category --- so, once you pick a category, you kind of know whether it's aggregated, or defaultEnabled, or whatever -- modelling this as a flag makes it look as if you can also emit a preview warning w/o the aggregation behavior, which I'm not sure makes sense?
>
>> My general feeling is that all these properties are ultimately tied to the lint category --- so, once you pick a category, you kind of know whether it's aggregated, or defaultEnabled, or whatever -- modelling this as a flag makes it look as if you can also emit a preview warning w/o the aggregation behavior, which I'm not sure makes sense?
> 
> The flags can't always be tied to the category (for example, `compiler.warn.preview.feature.use.classfile` is logged with `MANDATORY` but not `DEFAULT_ENABLED`), but it looks like they could be tied to the specific warning.
> 
> This could use our existing property file comment mechanism.  What do you think about that idea? Example:
> 
> # 0: message segment (feature)
> # lint: preview
> # diag-flags: mandatory, default-enabled, aggregate
> compiler.warn.preview.feature.use=\
>    {0} is a preview feature and may be removed in a future release.
> 
> # 0: file object (classfile), 1: string (expected version)
> # lint: preview
> # diag-flags: mandatory, aggregate
> compiler.warn.preview.feature.use.classfile=\
>    class file for {0} uses preview features of Java SE {1}.
> 
> 
> Then we could eliminate `Log.mandatoryWarning()` too.

I was thinking about capturing flags in the file too (but then hoped we could just ride the category). Doing what you suggest is a possibility -- my only "fear" is that by reflecting the flags in the `compiler.properties` file we'll make the current flag classification look more permanent than what it probably is (e.g. it seems to me there's a lot of ad-hocness to this classification, due to the ad-hoc behavior we're now trying to sort out). Anyway, perhaps worth doing it, even as if an exercise, as it will certainly make asymmetries between various flags pop out more -- then we can ask whether that asymmetry is there for a reason and needs to be supported going forward, or if we can make things a little less ad-hoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2162525162

From mcimadamore at openjdk.org  Mon Jun 23 21:13:28 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 21:13:28 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <BH_jvaEwWbC7Y86T-6oQVsC0CGf9e2EnTbhdLzm2_SI=.643dea32-5981-45ad-9f7c-4d0c611ef2ca@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
 <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
 <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>
 <j5osPwIO0Ux0VRM47PIsVIH-fgK14U1DzChVRvsl4jY=.92af7b8e-377b-4435-a2fe-ec056f0d9da3@github.com>
 <BH_jvaEwWbC7Y86T-6oQVsC0CGf9e2EnTbhdLzm2_SI=.643dea32-5981-45ad-9f7c-4d0c611ef2ca@github.com>
Message-ID: <I6kUBK9a4nuoDkje6kEVtQ2uuqm5QVJ29GyxjHIrQKI=.4090f49c-321a-4435-bd94-c924d24471e7@github.com>

On Mon, 23 Jun 2025 21:00:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> My general feeling is that all these properties are ultimately tied to the lint category --- so, once you pick a category, you kind of know whether it's aggregated, or defaultEnabled, or whatever -- modelling this as a flag makes it look as if you can also emit a preview warning w/o the aggregation behavior, which I'm not sure makes sense?
>> 
>> The flags can't always be tied to the category (for example, `compiler.warn.preview.feature.use.classfile` is logged with `MANDATORY` but not `DEFAULT_ENABLED`), but it looks like they could be tied to the specific warning.
>> 
>> This could use our existing property file comment mechanism.  What do you think about that idea? Example:
>> 
>> # 0: message segment (feature)
>> # lint: preview
>> # diag-flags: mandatory, default-enabled, aggregate
>> compiler.warn.preview.feature.use=\
>>    {0} is a preview feature and may be removed in a future release.
>> 
>> # 0: file object (classfile), 1: string (expected version)
>> # lint: preview
>> # diag-flags: mandatory, aggregate
>> compiler.warn.preview.feature.use.classfile=\
>>    class file for {0} uses preview features of Java SE {1}.
>> 
>> 
>> Then we could eliminate `Log.mandatoryWarning()` too.
>
> I was thinking about capturing flags in the file too (but then hoped we could just ride the category). Doing what you suggest is a possibility -- my only "fear" is that by reflecting the flags in the `compiler.properties` file we'll make the current flag classification look more permanent than what it probably is (e.g. it seems to me there's a lot of ad-hocness to this classification, due to the ad-hoc behavior we're now trying to sort out). Anyway, perhaps worth doing it, even as if an exercise, as it will certainly make asymmetries between various flags pop out more -- then we can ask whether that asymmetry is there for a reason and needs to be supported going forward, or if we can make things a little less ad-hoc.

Re. default-enabled, I suspect this is used for preview language feature warnings -- e.g. warnings to be issued when (a) preview features have been enabled and (b) the use of a preview language feature has been detected. As JEP 12 says, while it's ok to use suppressible warnings for preview APIs, it is not ok to use suppressible warnings for language features. So, I believe what JEP 12 says is not "default-enabled", but really "always-enabled", or "unsuppressible". (unfortunately the JEP text does some confusion as it uses the term `lint` warning to refer to the unsuppressible warning, when in reality, in javac, the term `lint` is used for warnings that *can* be suppressed).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2162539523

From mcimadamore at openjdk.org  Mon Jun 23 21:17:36 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Jun 2025 21:17:36 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <I6kUBK9a4nuoDkje6kEVtQ2uuqm5QVJ29GyxjHIrQKI=.4090f49c-321a-4435-bd94-c924d24471e7@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
 <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
 <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>
 <j5osPwIO0Ux0VRM47PIsVIH-fgK14U1DzChVRvsl4jY=.92af7b8e-377b-4435-a2fe-ec056f0d9da3@github.com>
 <BH_jvaEwWbC7Y86T-6oQVsC0CGf9e2EnTbhdLzm2_SI=.643dea32-5981-45ad-9f7c-4d0c611ef2ca@github.com>
 <I6kUBK9a4nuoDkje6kEVtQ2uuqm5QVJ29GyxjHIrQKI=.4090f49c-321a-4435-bd94-c924d24471e7@github.com>
Message-ID: <9bXZm7_y411nSqXeSxeWnqFy0Jvytx39UVXdXS9G0sM=.988d074c-4765-4cf0-a7a8-427499843c09@github.com>

On Mon, 23 Jun 2025 21:10:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I was thinking about capturing flags in the file too (but then hoped we could just ride the category). Doing what you suggest is a possibility -- my only "fear" is that by reflecting the flags in the `compiler.properties` file we'll make the current flag classification look more permanent than what it probably is (e.g. it seems to me there's a lot of ad-hocness to this classification, due to the ad-hoc behavior we're now trying to sort out). Anyway, perhaps worth doing it, even as if an exercise, as it will certainly make asymmetries between various flags pop out more -- then we can ask whether that asymmetry is there for a reason and needs to be supported going forward, or if we can make things a little less ad-hoc.
>
> Re. default-enabled, I suspect this is used for preview language feature warnings -- e.g. warnings to be issued when (a) preview features have been enabled and (b) the use of a preview language feature has been detected. As JEP 12 says, while it's ok to use suppressible warnings for preview APIs, it is not ok to use suppressible warnings for language features. So, I believe what JEP 12 says is not "default-enabled", but really "always-enabled", or "unsuppressible". (unfortunately the JEP text does some confusion as it uses the term `lint` warning to refer to the unsuppressible warning, when in reality, in javac, the term `lint` is used for warnings that *can* be suppressed).

Also, are there mandatory warnings for which there's no aggregation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2162546274

From acobbs at openjdk.org  Mon Jun 23 21:22:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 21:22:29 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <9bXZm7_y411nSqXeSxeWnqFy0Jvytx39UVXdXS9G0sM=.988d074c-4765-4cf0-a7a8-427499843c09@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
 <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
 <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>
 <j5osPwIO0Ux0VRM47PIsVIH-fgK14U1DzChVRvsl4jY=.92af7b8e-377b-4435-a2fe-ec056f0d9da3@github.com>
 <BH_jvaEwWbC7Y86T-6oQVsC0CGf9e2EnTbhdLzm2_SI=.643dea32-5981-45ad-9f7c-4d0c611ef2ca@github.com>
 <I6kUBK9a4nuoDkje6kEVtQ2uuqm5QVJ29GyxjHIrQKI=.4090f49c-321a-4435-bd94-c924d24471e7@github.com>
 <9bXZm7_y411nSqXeSxeWnqFy0Jvytx39UVXdXS9G0sM=.988d074c-4765-4cf0-a7a8-427499843c09@github.com>
Message-ID: <A_KbO3l548MshbnmwtyXPXeUiC7UF73AVoADjA34l20=.5cc11a8b-470d-443b-a610-f59cbda16e0e@github.com>

On Mon, 23 Jun 2025 21:15:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Re. default-enabled, I suspect this is used for preview language feature warnings -- e.g. warnings to be issued when (a) preview features have been enabled and (b) the use of a preview language feature has been detected. As JEP 12 says, while it's ok to use suppressible warnings for preview APIs, it is not ok to use suppressible warnings for language features. So, I believe what JEP 12 says is not "default-enabled", but really "always-enabled", or "unsuppressible". (unfortunately the JEP text does some confusion as it uses the term `lint` warning to refer to the unsuppressible warning, when in reality, in javac, the term `lint` is used for warnings that *can* be suppressed).
>
> Also, are there mandatory warnings for which there's no aggregation?

Thanks for your thoughts on that. I will work on a properties file version of this so we can take a look at it. I think this should help make things as "clean" as they can be, while still preserving the existing (slightly wonky) behavior.

Regarding the JEP, there may indeed be some disagreement between what it specifies and what's implemented. If so, adding these flags to the properties file should make that disagreement (a) more obvious and (b) easy to fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2162551867

From acobbs at openjdk.org  Mon Jun 23 21:27:40 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 23 Jun 2025 21:27:40 GMT
Subject: RFR: 8359493: Refactor how aggregated mandatory warnings are
 handled in the compiler [v2]
In-Reply-To: <A_KbO3l548MshbnmwtyXPXeUiC7UF73AVoADjA34l20=.5cc11a8b-470d-443b-a610-f59cbda16e0e@github.com>
References: <cNgGXJbQfH7OtGQtQCAOmt9o432jDuqCPUfL701Q7bU=.72e81015-307d-4b37-a241-d5b337a6dd38@github.com>
 <2dup9uP4srVhJvgH2st-LEq6k0_POkq1znKgLAjTU0c=.87640df2-daf6-4103-a653-274c56cf6f08@github.com>
 <R2aIHKF7HaPr282SZWEgjXAALnDcbHptDItvlCzzJBA=.c14fc1f4-5acc-45d8-bba9-c85fd558445a@github.com>
 <iMtxs1WyJa0Ih5zHUZ661RGRCUrVfGcU5zCV6aon8Qk=.fad9d068-eced-49cf-8df9-6c7753267282@github.com>
 <j5osPwIO0Ux0VRM47PIsVIH-fgK14U1DzChVRvsl4jY=.92af7b8e-377b-4435-a2fe-ec056f0d9da3@github.com>
 <BH_jvaEwWbC7Y86T-6oQVsC0CGf9e2EnTbhdLzm2_SI=.643dea32-5981-45ad-9f7c-4d0c611ef2ca@github.com>
 <I6kUBK9a4nuoDkje6kEVtQ2uuqm5QVJ29GyxjHIrQKI=.4090f49c-321a-4435-bd94-c924d24471e7@github.com>
 <9bXZm7_y411nSqXeSxeWnqFy0Jvytx39UVXdXS9G0sM=.988d074c-4765-4cf0-a7a8-427499843c09@github.com>
 <A_KbO3l548MshbnmwtyXPXeUiC7UF73AVoADjA34l20=.5cc11a8b-470d-443b-a610-f59cbda16e0e@github.com>
Message-ID: <YH2lTc91mP3bUokLyrq1U9FJzyF0UJWPo53t9t2ilDo=.aba1a73f-0213-47d6-a564-3773feaa72dd@github.com>

On Mon, 23 Jun 2025 21:19:37 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Also, are there mandatory warnings for which there's no aggregation?
>
> Thanks for your thoughts on that. I will work on a properties file version of this so we can take a look at it. I think this should help make things as "clean" as they can be, while still preserving the existing (slightly wonky) behavior.
> 
> Regarding the JEP, there may indeed be some disagreement between what it specifies and what's implemented. If so, adding these flags to the properties file should make that disagreement (a) more obvious and (b) easy to fix.

> Also, are there mandatory warnings for which there's no aggregation?

Yes, I believe these are the only two:

`compiler.warn.sun.proprietary`
`compiler.warn.preview.feature.use.classfile`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25810#discussion_r2162557517

From cstein at openjdk.org  Tue Jun 24 05:15:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:15:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
 <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
Message-ID: <bNn_SZAJQvbgRD39f2sJDCLItuz4Q-fJOjCQzc0URAo=.825ec4ad-31a1-4882-93ee-97f0eff02597@github.com>

On Mon, 23 Jun 2025 19:04:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").
>
> Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

Ja, "Hauptteilstrich" and "Hauptteilstriche" (pl) are correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162975420

From cstein at openjdk.org  Tue Jun 24 05:22:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:22:33 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <ws3HlD1kGmF5lUjtCE7SxWmnc4GEkdFi6FWo_Hnm7Tc=.c3dc65c9-7681-4145-afc2-a3af84857e78@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

For consistency with the "Hilfsteilstrich" (singular) and "Hilfsteilstriche" (plural) used below in `SliderDemo.minorticksdescription` and `SliderDemo.disableddescription`, I'd suggest to use:
Suggestion:

SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
SliderDemo.minorticks=Hilfsteilstriche


As "Labels" is not a German word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162982972

From cstein at openjdk.org  Tue Jun 24 05:34:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:34:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <8Orj0J7-iUsSjTQEc7t-pSShM2wHGmfReMStzGByHGY=.41967017-0e70-4e2a-9133-f84fd263ff51@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

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

> 176: javac.opt.Xlint.desc.restricted=Warnt vor der Verwendung eingeschr?nkter Methoden.
> 177: 
> 178: javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "Identit?t", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "Identit?t" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "Synchronisierung" zu verwenden.

"Identit?t" and "Synchronisierung" are literals that must not be translated.

The English base entry reads:


javac.opt.Xlint.desc.synchronization=\
    Warn about synchronization attempts on instances of value-based classes.\n\
\                         This key is a deprecated alias for ''identity'', which has the same uses and\n\
\                         effects. Users are encouraged to use the ''identity'' category for all future\n\
\                         and existing uses of ''synchronization''.


And `javac --help-lint` contains:


    strictfp             Warn about unnecessary use of the strictfp modifier.
    synchronization      Warn about synchronization attempts on instances of value-based classes.
    text-blocks          Warn about inconsistent white space characters in text block indentation.
    
    
    
Suggestion:

javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "identity", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "identity" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "synchronization" zu verwenden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162995954

From cstein at openjdk.org  Tue Jun 24 05:44:30 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:44:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <AQix03HSJOPQl9dpzNexQJ-oAj3KLVWEt4zDGOxjmZM=.1efb1178-489f-478e-9534-f9b32e5b92de@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

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

> 101: 
> 102: # 0: string
> 103: launcher.err.cant.find.main.method=main(String[])- oder main()-Methode nicht gefunden in Klasse: {0}

Suggestion:

launcher.err.cant.find.main.method=Konnte keine main(String[])- oder main()-Methode in der Klasse: {0} finden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2163006433

From mcimadamore at openjdk.org  Tue Jun 24 10:48:27 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 24 Jun 2025 10:48:27 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <JwanZ3v80X-UzLlrCILouA_-Y0oSxmQUHy3GS1i6R-E=.97ee374e-d5fc-450f-abad-1640cae2f528@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
 <tS09dK0SdPQ6l8qwdCgPLiGbtBpyIy6P0JC-TpavFBc=.6de63d84-0f35-4e27-aa0b-7d8c9d28be75@github.com>
 <4EXL4LYVS8YnOql2bTPA3HV9IHa-QK6bYn-9Lyih6Y4=.3fd99414-e040-4f5c-8e78-9ed0ee7810ae@github.com>
 <Lv7LtITSQe-q5dkcexoxwInW5GrhvdWfAzIhSikV3_s=.f4a24544-cdb6-4309-82ce-090558dfd6bd@github.com>
 <JwanZ3v80X-UzLlrCILouA_-Y0oSxmQUHy3GS1i6R-E=.97ee374e-d5fc-450f-abad-1640cae2f528@github.com>
Message-ID: <SSjZGOJSqHzG69ITvf9A_zQrUddm17dmGPvQPtwG8KQ=.ef95e64d-7b77-49c3-a82d-e02706b463b5@github.com>

On Mon, 23 Jun 2025 20:55:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Yeah, I think for now I'd prefer that. I believe each PR should be relatively standalone -- maybe we will go ahead and follow up with the other PR, but I'd prefer to avoid adding more stuff here which is really needed to support that other task.

Especially considering this is a fix that is also targeting 25 (now in rampdown mode), so there's extra motivations for keeping the fix as small as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2999769986

From acobbs at openjdk.org  Tue Jun 24 13:40:15 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 24 Jun 2025 13:40:15 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v3]
In-Reply-To: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
Message-ID: <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>

> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
> 
> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
> 
> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.

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

  Cleanups per review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25840/files
  - new: https://git.openjdk.org/jdk/pull/25840/files/9e788319..f01f19dc

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

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

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

From acobbs at openjdk.org  Tue Jun 24 13:40:15 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 24 Jun 2025 13:40:15 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v2]
In-Reply-To: <SSjZGOJSqHzG69ITvf9A_zQrUddm17dmGPvQPtwG8KQ=.ef95e64d-7b77-49c3-a82d-e02706b463b5@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <o8TWib8I4LxkMFVCK-iJ-eB_9c_QHCTKm2XJdUDCFFM=.c9217b51-3f4a-4520-b257-b778b03966b8@github.com>
 <tS09dK0SdPQ6l8qwdCgPLiGbtBpyIy6P0JC-TpavFBc=.6de63d84-0f35-4e27-aa0b-7d8c9d28be75@github.com>
 <4EXL4LYVS8YnOql2bTPA3HV9IHa-QK6bYn-9Lyih6Y4=.3fd99414-e040-4f5c-8e78-9ed0ee7810ae@github.com>
 <Lv7LtITSQe-q5dkcexoxwInW5GrhvdWfAzIhSikV3_s=.f4a24544-cdb6-4309-82ce-090558dfd6bd@github.com>
 <JwanZ3v80X-UzLlrCILouA_-Y0oSxmQUHy3GS1i6R-E=.97ee374e-d5fc-450f-abad-1640cae2f528@github.com>
 <SSjZGOJSqHzG69ITvf9A_zQrUddm17dmGPvQPtwG8KQ=.ef95e64d-7b77-49c3-a82d-e02706b463b5@github.com>
Message-ID: <aXqTLN5pebd0jHWL1arqGzBIXABfzW-mboIQeRiOIV8=.9bbd642a-0d5c-4829-9398-a1af1bc4b8b8@github.com>

On Tue, 24 Jun 2025 10:45:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Yeah, I think for now I'd prefer that. I believe each PR should be relatively standalone -- maybe we will go ahead and follow up with the other PR, but I'd prefer to avoid adding more stuff here which is really needed to support that other task.
> 
> Especially considering this is a fix that is also targeting 25 (now in rampdown mode), so there's extra motivations for keeping the fix as small as possible.

Good point. Should be fixed in f01f19dcb31.

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-3000527041

From mcimadamore at openjdk.org  Tue Jun 24 14:17:32 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 24 Jun 2025 14:17:32 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v3]
In-Reply-To: <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
Message-ID: <o4lEt1PRKwy_Yal2tupVs_n9h59Tys0iNh4fs_V0qXU=.8ecceb1b-229e-4100-85ee-769d2f9fde84@github.com>

On Tue, 24 Jun 2025 13:40:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups per review comments.

Looks good - thanks!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25840#pullrequestreview-2954076850

From weijun at openjdk.org  Tue Jun 24 14:56:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 14:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
Message-ID: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>

On Wed, 18 Jun 2025 16:43:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.
>
> Thank you for the clarification.

However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164251035

From weijun at openjdk.org  Tue Jun 24 15:01:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:

> 47: .Principal.=\t????\u0020
> 48: .Public.Credential.=\t??????:\u0020
> 49: .Private.Credential.=\t??????:\u0020

Why aren't the 2 lines above updated like in lines 46 and 47?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164262664

From weijun at openjdk.org  Tue Jun 24 15:01:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
 <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
Message-ID: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>

On Tue, 24 Jun 2025 14:54:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thank you for the clarification.
>
> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164261187

From acobbs at openjdk.org  Tue Jun 24 16:21:34 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 24 Jun 2025 16:21:34 GMT
Subject: RFR: 8359596: Behavior change when both -Xlint:options and
 -Xlint:-options flags are given [v3]
In-Reply-To: <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
References: <QtFevKtiOMef5YhzYaSVdzIHDyTqq5-_okmbqIg2NbE=.cd60b7b8-5f26-405a-aab3-056e15079fdd@github.com>
 <iWWOv1lhGVYJBGPiWczO93XydhuDAm7SG-p12tAd0tQ=.2096b428-7cfd-47ce-ae1f-a5b0bac1f778@github.com>
Message-ID: <I7kDGFMexqN_YJyKiN384tUagMedVSrECCUxbiEyoGw=.aaf27b52-23ae-47fa-af86-ce8a69beaa38@github.com>

On Tue, 24 Jun 2025 13:40:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups per review comments.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-3001114809

From achung at openjdk.org  Tue Jun 24 21:47:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 24 Jun 2025 21:47:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v5]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <D5DGFra1xHGKB6ITrD1TV1PQcZNS_7nlA8GfD8cwQ6w=.c87859b8-fb89-4d2e-93a4-d9c0e3e44f21@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/90bfd7bd..97f3fe37

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

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

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

From dnguyen at openjdk.org  Wed Jun 25 00:30:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jun 2025 00:30:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
Message-ID: <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>

On Tue, 24 Jun 2025 14:59:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to german translations
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:
> 
>> 47: .Principal.=\t????\u0020
>> 48: .Public.Credential.=\t??????:\u0020
>> 49: .Private.Credential.=\t??????:\u0020
> 
> Why aren't the 2 lines above updated like in lines 46 and 47?

I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.

I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2165200706