From jpai at openjdk.org  Mon Dec  2 07:13:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 07:13:21 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module [v2]
In-Reply-To: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
Message-ID: <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>

> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
> 
> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.

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

 - clean up ServiceLoader usage code
 - merge latest from master branch
 - 8345153: Clean up SecurityManager references from jdk.compiler module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22431/files
  - new: https://git.openjdk.org/jdk/pull/22431/files/495c94f0..66074dfd

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

  Stats: 32599 lines in 390 files changed: 26039 ins; 4332 del; 2228 mod
  Patch: https://git.openjdk.org/jdk/pull/22431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22431/head:pull/22431

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

From jpai at openjdk.org  Mon Dec  2 07:13:22 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 07:13:22 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module [v2]
In-Reply-To: <eDSKje_AQyUfqSNtYm9d4lMt7lSzg9hY2WtHrVXqccE=.109867d2-327a-445e-8b1d-98e4f67537ea@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
 <lYgEFoPio6qb_8RANuZRxieArqwZ3YZMz3wjPHpNZlQ=.c0969681-c1fb-4444-ac80-037904827f0f@github.com>
 <eDSKje_AQyUfqSNtYm9d4lMt7lSzg9hY2WtHrVXqccE=.109867d2-327a-445e-8b1d-98e4f67537ea@github.com>
Message-ID: <aYPDBnQ7eqmQW-Ari6TYk2Mz_nJEeWAdaF4EwUk6Kbs=.ff7328ad-5ddf-4d98-a1de-39a78bc8d4e9@github.com>

On Fri, 29 Nov 2024 08:04:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 354:
>> 
>>> 352:      * relevant path, otherwise if processors are present, logs an
>>> 353:      * error.  Called when a service loader is unavailable for some
>>> 354:      * reason, for example, because a service loader class cannot be found.
>> 
>> The comment "because a service loader class cannot be found" is puzzling. Zooming out, the remaining usage of handleServiceLoaderUnavailability is in ServiceIterator where it assumes that the 2-arg SL.load or SL::iterator can throw. SL.load will only throw if the caller (in jdk.compiler) doesn't `uses Processor` or that service class is not accessible, neither is true here. Maybe Jan or someone else can comment further but it looks to me that handleServiceLoaderUnavailability can be removed and the "Fail softly" handling in ServiceIterator can be removed too.
>
> I went through the code, and I think this is right - the whole `handleServiceLoaderUnavailability` can be dropped, and everything that is referred to from it (`needClassLoader`, `handleException`, and especially(!) `ServiceProxy`; and probably also relevant keys from `compiler.properties`, unless they are used elsewhere) can, I think, be dropped.
> 
> More specifically, from `ServiceIterator.<init>`:
> 
>             try {
>                 try {
>                     loader = ServiceLoader.load(Processor.class, classLoader);
>                     this.iterator = loader.iterator();
>                 } catch (Exception e) {
>                     // Fail softly if a loader is not actually needed.
>                     this.iterator = handleServiceLoaderUnavailability("proc.no.service", null);
>                 }
>             } catch (Throwable t) {
>                 log.error(Errors.ProcServiceProblem);
>                 throw new Abort(t);
>             }
> 
> 
> my reading of both the javadoc and code in the `ServiceLoader` is that we can drop both of the `try-catch` statements, leaving only:
> 
> loader = ServiceLoader.load(Processor.class, classLoader);
> this.iterator = loader.iterator();
> 
> 
> Although if we wanted to be very careful, we could keep the outter `try-catch`.
> 
> CC @jddarcy

Thank you for these inputs, Jan and Alan. I've now updated this PR to remove this additional code and related error property key (I've verified it's not used anywhere else). 
tier1, tier2 and tier3 testing continues to pass with these latest changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22431#discussion_r1865327907

From alanb at openjdk.org  Mon Dec  2 09:03:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Dec 2024 09:03:39 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module [v2]
In-Reply-To: <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
 <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
Message-ID: <ZhUOZQN_KcD3YjzfLeptf-uWb5-8EwvzrIy8uKbNm70=.cbab0df2-852e-4d9c-bc0d-9ec466b71476@github.com>

On Mon, 2 Dec 2024 07:13:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
>> 
>> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - clean up ServiceLoader usage code
>  - merge latest from master branch
>  - 8345153: Clean up SecurityManager references from jdk.compiler module

This looks like a good cleanup. I've set the Reviewers to 2 as this will require a reviewer from Jan or someone working in this area too.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22431#pullrequestreview-2472107018

From mcimadamore at openjdk.org  Mon Dec  2 10:09:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 10:09:41 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v4]
In-Reply-To: <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
Message-ID: <j137JhLhrPIWesa1i4f7ZmV5nzzIRRvmWL7C3FPmloc=.0226fe5e-182d-4752-b0fd-91a82c454e74@github.com>

On Sat, 30 Nov 2024 17:35:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review these changes with some minor lint-related fixes and cleanups.
>> 
>> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment by being less Streamy.

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

> 444:         EnumSet<LintCategory> result = LintCategory.newEmptySet();
> 445:         Attribute.Array values = (Attribute.Array)suppressWarnings.member(names.value);
> 446:         for (Attribute value : values.values) {

I think this loop is more stream-friendly - e.g. you start from `values.values` then:
* `flatMap` using `Optional.of(value).stream()`
* `map` (using `LintCategory::get`, as now)
* `collect` to a new enum set

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1865571144

From mcimadamore at openjdk.org  Mon Dec  2 13:40:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 13:40:44 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v4]
In-Reply-To: <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
Message-ID: <MYE9CU4RncGBBKSEMrBorGY87ZfX4o6X-euNuF-7VZM=.e69a6fe0-33ae-47c3-952e-5acbb2267dbf@github.com>

On Sat, 30 Nov 2024 17:35:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review these changes with some minor lint-related fixes and cleanups.
>> 
>> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment by being less Streamy.

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 717:

> 715:                                                   processor, log, lint));
> 716:                     if (lint && !patternAdded) {
> 717:                         log.warning(PROCESSING, null, Warnings.ProcDuplicateSupportedAnnotation(annotationPattern,

Did you run all langtools tests? I believe that if you change these, some test output will be broken, as an extra `[processing]` will be emitted. I'm seeing this while playing in a related area.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1865867119

From mcimadamore at openjdk.org  Mon Dec  2 13:40:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 13:40:44 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v4]
In-Reply-To: <MYE9CU4RncGBBKSEMrBorGY87ZfX4o6X-euNuF-7VZM=.e69a6fe0-33ae-47c3-952e-5acbb2267dbf@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
 <MYE9CU4RncGBBKSEMrBorGY87ZfX4o6X-euNuF-7VZM=.e69a6fe0-33ae-47c3-952e-5acbb2267dbf@github.com>
Message-ID: <tA9EZW-h2236Lsp9dVxNCz7Ixkup4VP_1o-OOsp7Nm0=.472c9012-40a5-432e-bf7e-02f9096f886b@github.com>

On Mon, 2 Dec 2024 13:37:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment by being less Streamy.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 717:
> 
>> 715:                                                   processor, log, lint));
>> 716:                     if (lint && !patternAdded) {
>> 717:                         log.warning(PROCESSING, null, Warnings.ProcDuplicateSupportedAnnotation(annotationPattern,
> 
> Did you run all langtools tests? I believe that if you change these, some test output will be broken, as an extra `[processing]` will be emitted. I'm seeing this while playing in a related area.

Example: test/langtools/tools/doclint/AnonClassTest.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1865867949

From jlahoda at openjdk.org  Mon Dec  2 13:53:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 2 Dec 2024 13:53:42 GMT
Subject: RFR: 8345248: Module name 'transitive' not accepted for `requires
 transitive` [v2]
In-Reply-To: <8jIxgBtGPpMFHk0reDWvvSQKifhxALDsnlH9_JEXZdE=.07575c6c-4832-42e1-b9a2-df25a58acfae@github.com>
References: <BdvX8oKPAwQCQFwvg4jAVqO_YldAQUYxmw6XP3IXJPU=.0370d7a1-5ee8-4fed-802f-8e02bc5f3817@github.com>
 <8jIxgBtGPpMFHk0reDWvvSQKifhxALDsnlH9_JEXZdE=.07575c6c-4832-42e1-b9a2-df25a58acfae@github.com>
Message-ID: <AbOZmu8o9tHu3sNibHyE233DuoYbvnHWuaS7SAMZYy0=.45713046-074c-4499-a3fe-e8aa6cd3c8bc@github.com>

On Fri, 29 Nov 2024 14:30:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Considering module named `transitive`, it should be possible to write: `requires transitive;`, which works, and also `requires transitive transitive;`, which currently does not work:
>> 
>> $ javac -d out/ --module-source-path . transitive/module-info.java test/module-info.java
>> test/module-info.java:2: error: repeated modifier
>>     requires transitive transitive;
>>                         ^
>> test/module-info.java:2: error: <identifier> expected
>>     requires transitive transitive;
>>                                   ^
>> 2 errors
>> 
>> 
>> The proposed solution is to properly handle lookahead if the transitive flag has already been seen.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

FWIW, this is a recent problem caused by:
https://bugs.openjdk.org/browse/JDK-8345058

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

PR Comment: https://git.openjdk.org/jdk/pull/22460#issuecomment-2511600234

From abimpoudis at openjdk.org  Mon Dec  2 14:09:22 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 2 Dec 2024 14:09:22 GMT
Subject: RFR: 8343932: Error when parsing qualified generic type test pattern
 in switch
Message-ID: <KwhStiWuQ9nMu0SbSWV8TKj4rB7wvrMWfzYffN7Y7-c=.62f5bcee-34cb-4da5-8dae-ae40b3232839@github.com>

Addressing issue in the`analyzePattern` with qualified type patterns (presence of `DOT`).

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

Commit messages:
 - 8343932: Error when parsing qualified generic type test pattern in switch

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

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

From acobbs at openjdk.org  Mon Dec  2 14:20:46 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Dec 2024 14:20:46 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v4]
In-Reply-To: <j137JhLhrPIWesa1i4f7ZmV5nzzIRRvmWL7C3FPmloc=.0226fe5e-182d-4752-b0fd-91a82c454e74@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
 <j137JhLhrPIWesa1i4f7ZmV5nzzIRRvmWL7C3FPmloc=.0226fe5e-182d-4752-b0fd-91a82c454e74@github.com>
Message-ID: <YitFWvn-pJjTVaaks7g-jZhp3caxTAzH69wDzKImn0Q=.ffd4695c-9367-405c-a5f6-5f98453633aa@github.com>

On Mon, 2 Dec 2024 10:07:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment by being less Streamy.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 446:
> 
>> 444:         EnumSet<LintCategory> result = LintCategory.newEmptySet();
>> 445:         Attribute.Array values = (Attribute.Array)suppressWarnings.member(names.value);
>> 446:         for (Attribute value : values.values) {
> 
> I think this loop is more stream-friendly - e.g. you start from `values.values` then:
> * `flatMap` using `Optional.of(value).stream()`
> * `map` (using `LintCategory::get`, as now)
> * `collect` to a new enum set
> 
> This allows to skip `ifPresent` check (subsumed by flatMap) and also the `result.add`. But, you'll end up with a complex expression inside the flat map (`Optional.of((String)((Attribute.Constant)value).value)`). So I'll leave to you whether this is worth it.

I used a loop based on the "use imperative logic" suggestion, but maybe that's not what you meant... In any case I agree it's somehow not fully satisfying, as there's no ideal solution here because of all the casting and null checking required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1865930427

From acobbs at openjdk.org  Mon Dec  2 14:20:47 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Dec 2024 14:20:47 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v4]
In-Reply-To: <tA9EZW-h2236Lsp9dVxNCz7Ixkup4VP_1o-OOsp7Nm0=.472c9012-40a5-432e-bf7e-02f9096f886b@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
 <MYE9CU4RncGBBKSEMrBorGY87ZfX4o6X-euNuF-7VZM=.e69a6fe0-33ae-47c3-952e-5acbb2267dbf@github.com>
 <tA9EZW-h2236Lsp9dVxNCz7Ixkup4VP_1o-OOsp7Nm0=.472c9012-40a5-432e-bf7e-02f9096f886b@github.com>
Message-ID: <RU78ItQlb_k949HMjjeQ82ymamrFTTW7QI6HLE7ErMY=.597faa14-93d2-4ba1-8778-285f687106eb@github.com>

On Mon, 2 Dec 2024 13:38:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java line 717:
>> 
>>> 715:                                                   processor, log, lint));
>>> 716:                     if (lint && !patternAdded) {
>>> 717:                         log.warning(PROCESSING, null, Warnings.ProcDuplicateSupportedAnnotation(annotationPattern,
>> 
>> Did you run all langtools tests? I believe that if you change these, some test output will be broken, as an extra `[processing]` will be emitted. I'm seeing this while playing in a related area.
>
> Example: test/langtools/tools/doclint/AnonClassTest.java

> Did you run all langtools tests? 

I did not run any tests beyond those that are run by GA - but they are all passing.

> Example: test/langtools/tools/doclint/AnonClassTest.java

When I run that test manually it passes... are you seeing it fail?


$ make test TEST="test/langtools/tools/doclint/AnonClassTest.java"
Building target 'test' in configuration 'macosx-aarch64-server-release'
Test selection 'test/langtools/tools/doclint/AnonClassTest.java', will run:
* jtreg:test/langtools/tools/doclint/AnonClassTest.java

Running test 'jtreg:test/langtools/tools/doclint/AnonClassTest.java'
Passed: tools/doclint/AnonClassTest.java
Test results: passed: 1
Report written to /Users/archie/proj/jdk/build/macosx-aarch64-server-release/test-results/jtreg_test_langtools_tools_doclint_AnonClassTest_java/html/report.html
Results written to /Users/archie/proj/jdk/build/macosx-aarch64-server-release/test-support/jtreg_test_langtools_tools_doclint_AnonClassTest_java
Finished running test 'jtreg:test/langtools/tools/doclint/AnonClassTest.java'
Test report is stored in build/macosx-aarch64-server-release/test-results/jtreg_test_langtools_tools_doclint_AnonClassTest_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/langtools/tools/doclint/AnonClassTest.java
                                                         1     1     0     0   
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'macosx-aarch64-server-release'

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1865930657

From mcimadamore at openjdk.org  Mon Dec  2 14:38:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 14:38:39 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v4]
In-Reply-To: <RU78ItQlb_k949HMjjeQ82ymamrFTTW7QI6HLE7ErMY=.597faa14-93d2-4ba1-8778-285f687106eb@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <IoEktynfX3dpDfPyKvlWLxaem8OM6hzqctfaAhT7-PE=.e0b169e0-3dcd-412e-9c8d-658e1c354622@github.com>
 <MYE9CU4RncGBBKSEMrBorGY87ZfX4o6X-euNuF-7VZM=.e69a6fe0-33ae-47c3-952e-5acbb2267dbf@github.com>
 <tA9EZW-h2236Lsp9dVxNCz7Ixkup4VP_1o-OOsp7Nm0=.472c9012-40a5-432e-bf7e-02f9096f886b@github.com>
 <RU78ItQlb_k949HMjjeQ82ymamrFTTW7QI6HLE7ErMY=.597faa14-93d2-4ba1-8778-285f687106eb@github.com>
Message-ID: <_BBGaHpibjToBupr4912wTd3-KZJRh4yEc30A5F0blo=.7113270a-4876-45b2-857e-c0ff271a9f60@github.com>

On Mon, 2 Dec 2024 14:17:52 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Example: test/langtools/tools/doclint/AnonClassTest.java
>
>> Did you run all langtools tests? 
> 
> I did not run any tests beyond those that are run by GA - but they are all passing.
> 
>> Example: test/langtools/tools/doclint/AnonClassTest.java
> 
> When I run that test manually it passes... are you seeing it fail?
> 
> 
> $ make test TEST="test/langtools/tools/doclint/AnonClassTest.java"
> Building target 'test' in configuration 'macosx-aarch64-server-release'
> Test selection 'test/langtools/tools/doclint/AnonClassTest.java', will run:
> * jtreg:test/langtools/tools/doclint/AnonClassTest.java
> 
> Running test 'jtreg:test/langtools/tools/doclint/AnonClassTest.java'
> Passed: tools/doclint/AnonClassTest.java
> Test results: passed: 1
> Report written to /Users/archie/proj/jdk/build/macosx-aarch64-server-release/test-results/jtreg_test_langtools_tools_doclint_AnonClassTest_java/html/report.html
> Results written to /Users/archie/proj/jdk/build/macosx-aarch64-server-release/test-support/jtreg_test_langtools_tools_doclint_AnonClassTest_java
> Finished running test 'jtreg:test/langtools/tools/doclint/AnonClassTest.java'
> Test report is stored in build/macosx-aarch64-server-release/test-results/jtreg_test_langtools_tools_doclint_AnonClassTest_java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/langtools/tools/doclint/AnonClassTest.java
>                                                          1     1     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'test' in configuration 'macosx-aarch64-server-release'

That seems ok. So probably there's something else broken in my repository. Tests do seem green with this PR, so that seems to point at a local issue on my part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1865962944

From mcimadamore at openjdk.org  Mon Dec  2 15:59:46 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 15:59:46 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
Message-ID: <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>

On Fri, 29 Nov 2024 18:46:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Agree... one of the best ways to ensure a policy is correctly followed is to make the build fail when it's not :)
>
> Filed:
> 
> https://bugs.openjdk.org/browse/JDK-8345263
> 
> I will take a look.

Initial stab:
https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:lint_warning_strong_checks?expand=1

The idea is to mark in compiler.properties which keys are associated to which lint category, and track the association in the generated `CompilerProperties` file. Then we can just drop the additional `LintCategory` parameter from all the call sites.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1866109145

From jlahoda at openjdk.org  Mon Dec  2 16:07:37 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 2 Dec 2024 16:07:37 GMT
Subject: RFR: 8343932: Error when parsing qualified generic type test
 pattern in switch
In-Reply-To: <KwhStiWuQ9nMu0SbSWV8TKj4rB7wvrMWfzYffN7Y7-c=.62f5bcee-34cb-4da5-8dae-ae40b3232839@github.com>
References: <KwhStiWuQ9nMu0SbSWV8TKj4rB7wvrMWfzYffN7Y7-c=.62f5bcee-34cb-4da5-8dae-ae40b3232839@github.com>
Message-ID: <947djQ1WE45HXSz20yW1bIlAuTNGAKpmhH-Mp8E3Kgg=.395e666a-7b86-40ff-9ab3-15909ad3fcc4@github.com>

On Mon, 2 Dec 2024 14:04:12 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Addressing issue in the`analyzePattern` with qualified type patterns (presence of `DOT`).

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22487#pullrequestreview-2473132440

From liach at openjdk.org  Mon Dec  2 16:54:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Dec 2024 16:54:52 GMT
Subject: RFR: 8345319: Fix the tag type in PoolEntry and AnnotationValue
Message-ID: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>

Change the return type of PoolEntry and AnnotationValue tags to int, as in TypeAnnotation TargetType and StackMapFrameInfo frameType.  The main impact is that AnnotationValue tags should be converted to char before printing now.

Please review the associated CSR for this hotfix as well.

Testing: classfile and javap, tier 1-3 in progress

Pinging @lukellmann

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

Commit messages:
 - 8345319: Fix the tag type in PoolEntry and AnnotationValue

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

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

From acobbs at openjdk.org  Mon Dec  2 17:42:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Dec 2024 17:42:39 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
Message-ID: <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>

On Mon, 2 Dec 2024 15:57:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Filed:
>> 
>> https://bugs.openjdk.org/browse/JDK-8345263
>> 
>> I will take a look.
>
> Initial stab:
> https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:lint_warning_strong_checks?expand=1
> 
> The idea is to mark in compiler.properties which keys are associated to which lint category, and track the association in the generated `CompilerProperties` file. Then we can just drop the additional `LintCategory` parameter from all the call sites.

I like that a lot - very nice!

I have one comment in two parts...

(1) Even though the following current idiom is verbose and contains redundancy:

if (lint.isEnabled(LintCategory.DEP_ANN))
    log.warn(LintCategory.DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation));

that redundancy has a nice side effect which is that it makes it easy to spot a mismatch between the lint category being tested and the lint category of the subsequent warning, where as your patch makes it easier to make a mistake like this:

if (lint.isEnabled(LintCategory.DEPRECATION))
    log.warn(pos, Warnings.MissingDeprecatedAnnotation));

Such a mismatch would result in a bug causing a very frustrating (dis)appearance of some warning, potentially failing builds, etc.

(2) The connection of a warning to a lint category, which is based on a properties file comment line, could easily get out of sync with the code without notice causing similar problems to (1). E.g., someone could put the wrong category in the comment (or change it later in the file but not the code), or accidentally forget to add the comment line, etc.

Both (1) and (2) could be addressed easily I think - for example, what if we baked the lint category more firmly into the property name, and used that to make it more visible in the code?

Example:

compiler.warn[dep-ann].missing.deprecated.annotation=\
    deprecated item is not annotated with @Deprecated


if (lint.isEnabled(LintCategory.DEP_ANN))
    log.warn(pos, Warnings.LintDepAnn.MissingDeprecatedAnnotation));


That way it's more visually obvious that the warning is associated to the `DEP_ANN` lint category in both the code and the properties file, and so they hopefully would have a harder time getting out of sync.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1866311399

From darcy at openjdk.org  Mon Dec  2 17:46:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Dec 2024 17:46:43 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v7]
In-Reply-To: <LbvK_7HLZxB4HwBEFbYci9EJ8wQtWQZta-eKxI9dT0M=.a148362e-a086-4a0c-b983-c665981cb82f@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <LbvK_7HLZxB4HwBEFbYci9EJ8wQtWQZta-eKxI9dT0M=.a148362e-a086-4a0c-b983-c665981cb82f@github.com>
Message-ID: <oj79-C7J8fUDcaCcL_delOqSO2Wa9JPDgMUeeFRPKfQ=.e0d920d1-18ed-4b5a-b2f6-310509e5b2ac@github.com>

On Mon, 25 Nov 2024 11:40:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo 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 11 additional commits since the last revision:
> 
>  - Update --release 24 symbol information for JDK 24 build 25
>    
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 24
>    
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 23
>    
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 22
>    
>    The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 21
>    
>    The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
>  - Add forgotten .jcheck/conf
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/88e8ad28...4d3461da

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2473453018

From mcimadamore at openjdk.org  Mon Dec  2 17:56:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 17:56:37 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
Message-ID: <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>

On Mon, 2 Dec 2024 17:39:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Initial stab:
>> https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:lint_warning_strong_checks?expand=1
>> 
>> The idea is to mark in compiler.properties which keys are associated to which lint category, and track the association in the generated `CompilerProperties` file. Then we can just drop the additional `LintCategory` parameter from all the call sites.
>
> I like that a lot - very nice!
> 
> I have one comment in two parts...
> 
> (1) Even though the following current idiom is verbose and contains redundancy:
> 
> if (lint.isEnabled(LintCategory.DEP_ANN))
>     log.warn(LintCategory.DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation));
> 
> that redundancy has a nice side effect which is that it makes it easy to spot a mismatch between the lint category being tested and the lint category of the subsequent warning, where as your patch makes it easier to make a mistake like this:
> 
> if (lint.isEnabled(LintCategory.DEPRECATION))
>     log.warn(pos, Warnings.MissingDeprecatedAnnotation));
> 
> Such a mismatch would result in a bug causing a very frustrating (dis)appearance of some warning, potentially failing builds, etc.
> 
> (2) The connection of a warning to a lint category, which is based on a properties file comment line, could easily get out of sync with the code without notice causing similar problems to (1). E.g., someone could put the wrong category in the comment (or change it later in the file but not the code), or accidentally forget to add the comment line, etc.
> 
> Both (1) and (2) could be addressed easily I think - for example, what if we baked the lint category more firmly into the property name, and used that to make it more visible in the code?
> 
> Example:
> 
> compiler.warn[dep-ann].missing.deprecated.annotation=\
>     deprecated item is not annotated with @Deprecated
> 
> 
> if (lint.isEnabled(LintCategory.DEP_ANN))
>     log.warn(pos, Warnings.LintDepAnn.MissingDeprecatedAnnotation));
> 
> 
> That way it's more visually obvious that the warning is associated to the `DEP_ANN` lint category in both the code and the properties file, and so they hopefully would have a harder time getting out of sync.

Changing the key is possible. I even prototyped that - but ran out of steam when I realized that all compiler negative tests required some fixing. So I'm a bit wary of going down that path.

IMHO, the issue with stuff like:


if (lint.isEnabled(LintCategory.DEP_ANN))
    log.warn(LintCategory.DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation));


Is that compiler code should even bother to do this! Ideally, you might want to have a single routine:


log.warnIfEnabled(DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation)


This could test whether `DEP_ANN` is enabled _and_ also check that the provided warning key has the correct category set

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1866329026

From mcimadamore at openjdk.org  Mon Dec  2 17:56:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 17:56:38 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
Message-ID: <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>

On Mon, 2 Dec 2024 17:52:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> `log.warnIfEnabled(DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation)`

Or, even better:

`log.warnIfEnabled(pos, Warnings.MissingDeprecatedAnnotation)`

(e.g. just use the warning key option for the `isEnabled` check)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1866331563

From mcimadamore at openjdk.org  Mon Dec  2 17:59:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Dec 2024 17:59:37 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
Message-ID: <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>

On Mon, 2 Dec 2024 17:53:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Changing the key is possible. I even prototyped that - but ran out of steam when I realized that all compiler negative tests required some fixing. So I'm a bit wary of going down that path.
>> 
>> IMHO, the issue with stuff like:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DEP_ANN))
>>     log.warn(LintCategory.DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation));
>> 
>> 
>> Is that compiler code should even bother to do this! Ideally, you might want to have a single routine:
>> 
>> 
>> log.warnIfEnabled(DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation)
>> 
>> 
>> This could test whether `DEP_ANN` is enabled _and_ also check that the provided warning key has the correct category set
>
>> `log.warnIfEnabled(DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation)`
> 
> Or, even better:
> 
> `log.warnIfEnabled(pos, Warnings.MissingDeprecatedAnnotation)`
> 
> (e.g. just use the warning key option for the `isEnabled` check)

Another observation: it would be better if we had two distinct set of diagnostics; warnings and lint warnings. If one couldn't be passed in place of the other that will force clients to use the correct `log` method. Which might make it easier to check that all the places issuing a lint warning also check as to whether the warning is enabled.

(that said, we can't check for enable-ment in all cases - e.g. for lint warnings in the tokenizer, so there will always be some ad-hocness somewhere, I think. I think we win if we can find something that works in most cases, but we can't make everything statically type-checkable, not without significant cost and effort).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1866336502

From liach at openjdk.org  Mon Dec  2 18:06:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Dec 2024 18:06:53 GMT
Subject: RFR: 8345319: Fix the tag type in PoolEntry and AnnotationValue
 [v2]
In-Reply-To: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>
References: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>
Message-ID: <6tnVDgneQL3QfoDhL7y1fL2z7ROvo4gLhWAVARU4EWg=.3c08386c-8034-469c-86fb-97db4c58817f@github.com>

> Change the return type of PoolEntry and AnnotationValue tags to int, as in TypeAnnotation TargetType and StackMapFrameInfo frameType.  The main impact is that AnnotationValue tags should be converted to char before printing now.
> 
> Please review the associated CSR for this hotfix as well.
> 
> Testing: classfile and javap, tier 1-3 in progress
> 
> Pinging @lukellmann

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

  Fix AnnotationDefaultTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22489/files
  - new: https://git.openjdk.org/jdk/pull/22489/files/a025dee6..5d59acd5

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

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

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

From acobbs at openjdk.org  Mon Dec  2 18:38:49 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Dec 2024 18:38:49 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
Message-ID: <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGancwSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>

On Mon, 2 Dec 2024 17:57:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> `log.warnIfEnabled(DEP_ANN, pos, Warnings.MissingDeprecatedAnnotation)`
>> 
>> Or, even better:
>> 
>> `log.warnIfEnabled(pos, Warnings.MissingDeprecatedAnnotation)`
>> 
>> (e.g. just use the warning key option for the `isEnabled` check)
>
> Another observation: it would be better if we had two distinct set of diagnostics; warnings and lint warnings. If one couldn't be passed in place of the other that will force clients to use the correct `log` method. Which might make it easier to check that all the places issuing a lint warning also check as to whether the warning is enabled.
> 
> (that said, we can't check for enable-ment in all cases - e.g. for lint warnings in the tokenizer, so there will always be some ad-hocness somewhere, I think. I think we win if we can find something that works in most cases, but we can't make everything statically type-checkable, not without significant cost and effort).

> Changing the key is possible. I even prototyped that - but ran out of steam when I realized that all compiler negative tests required some fixing. So I'm a bit wary of going down that path.

I think we could still minimize the chance for mismatches without changing the keys, e.g. by using combining my idea of baking the lint category into the warning name with your idea of having two distinct set of diagnostics.

For example:

# lint: dep-ann
compiler.warn.missing.deprecated.annotation=\
    deprecated item is not annotated with @Deprecated

then in the code we have this - which is both type safe and visually confirms the lint category:

log.warn(pos, LintWarnings.DepAnn.MissingDeprecatedAnnotation);


> Ideally, you might want to have a single routine...

Agreed.. but (minor detail) of course that requires a `lint` object, e.g.:

lint.warnIfEnabled(log, pos, LintWarnings.DepAnn.MissingDeprecatedAnnotation);

> we can't check for enable-ment in all cases...

Actually that's not the problem - I think it's always possible to check for enablement. Put another way, all warnings that are generated in a place where it's not possible to check for enablement are not lint warnings. Put yet another way, there is no lint warning in category `foo` that is generated when `-Xlint:-foo` is given.

The limitations that do occur are:
* In some places in the code, we have to check enablement "manually" by inspecting `Options` directly because no `lint` object is available. So you can't use `Lint.warnIfEnabled()` but so what, it's just a convenience.
* In some places in the code, there is no way to apply `@SuppressWarnings` (e.g., `output-file-clash`). No problem, you just always use the root `Lint` singleton (or `Options` directly).

> but we can't make everything statically type-checkable, not without significant cost and effort...

See the first suggestion in this comment... would that work?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1866393483

From darcy at openjdk.org  Mon Dec  2 18:51:47 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Dec 2024 18:51:47 GMT
Subject: RFR: 8345324: Update comment in SourceVersion for language evolution
 history for changes in 24
Message-ID: <yuVX5Fb2ejpUO9BgBYEVDgLBQaMDfznWgltJSthGdn4=.cf619982-7987-434e-a709-fbc1a81cb59c@github.com>

Update source-level, in other words non-javadoc, comment to describe the actual language changes made in 24.

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

Commit messages:
 - JDK-8345324: Update comment in SourceVersion for language evolution history for changes in 24

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

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

From iris at openjdk.org  Mon Dec  2 19:02:38 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 2 Dec 2024 19:02:38 GMT
Subject: RFR: 8345324: Update comment in SourceVersion for language
 evolution history for changes in 24
In-Reply-To: <yuVX5Fb2ejpUO9BgBYEVDgLBQaMDfznWgltJSthGdn4=.cf619982-7987-434e-a709-fbc1a81cb59c@github.com>
References: <yuVX5Fb2ejpUO9BgBYEVDgLBQaMDfznWgltJSthGdn4=.cf619982-7987-434e-a709-fbc1a81cb59c@github.com>
Message-ID: <FOqefRgWzzjtvxVdPIgs1ifKHR04XpZT_fcIS5VWUTI=.e3bc577d-52ef-4a96-9cbb-957d28f94d8f@github.com>

On Mon, 2 Dec 2024 18:46:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update source-level, in other words non-javadoc, comment to describe the actual language changes made in 24.

List of language JEPs and preview status confirmed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22495#pullrequestreview-2473655841

From darcy at openjdk.org  Mon Dec  2 19:46:43 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 2 Dec 2024 19:46:43 GMT
Subject: Integrated: 8345324: Update comment in SourceVersion for language
 evolution history for changes in 24
In-Reply-To: <yuVX5Fb2ejpUO9BgBYEVDgLBQaMDfznWgltJSthGdn4=.cf619982-7987-434e-a709-fbc1a81cb59c@github.com>
References: <yuVX5Fb2ejpUO9BgBYEVDgLBQaMDfznWgltJSthGdn4=.cf619982-7987-434e-a709-fbc1a81cb59c@github.com>
Message-ID: <BxQrr8o1RgrOBy8CbByc4WCOKxs4_3WczMlwrutVdI0=.4f8124c7-ec73-450a-bf9a-bf3a6368ec1b@github.com>

On Mon, 2 Dec 2024 18:46:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update source-level, in other words non-javadoc, comment to describe the actual language changes made in 24.

This pull request has now been integrated.

Changeset: 525f33ba
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/525f33baaea2cc559ddd2396611a7734a64a9d66
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8345324: Update comment in SourceVersion for language evolution history for changes in 24

Reviewed-by: iris

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

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

From prappo at openjdk.org  Mon Dec  2 22:57:01 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 2 Dec 2024 22:57:01 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v8]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <84R8Q2uInoyc8jKLyJgidkAShWn_e7K4zVfX7zAu63I=.15f7f472-7a50-4040-9f76-03179610f478@github.com>

> Prepare for JDK 25.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Update --release 24 symbol information for JDK 24 build 26
   
   The macOS/AArch64 build 26 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
   
   # Conflicts:
   #	src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
 - Update --release 24 symbol information for JDK 24 build 25
   
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 24
   
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 23
   
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - ... and 3 more: https://git.openjdk.org/jdk/compare/3a3bcd53...fc1d8b82

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

Changes: https://git.openjdk.org/jdk/pull/21763/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=07
  Stats: 6176 lines in 98 files changed: 6127 ins; 3 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/21763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21763/head:pull/21763

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

From iris at openjdk.org  Tue Dec  3 00:42:46 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 3 Dec 2024 00:42:46 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v8]
In-Reply-To: <84R8Q2uInoyc8jKLyJgidkAShWn_e7K4zVfX7zAu63I=.15f7f472-7a50-4040-9f76-03179610f478@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <84R8Q2uInoyc8jKLyJgidkAShWn_e7K4zVfX7zAu63I=.15f7f472-7a50-4040-9f76-03179610f478@github.com>
Message-ID: <iT0QsaB9nuoT6JrS8uAARRMnwCR5Mj2gl3vHD2_6Ixk=.7b31659b-8f55-4e6b-9443-6928c2ef2229@github.com>

On Mon, 2 Dec 2024 22:57:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Update --release 24 symbol information for JDK 24 build 26
>    
>    The macOS/AArch64 build 26 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>    
>    # Conflicts:
>    #	src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>  - Update --release 24 symbol information for JDK 24 build 25
>    
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 24
>    
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 23
>    
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 22
>    
>    The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/3a3bcd53...fc1d8b82

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2474229433

From abimpoudis at openjdk.org  Tue Dec  3 09:21:45 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 3 Dec 2024 09:21:45 GMT
Subject: Integrated: 8343932: Error when parsing qualified generic type test
 pattern in switch
In-Reply-To: <KwhStiWuQ9nMu0SbSWV8TKj4rB7wvrMWfzYffN7Y7-c=.62f5bcee-34cb-4da5-8dae-ae40b3232839@github.com>
References: <KwhStiWuQ9nMu0SbSWV8TKj4rB7wvrMWfzYffN7Y7-c=.62f5bcee-34cb-4da5-8dae-ae40b3232839@github.com>
Message-ID: <QihhkVEbrqmYGlfvW1zWPZZBJvDqKnUINNxI-c9js3c=.9c865cf3-4f1f-4e6f-ada6-ba0dd6475eb5@github.com>

On Mon, 2 Dec 2024 14:04:12 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Addressing issue in the`analyzePattern` with qualified type patterns (presence of `DOT`).

This pull request has now been integrated.

Changeset: ec93cc50
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec93cc50988c4bd58bf599e007d09824702720b2
Stats:     58 lines in 2 files changed: 57 ins; 0 del; 1 mod

8343932: Error when parsing qualified generic type test pattern in switch

Reviewed-by: jlahoda

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

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

From mcimadamore at openjdk.org  Tue Dec  3 13:13:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Dec 2024 13:13:40 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGancwSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
Message-ID: <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>

On Mon, 2 Dec 2024 18:35:44 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> See the first suggestion in this comment... would that work?

I like that idea. So, one concrete proposal might be:

1. have LintWarning as a subclass of Warning
2. have CompilerProperties reflect the lint categories, by having different nested classes where LintWarnings factories and fields would appear (one nested class per lint category)
3. don't change `AbstractLog` - that will still offer a `log` method that takes a `Warning` that can be used for both regular warning and lint warnings (in case the lint warning is not really suppressible)
4. Add a method in `lint` to "logIfEnabled". This method accepts a `LintWarning`, not a warning. So we get some static type checking.

(That said, if lint warnings are to be reported using (4), what would be the added benefit of (2) ? )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1867697913

From vromero at openjdk.org  Tue Dec  3 14:56:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Dec 2024 14:56:41 GMT
Subject: RFR: 8345248: Module name 'transitive' not accepted for `requires
 transitive` [v2]
In-Reply-To: <8jIxgBtGPpMFHk0reDWvvSQKifhxALDsnlH9_JEXZdE=.07575c6c-4832-42e1-b9a2-df25a58acfae@github.com>
References: <BdvX8oKPAwQCQFwvg4jAVqO_YldAQUYxmw6XP3IXJPU=.0370d7a1-5ee8-4fed-802f-8e02bc5f3817@github.com>
 <8jIxgBtGPpMFHk0reDWvvSQKifhxALDsnlH9_JEXZdE=.07575c6c-4832-42e1-b9a2-df25a58acfae@github.com>
Message-ID: <A2v66RVCEK9avE0i6X2OTL9YOhIXG084wIyAXFRn8X8=.8a71020c-29bc-4a08-8fb0-9f452b5775d9@github.com>

On Fri, 29 Nov 2024 14:30:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Considering module named `transitive`, it should be possible to write: `requires transitive;`, which works, and also `requires transitive transitive;`, which currently does not work:
>> 
>> $ javac -d out/ --module-source-path . transitive/module-info.java test/module-info.java
>> test/module-info.java:2: error: repeated modifier
>>     requires transitive transitive;
>>                         ^
>> test/module-info.java:2: error: <identifier> expected
>>     requires transitive transitive;
>>                                   ^
>> 2 errors
>> 
>> 
>> The proposed solution is to properly handle lookahead if the transitive flag has already been seen.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22460#pullrequestreview-2475941695

From mcimadamore at openjdk.org  Tue Dec  3 15:19:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Dec 2024 15:19:39 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
Message-ID: <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>

On Tue, 3 Dec 2024 13:10:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Changing the key is possible. I even prototyped that - but ran out of steam when I realized that all compiler negative tests required some fixing. So I'm a bit wary of going down that path.
>> 
>> I think we could still minimize the chance for mismatches without changing the keys, e.g. by using combining my idea of baking the lint category into the warning name with your idea of having two distinct set of diagnostics.
>> 
>> For example:
>> 
>> # lint: dep-ann
>> compiler.warn.missing.deprecated.annotation=\
>>     deprecated item is not annotated with @Deprecated
>> 
>> then in the code we have this - which is both type safe and visually confirms the lint category:
>> 
>> log.warn(pos, LintWarnings.DepAnn.MissingDeprecatedAnnotation);
>> 
>> 
>>> Ideally, you might want to have a single routine...
>> 
>> Agreed.. but (minor detail) of course that requires a `lint` object, e.g.:
>> 
>> lint.warnIfEnabled(log, pos, LintWarnings.DepAnn.MissingDeprecatedAnnotation);
>> 
>>> we can't check for enable-ment in all cases...
>> 
>> Actually that's not the problem - I think it's always possible to check for enablement. Put another way, all warnings that are generated in a place where it's not possible to check for enablement are not lint warnings. Put yet another way, there is no lint warning in category `foo` that is generated when `-Xlint:-foo` is given.
>> 
>> The limitations that do occur are:
>> * In some places in the code, we have to check enablement "manually" by inspecting `Options` directly because no `lint` object is available. So you can't use `Lint.warnIfEnabled()` but so what, it's just a convenience.
>> * In some places in the code, there is no way to apply `@SuppressWarnings` (e.g., `output-file-clash`). No problem, you just always use the root `Lint` singleton (or `Options` directly).
>> 
>>> but we can't make everything statically type-checkable, not without significant cost and effort...
>> 
>> See the first suggestion in this comment... would that work?
>
>> See the first suggestion in this comment... would that work?
> 
> I like that idea. So, one concrete proposal might be:
> 
> 1. have LintWarning as a subclass of Warning
> 2. have CompilerProperties reflect the lint categories, by having different nested classes where LintWarnings factories and fields would appear (one nested class per lint category)
> 3. don't change `AbstractLog` - that will still offer a `log` method that takes a `Warning` that can be used for both regular warning and lint warnings (in case the lint warning is not really suppressible)
> 4. Add a method in `lint` to "logIfEnabled". This method accepts a `LintWarning`, not a warning. So we get some static type checking.
> 
> (That said, if lint warnings are to be reported using (4), what would be the added benefit of (2) ? )

There's also another issue with `logIfEnabled`. While that seems to be the majority of cases, there is a non-trivial amount of uses where the is-enabled check occurs at some outer level, at which point the inner code just warns w/o a check (see all the serial warnings inside `Check` -- but there's several other cases too). So, not sure how much that infrastructure would be worth adding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1867920414

From acobbs at openjdk.org  Tue Dec  3 15:25:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Dec 2024 15:25:40 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
Message-ID: <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>

On Tue, 3 Dec 2024 15:17:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> See the first suggestion in this comment... would that work?
>> 
>> I like that idea. So, one concrete proposal might be:
>> 
>> 1. have LintWarning as a subclass of Warning
>> 2. have CompilerProperties reflect the lint categories, by having different nested classes where LintWarnings factories and fields would appear (one nested class per lint category)
>> 3. don't change `AbstractLog` - that will still offer a `log` method that takes a `Warning` that can be used for both regular warning and lint warnings (in case the lint warning is not really suppressible)
>> 4. Add a method in `lint` to "logIfEnabled". This method accepts a `LintWarning`, not a warning. So we get some static type checking.
>> 
>> (That said, if lint warnings are to be reported using (4), what would be the added benefit of (2) ? )
>
> There's also another issue with `logIfEnabled`. While that seems to be the majority of cases, there is a non-trivial amount of uses where the is-enabled check occurs at some outer level, at which point the inner code just warns w/o a check (see all the serial warnings inside `Check` -- but there's several other cases too). So, not sure how much that infrastructure would be worth adding.

> So, one concrete proposal might be:
> 
> - have LintWarning as a subclass of Warning
> - don't change `AbstractLog` - that will still offer a `log` method that takes a `Warning` that can be used for both regular warning and lint warnings (in case the lint warning is not really suppressible)

I'm with you except for these two items. I believe that every warning associated with a lint category is always suppressible at least via the `-Xlint:-foo` command line flag. Do you have any specific counter-examples in mind?

If that's true, then we should be able to go a little further:

1. Have `LintWarning` be a sibling class, not a subclass, of `Warning`
2. Have `CompilerProperties` reflect the lint categories, by having different nested classes where `LintWarning` factories and fields would appear (one nested class per lint category)
3. Change `AbstractLog` to add methods taking a `LintWarning`; these will automatically add the "[foo]" prefix to the warning text that is emitted
4. Add a convenience instance method `Lint.logIfEnabled()` which accepts a `LintWarning`, does the enablement check, and then (if the category is enabled) invokes the new `Log` method added in the previous step.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1867933843

From acobbs at openjdk.org  Tue Dec  3 15:31:41 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Dec 2024 15:31:41 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
Message-ID: <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>

On Tue, 3 Dec 2024 15:23:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> There's also another issue with `logIfEnabled`. While that seems to be the majority of cases, there is a non-trivial amount of uses where the is-enabled check occurs at some outer level, at which point the inner code just warns w/o a check (see all the serial warnings inside `Check` -- but there's several other cases too). So, not sure how much that infrastructure would be worth adding.
>
>> So, one concrete proposal might be:
>> 
>> - have LintWarning as a subclass of Warning
>> - don't change `AbstractLog` - that will still offer a `log` method that takes a `Warning` that can be used for both regular warning and lint warnings (in case the lint warning is not really suppressible)
> 
> I'm with you except for these two items. I believe that every warning associated with a lint category is always suppressible at least via the `-Xlint:-foo` command line flag. Do you have any specific counter-examples in mind?
> 
> If that's true, then we should be able to go a little further:
> 
> 1. Have `LintWarning` be a sibling class, not a subclass, of `Warning`
> 2. Have `CompilerProperties` reflect the lint categories, by having different nested classes where `LintWarning` factories and fields would appear (one nested class per lint category)
> 3. Change `AbstractLog` to add methods taking a `LintWarning`; these will automatically add the "[foo]" prefix to the warning text that is emitted
> 4. Add a convenience instance method `Lint.logIfEnabled()` which accepts a `LintWarning`, does the enablement check, and then (if the category is enabled) invokes the new `Log` method added in the previous step.

> There's also another issue with `logIfEnabled`. While that seems to be the majority of cases, there is a non-trivial amount of uses where the is-enabled check occurs at some outer level, at which point the inner code just warns w/o a check (see all the serial warnings inside `Check` -- but there's several other cases too). So, not sure how much that infrastructure would be worth adding.

I think it's still worth adding. It's just a convenience method, to be used when it's appropriate - which is in most cases - and not when it's not appropriate. In the inappropriate cases (like within `SerialTypeVisitor`), there's no change - we would just use `log()` like before. But we still accrue the cleanup benefit for most cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1867942813

From asotona at openjdk.org  Tue Dec  3 16:05:44 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Dec 2024 16:05:44 GMT
Subject: RFR: 8345319: Fix the tag type in PoolEntry and AnnotationValue
 [v2]
In-Reply-To: <6tnVDgneQL3QfoDhL7y1fL2z7ROvo4gLhWAVARU4EWg=.3c08386c-8034-469c-86fb-97db4c58817f@github.com>
References: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>
 <6tnVDgneQL3QfoDhL7y1fL2z7ROvo4gLhWAVARU4EWg=.3c08386c-8034-469c-86fb-97db4c58817f@github.com>
Message-ID: <vbpqaKAbBcUlSZ-VUXRhIYp4izYZezMXBKtfcO0Txdg=.8cfbb640-4bb8-4903-806d-ae02bd72c091@github.com>

On Mon, 2 Dec 2024 18:06:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Change the return type of PoolEntry and AnnotationValue tags to int, as in TypeAnnotation TargetType and StackMapFrameInfo frameType.  The main impact is that AnnotationValue tags should be converted to char before printing now.
>> 
>> Please review the associated CSR for this hotfix as well.
>> 
>> Testing: classfile and javap, tier 1-3 in progress
>> 
>> Pinging @lukellmann
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AnnotationDefaultTest

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22489#pullrequestreview-2476137338

From mcimadamore at openjdk.org  Tue Dec  3 16:07:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Dec 2024 16:07:41 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
 <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
Message-ID: <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>

On Tue, 3 Dec 2024 15:28:34 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> So, one concrete proposal might be:
>>> 
>>> - have LintWarning as a subclass of Warning
>>> - don't change `AbstractLog` - that will still offer a `log` method that takes a `Warning` that can be used for both regular warning and lint warnings (in case the lint warning is not really suppressible)
>> 
>> I'm with you except for these two items. I believe that every warning associated with a lint category is always suppressible at least via the `-Xlint:-foo` command line flag. Do you have any specific counter-examples in mind?
>> 
>> If that's true, then we should be able to go a little further:
>> 
>> 1. Have `LintWarning` be a sibling class, not a subclass, of `Warning`
>> 2. Have `CompilerProperties` reflect the lint categories, by having different nested classes where `LintWarning` factories and fields would appear (one nested class per lint category)
>> 3. Change `AbstractLog` to add methods taking a `LintWarning`; these will automatically add the "[foo]" prefix to the warning text that is emitted
>> 4. Add a convenience instance method `Lint.logIfEnabled()` which accepts a `LintWarning`, does the enablement check, and then (if the category is enabled) invokes the new `Log` method added in the previous step.
>
>> There's also another issue with `logIfEnabled`. While that seems to be the majority of cases, there is a non-trivial amount of uses where the is-enabled check occurs at some outer level, at which point the inner code just warns w/o a check (see all the serial warnings inside `Check` -- but there's several other cases too). So, not sure how much that infrastructure would be worth adding.
> 
> I think it's still worth adding. It's just a convenience method, to be used when it's appropriate - which is in most cases - and not when it's not appropriate. In the inappropriate cases (like within `SerialTypeVisitor`), there's no change - we would just use `log()` like before. But we still accrue the cleanup benefit for most cases.

> 3. Change `AbstractLog` to add methods taking a `LintWarning`; these will automatically add the "[foo]" prefix to the warning text that is emitted

In terms of user experience, what would be the difference between using `log(LintWarning)` and `log(Warning)` ? I believe there is a need for having a method that "just logs" because sometimes (see my previous message) the is-enabled check occurs somewhere else, far from where the diagnostic is logged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1868002845

From acobbs at openjdk.org  Tue Dec  3 16:44:45 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Dec 2024 16:44:45 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
 <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
 <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>
Message-ID: <BU6wRBTmfIhFXbJMxEd0zoJxmb2sZD6OC5envnsuUEY=.da89ea2a-06d7-4e9a-9750-501f0112dfc2@github.com>

On Tue, 3 Dec 2024 16:04:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> In terms of user experience, what would be the difference between using `log(LintWarning)` and `log(Warning)` ? I believe there is a need for having a method that "just logs" because sometimes (see my previous message) the is-enabled check occurs somewhere else, far from where the diagnostic is logged.

The methods `log(LintWarning)` and `log(Warning)` would behave the same. The reason I want both methods to exist is simply because I want `LintWarning` to not be a subclass of `Warning`.

Here's why I think that's important:
* We are using the same English word "warning" to describe the following two things:
  * Generic compiler warnings that have nothing to do with lint. Example: `Warnings.InvalidUtf8InClassfile`
  * Compiler warnings that have an associated lint category. Example: `Warnings.MissingDeprecatedAnnotation`
* But really two things are distinct: they do not overlap, and every compiler "warning" is one or the other (and never both). _Practically speaking_, "generic warnings" and "lint warnings" are just as distinct from each other as are `Error`, `Note`, and `Fragment`. Therefore, we can make them peer classes with no inheritance relationship.
* Why is this helpful? Because the stronger type checking prevents possible mistakes like this:

// somewhere in the code
LintWarning lw = ...;

// somewhere else in the code
Warning w = lw;
log.warning(pos, w);

The result of the above mistake would be a lint warning emitted that:
* Does not have the "[foo]" prefix; and
* Possibly escapes being suppressed by `-Xlint:-foo` as it should.

Put another way, I don't see any reason to make `LintWarning` a subclass of `Warning` - so why do it??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1868062530

From liach at openjdk.org  Tue Dec  3 16:45:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 16:45:17 GMT
Subject: RFR: 8345343: Restore the preview status of
 java.lang.classfile.components package
Message-ID: <aDzabDCgbKYNmC56FZuxbxWLhJoYLh1CNSsw2U5FIPU=.76d4a509-b3e2-468e-82eb-5cb0e1b72359@github.com>

The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized. In the previous rounds of reviews by other engineers, most of the review efforts were devoted to other core modeling and API classes, and components was largely omitted; a few questions were asked, but no solution were proposed and the questions were forgotten.

To compensate in such a short time to the stabilization of JDK 24, we propose to restore the preview status of the java.lang.classfile.component package and its member classes. This allows us to better consider the role of this package and its members.

See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.

See the CSR for alternative solutions and why they were not chosen.

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

Commit messages:
 - 8345344: Restore the preview status of java.lang.classfile.components package

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

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

From liach at openjdk.org  Tue Dec  3 17:02:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 17:02:47 GMT
Subject: RFR: 8345319: Fix the tag type in PoolEntry and AnnotationValue
 [v2]
In-Reply-To: <6tnVDgneQL3QfoDhL7y1fL2z7ROvo4gLhWAVARU4EWg=.3c08386c-8034-469c-86fb-97db4c58817f@github.com>
References: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>
 <6tnVDgneQL3QfoDhL7y1fL2z7ROvo4gLhWAVARU4EWg=.3c08386c-8034-469c-86fb-97db4c58817f@github.com>
Message-ID: <cVoeRn__e-EsLV5RL0lmwHwFbGIrS7HFBaNyCy5A73U=.a8aba5b8-aa2b-42b8-a58d-35d4e3b5cfa6@github.com>

On Mon, 2 Dec 2024 18:06:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Change the return type of PoolEntry and AnnotationValue tags to int, as in TypeAnnotation TargetType and StackMapFrameInfo frameType.  The main impact is that AnnotationValue tags should be converted to char before printing now.
>> 
>> Please review the associated CSR for this hotfix as well.
>> 
>> Testing: classfile and javap, tier 1-3 in progress
>> 
>> Pinging @lukellmann
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix AnnotationDefaultTest

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22489#issuecomment-2515107148

From liach at openjdk.org  Tue Dec  3 17:02:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 17:02:48 GMT
Subject: Integrated: 8345319: Fix the tag type in PoolEntry and AnnotationValue
In-Reply-To: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>
References: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>
Message-ID: <e1oiJvhHOjrkwBr1JI7UPT-uCooaK_Wc79_ClXIa7Io=.46a44a8d-58eb-4cc5-bb2a-6073f6eea2ee@github.com>

On Mon, 2 Dec 2024 16:50:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> Change the return type of PoolEntry and AnnotationValue tags to int, as in TypeAnnotation TargetType and StackMapFrameInfo frameType.  The main impact is that AnnotationValue tags should be converted to char before printing now.
> 
> Please review the associated CSR for this hotfix as well.
> 
> Testing: classfile and javap, tier 1-3 in progress
> 
> Pinging @lukellmann

This pull request has now been integrated.

Changeset: 76e874c0
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76e874c08e6434747ac4f4cb4d2e2edcde163b2a
Stats:     46 lines in 7 files changed: 3 ins; 0 del; 43 mod

8345319: Fix the tag type in PoolEntry and AnnotationValue

Reviewed-by: asotona

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

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

From duke at openjdk.org  Tue Dec  3 17:44:47 2024
From: duke at openjdk.org (Luca Kellermann)
Date: Tue, 3 Dec 2024 17:44:47 GMT
Subject: RFR: 8345319: Fix the tag type in PoolEntry and AnnotationValue
 [v2]
In-Reply-To: <cVoeRn__e-EsLV5RL0lmwHwFbGIrS7HFBaNyCy5A73U=.a8aba5b8-aa2b-42b8-a58d-35d4e3b5cfa6@github.com>
References: <zJvxEQUluNNrSTCbzkQO2V05VU3uEBN1VDllKt5TU6I=.32b0ccf8-ae42-4c82-92a6-09ca4bc0d4b3@github.com>
 <6tnVDgneQL3QfoDhL7y1fL2z7ROvo4gLhWAVARU4EWg=.3c08386c-8034-469c-86fb-97db4c58817f@github.com>
 <cVoeRn__e-EsLV5RL0lmwHwFbGIrS7HFBaNyCy5A73U=.a8aba5b8-aa2b-42b8-a58d-35d4e3b5cfa6@github.com>
Message-ID: <zm4YIU7sYtQ2Uofblzc0-ATWxDTRK8NvXRB8gYgJb7o=.85885b4f-c169-4059-a490-d304c73ff2c7@github.com>

On Tue, 3 Dec 2024 16:59:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix AnnotationDefaultTest
>
> Thanks for the reviews!

@liach thanks :)

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

PR Comment: https://git.openjdk.org/jdk/pull/22489#issuecomment-2515206629

From mcimadamore at openjdk.org  Tue Dec  3 23:33:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Dec 2024 23:33:38 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <BU6wRBTmfIhFXbJMxEd0zoJxmb2sZD6OC5envnsuUEY=.da89ea2a-06d7-4e9a-9750-501f0112dfc2@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
 <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
 <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>
 <BU6wRBTmfIhFXbJMxEd0zoJxmb2sZD6OC5envnsuUEY=.da89ea2a-06d7-4e9a-9750-501f0112dfc2@github.com>
Message-ID: <G7veeTQGse_vX2QYr_pqwOcatpR7WpT_tl6sRhKMOS8=.d1dded8e-a8a9-4ac2-9d88-19af9623a767@github.com>

On Tue, 3 Dec 2024 16:41:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>>> 3. Change `AbstractLog` to add methods taking a `LintWarning`; these will automatically add the "[foo]" prefix to the warning text that is emitted
>> 
>> In terms of user experience, what would be the difference between using `log(LintWarning)` and `log(Warning)` ? I believe there is a need for having a method that "just logs" because sometimes (see my previous message) the is-enabled check occurs somewhere else, far from where the diagnostic is logged.
>
>> In terms of user experience, what would be the difference between using `log(LintWarning)` and `log(Warning)` ? I believe there is a need for having a method that "just logs" because sometimes (see my previous message) the is-enabled check occurs somewhere else, far from where the diagnostic is logged.
> 
> The methods `log(LintWarning)` and `log(Warning)` would behave the same. The reason I want both methods to exist is simply because I want `LintWarning` to not be a subclass of `Warning`.
> 
> Here's why I think that's important:
> * We are using the same English word "warning" to describe the following two things:
>   * Generic compiler warnings that have nothing to do with lint. Example: `Warnings.InvalidUtf8InClassfile`
>   * Compiler warnings that have an associated lint category. Example: `Warnings.MissingDeprecatedAnnotation`
> * But really two things are distinct: they do not overlap, and every compiler "warning" is one or the other (and never both). _Practically speaking_, "generic warnings" and "lint warnings" are just as distinct from each other as are `Error`, `Note`, and `Fragment`. Therefore, we can make them peer classes with no inheritance relationship.
> * Why is this helpful? Because the stronger type checking prevents possible mistakes like this:
> 
> // somewhere in the code
> LintWarning lw = ...;
> 
> // somewhere else in the code
> Warning w = lw;
> log.warning(pos, w);
> 
> The result of the above mistake would be a lint warning emitted that:
> * Does not have the "[foo]" prefix; and
> * Possibly escapes being suppressed by `-Xlint:-foo` as it should.
> 
> Put another way, I don't see any reason to make `LintWarning` a subclass of `Warning` - so why do it??

Not sure I buy your arguments :-) 
While the mechanics of lint warning is a bit different, they are _still_ warnings (e.g. the compiler still says `warning: <text>`, and it is still something that counts towards `Werror`. Making them completely separate seems like trying to make them more different than they really are.

And, if we have both `log(Warning)` and `log(LintWarning)` whether they are the same type or not becomes a mot question, because you can still use them in place of another. And, if you have subclassing and have only a single `log(Warning)` method which adds the category or not depending on the _runtime_ type of the warning, then the problem you describe above cannot occur (I think).

So, while I see how one can argue this several ways, the advantage for going down the path you describe seems less clear to me. In terms of object-oriented hierarchy, saying that a lint warning *is a* warning with a category added on top seems to me like a good modelling of the situation we have.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1868498303

From liach at openjdk.org  Tue Dec  3 23:36:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 23:36:42 GMT
Subject: RFR: 8345343: Restore the preview status of
 java.lang.classfile.components package
In-Reply-To: <aDzabDCgbKYNmC56FZuxbxWLhJoYLh1CNSsw2U5FIPU=.76d4a509-b3e2-468e-82eb-5cb0e1b72359@github.com>
References: <aDzabDCgbKYNmC56FZuxbxWLhJoYLh1CNSsw2U5FIPU=.76d4a509-b3e2-468e-82eb-5cb0e1b72359@github.com>
Message-ID: <QVzNhINvBKX7w5nLAvEdwbbtuZ1mdDBTmNT2w1SUdpM=.f197f164-37af-46cc-b481-18bd44ccb4d3@github.com>

On Mon, 2 Dec 2024 22:44:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized. In the previous rounds of reviews by other engineers, most of the review efforts were devoted to other core modeling and API classes, and components was largely omitted; a few questions were asked, but no solution were proposed and the questions were forgotten.
> 
> To compensate in such a short time to the stabilization of JDK 24, we propose to restore the preview status of the java.lang.classfile.component package and its member classes. This allows us to better consider the role of this package and its members.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.
> 
> See the CSR for alternative solutions and why they were not chosen.

Closing; after studying, it is now too late to mark this package preview or incubating, as the JEP does not provide for such. Withdrawing this to internal is the only option aside from letting this through.

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

PR Comment: https://git.openjdk.org/jdk/pull/22501#issuecomment-2515804388

From liach at openjdk.org  Tue Dec  3 23:36:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 23:36:43 GMT
Subject: Withdrawn: 8345343: Restore the preview status of
 java.lang.classfile.components package
In-Reply-To: <aDzabDCgbKYNmC56FZuxbxWLhJoYLh1CNSsw2U5FIPU=.76d4a509-b3e2-468e-82eb-5cb0e1b72359@github.com>
References: <aDzabDCgbKYNmC56FZuxbxWLhJoYLh1CNSsw2U5FIPU=.76d4a509-b3e2-468e-82eb-5cb0e1b72359@github.com>
Message-ID: <Z0uJz0kYgiJoBXP3JDCuGuKL3E1uVoCBrySXFcYt4zY=.5c9db0a0-72b8-4628-a795-aad5f10f61b7@github.com>

On Mon, 2 Dec 2024 22:44:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> The java.lang.classfile.components package was underused and had almost no usage feedback; as a result, it did not caught attention during the preview process of the Class-File API, until the late adoption when Class-File API is sure to become finalized. In the previous rounds of reviews by other engineers, most of the review efforts were devoted to other core modeling and API classes, and components was largely omitted; a few questions were asked, but no solution were proposed and the questions were forgotten.
> 
> To compensate in such a short time to the stabilization of JDK 24, we propose to restore the preview status of the java.lang.classfile.component package and its member classes. This allows us to better consider the role of this package and its members.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2024-November/000611.html for initial problem discovery and https://mail.openjdk.org/pipermail/classfile-api-dev/2024-December/000613.html for revision proposal.
> 
> See the CSR for alternative solutions and why they were not chosen.

This pull request has been closed without being integrated.

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

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

From acobbs at openjdk.org  Tue Dec  3 23:57:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Dec 2024 23:57:39 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <G7veeTQGse_vX2QYr_pqwOcatpR7WpT_tl6sRhKMOS8=.d1dded8e-a8a9-4ac2-9d88-19af9623a767@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
 <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
 <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>
 <BU6wRBTmfIhFXbJMxEd0zoJxmb2sZD6OC5envnsuUEY=.da89ea2a-06d7-4e9a-9750-501f0112dfc2@github.com>
 <G7veeTQGse_vX2QYr_pqwOcatpR7WpT_tl6sRhKMOS8=.d1dded8e-a8a9-4ac2-9d88-19af9623a767@github.com>
Message-ID: <X4eBDuNcgAiuiZLVMvqwaD19adDrLJPVIQyg0YS6r_A=.6bcb34dd-1a2a-4d1c-ada5-c782e04571a2@github.com>

On Tue, 3 Dec 2024 23:29:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> In terms of user experience, what would be the difference between using `log(LintWarning)` and `log(Warning)` ? I believe there is a need for having a method that "just logs" because sometimes (see my previous message) the is-enabled check occurs somewhere else, far from where the diagnostic is logged.
>> 
>> The methods `log(LintWarning)` and `log(Warning)` would behave the same. The reason I want both methods to exist is simply because I want `LintWarning` to not be a subclass of `Warning`.
>> 
>> Here's why I think that's important:
>> * We are using the same English word "warning" to describe the following two things:
>>   * Generic compiler warnings that have nothing to do with lint. Example: `Warnings.InvalidUtf8InClassfile`
>>   * Compiler warnings that have an associated lint category. Example: `Warnings.MissingDeprecatedAnnotation`
>> * But really two things are distinct: they do not overlap, and every compiler "warning" is one or the other (and never both). _Practically speaking_, "generic warnings" and "lint warnings" are just as distinct from each other as are `Error`, `Note`, and `Fragment`. Therefore, we can make them peer classes with no inheritance relationship.
>> * Why is this helpful? Because the stronger type checking prevents possible mistakes like this:
>> 
>> // somewhere in the code
>> LintWarning lw = ...;
>> 
>> // somewhere else in the code
>> Warning w = lw;
>> log.warning(pos, w);
>> 
>> The result of the above mistake would be a lint warning emitted that:
>> * Does not have the "[foo]" prefix; and
>> * Possibly escapes being suppressed by `-Xlint:-foo` as it should.
>> 
>> Put another way, I don't see any reason to make `LintWarning` a subclass of `Warning` - so why do it??
>
> Not sure I buy your arguments :-) 
> While the mechanics of lint warning is a bit different, they are _still_ warnings (e.g. the compiler still says `warning: <text>`, and it is still something that counts towards `Werror`. Making them completely separate seems like trying to make them more different than they really are.
> 
> And, if we have both `log(Warning)` and `log(LintWarning)` whether they are the same type or not becomes a mot question, because you can still use them in place of another. And, if you have subclassing and have only a single `log(Warning)` method which adds the category or not depending on the _runtime_ type of the warning, then the problem you describe above cannot occur (I think).
> 
> So, while I see how one can argue this several ways, the advantage for going down the path you describe seems less clear to me. In terms of object-oriented hierarchy, saying that a lint warning *is a* warning with a category added on top seems to me like a good modelling of the situation we have.

OK I think you're right and it will all work out - using the runtime type ensures the prefix always appears, and the other thing I was worried about, which is someone accidentally logging a lint warning without checking for enablement because they thought it was a generic warning, should be prevented now because the in the code you will see `LintWarnings.FooBar` instead of `Warnings.FooBar` so hopefully it will be very obvious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1868514301

From acobbs at openjdk.org  Wed Dec  4 02:24:20 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 02:24:20 GMT
Subject: RFR: 8345438: Invalid error for return in early construction context
 lambda
Message-ID: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>

The "Flexible Constructors" JEP feature allows statements to appear before a `super()` invocation, but some restrictions, one of which is that `return` is not allowed. The compiler check for this was being too strict in that it was incorrectly disallowing a `return` statement that was nested inside a lambda, which is OK.

Please review this patch to the `SuperThisChecker` which fixes this.

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

Commit messages:
 - Allow 'return' in a lambda declared in an early construction context.

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

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

From liach at openjdk.org  Wed Dec  4 02:41:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Dec 2024 02:41:42 GMT
Subject: RFR: 8345438: Invalid error for return in early construction
 context lambda
In-Reply-To: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
Message-ID: <MLgFMmyLoYWIzHA1Ye4CUcepULtKHlxa8p6dGZzbfW4=.3beab941-30b8-4a1f-96e5-3b78ab995adc@github.com>

On Wed, 4 Dec 2024 02:19:24 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The "Flexible Constructors" JEP feature allows statements to appear before a `super()` invocation, but some restrictions, one of which is that `return` is not allowed. The compiler check for this was being too strict in that it was incorrectly disallowing a `return` statement that was nested inside a lambda, which is OK.
> 
> Please review this patch to the `SuperThisChecker` which fixes this.

Since those checks were not initialized correct for lambda nesting at all, is there any other implied effects of missing these state initializations? Is there any scenario that is erroneously allowed in a lambda, or any other scenario that is erroneously rejected in a lambda? Would be nice to include them in the test if there is any.

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

PR Comment: https://git.openjdk.org/jdk/pull/22531#issuecomment-2516043143

From jlahoda at openjdk.org  Wed Dec  4 06:04:46 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Dec 2024 06:04:46 GMT
Subject: Integrated: 8345248: Module name 'transitive' not accepted for
 `requires transitive`
In-Reply-To: <BdvX8oKPAwQCQFwvg4jAVqO_YldAQUYxmw6XP3IXJPU=.0370d7a1-5ee8-4fed-802f-8e02bc5f3817@github.com>
References: <BdvX8oKPAwQCQFwvg4jAVqO_YldAQUYxmw6XP3IXJPU=.0370d7a1-5ee8-4fed-802f-8e02bc5f3817@github.com>
Message-ID: <59pSRZoEqkm5BAmF0SlNCGIkw5c5-x5I7WjQRlMnq9s=.397dece5-784a-409f-a936-98df139dea60@github.com>

On Fri, 29 Nov 2024 14:16:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering module named `transitive`, it should be possible to write: `requires transitive;`, which works, and also `requires transitive transitive;`, which currently does not work:
> 
> $ javac -d out/ --module-source-path . transitive/module-info.java test/module-info.java
> test/module-info.java:2: error: repeated modifier
>     requires transitive transitive;
>                         ^
> test/module-info.java:2: error: <identifier> expected
>     requires transitive transitive;
>                                   ^
> 2 errors
> 
> 
> The proposed solution is to properly handle lookahead if the transitive flag has already been seen.

This pull request has now been integrated.

Changeset: e15912b8
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e15912b804ca42446f5fc309aa44043c9209b977
Stats:     110 lines in 2 files changed: 106 ins; 3 del; 1 mod

8345248: Module name 'transitive' not accepted for `requires transitive`

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Wed Dec  4 08:44:40 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Dec 2024 08:44:40 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module [v2]
In-Reply-To: <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
 <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
Message-ID: <QiALd1MzS6GPywZladH-wX-K3hpNoULXuGeNBJ7784I=.8698df34-944f-4bc5-b23b-c52bcc5628a3@github.com>

On Mon, 2 Dec 2024 07:13:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
>> 
>> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - clean up ServiceLoader usage code
>  - merge latest from master branch
>  - 8345153: Clean up SecurityManager references from jdk.compiler module

Looks good to me. Thanks for the cleanup!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22431#pullrequestreview-2477696316

From jlahoda at openjdk.org  Wed Dec  4 08:59:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Dec 2024 08:59:44 GMT
Subject: RFR: 8343540: Report preview error for inherited
 effectively-preview methods [v2]
In-Reply-To: <3qEa74HyiZQ79MnMQRdpPGB-FX9bzagBA-T2Wy_wmMU=.77adc8d1-c379-450f-accc-bd786c965423@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
 <3qEa74HyiZQ79MnMQRdpPGB-FX9bzagBA-T2Wy_wmMU=.77adc8d1-c379-450f-accc-bd786c965423@github.com>
Message-ID: <AynRU6hxVSUG0o-SKYSy8o6UiitdpM6LXtdUDXfja-k=.2d813b91-e645-41c2-ae5e-440171110df3@github.com>

On Fri, 15 Nov 2024 16:00:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3852:
> 
>> 3850:         } else {
>> 3851:             sIsPreview = false;
>> 3852:             previewSymbol = null;
> 
> nit: this assignment seems to be unnecessary

I am afraid both these assignments are needed here, otherwise the variables would not be definitely assigned at their use site as per JLS. It is true there's no code path where `previewSymbol` would be used when `sIsPreview` is `false`, so the value is unused in reality, but the definite assignment is not tracking that, to my knowledge. I.e. the assignment is needed here, so that the code compiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21953#discussion_r1868997784

From jlahoda at openjdk.org  Wed Dec  4 09:50:41 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Dec 2024 09:50:41 GMT
Subject: Integrated: 8343540: Report preview error for inherited
 effectively-preview methods
In-Reply-To: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
References: <BCXdTEsxBu7flybher0_C9ZPV2YP67Jzuk0YBn5BfX8=.90f593e1-bf5f-43db-9c6f-cf17bc7788d3@github.com>
Message-ID: <vWcpDFExeiyVgzu4n3s3ZNwfLlHPnRiSyoDSKp_Rlyo=.f1ca7941-9759-4c2e-b8cf-bede9c4fea08@github.com>

On Thu, 7 Nov 2024 13:10:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a case where a new preview interface is introduced to JDK, and an existing non-preview class is retrofitted to use it. I.e. a case like:
> 
> 
> //JDK types:
> @PreviewFeature(...)
> public interface NewAPI {
>     public default void test() {}
> }
> public class ExistingRetrofittedClass implements NewAPI {}
> 
> //user type:
> class Test {
>     void t(ExistingRetrofittedClass c) {
>         c.test();
>     }
> }
> 
> 
> There is currently no error or warning about the invocation of the test method, as the method itself is not marked as preview, and the receiver is not preview either.
> 
> The proposal herein is that invoking a method on a receiver that is not of preview type itself, but the method is declared in a preview class or interface, the method will be considered to be a preview method, and the appropriate error or warning will be printed. Similar behavior is implementing for dereferencing fields.
> 
> 
> Similarly when implementing or overriding such "effectively" preview methods, like:
> 
> 
> //user types:
> class Test1 extends ExistingRetrofittedClass {
>     public void test() {}
> }
> 
> 
> java also does not produce any error or warning. If the method itself would be marked as preview, an error or warning would be printed.
> 
> The proposal herein is to produce an error or warning for a method declared inside a non-preview class or interface, which directly overrides a method declared inside a preview class or interface.
> 
> In particular, for the two example above, javac is currently producing no errors. With the change proposed herein, javac will produce output like (with no `--enable-preview`):
> 
> 
> src/Test1.java:4: error: test() is a preview API and is disabled by default.
>     public void test() {}
>                 ^
>   (use --enable-preview to enable preview APIs)
> src/Test.java:5: error: test() is a preview API and is disabled by default.
>         c.test();
>          ^
>   (use --enable-preview to enable preview APIs)
> 2 errors

This pull request has now been integrated.

Changeset: 56d315da
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56d315da480dcd2198e2000ead301c3be8b27d84
Stats:     449 lines in 3 files changed: 430 ins; 0 del; 19 mod

8343540: Report preview error for inherited effectively-preview methods

Reviewed-by: vromero

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

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

From abimpoudis at openjdk.org  Wed Dec  4 10:54:50 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Dec 2024 10:54:50 GMT
Subject: RFR: 8345474: instanceof does not reify the deduced type when patterns
 are not used in the compilation unit
Message-ID: <aMvcSu6_tFdHmGHAUgwnLZ4PIYjddxttQgUJcbYGris=.28fe5035-6bbd-43e5-9eab-ebf3b0666734@github.com>

Our tests for #21539 covered the case of using `instanceof` as both a type comparison operator and a pattern matching operator in a single compilation unit. That concealed the fact that the translation is getting triggered only when the compilation unit `hasPatterns`. This was evident/reproducible also by experimentation using jshell. This PR addresses this issue.

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

Commit messages:
 - 8345474: instanceof does not reify the deduced type when patterns are not used in the compilation unit

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

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

From abimpoudis at openjdk.org  Wed Dec  4 11:01:54 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Dec 2024 11:01:54 GMT
Subject: RFR: 8345474: Translation for instanceof is not triggered when
 patterns are not used in the compilation unit [v2]
In-Reply-To: <aMvcSu6_tFdHmGHAUgwnLZ4PIYjddxttQgUJcbYGris=.28fe5035-6bbd-43e5-9eab-ebf3b0666734@github.com>
References: <aMvcSu6_tFdHmGHAUgwnLZ4PIYjddxttQgUJcbYGris=.28fe5035-6bbd-43e5-9eab-ebf3b0666734@github.com>
Message-ID: <ROV_QT5wnlzSFH8ixbpF_ITBhzfuEWLvOGzUfy5Ic_U=.a831cd45-8c1a-4979-b4ce-388b406bfe74@github.com>

> Our tests for #21539 covered the case of using `instanceof` as both a type comparison operator and a pattern matching operator in a single compilation unit. That concealed the fact that the translation is getting triggered only when the compilation unit `hasPatterns`. This was evident/reproducible also by experimentation using jshell. This PR addresses this issue.

Aggelos Biboudis 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:

  8345474: Translation for instanceof is not triggered when patterns are not used in the compilation unit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22541/files
  - new: https://git.openjdk.org/jdk/pull/22541/files/e46f9bc8..c5e4b62a

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

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

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

From mcimadamore at openjdk.org  Wed Dec  4 11:01:55 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 11:01:55 GMT
Subject: RFR: 8345474: Translation for instanceof is not triggered when
 patterns are not used in the compilation unit [v2]
In-Reply-To: <ROV_QT5wnlzSFH8ixbpF_ITBhzfuEWLvOGzUfy5Ic_U=.a831cd45-8c1a-4979-b4ce-388b406bfe74@github.com>
References: <aMvcSu6_tFdHmGHAUgwnLZ4PIYjddxttQgUJcbYGris=.28fe5035-6bbd-43e5-9eab-ebf3b0666734@github.com>
 <ROV_QT5wnlzSFH8ixbpF_ITBhzfuEWLvOGzUfy5Ic_U=.a831cd45-8c1a-4979-b4ce-388b406bfe74@github.com>
Message-ID: <d2RPwG-R2iOv8vORJsAXnWoToW1_lwj2-mjyLhEewQ4=.de66bb56-2aa3-485f-933f-57e54916fdb7@github.com>

On Wed, 4 Dec 2024 10:59:00 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Our tests for #21539 covered the case of using `instanceof` as both a type comparison operator and a pattern matching operator in a single compilation unit. That concealed the fact that the translation is getting triggered only when the compilation unit `hasPatterns`. This was evident/reproducible also by experimentation using jshell. This PR addresses this issue.
>
> Aggelos Biboudis 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:
> 
>   8345474: Translation for instanceof is not triggered when patterns are not used in the compilation unit

Good catch!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22541#pullrequestreview-2478135992

From mcimadamore at openjdk.org  Wed Dec  4 11:06:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 11:06:37 GMT
Subject: RFR: 8345474: Translation for instanceof is not triggered when
 patterns are not used in the compilation unit [v2]
In-Reply-To: <ROV_QT5wnlzSFH8ixbpF_ITBhzfuEWLvOGzUfy5Ic_U=.a831cd45-8c1a-4979-b4ce-388b406bfe74@github.com>
References: <aMvcSu6_tFdHmGHAUgwnLZ4PIYjddxttQgUJcbYGris=.28fe5035-6bbd-43e5-9eab-ebf3b0666734@github.com>
 <ROV_QT5wnlzSFH8ixbpF_ITBhzfuEWLvOGzUfy5Ic_U=.a831cd45-8c1a-4979-b4ce-388b406bfe74@github.com>
Message-ID: <LeqvAjEXwjvbXeFaKd8DYDW-pFw__sW8LsPr7BkE6aY=.e7846126-a2e1-4da3-8373-3d585ec8a6d8@github.com>

On Wed, 4 Dec 2024 11:01:54 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Our tests for #21539 covered the case of using `instanceof` as both a type comparison operator and a pattern matching operator in a single compilation unit. That concealed the fact that the translation is getting triggered only when the compilation unit `hasPatterns`. This was evident/reproducible also by experimentation using jshell. This PR addresses this issue.
>
> Aggelos Biboudis 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:
> 
>   8345474: Translation for instanceof is not triggered when patterns are not used in the compilation unit

We should *really* assess whether these complex checks to decide whether a pipeline step is needed or not are really required. The general feeling when they were added was that skipping a translation step (e.g. for lambdas) might be advantageous for performance, but we never really collected hard evidence. As this PR shows, this logic can backfire badly.

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

PR Comment: https://git.openjdk.org/jdk/pull/22541#issuecomment-2516990017

From mcimadamore at openjdk.org  Wed Dec  4 11:51:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 11:51:40 GMT
Subject: RFR: 8345438: Invalid error for return in early construction
 context lambda
In-Reply-To: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
Message-ID: <qBL9_LWK050dsHom7q5P90kRtisTT7t9ZT6eQ4fFFWg=.9f4015c8-0a03-474a-a74c-d3f208c6e8b5@github.com>

On Wed, 4 Dec 2024 02:19:24 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The "Flexible Constructors" JEP feature allows statements to appear before a `super()` invocation, but some restrictions, one of which is that `return` is not allowed. The compiler check for this was being too strict in that it was incorrectly disallowing a `return` statement that was nested inside a lambda, which is OK.
> 
> Please review this patch to the `SuperThisChecker` which fixes this.

Looks good. I was a bit worried re. setting `scanDepth = 0`, but I see that the `costructor` check dominates everything else.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22531#pullrequestreview-2478316461

From abimpoudis at openjdk.org  Wed Dec  4 14:35:46 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Dec 2024 14:35:46 GMT
Subject: Integrated: 8345474: Translation for instanceof is not triggered when
 patterns are not used in the compilation unit
In-Reply-To: <aMvcSu6_tFdHmGHAUgwnLZ4PIYjddxttQgUJcbYGris=.28fe5035-6bbd-43e5-9eab-ebf3b0666734@github.com>
References: <aMvcSu6_tFdHmGHAUgwnLZ4PIYjddxttQgUJcbYGris=.28fe5035-6bbd-43e5-9eab-ebf3b0666734@github.com>
Message-ID: <PaCcLJSKarZR9rONMckNAh4hTs9acE1ADEkpoaxWhPU=.fa171c03-af7a-4c70-9ced-7b43874a2109@github.com>

On Wed, 4 Dec 2024 10:50:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Our tests for #21539 covered the case of using `instanceof` as both a type comparison operator and a pattern matching operator in a single compilation unit. That concealed the fact that the translation is getting triggered only when the compilation unit `hasPatterns`. This was evident/reproducible also by experimentation using jshell. This PR addresses this issue.

This pull request has now been integrated.

Changeset: 6c1ed0bb
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c1ed0bb6912d8085b98f50b7bdbb467369f3992
Stats:     57 lines in 2 files changed: 57 ins; 0 del; 0 mod

8345474: Translation for instanceof is not triggered when patterns are not used in the compilation unit

Reviewed-by: mcimadamore

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

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

From acobbs at openjdk.org  Wed Dec  4 15:49:04 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 15:49:04 GMT
Subject: RFR: 8345438: Invalid error for return in early construction
 context lambda [v2]
In-Reply-To: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
Message-ID: <b5DTSCwTP3Xnm2r-qfUHA6xinvBfq1lzA3LC0Xdn3Wk=.141c82ff-d04e-429b-a6c3-206acbb935b3@github.com>

> The "Flexible Constructors" JEP feature allows statements to appear before a `super()` invocation, but some restrictions, one of which is that `return` is not allowed. The compiler check for this was being too strict in that it was incorrectly disallowing a `return` statement that was nested inside a lambda, which is OK.
> 
> Please review this patch to the `SuperThisChecker` which fixes this.

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

  Add a few more regression tests involving lambdas.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22531/files
  - new: https://git.openjdk.org/jdk/pull/22531/files/470684f8..0dce8b32

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

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

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

From acobbs at openjdk.org  Wed Dec  4 15:49:04 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 15:49:04 GMT
Subject: RFR: 8345438: Invalid error for return in early construction
 context lambda
In-Reply-To: <MLgFMmyLoYWIzHA1Ye4CUcepULtKHlxa8p6dGZzbfW4=.3beab941-30b8-4a1f-96e5-3b78ab995adc@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
 <MLgFMmyLoYWIzHA1Ye4CUcepULtKHlxa8p6dGZzbfW4=.3beab941-30b8-4a1f-96e5-3b78ab995adc@github.com>
Message-ID: <i_kyp_3AhMv2_nPo-QgQzJWer_A9K7t8ALJUv_u7V-Y=.55e609fd-933b-4cb3-a6c7-718803c36f7d@github.com>

On Wed, 4 Dec 2024 02:39:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Since those checks were not initialized correct for lambda nesting at all, is there any other implied effects of missing these state initializations? Is there any scenario that is erroneously allowed in a lambda, or any other scenario that is erroneously rejected in a lambda? Would be nice to include them in the test if there is any.

I did think about that as well and couldn't come up with any. However, I've sprinkled in some more tests in 0dce8b32b83.

For the purposes of this analysis, the handling of a lambda should be the same as the handling of a non-constructor method, which is the effect that this patch has.

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

PR Comment: https://git.openjdk.org/jdk/pull/22531#issuecomment-2517826149

From mcimadamore at openjdk.org  Wed Dec  4 17:12:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 17:12:42 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <X4eBDuNcgAiuiZLVMvqwaD19adDrLJPVIQyg0YS6r_A=.6bcb34dd-1a2a-4d1c-ada5-c782e04571a2@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
 <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
 <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>
 <BU6wRBTmfIhFXbJMxEd0zoJxmb2sZD6OC5envnsuUEY=.da89ea2a-06d7-4e9a-9750-501f0112dfc2@github.com>
 <G7veeTQGse_vX2QYr_pqwOcatpR7WpT_tl6sRhKMOS8=.d1dded8e-a8a9-4ac2-9d88-19af9623a767@github.com>
 <X4eBDuNcgAiuiZLVMvqwaD19adDrLJPVIQyg0YS6r_A=.6bcb34dd-1a2a-4d1c-ada5-c782e04571a2@github.com>
Message-ID: <uCmPKyMlcy701imv7ZxO2t4sDrddIjvsb2YLPo0P-E8=.073d0124-22d1-4b2d-83d8-b81f569ba6f4@github.com>

On Tue, 3 Dec 2024 23:55:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Not sure I buy your arguments :-) 
>> While the mechanics of lint warning is a bit different, they are _still_ warnings (e.g. the compiler still says `warning: <text>`, and it is still something that counts towards `Werror`. Making them completely separate seems like trying to make them more different than they really are.
>> 
>> And, if we have both `log(Warning)` and `log(LintWarning)` whether they are the same type or not becomes a mot question, because you can still use them in place of another. And, if you have subclassing and have only a single `log(Warning)` method which adds the category or not depending on the _runtime_ type of the warning, then the problem you describe above cannot occur (I think).
>> 
>> So, while I see how one can argue this several ways, the advantage for going down the path you describe seems less clear to me. In terms of object-oriented hierarchy, saying that a lint warning *is a* warning with a category added on top seems to me like a good modelling of the situation we have.
>
> OK I think you're right and it will all work out - using the runtime type ensures the prefix always appears, and the other thing I was worried about, which is someone accidentally logging a lint warning without checking for enablement because they thought it was a generic warning, should be prevented now because the in the code you will see `LintWarnings.FooBar` instead of `Warnings.FooBar` so hopefully it will be very obvious.

I've updated the branch in place. This adds `LintWarnings` in `CompilerProperties` but does *not* add the intermediate grouping based on the lint category. E.g. We have `LintWarnings.DivZero` but not `LintWarnings.DivZero.DivZero`. The reason is twofold:

* Implementation-wise, collecting different warnings associated with the same category starts to be some work in the build tool we use to generate CompilerProperties.
* More importantly, while converting the use cases to use the new `LintWarning` class it seems to me that either the `isEnabled` check is immediately preceding (in which case the new `Lint::logIfEnabled` can be used), or the check is typically far enough that we have no idea on which category we are handling. E.g. pattern like `if (lint) { log ... }` is extremely common, where `lint` is either a method parameter or a class field.

I think I'm fairly happy with where this has landed. Note that the new type `LintWarning` can be used to make the signature of some methods (notably those in `MandatoryWarningHandler`) tighter, so that we can detect more issues at compile-time (and at runtime). In fact, this has helped me fixing a couple of warning keys which were missing the `lint` category in the `compiler.properties` file.

I'm not 100% happy with `Lint::logIfEnabled`: the use sites look good, but having `Lint` keep track of a log seems a bit odd (given that `Lint` objects are duplicated on the fly).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1869962967

From mcimadamore at openjdk.org  Wed Dec  4 17:12:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 17:12:42 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <uCmPKyMlcy701imv7ZxO2t4sDrddIjvsb2YLPo0P-E8=.073d0124-22d1-4b2d-83d8-b81f569ba6f4@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
 <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
 <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>
 <BU6wRBTmfIhFXbJMxEd0zoJxmb2sZD6OC5envnsuUEY=.da89ea2a-06d7-4e9a-9750-501f0112dfc2@github.com>
 <G7veeTQGse_vX2QYr_pqwOcatpR7WpT_tl6sRhKMOS8=.d1dded8e-a8a9-4ac2-9d88-19af9623a767@github.com>
 <X4eBDuNcgAiuiZLVMvqwaD19adDrLJPVIQyg0YS6r_A=.6bcb34dd-1a2a-4d1c-ada5-c782e04571a2@github.com>
 <uCmPKyMlcy701imv7ZxO2t4sDrddIjvsb2YLPo0P-E8=.073d0124-22d1-4b2d-83d8-b81f569ba6f4@github.com>
Message-ID: <ADSuBZi9Hu_6jdEESTMzOFGmpiZMNztvIsXaignTRZs=.1bc005ed-6f81-4783-ac59-45c2852eea20@github.com>

On Wed, 4 Dec 2024 17:09:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> OK I think you're right and it will all work out - using the runtime type ensures the prefix always appears, and the other thing I was worried about, which is someone accidentally logging a lint warning without checking for enablement because they thought it was a generic warning, should be prevented now because the in the code you will see `LintWarnings.FooBar` instead of `Warnings.FooBar` so hopefully it will be very obvious.
>
> I've updated the branch in place. This adds `LintWarnings` in `CompilerProperties` but does *not* add the intermediate grouping based on the lint category. E.g. We have `LintWarnings.DivZero` but not `LintWarnings.DivZero.DivZero`. The reason is twofold:
> 
> * Implementation-wise, collecting different warnings associated with the same category starts to be some work in the build tool we use to generate CompilerProperties.
> * More importantly, while converting the use cases to use the new `LintWarning` class it seems to me that either the `isEnabled` check is immediately preceding (in which case the new `Lint::logIfEnabled` can be used), or the check is typically far enough that we have no idea on which category we are handling. E.g. pattern like `if (lint) { log ... }` is extremely common, where `lint` is either a method parameter or a class field.
> 
> I think I'm fairly happy with where this has landed. Note that the new type `LintWarning` can be used to make the signature of some methods (notably those in `MandatoryWarningHandler`) tighter, so that we can detect more issues at compile-time (and at runtime). In fact, this has helped me fixing a couple of warning keys which were missing the `lint` category in the `compiler.properties` file.
> 
> I'm not 100% happy with `Lint::logIfEnabled`: the use sites look good, but having `Lint` keep track of a log seems a bit odd (given that `Lint` objects are duplicated on the fly).

I'll probably issue a PR against that branch, so that we can discuss that there. Sorry for hijacking your PR :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1869964035

From acobbs at openjdk.org  Wed Dec  4 17:24:41 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 17:24:41 GMT
Subject: RFR: 8345438: Invalid error for return in early construction
 context lambda [v2]
In-Reply-To: <qBL9_LWK050dsHom7q5P90kRtisTT7t9ZT6eQ4fFFWg=.9f4015c8-0a03-474a-a74c-d3f208c6e8b5@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
 <qBL9_LWK050dsHom7q5P90kRtisTT7t9ZT6eQ4fFFWg=.9f4015c8-0a03-474a-a74c-d3f208c6e8b5@github.com>
Message-ID: <YOUY9iHv7x-nuEls73VbbVdSOhGPteEkk0MPICSPm7g=.b264ee80-31b1-45d4-9ac8-bb3c941892c9@github.com>

On Wed, 4 Dec 2024 11:49:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a few more regression tests involving lambdas.
>
> Looks good. I was a bit worried re. setting `scanDepth = 0`, but I see that the `costructor` check dominates everything else.

@mcimadamore, requesting a re-review after new unit tests added. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/22531#issuecomment-2518081733

From acobbs at openjdk.org  Wed Dec  4 17:38:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 17:38:39 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v2]
In-Reply-To: <ADSuBZi9Hu_6jdEESTMzOFGmpiZMNztvIsXaignTRZs=.1bc005ed-6f81-4783-ac59-45c2852eea20@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
 <LwztyUfxQj43PRK-Xn69743Jt7pBIuNJizE7kSvy7vI=.f92b6389-5965-4cfc-9315-87613cc5684b@github.com>
 <b6yxi3k3K7hYUYP0YbXS3VEbt-f_DzBYhmdsXYfu45k=.ef36cb15-6cc5-421d-b8e5-6c4beeafbb30@github.com>
 <RKysSTMfdMVrCQ2VP1arOpc4z8qyow9SU_r0dbvQ3K8=.6ddacac7-facf-4e13-89a1-1fe2244643b6@github.com>
 <FC0eavf9tFTJkDOJ_OAwlt5yz3eR-OGMsszq214ziSo=.196ac6c5-4acd-4956-8e60-837289836646@github.com>
 <St8gXpjR7ChE0VZRGx5nGB0-wUYctnZG2VsWiKV64pQ=.7f2081be-7f21-4cf9-b2f9-e56d1e8d3f25@github.com>
 <IZ5q5sbphxGSHfvkcWn-XIYCjzEVQO8koaP5XD7pFkY=.a89d1b3f-a082-4972-9074-636006877f84@github.com>
 <0udamo-oSkKzQGbuUgAYbrhXUmQAEwQpwNZYD55CVcw=.f4404eff-d59c-418e-8e95-b46bb87802f6@github.com>
 <8iNM-cm3uNPV4SsVwWwfmJQ4R3GjF9CrSVk6MkLHzLc=.bfcf3ea8-4bf1-48dd-a1c5-fada1324cd7a@github.com>
 <qSuePQgNHtaab33igApJAu7XKyKRiYXr8GpvQpeJwvA=.53a11094-3b89-49f6-a131-c27ed36a4363@github.com>
 <vDd9sIiCCKMq6ZqXWQhD_crNjNz3imwGanc
 wSBXi-9Y=.7df813fd-8446-4f61-b27f-065ae22c05c8@github.com>
 <VZLys2a6ZIeXy74uxKMUzm3kdVBPPNNt8D8mYis57lQ=.8065daaa-6f0e-4831-a9cc-37f3d0f19ae4@github.com>
 <wbMCF-FlIEtwLYg5SYhdjyOFILyh58DfP_gHjv7Vuq8=.8f30b7be-b5db-4f1b-be3e-5269f60f3fd4@github.com>
 <8n3D8dmVRNICkvgfQTUQI9qo19ZjcmhAIJScV1fwpxA=.e19119f9-6474-4180-8e7a-b92383d63f84@github.com>
 <w7Wt9bOQz0dga8B2b-yn0Cy2_jSQEQ_zlWrFIS_iNys=.ebc50a86-cb30-41ce-b6b4-116f5b340d31@github.com>
 <Sb0H40WtqUhD9DLTC4L5dygsBeUCJ3CHMgvl7ODTl6c=.53ac2b1d-33ac-46cc-9265-e3b0a2c48133@github.com>
 <BU6wRBTmfIhFXbJMxEd0zoJxmb2sZD6OC5envnsuUEY=.da89ea2a-06d7-4e9a-9750-501f0112dfc2@github.com>
 <G7veeTQGse_vX2QYr_pqwOcatpR7WpT_tl6sRhKMOS8=.d1dded8e-a8a9-4ac2-9d88-19af9623a767@github.com>
 <X4eBDuNcgAiuiZLVMvqwaD19adDrLJPVIQyg0YS6r_A=.6bcb34dd-1a2a-4d1c-ada5-c782e04571a2@github.com>
 <uCmPKyMlcy701imv7ZxO2t4sDrddIjvsb2YLPo0P-E8=.073d0124-22d1-4b2d-83d8-b81f569ba6f4@github.com>
 <ADSuBZi9Hu_6jdEESTMzOFGmpiZMNztvIsXaignTRZs=.1bc005ed-6f81-4783-ac59-45c2852eea20@
 github.com>
Message-ID: <NJ_egRKbPj6xjX8JW41g9k2NN1aRvZTMGR1RdD6C9uw=.bdea84fa-d824-4706-801f-045b68816ba7@github.com>

On Wed, 4 Dec 2024 17:10:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've updated the branch in place. This adds `LintWarnings` in `CompilerProperties` but does *not* add the intermediate grouping based on the lint category. E.g. We have `LintWarnings.DivZero` but not `LintWarnings.DivZero.DivZero`. The reason is twofold:
>> 
>> * Implementation-wise, collecting different warnings associated with the same category starts to be some work in the build tool we use to generate CompilerProperties.
>> * More importantly, while converting the use cases to use the new `LintWarning` class it seems to me that either the `isEnabled` check is immediately preceding (in which case the new `Lint::logIfEnabled` can be used), or the check is typically far enough that we have no idea on which category we are handling. E.g. pattern like `if (lint) { log ... }` is extremely common, where `lint` is either a method parameter or a class field.
>> 
>> I think I'm fairly happy with where this has landed. Note that the new type `LintWarning` can be used to make the signature of some methods (notably those in `MandatoryWarningHandler`) tighter, so that we can detect more issues at compile-time (and at runtime). In fact, this has helped me fixing a couple of warning keys which were missing the `lint` category in the `compiler.properties` file.
>> 
>> I'm not 100% happy with `Lint::logIfEnabled`: the use sites look good, but having `Lint` keep track of a log seems a bit odd (given that `Lint` objects are duplicated on the fly).
>
> I'll probably issue a PR against that branch, so that we can discuss that there. Sorry for hijacking your PR :-)

I think this sounds like a good plan and agree with your reasoning for not over-complicating the class hierarchy.

I'm sure I'll have some minor comments on the patch but will wait for you to create a new PR and comment there when it appears.

Thanks.

> I'm not 100% happy with Lint::logIfEnabled: the use sites look good, but having Lint keep track of a log seems a bit odd (given that Lint objects are duplicated on the fly).

I was thinking that a `log` parameter would have to be passed as a parameter, because there is at least one subclass somewhere (`ReusableLog extends Log`), but maybe I was being too conservative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1870003820

From prappo at openjdk.org  Wed Dec  4 17:49:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 4 Dec 2024 17:49:16 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v9]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <n25JKDT_W671xuSLtxrQgZkwonFyuo9xGhppCLmfvLY=.1012dfab-5247-4207-a7bc-934da7b774cf@github.com>

> Prepare for JDK 25.

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

 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 26
   
   The macOS/AArch64 build 26 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
   
   # Conflicts:
   #	src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
 - Update --release 24 symbol information for JDK 24 build 25
   
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 24
   
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 23
   
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - ... and 4 more: https://git.openjdk.org/jdk/compare/79eb77b7...1110c336

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

Changes: https://git.openjdk.org/jdk/pull/21763/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=08
  Stats: 6176 lines in 98 files changed: 6127 ins; 3 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/21763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21763/head:pull/21763

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

From darcy at openjdk.org  Wed Dec  4 18:04:48 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Dec 2024 18:04:48 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v9]
In-Reply-To: <n25JKDT_W671xuSLtxrQgZkwonFyuo9xGhppCLmfvLY=.1012dfab-5247-4207-a7bc-934da7b774cf@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <n25JKDT_W671xuSLtxrQgZkwonFyuo9xGhppCLmfvLY=.1012dfab-5247-4207-a7bc-934da7b774cf@github.com>
Message-ID: <5itQhKXNny4vX3yhmekVPljTVrp5sJ5ZtiDSOuD8Y60=.d967913f-df71-43b4-9e2d-250776ac3943@github.com>

On Wed, 4 Dec 2024 17:49:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 26
>    
>    The macOS/AArch64 build 26 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>    
>    # Conflicts:
>    #	src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>  - Update --release 24 symbol information for JDK 24 build 25
>    
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 24
>    
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 23
>    
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 22
>    
>    The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/79eb77b7...1110c336

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2479506754

From mcimadamore at openjdk.org  Wed Dec  4 19:13:33 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 19:13:33 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly when
 logging lint warnings
Message-ID: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>

This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:


if (lint.isEnabled(LintCategory.DIVZERO) {
    log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
}

There are some issues with this approach:

* logging a lint warning has to be preceded by the correct `isEnabled` check
* the check and the `log::warning` call must share the same `LintCategory`
* the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`

This PR addresses these issues, so that the above code is now written as follows:


lint.logIfEnabled(pos, LintWarnings.DIVZERO);


The new idiom builds on a number of small improvements:

* the lint category is now tracked directly in the `compiler.properties` file;
* a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
* the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
* A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.

As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.

Many thanks @archiecobbs for the useful discussions!

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

Commit messages:
 - Fix regression
 - Separate LintWarnings from Warnings in CompilerProperties
 - Simplify code
 - All langtools tests pass
 - All tests pass
 - Use diagnostic info line to declare lint category
 - Builds ok
 - Tweak warning keys in compiler.properties

Changes: https://git.openjdk.org/jdk/pull/22553/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22553&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345263
  Stats: 598 lines in 24 files changed: 234 ins; 110 del; 254 mod
  Patch: https://git.openjdk.org/jdk/pull/22553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22553/head:pull/22553

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

From mcimadamore at openjdk.org  Wed Dec  4 19:13:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 19:13:35 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings
In-Reply-To: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
Message-ID: <N1G0BiCMt-UqSpho2LQeC7Cyk73gprSBQRvKfknGNc8=.2eaeddd3-7d2d-4815-b835-a8744908fb83@github.com>

On Wed, 4 Dec 2024 17:11:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
> 
> 
> if (lint.isEnabled(LintCategory.DIVZERO) {
>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
> }
> 
> There are some issues with this approach:
> 
> * logging a lint warning has to be preceded by the correct `isEnabled` check
> * the check and the `log::warning` call must share the same `LintCategory`
> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
> 
> This PR addresses these issues, so that the above code is now written as follows:
> 
> 
> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
> 
> 
> The new idiom builds on a number of small improvements:
> 
> * the lint category is now tracked directly in the `compiler.properties` file;
> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
> 
> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
> 
> Many thanks @archiecobbs for the useful discussions!

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

> 396:      */
> 397:     public void logIfEnabled(DiagnosticPosition pos, LintWarning warning) {
> 398:         if (isEnabled(warning.getLintCategory())) {

I'm not 100% sure about this method. On the one hand it makes clients simpler - but it does require `Lint` keeping track of a `log`. An alternative could be to add a method in `AbstractLog`, e.g.:

warningIfEnabled(DiagnosticPosition pos, Lint lint, LintWarning key)

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

> 4470:             // a warning. Make allowance for the class of an array type e.g. Object[].class)
> 4471:             if (!sym.owner.isAnonymous()) {
> 4472:                 chk.lint.logIfEnabled(tree, LintWarnings.StaticNotQualifiedByType(sym.kind.kindName(), sym.owner));

This is an odd one - the rest of `Attr` uses `env.info.lint` but if I do that here I get some NPE in some unrelated JVM test. I wonder how robust using two different lints is... but for now I'll keep compatibility with what we have.

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

> 4662:         if ((rd.module.flags() & Flags.AUTOMATIC_MODULE) != 0) {
> 4663:             deferredLintHandler.report(_ -> {
> 4664:                 if (rd.isTransitive() && lint.isEnabled(LintCategory.REQUIRES_TRANSITIVE_AUTOMATIC)) {

This one is a bit odd - the warning can be reported under two categories, so the code makes sure we don't report twice. This is deliberate I've checked with @lahodaj

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870145545
PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870139558
PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870141200

From acobbs at openjdk.org  Wed Dec  4 19:13:37 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 19:13:37 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings
In-Reply-To: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
Message-ID: <6ZXBrbNwFIBwdYz_d8qutoP2lHjwxnMFYfF9jDzYHaA=.ae444791-45d2-4886-ab2a-cb5888a318c8@github.com>

On Wed, 4 Dec 2024 17:11:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
> 
> 
> if (lint.isEnabled(LintCategory.DIVZERO) {
>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
> }
> 
> There are some issues with this approach:
> 
> * logging a lint warning has to be preceded by the correct `isEnabled` check
> * the check and the `log::warning` call must share the same `LintCategory`
> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
> 
> This PR addresses these issues, so that the above code is now written as follows:
> 
> 
> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
> 
> 
> The new idiom builds on a number of small improvements:
> 
> * the lint category is now tracked directly in the `compiler.properties` file;
> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
> 
> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
> 
> Many thanks @archiecobbs for the useful discussions!

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

> 1325:         DiagnosticPosition prevLintPos = deferredLintHandler.setPos(pos);
> 1326:         try {
> 1327:             deferredLintHandler.report(_ -> {

Nit: we can remove the lambda braces now. Also in a few other places below.

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

> 5135:                  log.warning(
> 5136:                          TreeInfo.diagnosticPositionFor(svuid, tree),
> 5137:                              Warnings.ImproperSVUID((Symbol)e));

Shouldn't this be changed to `LintWarnings.ImproperSVUID`? There are several other similar examples in this class.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java line 528:

> 526:         // Check whether we've already opened this file for output
> 527:         if (!outputFilesWritten.add(realPath))
> 528:             log.warning(LintWarnings.OutputFileClash(path)); // @@@: shouldn't we check for suppression?

Re: "shouldn't we check for suppression?": If `-Xlint:-output-file-clash` is in effect, then `outputFilesWritten` will be null and you'll never get here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870023374
PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870030235
PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870034373

From vromero at openjdk.org  Wed Dec  4 19:44:40 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Dec 2024 19:44:40 GMT
Subject: RFR: 8345438: Invalid error for return in early construction
 context lambda [v2]
In-Reply-To: <b5DTSCwTP3Xnm2r-qfUHA6xinvBfq1lzA3LC0Xdn3Wk=.141c82ff-d04e-429b-a6c3-206acbb935b3@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
 <b5DTSCwTP3Xnm2r-qfUHA6xinvBfq1lzA3LC0Xdn3Wk=.141c82ff-d04e-429b-a6c3-206acbb935b3@github.com>
Message-ID: <8oU5pv3lI60Tvt3un0AgnAJpvaUWnL_AmwHn-beFmiY=.6a9e0965-93b7-427c-90da-54c0090cff82@github.com>

On Wed, 4 Dec 2024 15:49:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The "Flexible Constructors" JEP feature allows statements to appear before a `super()` invocation, but some restrictions, one of which is that `return` is not allowed. The compiler check for this was being too strict in that it was incorrectly disallowing a `return` statement that was nested inside a lambda, which is OK.
>> 
>> Please review this patch to the `SuperThisChecker` which fixes this.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more regression tests involving lambdas.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22531#pullrequestreview-2479742335

From liach at openjdk.org  Wed Dec  4 20:16:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Dec 2024 20:16:28 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v6]
In-Reply-To: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
Message-ID: <ae0olhkF3tBg04SKrrB32AaCTrPacmstqysLRKYRHF0=.a12824bf-e98f-49a7-9a9b-8cd2d4b8a27a@github.com>

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang 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 14 additional commits since the last revision:

 - Slightly improve snippet
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Improve getRawType
 - Intro and other various improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Mass improvements
 - ... and 4 more: https://git.openjdk.org/jdk/compare/bfab6c29...eb0e2e3c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/35abd93c..eb0e2e3c

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

  Stats: 304650 lines in 5197 files changed: 145760 ins; 137117 del; 21773 mod
  Patch: https://git.openjdk.org/jdk/pull/19977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977

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

From mcimadamore at openjdk.org  Wed Dec  4 21:56:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 21:56:37 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings
In-Reply-To: <N1G0BiCMt-UqSpho2LQeC7Cyk73gprSBQRvKfknGNc8=.2eaeddd3-7d2d-4815-b835-a8744908fb83@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <N1G0BiCMt-UqSpho2LQeC7Cyk73gprSBQRvKfknGNc8=.2eaeddd3-7d2d-4815-b835-a8744908fb83@github.com>
Message-ID: <FXit0-WEQPd0Sl7xP3pFS62tpW_NH2KYZLFMhc1QwnY=.02b205a0-48ff-4d21-a246-2acbcbe614a4@github.com>

On Wed, 4 Dec 2024 19:11:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 398:
> 
>> 396:      */
>> 397:     public void logIfEnabled(DiagnosticPosition pos, LintWarning warning) {
>> 398:         if (isEnabled(warning.getLintCategory())) {
> 
> I'm not 100% sure about this method. On the one hand it makes clients simpler - but it does require `Lint` keeping track of a `log`. An alternative could be to add a method in `AbstractLog`, e.g.:
> 
> warningIfEnabled(DiagnosticPosition pos, Lint lint, LintWarning key)

elsewhere, @archiecobbs suggested to maybe make `log` a parameter of the method. I like the simplicity of the suggestion, and I will go with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870330363

From mcimadamore at openjdk.org  Wed Dec  4 21:56:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Dec 2024 21:56:38 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings
In-Reply-To: <6ZXBrbNwFIBwdYz_d8qutoP2lHjwxnMFYfF9jDzYHaA=.ae444791-45d2-4886-ab2a-cb5888a318c8@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <6ZXBrbNwFIBwdYz_d8qutoP2lHjwxnMFYfF9jDzYHaA=.ae444791-45d2-4886-ab2a-cb5888a318c8@github.com>
Message-ID: <00NYHFnIMMl5EOvNSRyQj7LVsPkP3N6dKSGmBt3qnKE=.3894301d-fe06-418b-af69-f070ca272d72@github.com>

On Wed, 4 Dec 2024 17:57:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 5137:
> 
>> 5135:                  log.warning(
>> 5136:                          TreeInfo.diagnosticPositionFor(svuid, tree),
>> 5137:                              Warnings.ImproperSVUID((Symbol)e));
> 
> Shouldn't this be changed to `LintWarnings.ImproperSVUID`? There are several other similar examples in this class.

Good catch, I probably misclassified some of these warnings

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1870331366

From darcy at openjdk.org  Wed Dec  4 22:35:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Dec 2024 22:35:40 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module [v2]
In-Reply-To: <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
 <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
Message-ID: <nCu7B6xsflYdF8HzvKspGIrCIaqYSDzsw3QVkV78yUU=.7bba568a-dc32-4ddf-8595-785370170bff@github.com>

On Mon, 2 Dec 2024 07:13:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
>> 
>> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - clean up ServiceLoader usage code
>  - merge latest from master branch
>  - 8345153: Clean up SecurityManager references from jdk.compiler module

Looks fine; thanks for the cleanup.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22431#pullrequestreview-2480052193

From acobbs at openjdk.org  Wed Dec  4 23:20:46 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 23:20:46 GMT
Subject: RFR: 8345438: Invalid error for return in early construction
 context lambda [v2]
In-Reply-To: <b5DTSCwTP3Xnm2r-qfUHA6xinvBfq1lzA3LC0Xdn3Wk=.141c82ff-d04e-429b-a6c3-206acbb935b3@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
 <b5DTSCwTP3Xnm2r-qfUHA6xinvBfq1lzA3LC0Xdn3Wk=.141c82ff-d04e-429b-a6c3-206acbb935b3@github.com>
Message-ID: <NBRUxOuciZ0hESVb0uaSDUVWXUyrv7t13-BrnbBt_iM=.fce8640f-6a18-4843-9995-bc459f95ba04@github.com>

On Wed, 4 Dec 2024 15:49:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The "Flexible Constructors" JEP feature allows statements to appear before a `super()` invocation, but some restrictions, one of which is that `return` is not allowed. The compiler check for this was being too strict in that it was incorrectly disallowing a `return` statement that was nested inside a lambda, which is OK.
>> 
>> Please review this patch to the `SuperThisChecker` which fixes this.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few more regression tests involving lambdas.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22531#issuecomment-2518752027

From acobbs at openjdk.org  Wed Dec  4 23:20:48 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Dec 2024 23:20:48 GMT
Subject: Integrated: 8345438: Invalid error for return in early construction
 context lambda
In-Reply-To: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
References: <Q4jPlD3YtzKtx9shlRjnI-g24fTYHNmUZCMnKo3WM9A=.e692ba12-4508-4099-bb73-530dbd72f159@github.com>
Message-ID: <Pc9TvRmxahLzt8SGbqZKSk2ZKl6zz4aQzXJdZjgq9sY=.2dcd2dac-3eb0-46a9-b503-d606ad5053af@github.com>

On Wed, 4 Dec 2024 02:19:24 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The "Flexible Constructors" JEP feature allows statements to appear before a `super()` invocation, but some restrictions, one of which is that `return` is not allowed. The compiler check for this was being too strict in that it was incorrectly disallowing a `return` statement that was nested inside a lambda, which is OK.
> 
> Please review this patch to the `SuperThisChecker` which fixes this.

This pull request has now been integrated.

Changeset: 7a0cc796
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a0cc796689a5c50e5b41fa4369640806b92d52e
Stats:     129 lines in 5 files changed: 127 ins; 0 del; 2 mod

8345438: Invalid error for return in early construction context lambda

Reviewed-by: vromero, mcimadamore

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

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

From jpai at openjdk.org  Thu Dec  5 01:26:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Dec 2024 01:26:45 GMT
Subject: RFR: 8345153: Clean up SecurityManager references from
 jdk.compiler module [v2]
In-Reply-To: <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
 <jPv0-SQtGzBNTcaojWICjyyELpR6ze07G0CMzxzvokA=.54fd5e7e-7804-4549-a5b7-b470c2e3149c@github.com>
Message-ID: <tnlxq4hF400RTnCD1smRQZ1HOiOW0gGnCcxMs5vGNTg=.07f5e64b-8107-4932-a861-73625ba5aaa8@github.com>

On Mon, 2 Dec 2024 07:13:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
>> 
>> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - clean up ServiceLoader usage code
>  - merge latest from master branch
>  - 8345153: Clean up SecurityManager references from jdk.compiler module

Thank you everyone for the inputs and reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22431#issuecomment-2518885791

From jpai at openjdk.org  Thu Dec  5 01:26:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Dec 2024 01:26:45 GMT
Subject: Integrated: 8345153: Clean up SecurityManager references from
 jdk.compiler module
In-Reply-To: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
References: <MgCle1Oxo9G_xGD_3wcVHvJIISIbm1BG50rQ156oI7k=.f17f2fbc-1ebe-461d-a166-91962400d31b@github.com>
Message-ID: <iI5XdEC2EoYVKFDhyUzyQP1pbE5dRevl5ZUsqVu8YdQ=.2474acbc-5a6a-4861-b58b-cc29929d1a0a@github.com>

On Thu, 28 Nov 2024 10:16:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes references to SecurityManager related APIs from the `jdk.compiler` module?
> 
> With the removal of SecurityManager implementation, various parts of the JDK, including classloader construction or `ServiceLoader` usage will no longer do the `SecurityManager` backed security checks. Failure of such security checks would previously raise a `SecurityException`. With these checks now no longer applicable, the `SecurityException` is treated as any other regular `RuntimeException`. The commit in this PR removes the special treatment of `SecurityException` and other usages of SecurityManager implementation.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass with this change.

This pull request has now been integrated.

Changeset: 63d09516
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63d095169aedb0c5dcf86f331f5ec5348a677923
Stats:     314 lines in 8 files changed: 0 ins; 274 del; 40 mod

8345153: Clean up SecurityManager references from jdk.compiler module

Reviewed-by: alanb, jlahoda, darcy

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

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

From mcimadamore at openjdk.org  Thu Dec  5 08:55:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Dec 2024 08:55:19 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
Message-ID: <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>

> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
> 
> 
> if (lint.isEnabled(LintCategory.DIVZERO) {
>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
> }
> 
> There are some issues with this approach:
> 
> * logging a lint warning has to be preceded by the correct `isEnabled` check
> * the check and the `log::warning` call must share the same `LintCategory`
> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
> 
> This PR addresses these issues, so that the above code is now written as follows:
> 
> 
> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
> 
> 
> The new idiom builds on a number of small improvements:
> 
> * the lint category is now tracked directly in the `compiler.properties` file;
> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
> 
> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
> 
> Many thanks @archiecobbs for the useful discussions!

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

  Add missing lint categories in compiler.properties
  Simplify some lambda expressions
  Simplify Lint::logIfEnabled by accepting a log parameter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22553/files
  - new: https://git.openjdk.org/jdk/pull/22553/files/9a657f23..64883bbd

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

  Stats: 82 lines in 6 files changed: 22 ins; 10 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/22553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22553/head:pull/22553

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

From jlahoda at openjdk.org  Thu Dec  5 14:36:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 5 Dec 2024 14:36:42 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
Message-ID: <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>

On Thu, 5 Dec 2024 08:55:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing lint categories in compiler.properties
>   Simplify some lambda expressions
>   Simplify Lint::logIfEnabled by accepting a log parameter

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

> 4257:      */
> 4258:     void checkForBadAuxiliaryClassAccess(DiagnosticPosition pos, Env<AttrContext> env, ClassSymbol c) {
> 4259:         if ((c.flags() & AUXILIARY) != 0 &&

Here, and on a few other places, the checks were ordered so that the potentially more expensive checks were done after the `isEnabled` check. Checking the exact places, I don't think delaying the check is terrible for the cases in this PR, but if we would like to be adding new lints, we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.

(Admittedly, on some places, the `isEnabled` check was last, after the more expensive checks. This is particularly the case for the `TRY` lint, where the checks might be considerable.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1871495437

From acobbs at openjdk.org  Thu Dec  5 15:23:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 5 Dec 2024 15:23:40 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
Message-ID: <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>

On Thu, 5 Dec 2024 14:34:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.

Agreed.

Slight comment hijack follows...

The [unnecessary suppression warning proposal](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html) would create a natural answer for this, because there would be a new concept "active" along with "enabled": A category is active if it's enabled OR we are tracking unnecessary suppressions, the category is being suppressed at this point in the code, and so far that suppression is unnecessary (i.e., no warnings would have fired yet).

So linter code would want to check for "active" status (instead of "enabled" status) before doing a non-trivial calculation, which would end up looking like this:

if (lint.isActive(LintCategory.FOO) &&
  complicatedCalculationA() &&
  complicatedCalculationB()) {
    lint.logIfEnabled(log, pos, LintWarnings.FooProblem);
}

But perhaps then we should then consider lambda-ification, which would simplify this down to:

lint.check(log, pos, LintWarnings.FooProblem,
  () -> complicatedCalculationA() && complicatedCalculationB());

This could be your "(semi-)automatic" option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1871579738

From prappo at openjdk.org  Thu Dec  5 17:06:49 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 5 Dec 2024 17:06:49 GMT
Subject: Integrated: 8342979: Start of release updates for JDK 25
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <feTjIm0LG524q8sIz2RqRrbIa5-uyKv8v3kACrv1MH4=.3a906627-ae4e-478f-9999-ec25c3ba7f6d@github.com>

On Tue, 29 Oct 2024 13:26:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Prepare for JDK 25.

This pull request has now been integrated.

Changeset: 5cc150c6
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cc150c63632c3ab8bf23d94f941d3b6db45d55c
Stats:     6176 lines in 98 files changed: 6127 ins; 3 del; 46 mod

8342979: Start of release updates for JDK 25
8342982: Add SourceVersion.RELEASE_25
8342983: Add source 25 and target 25 to javac

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

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

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

From liach at openjdk.org  Thu Dec  5 17:54:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 17:54:34 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v7]
In-Reply-To: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
Message-ID: <R6SVN7t6Z0aACoWYoC9CpvJegysiCcuUQsgb5BJWMWU=.f878b315-1c43-48b2-bd4a-f14f6aa8dae6@github.com>

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

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

  Problems with owner type, kevin suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/eb0e2e3c..1306153e

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

  Stats: 133 lines in 7 files changed: 44 ins; 25 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/19977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977

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

From liach at openjdk.org  Thu Dec  5 20:44:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 20:44:59 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
 - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

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

Changes: https://git.openjdk.org/jdk/pull/22420/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22420&range=01
  Stats: 634 lines in 360 files changed: 2 ins; 555 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22420.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22420/head:pull/22420

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

From mchung at openjdk.org  Thu Dec  5 22:02:40 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Dec 2024 22:02:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

The change looks okay to me except `ParameterAnnotations.java`.   This task is part of JEP 484 and test-only.   It seems good to backport to 24.

test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:

> 641: 
> 642:         Task.Result result = new JavacTask(tb)
> 643:                 .processors(new TestAP())

I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.

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

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483057967
PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872207964

From vromero at openjdk.org  Thu Dec  5 22:11:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Dec 2024 22:11:38 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
Message-ID: <FeAvVxwxY_LAUIxIeGLowBUtXAWFN6_LDtVw8cSFv00=.c562c983-722d-4b08-a3eb-841c9c665b94@github.com>

On Thu, 5 Dec 2024 08:55:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing lint categories in compiler.properties
>   Simplify some lambda expressions
>   Simplify Lint::logIfEnabled by accepting a log parameter

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

> 2970:                     if (belongsToRestrictedPackage(sym)) {
> 2971:                         log.warning(tree.pos(),
> 2972:                                     Warnings.AccessToMemberFromSerializableLambda(sym));

so this one won't be a lint warning anymore I guess

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1872223639

From vromero at openjdk.org  Thu Dec  5 22:18:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Dec 2024 22:18:38 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
Message-ID: <cm1Xhsdu1WulI0hUgxfrxI3b1VktA7r-jyjCpdpV7oI=.6956962c-264f-40e3-9ade-ba527ef4819d@github.com>

On Thu, 5 Dec 2024 08:55:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing lint categories in compiler.properties
>   Simplify some lambda expressions
>   Simplify Lint::logIfEnabled by accepting a log parameter

really nice simplification and clean-up

src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 596:

> 594: 
> 595:     /**
> 596:      * Class representing warning diagnostic keys.

representing `lint` warning ...?

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

PR Review: https://git.openjdk.org/jdk/pull/22553#pullrequestreview-2483095994
PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1872229461

From acobbs at openjdk.org  Thu Dec  5 22:18:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 5 Dec 2024 22:18:39 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <FeAvVxwxY_LAUIxIeGLowBUtXAWFN6_LDtVw8cSFv00=.c562c983-722d-4b08-a3eb-841c9c665b94@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <FeAvVxwxY_LAUIxIeGLowBUtXAWFN6_LDtVw8cSFv00=.c562c983-722d-4b08-a3eb-841c9c665b94@github.com>
Message-ID: <5YoKiG_iF42RQmlIAv94rQECBHHzCdtAHjtnXCmSWpg=.6c611d7f-bcee-4682-bdd0-7ae0d3c0ebe4@github.com>

On Thu, 5 Dec 2024 22:08:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing lint categories in compiler.properties
>>   Simplify some lambda expressions
>>   Simplify Lint::logIfEnabled by accepting a log parameter
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2972:
> 
>> 2970:                     if (belongsToRestrictedPackage(sym)) {
>> 2971:                         log.warning(tree.pos(),
>> 2972:                                     Warnings.AccessToMemberFromSerializableLambda(sym));
> 
> so this one won't be a lint warning anymore I guess

Actually I think this is another accidentally omitted conversion from `Warnings` to `LintWarnings`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1872230542

From liach at openjdk.org  Thu Dec  5 22:29:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 22:29:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
 <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
Message-ID: <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>

On Thu, 5 Dec 2024 21:54:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714
>
> test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:
> 
>> 641: 
>> 642:         Task.Result result = new JavacTask(tb)
>> 643:                 .processors(new TestAP())
> 
> I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.

It is required.  If we use the command line and FQN to specify a processor like in the current code without preview, this test fails with some classpath error.

> Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java

>Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.

I should attach the exact error message:


test: testInnerClass
[DIRECT]:
- compiler.err.proc.processor.not.found: ParameterAnnotations$TestAP
- compiler.err.proc.no.explicit.annotation.processing.requested: T$I
2 errors
Exception running test testInnerClass: toolbox.Task$TaskError: Task javac failed: rc=1
toolbox.Task$TaskError: Task javac failed: rc=1
        at toolbox.AbstractTask.checkExit(AbstractTask.java:154)
        at toolbox.JavacTask.run(JavacTask.java:381)
        at toolbox.AbstractTask.run(AbstractTask.java:102)
        at toolbox.JavacTask.run(JavacTask.java:52)
        at toolbox.JavacTask.run(JavacTask.java:321)
        at ParameterAnnotations.doTest(ParameterAnnotations.java:650)
        at ParameterAnnotations.testInnerClass(ParameterAnnotations.java:151)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at toolbox.TestRunner.runTests(TestRunner.java:91)
        at ParameterAnnotations.runTests(ParameterAnnotations.java:82)
        at ParameterAnnotations.main(ParameterAnnotations.java:73)
        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.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1447)


Same for all 5 tests in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872240998

From liach at openjdk.org  Thu Dec  5 22:39:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 22:39:38 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
 <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
 <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>
Message-ID: <YGI23OMLvPmZm9gfhhWUYJBV33J8XNfmEgNxr_BqDNc=.b0bb0f88-7494-433e-81f7-bddfc90039aa@github.com>

On Thu, 5 Dec 2024 22:26:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:
>> 
>>> 641: 
>>> 642:         Task.Result result = new JavacTask(tb)
>>> 643:                 .processors(new TestAP())
>> 
>> I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.
>
> It is required.  If we use the command line and FQN to specify a processor like in the current code without preview, this test fails with some classpath error.
> 
>> Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>>Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> I should attach the exact error message:
> 
> 
> test: testInnerClass
> [DIRECT]:
> - compiler.err.proc.processor.not.found: ParameterAnnotations$TestAP
> - compiler.err.proc.no.explicit.annotation.processing.requested: T$I
> 2 errors
> Exception running test testInnerClass: toolbox.Task$TaskError: Task javac failed: rc=1
> toolbox.Task$TaskError: Task javac failed: rc=1
>         at toolbox.AbstractTask.checkExit(AbstractTask.java:154)
>         at toolbox.JavacTask.run(JavacTask.java:381)
>         at toolbox.AbstractTask.run(AbstractTask.java:102)
>         at toolbox.JavacTask.run(JavacTask.java:52)
>         at toolbox.JavacTask.run(JavacTask.java:321)
>         at ParameterAnnotations.doTest(ParameterAnnotations.java:650)
>         at ParameterAnnotations.testInnerClass(ParameterAnnotations.java:151)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at toolbox.TestRunner.runTests(TestRunner.java:91)
>         at ParameterAnnotations.runTests(ParameterAnnotations.java:82)
>         at ParameterAnnotations.main(ParameterAnnotations.java:73)
>         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.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>         at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> 
> Same for all 5 tests in this file.

Filed https://bugs.openjdk.org/browse/JDK-8345622. There is no similar issues that happen as a conjunction of preview and annotation processing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872252558

From jlu at openjdk.org  Thu Dec  5 22:40:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Dec 2024 22:40:59 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
Message-ID: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>

Please review this PR which contains the open L10n drop changes for RDP1.

I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.

Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

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

Commit messages:
 - remove quotes around 'Ablehnen'
 - init

Changes: https://git.openjdk.org/jdk/pull/22588/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22588&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345327
  Stats: 404 lines in 45 files changed: 165 ins; 123 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/22588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22588/head:pull/22588

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

From mchung at openjdk.org  Thu Dec  5 23:04:40 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Dec 2024 23:04:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <maLFwsbZ7sM2p1lT95sryUOcy-Np0ltOALkqtOi2V14=.50a73592-c116-467e-8b01-de69d690acc4@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Thanks for filing the issue to follow up.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483183112

From dnguyen at openjdk.org  Fri Dec  6 00:26:38 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 6 Dec 2024 00:26:38 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

Looks generally fine overall. But, looking at the URL for the differences in each file per language, I see changes for `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher`. I don't see any changes for this file in the actual file changes for this PR though. Was there actually a change here? Or some mistake with what was picked up by the diff tool?

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

> 188: javac.opt.Xdoclint.package.args = [-]<???>(,[-]<???>)*
> 189: 
> 190: javac.opt.Xdoclint.package.desc=?????????????????? <package> ?\n??????????????????? ''.*''\n??????????????????????? <package>\n???? ''-'' ????????????

Looks like single-quotes are being changed to double single-quotes for some instances. Is this intentional? Or an issue with how the translation process reads this text?

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

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2483331030
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1872379231

From dnguyen at openjdk.org  Fri Dec  6 00:32:38 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 6 Dec 2024 00:32:38 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
Message-ID: <9TIMWt3fO2KwB3iB6EbAbkEqmZ6f055jt9Ldrp4Mdes=.3ff0da2e-9f0b-4762-82e2-99a0f99b04e3@github.com>

On Fri, 6 Dec 2024 00:24:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Looks generally fine overall. But, looking at the URL for the differences in each file per language, I see changes for `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher`. I don't see any changes for this file in the actual file changes for this PR though. Was there actually a change here? Or some mistake with what was picked up by the diff tool?

Just noticed you mentioned there are some keys that weren't caught here but will be in RDP2. Maybe this is one of them? If so, that's fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/22588#issuecomment-2521811145

From jlu at openjdk.org  Fri Dec  6 00:32:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Dec 2024 00:32:39 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <9TIMWt3fO2KwB3iB6EbAbkEqmZ6f055jt9Ldrp4Mdes=.3ff0da2e-9f0b-4762-82e2-99a0f99b04e3@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
 <9TIMWt3fO2KwB3iB6EbAbkEqmZ6f055jt9Ldrp4Mdes=.3ff0da2e-9f0b-4762-82e2-99a0f99b04e3@github.com>
Message-ID: <MSvr7ioTxif6MUTDa3vxCu_iHvs6Iz2CBwmBDSKkSpI=.459b7476-0a3f-46b1-b53a-9b7bba77abc7@github.com>

On Fri, 6 Dec 2024 00:27:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> > Looks generally fine overall. But, looking at the URL for the differences in each file per language, I see changes for `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher`. I don't see any changes for this file in the actual file changes for this PR though. Was there actually a change here? Or some mistake with what was picked up by the diff tool?
> 
> Just noticed you mentioned there are some keys that weren't caught here but will be in RDP2. Maybe this is one of them? If so, that's fine.

Yup, that change came in 12/5. We submitted for translations a few days ago. We can address it in the second L10n drop.

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

PR Comment: https://git.openjdk.org/jdk/pull/22588#issuecomment-2521812370

From jlu at openjdk.org  Fri Dec  6 00:32:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Dec 2024 00:32:40 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
Message-ID: <63vcWFd5fwCuIIAMsbD2q62_YVzviMzRFGt9qdg5CD0=.406630d5-ee2b-4f2e-af21-984770227578@github.com>

On Fri, 6 Dec 2024 00:21:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Please review this PR which contains the open L10n drop changes for RDP1.
>> 
>> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
>> 
>> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 190:
> 
>> 188: javac.opt.Xdoclint.package.args = [-]<???>(,[-]<???>)*
>> 189: 
>> 190: javac.opt.Xdoclint.package.desc=?????????????????? <package> ?\n??????????????????? ''.*''\n??????????????????????? <package>\n???? ''-'' ????????????
> 
> Looks like single-quotes are being changed to double single-quotes for some instances. Is this intentional? Or an issue with how the translation process reads this text?

That's because the English source file had an update to introduce those double single quotes. (See https://cr.openjdk.org/~jlu/output/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.html). It's just being updated to match.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1872384728

From dnguyen at openjdk.org  Fri Dec  6 00:46:37 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 6 Dec 2024 00:46:37 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <6t9NSz5O0tFxmb-pYaTUTThJMnReoS-PuWpwOPRCa_M=.4c65900d-ced5-45d8-a941-3e718f643695@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2483359819

From dnguyen at openjdk.org  Fri Dec  6 00:46:38 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 6 Dec 2024 00:46:38 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <63vcWFd5fwCuIIAMsbD2q62_YVzviMzRFGt9qdg5CD0=.406630d5-ee2b-4f2e-af21-984770227578@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
 <63vcWFd5fwCuIIAMsbD2q62_YVzviMzRFGt9qdg5CD0=.406630d5-ee2b-4f2e-af21-984770227578@github.com>
Message-ID: <wMmxoyGUzJO2n0fsrJXJ_2wHXWP00bckY-MEuyRcBhA=.8fdf03f7-73eb-4e05-8268-e92fd01dede5@github.com>

On Fri, 6 Dec 2024 00:30:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 190:
>> 
>>> 188: javac.opt.Xdoclint.package.args = [-]<???>(,[-]<???>)*
>>> 189: 
>>> 190: javac.opt.Xdoclint.package.desc=?????????????????? <package> ?\n??????????????????? ''.*''\n??????????????????????? <package>\n???? ''-'' ????????????
>> 
>> Looks like single-quotes are being changed to double single-quotes for some instances. Is this intentional? Or an issue with how the translation process reads this text?
>
> That's because the English source file had an update to introduce those double single quotes. (See https://cr.openjdk.org/~jlu/output/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.html). It's just being updated to match.

Oh you're right. That's odd though. But the translations aren't wrong then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1872398739

From asotona at openjdk.org  Fri Dec  6 07:01:45 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Dec 2024 07:01:45 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <cYKI7KfuddHlzINClbgrqWQuLJPTw5rYBUurMV61Gbg=.a84e6ec5-b489-44be-ad12-65bbb954aab8@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Looks good to me, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483795644

From mcimadamore at openjdk.org  Fri Dec  6 10:31:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 10:31:38 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <5YoKiG_iF42RQmlIAv94rQECBHHzCdtAHjtnXCmSWpg=.6c611d7f-bcee-4682-bdd0-7ae0d3c0ebe4@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <FeAvVxwxY_LAUIxIeGLowBUtXAWFN6_LDtVw8cSFv00=.c562c983-722d-4b08-a3eb-841c9c665b94@github.com>
 <5YoKiG_iF42RQmlIAv94rQECBHHzCdtAHjtnXCmSWpg=.6c611d7f-bcee-4682-bdd0-7ae0d3c0ebe4@github.com>
Message-ID: <gnZCOU1ZtkEmPujLEo0fDC40qDIHIo_GTORYWgP8eSU=.280c2f98-371c-453b-8e38-5d468b15dd63@github.com>

On Thu, 5 Dec 2024 22:16:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2972:
>> 
>>> 2970:                     if (belongsToRestrictedPackage(sym)) {
>>> 2971:                         log.warning(tree.pos(),
>>> 2972:                                     Warnings.AccessToMemberFromSerializableLambda(sym));
>> 
>> so this one won't be a lint warning anymore I guess
>
> Actually I think this is another accidentally omitted conversion from `Warnings` to `LintWarnings`.

True, this is a bug in compiler.properties.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873006536

From mcimadamore at openjdk.org  Fri Dec  6 10:31:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 10:31:40 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
 <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>
Message-ID: <o5hAokljPQvm1KWItpBiy6QsytLrLa-EUQLedrCjIKk=.3798f3eb-c647-4013-8560-cf7f223ce344@github.com>

On Thu, 5 Dec 2024 15:20:32 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4259:
>> 
>>> 4257:      */
>>> 4258:     void checkForBadAuxiliaryClassAccess(DiagnosticPosition pos, Env<AttrContext> env, ClassSymbol c) {
>>> 4259:         if ((c.flags() & AUXILIARY) != 0 &&
>> 
>> Here, and on a few other places, the checks were ordered so that the potentially more expensive checks were done after the `isEnabled` check. Checking the exact places, I don't think delaying the check is terrible for the cases in this PR, but if we would like to be adding new lints, we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.
>> 
>> (Admittedly, on some places, the `isEnabled` check was last, after the more expensive checks. This is particularly the case for the `TRY` lint, where the checks might be considerable.)
>
>> we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.
> 
> Agreed.
> 
> Slight comment hijack follows...
> 
> The [unnecessary suppression warning proposal](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html) would create a natural answer for this, because there would be a new concept "active" along with "enabled": A category is active if it's enabled OR we are tracking unnecessary suppressions, the category is being suppressed at this point in the code, and so far that suppression is unnecessary (i.e., no warnings would have fired yet).
> 
> So linter code would want to check for "active" status (instead of "enabled" status) before doing a non-trivial calculation, which would end up looking like this:
> 
> if (lint.isActive(LintCategory.FOO) &&
>   complicatedCalculationA() &&
>   complicatedCalculationB()) {
>     lint.logIfEnabled(log, pos, LintWarnings.FooProblem);
> }
> 
> But perhaps then we should then consider lambda-ification, which would simplify this down to:
> 
> lint.check(log, pos, LintWarnings.FooProblem,
>   () -> complicatedCalculationA() && complicatedCalculationB());
> 
> This could be your "(semi-)automatic" option.

> Here, and on a few other places, the checks were ordered so that the potentially more expensive checks were done after the `isEnabled` check. Checking the exact places, I don't think delaying the check is terrible for the cases in this PR, but if we would like to be adding new lints, we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.
> 
> (Admittedly, on some places, the `isEnabled` check was last, after the more expensive checks. This is particularly the case for the `TRY` lint, where the checks might be considerable.)

I was aware of that. As you might notice, in some cases I preserved the original code structure - in other cases I've changed it when the preceding checks seemed O(1) -- I might have made some mistakes, but that was the spirit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873000622

From mcimadamore at openjdk.org  Fri Dec  6 10:31:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 10:31:40 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <o5hAokljPQvm1KWItpBiy6QsytLrLa-EUQLedrCjIKk=.3798f3eb-c647-4013-8560-cf7f223ce344@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
 <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>
 <o5hAokljPQvm1KWItpBiy6QsytLrLa-EUQLedrCjIKk=.3798f3eb-c647-4013-8560-cf7f223ce344@github.com>
Message-ID: <qeJVNOi0h_Xt0JYwdTyanuNywwggx2UzH6WLYIDtxgo=.71cd23c8-75d3-4cec-8841-646f6bcfeba8@github.com>

On Fri, 6 Dec 2024 10:24:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.
>> 
>> Agreed.
>> 
>> Slight comment hijack follows...
>> 
>> The [unnecessary suppression warning proposal](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html) would create a natural answer for this, because there would be a new concept "active" along with "enabled": A category is active if it's enabled OR we are tracking unnecessary suppressions, the category is being suppressed at this point in the code, and so far that suppression is unnecessary (i.e., no warnings would have fired yet).
>> 
>> So linter code would want to check for "active" status (instead of "enabled" status) before doing a non-trivial calculation, which would end up looking like this:
>> 
>> if (lint.isActive(LintCategory.FOO) &&
>>   complicatedCalculationA() &&
>>   complicatedCalculationB()) {
>>     lint.logIfEnabled(log, pos, LintWarnings.FooProblem);
>> }
>> 
>> But perhaps then we should then consider lambda-ification, which would simplify this down to:
>> 
>> lint.check(log, pos, LintWarnings.FooProblem,
>>   () -> complicatedCalculationA() && complicatedCalculationB());
>> 
>> This could be your "(semi-)automatic" option.
>
>> Here, and on a few other places, the checks were ordered so that the potentially more expensive checks were done after the `isEnabled` check. Checking the exact places, I don't think delaying the check is terrible for the cases in this PR, but if we would like to be adding new lints, we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.
>> 
>> (Admittedly, on some places, the `isEnabled` check was last, after the more expensive checks. This is particularly the case for the `TRY` lint, where the checks might be considerable.)
> 
> I was aware of that. As you might notice, in some cases I preserved the original code structure - in other cases I've changed it when the preceding checks seemed O(1) -- I might have made some mistakes, but that was the spirit.

> But perhaps then we should then consider lambda-ification, which would simplify this down to:
> 
> ```java
> lint.check(log, pos, LintWarnings.FooProblem,
>   () -> complicatedCalculationA() && complicatedCalculationB());
> ```

I thought about this as well but found it a bit too convoluted for my liking. One might already argue that `Lint::logIfEnabled` is doing two things at once (check and log). Making it an open box where you check if the lint is enabled, you check some user provided condition, and if both are true then you log" seems a rather ad-hoc API to add :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873003778

From mcimadamore at openjdk.org  Fri Dec  6 10:31:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 10:31:40 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <qeJVNOi0h_Xt0JYwdTyanuNywwggx2UzH6WLYIDtxgo=.71cd23c8-75d3-4cec-8841-646f6bcfeba8@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
 <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>
 <o5hAokljPQvm1KWItpBiy6QsytLrLa-EUQLedrCjIKk=.3798f3eb-c647-4013-8560-cf7f223ce344@github.com>
 <qeJVNOi0h_Xt0JYwdTyanuNywwggx2UzH6WLYIDtxgo=.71cd23c8-75d3-4cec-8841-646f6bcfeba8@github.com>
Message-ID: <Gh9go5XFn62hhKaWAIKhLGL4bYvKe6BVthUh7-IgOec=.8eab00ed-9cb2-4779-acf9-9e9aef0808b6@github.com>

On Fri, 6 Dec 2024 10:26:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Here, and on a few other places, the checks were ordered so that the potentially more expensive checks were done after the `isEnabled` check. Checking the exact places, I don't think delaying the check is terrible for the cases in this PR, but if we would like to be adding new lints, we probably need something that will avoid running the lint's code completely in a (semi-)automatic way. That could be part of a more generic 22088.
>>> 
>>> (Admittedly, on some places, the `isEnabled` check was last, after the more expensive checks. This is particularly the case for the `TRY` lint, where the checks might be considerable.)
>> 
>> I was aware of that. As you might notice, in some cases I preserved the original code structure - in other cases I've changed it when the preceding checks seemed O(1) -- I might have made some mistakes, but that was the spirit.
>
>> But perhaps then we should then consider lambda-ification, which would simplify this down to:
>> 
>> ```java
>> lint.check(log, pos, LintWarnings.FooProblem,
>>   () -> complicatedCalculationA() && complicatedCalculationB());
>> ```
> 
> I thought about this as well but found it a bit too convoluted for my liking. One might already argue that `Lint::logIfEnabled` is doing two things at once (check and log). Making it an open box where you check if the lint is enabled, you check some user provided condition, and if both are true then you log" seems a rather ad-hoc API to add :-)

Overall I just think the problem of "you checked for A, but are logging a B" is not big enough to warrant an hammer like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873004847

From mcimadamore at openjdk.org  Fri Dec  6 10:31:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 10:31:42 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <cm1Xhsdu1WulI0hUgxfrxI3b1VktA7r-jyjCpdpV7oI=.6956962c-264f-40e3-9ade-ba527ef4819d@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <cm1Xhsdu1WulI0hUgxfrxI3b1VktA7r-jyjCpdpV7oI=.6956962c-264f-40e3-9ade-ba527ef4819d@github.com>
Message-ID: <4GNzH3fEoP9MHMsnaAQs12ST44dte7RXLKkYFGQxki8=.b15f3098-afdb-402d-89da-e077746bb1e2@github.com>

On Thu, 5 Dec 2024 22:14:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing lint categories in compiler.properties
>>   Simplify some lambda expressions
>>   Simplify Lint::logIfEnabled by accepting a log parameter
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java line 596:
> 
>> 594: 
>> 595:     /**
>> 596:      * Class representing warning diagnostic keys.
> 
> representing `lint` warning ...?

Good catch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873006287

From mcimadamore at openjdk.org  Fri Dec  6 11:03:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 11:03:00 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v3]
In-Reply-To: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
Message-ID: <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>

> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
> 
> 
> if (lint.isEnabled(LintCategory.DIVZERO) {
>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
> }
> 
> There are some issues with this approach:
> 
> * logging a lint warning has to be preceded by the correct `isEnabled` check
> * the check and the `log::warning` call must share the same `LintCategory`
> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
> 
> This PR addresses these issues, so that the above code is now written as follows:
> 
> 
> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
> 
> 
> The new idiom builds on a number of small improvements:
> 
> * the lint category is now tracked directly in the `compiler.properties` file;
> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
> 
> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
> 
> Many thanks @archiecobbs for the useful discussions!

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

  Add other missing lint categories

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22553/files
  - new: https://git.openjdk.org/jdk/pull/22553/files/64883bbd..a3393ca4

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

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

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

From mcimadamore at openjdk.org  Fri Dec  6 11:03:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 11:03:00 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <Gh9go5XFn62hhKaWAIKhLGL4bYvKe6BVthUh7-IgOec=.8eab00ed-9cb2-4779-acf9-9e9aef0808b6@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
 <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>
 <o5hAokljPQvm1KWItpBiy6QsytLrLa-EUQLedrCjIKk=.3798f3eb-c647-4013-8560-cf7f223ce344@github.com>
 <qeJVNOi0h_Xt0JYwdTyanuNywwggx2UzH6WLYIDtxgo=.71cd23c8-75d3-4cec-8841-646f6bcfeba8@github.com>
 <Gh9go5XFn62hhKaWAIKhLGL4bYvKe6BVthUh7-IgOec=.8eab00ed-9cb2-4779-acf9-9e9aef0808b6@github.com>
Message-ID: <7bvxDhRAIVyaFD-vk8548QQum7-ftpFNaaZUUnNXCG0=.a817b2c0-b059-4b49-8a5e-c81851522051@github.com>

On Fri, 6 Dec 2024 10:27:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> But perhaps then we should then consider lambda-ification, which would simplify this down to:
>>> 
>>> ```java
>>> lint.check(log, pos, LintWarnings.FooProblem,
>>>   () -> complicatedCalculationA() && complicatedCalculationB());
>>> ```
>> 
>> I thought about this as well but found it a bit too convoluted for my liking. One might already argue that `Lint::logIfEnabled` is doing two things at once (check and log). Making it an open box where you check if the lint is enabled, you check some user provided condition, and if both are true then you log" seems a rather ad-hoc API to add :-)
>
> Overall I just think the problem of "you checked for A, but are logging a B" is not big enough to warrant an hammer like this.

What would be better, IMHO, is to investigate an automate way to e.g. enhance something like CheckExamples to automatically test for suppression of lint warnings. E.g. for each diagnostic example that refers to a lint warning, it would be great if we could run the example with `-Xlint:-xyz` (to test command-line suppression) and maybe to auto-decorate the whole thing with `@SuppressWarnings("xyz")` and try again (to test programmatic supression) -- where `xyz` is the lint category associated to the compiler key under test. While this is probably too big to tacked as part of this PR, I don't see why we couldn't automate part of this -- and this will ensure that any issue where suppression is not respected is identified early in the process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873062627

From liach at openjdk.org  Fri Dec  6 14:27:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 14:27:45 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <NFMYqK-YAR0M4ogdKPBJCDErb0InxSmKB1-4xAwM4m4=.b208051b-f553-41e3-b365-6fe0b48f4e68@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2523362333

From liach at openjdk.org  Fri Dec  6 14:27:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 14:27:46 GMT
Subject: Integrated: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <lC5dc_Tdirtuqzeo_Owzx7FAERGLPn3zxVToCnmFrVc=.37555c56-eae5-4674-812f-cf8c4c666c16@github.com>

On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

This pull request has now been integrated.

Changeset: 49664195
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/496641955041c5e48359e6256a4a61812653d900
Stats:     634 lines in 360 files changed: 2 ins; 555 del; 77 mod

8334733: Remove obsolete @enablePreview from tests after JDK-8334714

Reviewed-by: mchung, asotona

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

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

From liach at openjdk.org  Fri Dec  6 15:08:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 15:08:47 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <UbEObYZrmrSyDOgIKSYDiGuI4DJ5xs-oooevsmtRw3Q=.e2fbe36e-0d43-4ab1-9044-2a203019ffaa@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

>From internal discussion, this task is logically associated with the finalization of ClassFile API and is best done for the same release 24.

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

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2523450991

From liach at openjdk.org  Fri Dec  6 15:17:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 15:17:26 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714
Message-ID: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>

Hi all,

This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.

The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.

Thanks!

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

Commit messages:
 - Backport 496641955041c5e48359e6256a4a61812653d900

Changes: https://git.openjdk.org/jdk/pull/22607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334733
  Stats: 634 lines in 360 files changed: 2 ins; 555 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22607/head:pull/22607

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

From vromero at openjdk.org  Fri Dec  6 15:23:39 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 6 Dec 2024 15:23:39 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v3]
In-Reply-To: <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
Message-ID: <rXk-Zm0VgOg9G1OFk_cz6EX0UWFZ52hZ8JvY_nw1iJ8=.ad169457-dd5a-494e-9347-2bf96a705a2b@github.com>

On Fri, 6 Dec 2024 11:03:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add other missing lint categories

lvgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22553#pullrequestreview-2485111847

From acobbs at openjdk.org  Fri Dec  6 15:48:39 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 6 Dec 2024 15:48:39 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <7bvxDhRAIVyaFD-vk8548QQum7-ftpFNaaZUUnNXCG0=.a817b2c0-b059-4b49-8a5e-c81851522051@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
 <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>
 <o5hAokljPQvm1KWItpBiy6QsytLrLa-EUQLedrCjIKk=.3798f3eb-c647-4013-8560-cf7f223ce344@github.com>
 <qeJVNOi0h_Xt0JYwdTyanuNywwggx2UzH6WLYIDtxgo=.71cd23c8-75d3-4cec-8841-646f6bcfeba8@github.com>
 <Gh9go5XFn62hhKaWAIKhLGL4bYvKe6BVthUh7-IgOec=.8eab00ed-9cb2-4779-acf9-9e9aef0808b6@github.com>
 <7bvxDhRAIVyaFD-vk8548QQum7-ftpFNaaZUUnNXCG0=.a817b2c0-b059-4b49-8a5e-c81851522051@github.com>
Message-ID: <uGTRwb_71eenvcy_z9BljHbE9mL5KmptcWKJ2Fq9ni0=.fddcda86-e71a-413b-a1d2-6b363734cdcb@github.com>

On Fri, 6 Dec 2024 10:59:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What would be better, IMHO, is to investigate an automate way to e.g. enhance something like CheckExamples to automatically test for suppression of lint warnings.

Indeed... and I've already got a [precursor](https://github.com/archiecobbs/jdk/blob/suppression/test/langtools/tools/javac/lint/SuppressionWarningTest.java) which could serve as a starting point for something like that. What's missing in the precursor is automatic verification that _every_ lint warning is tested, since until this PR that was impractical. But with this PR we can now enumerate all the `LintWarning`'s, so it would be easy to automatically verify we have complete coverage. Of course, we'd also have to add all the missing warnable code examples, which is not hard but somewhat tedious. Let me know if you are interested in putting something together, I'm happy to help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873538017

From mcimadamore at openjdk.org  Fri Dec  6 17:32:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Dec 2024 17:32:41 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v2]
In-Reply-To: <uGTRwb_71eenvcy_z9BljHbE9mL5KmptcWKJ2Fq9ni0=.fddcda86-e71a-413b-a1d2-6b363734cdcb@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <1is8Ki2x633ATb_EKFLFyiXMjl6aqW-8reE-vUUr8G4=.8d6f8da9-742d-4e1c-895e-9a235cb70377@github.com>
 <fBOX99sqfaRkHn_CtBREkiWaxHKbIkuTKkGDCmIVDp8=.c1210729-d0db-4340-b310-055ab9c49688@github.com>
 <lqZm2xzfEI1N_Yyw8YWR-MtwPfERRMIlF1pnf_dMKwM=.8d78c077-7949-4a6b-ac78-862b3d3f67f5@github.com>
 <o5hAokljPQvm1KWItpBiy6QsytLrLa-EUQLedrCjIKk=.3798f3eb-c647-4013-8560-cf7f223ce344@github.com>
 <qeJVNOi0h_Xt0JYwdTyanuNywwggx2UzH6WLYIDtxgo=.71cd23c8-75d3-4cec-8841-646f6bcfeba8@github.com>
 <Gh9go5XFn62hhKaWAIKhLGL4bYvKe6BVthUh7-IgOec=.8eab00ed-9cb2-4779-acf9-9e9aef0808b6@github.com>
 <7bvxDhRAIVyaFD-vk8548QQum7-ftpFNaaZUUnNXCG0=.a817b2c0-b059-4b49-8a5e-c81851522051@github.com>
 <uGTRwb_71eenvcy_z9BljHbE9mL5KmptcWKJ2Fq9ni0=.fddcda86-e71a-413b-a1d2-6b363734cdcb@github.com>
Message-ID: <nuFohkcCrQNuvKIatC7VJm-OonejeZnVRpnv8uSNJ1E=.9f69bb75-d942-41d3-8985-0d2336136954@github.com>

On Fri, 6 Dec 2024 15:46:17 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> But with this PR we can now enumerate all the `LintWarning`

Yes, this is indeed the part I like the most about this PR. I'm already using it to collect a bunch of stats on how many lint warnings we have, how many warnings by category, etc. - which is very useful to spot inconsistencies etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22553#discussion_r1873749715

From joehw at openjdk.org  Fri Dec  6 18:47:37 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 6 Dec 2024 18:47:37 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <OrXErTBG9l86w2MQHUba0If9-3gLS8vF_hJf179W3BA=.9a77033b-623c-4a3a-9f65-06c1824c5499@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

The java.xml changes look good. Thanks.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2485626636

From cushon at openjdk.org  Sat Dec  7 00:47:39 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 7 Dec 2024 00:47:39 GMT
Subject: RFR: 8344647: Make java.se participate in the preview language
 feature `requires transitive java.base`
In-Reply-To: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
References: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
Message-ID: <lmatnQ-knSuu6OdgmNZl7u82VxE-3tt9cgC-rolEBms=.e9ac8bc1-404b-4182-9311-71e0e94d6932@github.com>

On Fri, 22 Nov 2024 13:42:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

LGTM, thanks!

I verified this fixes the original issue I was seeing.

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

PR Comment: https://git.openjdk.org/jdk/pull/22322#issuecomment-2524711481

From prappo at openjdk.org  Mon Dec  9 11:35:12 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 9 Dec 2024 11:35:12 GMT
Subject: RFR: 8342987: Update --release 24 symbol information for JDK 24 build
 27
Message-ID: <5xzJhBuPr3norrdecIeY2ZbkMji5TZ986CsIRxfZIeY=.d5356fa8-a441-451f-a1f5-04724583b86d@github.com>

Usual symbol file update for a new JDK build.

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

Commit messages:
 - 8342987: Update --release 24 symbol information for JDK 24 build 27

Changes: https://git.openjdk.org/jdk/pull/22635/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342987
  Stats: 225 lines in 6 files changed: 96 ins; 99 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/22635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22635/head:pull/22635

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

From ihse at openjdk.org  Mon Dec  9 12:12:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:12:13 GMT
Subject: RFR: 8345793: Update copyright year to 2024 for the build system in
 files where it was missed
Message-ID: <sLQyjth6TY1YgV4k9Nt7iHm7L7i6fPQ6kPFtMsc0H4w=.9e9f9ad5-944c-42f6-97a6-ef634a2d81d0@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345793: Update copyright year to 2024 for the build system in files where it was missed

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

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

From ihse at openjdk.org  Mon Dec  9 12:34:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:34:53 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed
Message-ID: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345799: Update copyright year to 2024 for core-libs in files where it was missed

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

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

From ihse at openjdk.org  Mon Dec  9 13:01:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 13:01:55 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed
Message-ID: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345804: Update copyright year to 2024 for langtools in files where it was missed

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

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

From ihse at openjdk.org  Mon Dec  9 13:03:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 13:03:06 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add more core-libs files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22640/files
  - new: https://git.openjdk.org/jdk/pull/22640/files/e7cfe0f7..8e040c3a

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

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

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

From dfuchs at openjdk.org  Mon Dec  9 13:30:43 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Dec 2024 13:30:43 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <vn5KixoVXSgvE9fcU5Pcd-y9NkYlVz86c8VG-g_P6OM=.3a4a66f2-9b24-49f8-9459-628ab9c8b229@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

changes to sun.net and java.naming/jdk.naming.* look ok

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2527957595

From kevinw at openjdk.org  Mon Dec  9 14:02:39 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 14:02:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <CZvJVQu03QkOiUM5mcdagcdfDvo6SMRhg-OVi9-O9RY=.a676e608-9fbf-4224-a417-2b1e063275af@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

Looks good.
They all seem to follow the pattern, I looked at some and yes they have changes in 2024 but no year update.  One of them was mine I noticed!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2488883450

From liach at openjdk.org  Mon Dec  9 14:08:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 14:08:38 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed
In-Reply-To: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
Message-ID: <t5s3D1kpkqzdxW0gygdpZFC4BW_buSEcJnXHIRCLM24=.e2f924bf-e3f3-4266-a402-c09926a04a08@github.com>

On Mon, 9 Dec 2024 12:55:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Do we intend to update tests? Some tests have trivial changes as a removal of `@enablePreview` when the ClassFile API is finalized.

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

PR Comment: https://git.openjdk.org/jdk/pull/22643#issuecomment-2528059231

From rriggs at openjdk.org  Mon Dec  9 15:19:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Dec 2024 15:19:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

Copyright dates in third party files are not updated uniformly. See the previous comment.

That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2489132284
PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528303669

From kevinw at openjdk.org  Mon Dec  9 15:28:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 15:28:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

I also meant to note that there are updates to binaries, src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which maybe isn't intentional, or I just don't understand?

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528357715

From ihse at openjdk.org  Mon Dec  9 15:42:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:42:57 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>
Message-ID: <QLNzClECNTKmLMG1OzFKoY6S9ZscAfwfF0BhnfJ6_PE=.6c75b36a-0b08-4c14-93b8-553deeb0dd48@github.com>

On Mon, 9 Dec 2024 15:26:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I also meant to note that there are updates to binaries, src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which maybe isn't intentional, or I just don't understand?

That was certainly not intentional! I'm not sure how that happened, I need to look at my copyright update script again...

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528425161

From ihse at openjdk.org  Mon Dec  9 15:42:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:42:57 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to binary files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22640/files
  - new: https://git.openjdk.org/jdk/pull/22640/files/8e040c3a..c8d541f9

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

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

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

From ihse at openjdk.org  Mon Dec  9 15:48:38 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:48:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
Message-ID: <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>

On Mon, 9 Dec 2024 15:16:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.

I'm not sure I understand what you mean. Are you saying that I did not update files that should have been updated, or that I updated files that should not have been updated?

The only 3rd party XML files I know about are the ones in `make/data/cldr`. They have certainly been updated in 2024 from upstream, but they do not carry an Oracle copyright header, so there is nothing there to update.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528451279

From ihse at openjdk.org  Mon Dec  9 15:52:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:52:36 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed
In-Reply-To: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
Message-ID: <BHb13lLThkRZmJw6UjWu4T2gYFK1wyxvUoe4VDZjarY=.a8fb5a16-5ca2-4157-aa1e-a88ec4ea1ad2@github.com>

On Mon, 9 Dec 2024 12:55:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Yes, all files should be updated. I'm continuing this discussion off-line.

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

PR Comment: https://git.openjdk.org/jdk/pull/22643#issuecomment-2528470989

From darcy at openjdk.org  Mon Dec  9 17:39:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Dec 2024 17:39:41 GMT
Subject: RFR: 8342987: Update --release 24 symbol information for JDK 24
 build 27
In-Reply-To: <5xzJhBuPr3norrdecIeY2ZbkMji5TZ986CsIRxfZIeY=.d5356fa8-a441-451f-a1f5-04724583b86d@github.com>
References: <5xzJhBuPr3norrdecIeY2ZbkMji5TZ986CsIRxfZIeY=.d5356fa8-a441-451f-a1f5-04724583b86d@github.com>
Message-ID: <hBMopr5SlFVRWsrA8DDirGhyiqqgDIdFHOnh6Rc5gFM=.a2e4c146-57af-4668-93b9-1b69a68048a7@github.com>

On Mon, 9 Dec 2024 11:30:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

Changes look plausible.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22635#pullrequestreview-2489524319

From joehw at openjdk.org  Mon Dec  9 17:44:40 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 9 Dec 2024 17:44:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <mu_rEJuYYxO7juUhV0qSjwkgt7XFhpnwddzS_bRgYcU=.fcc039a4-77c9-445a-9874-b934abeaefeb@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

The git query found all those java.xml properties files likely due to the jcheck change (JDK-8325558) you made. That patch correctly kept the copyright years as they were since we generally don't change copyright year unless the change is significant.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528864312

From iris at openjdk.org  Mon Dec  9 17:58:37 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 9 Dec 2024 17:58:37 GMT
Subject: RFR: 8342987: Update --release 24 symbol information for JDK 24
 build 27
In-Reply-To: <5xzJhBuPr3norrdecIeY2ZbkMji5TZ986CsIRxfZIeY=.d5356fa8-a441-451f-a1f5-04724583b86d@github.com>
References: <5xzJhBuPr3norrdecIeY2ZbkMji5TZ986CsIRxfZIeY=.d5356fa8-a441-451f-a1f5-04724583b86d@github.com>
Message-ID: <xzg_L9M9HTzjSmitjhPl0lp9yyl5dZtQY_MM1ZxIyIE=.0f6ff4d5-fc8c-44a3-b556-3316bebc8b0f@github.com>

On Mon, 9 Dec 2024 11:30:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22635#pullrequestreview-2489580475

From mchung at openjdk.org  Mon Dec  9 18:01:37 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 9 Dec 2024 18:01:37 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <SReh6u2czEgXid48w9XheeErSgeSc3O2_NKZFcl3nCc=.7c7f1e0e-cc65-4344-900d-e6e2fde25358@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22607#pullrequestreview-2489586744

From duke at openjdk.org  Mon Dec  9 18:05:52 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 9 Dec 2024 18:05:52 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <UGrZ0I-Ehrm3LW1N7wtCZk6BD_pSZgSIyqC68uksZ4Q=.d55aada7-d6e9-425a-98bf-04a2088a1639@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
 <UGrZ0I-Ehrm3LW1N7wtCZk6BD_pSZgSIyqC68uksZ4Q=.d55aada7-d6e9-425a-98bf-04a2088a1639@github.com>
Message-ID: <TuIel5N5ZAW1Ap8zThk5Fc5nq2CHFyl_1QoFV2s4qaw=.22db399a-3176-4f91-a5a3-7e7f3b4bd7fe@github.com>

On Fri, 15 Nov 2024 14:35:26 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>>    #...
>
> Thank you!

@asotona
> > I wish that the concrete `PoolEntry` subtypes had `of(?)` factory methods...
> 
> Please forward the proposal on clasfile-api-dev mailing list, where it can be discussed. Thank you.

I?filed [JDK?8345737] for?that, and?would?prefer that?at?least `jdk.internal.classfile.impl.TemporaryConstantPool` were?fully?implemented in?**JDK?24** (see?[JDK?8345734]).

[JDK?8345734]: https://bugs.openjdk.org/browse/JDK-8345734
[JDK?8345737]: https://bugs.openjdk.org/browse/JDK-8345737

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2528944663

From liach at openjdk.org  Mon Dec  9 18:37:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 18:37:42 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <-vHUTV6ABJZEaxVGeZ2FytzgMEIx-Cdcgm_I5TIuxo4=.5f76bd21-9378-4e52-949b-06ad59192bab@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22607#issuecomment-2529047739

From liach at openjdk.org  Mon Dec  9 18:37:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 18:37:43 GMT
Subject: [jdk24] Integrated: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <pKY85AZzy2hqc6ksUGd7oUO5wOaRP9FPj4dS5pha6k4=.f8a0d57a-a0c4-46cc-994e-844867b88e09@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a8132543
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a81325433d7da6b73abb37ea3e33489d0a3afbae
Stats:     634 lines in 360 files changed: 2 ins; 555 del; 77 mod

8334733: Remove obsolete @enablePreview from tests after JDK-8334714

Reviewed-by: mchung
Backport-of: 496641955041c5e48359e6256a4a61812653d900

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

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

From liach at openjdk.org  Mon Dec  9 18:42:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 18:42:53 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <XjF1hXOEYzEqfAVheNHiYyYizF6lF-juVOwxrNMWzg8=.51cf6a58-a001-446f-be48-9565247743a8@github.com>

On Fri, 15 Nov 2024 11:53:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynami...

I fear that promoting creation of unbound `PoolEntry` may be a bad move - they are there only for temporary components of attributes. We should promote creating a local pool entry whenever possible - this is one of the tricks for CodeBuilder optimization, where the usage of CodeBuilder convenience factories elide the creation of intermediate instruction and non-local pool entry objects.

Also for `TemporaryConstantPool` - it has a few weird behaviors, especially that its elements have bad indices.  The `TemporaryConstantPool` itself is never used as a `ConstantPoolBuilder`, and it can be refitted to only implement `ConstantPool` with minimal impact. (Well, aside from these blunt cast-and use cases you've shown)

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2529060857

From acobbs at openjdk.org  Mon Dec  9 19:18:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 9 Dec 2024 19:18:56 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v8]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <NdcN2a6fhP929YpbPClZ5QfaZDJmjTn3ec-eN14aV_Y=.dfc15018-d90d-4bc3-a91f-b2e51398986f@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Remove more unnecessary suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary @SuppressWarnings annotations.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary warning suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update copyright years.
 - Remove a few more @SuppressWarnings annotations.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/cc628a13...ee2862e5

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

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=07
  Stats: 194 lines in 99 files changed: 0 ins; 106 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From acobbs at openjdk.org  Mon Dec  9 19:20:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 9 Dec 2024 19:20:35 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v6]
In-Reply-To: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
Message-ID: <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Merge branch 'master' into SuppressWarningsCleanup-compiler
 - Apply change that was missed somehow.
 - Undo change that will be moved to the core-libs branch.
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21851/files
  - new: https://git.openjdk.org/jdk/pull/21851/files/af81a548..58bed339

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

  Stats: 135916 lines in 2693 files changed: 95118 ins; 30317 del; 10481 mod
  Patch: https://git.openjdk.org/jdk/pull/21851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21851/head:pull/21851

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

From darcy at openjdk.org  Mon Dec  9 19:38:42 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Dec 2024 19:38:42 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v6]
In-Reply-To: <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
 <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
Message-ID: <tfe00iuGcNnatWgrkIxJzXyOkd2LaVeCGWaSXdOfHxo=.af3a1293-5f65-4c23-8c01-5e6e820473b4@github.com>

On Mon, 9 Dec 2024 19:20:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Apply change that was missed somehow.
>  - Undo change that will be moved to the core-libs branch.
>  - Remove unnecessary @SuppressWarnings annotations.

Looks fine; thanks for the cleanup @archiecobbs .

Bumped the reviewer count so someone who more directly works on javac will take a look too.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21851#pullrequestreview-2489826295

From joehw at openjdk.org  Mon Dec  9 19:53:38 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 9 Dec 2024 19:53:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <xsjhXJx2YAuLVr-ryIB6HgQo5pFQbbT5gwORtR-PwrI=.fc98b8c8-a0a7-4bd4-ab1e-1e42eed6b17f@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2489899005

From duke at openjdk.org  Mon Dec  9 20:18:49 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 9 Dec 2024 20:18:49 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <uwuO-ASHIdCpt7gFtyGq4Aa6M_3W4yC50TMG1UV5JL8=.12bd74ca-41c1-4264-85d4-a97160d6b558@github.com>

On Fri, 15 Nov 2024 11:53:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynami...

Thanks to?`TemporaryConstantPool`, I?have been?able to?find [JI?9077904].

[JI?9077904]: https://bugs.openjdk.org/browse/JI-9077904 "[JI?9077904] Broken?`equals` and?`hashCode`?implementation of?`PoolEntry` and?`BootstrapMethodEntry`?implementations"

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2529353994

From ihse at openjdk.org  Mon Dec  9 21:05:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:05:30 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed [v2]
In-Reply-To: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
Message-ID: <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert mistaken changes to binary files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22643/files
  - new: https://git.openjdk.org/jdk/pull/22643/files/114fd977..5eda7858

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

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

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

From rriggs at openjdk.org  Mon Dec  9 21:11:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Dec 2024 21:11:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
 <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>
Message-ID: <mDL9FucpxYnDugHN7ibpYO5qP5o1qwhidL0fzZiTuog=.b93210c4-6fed-4f1b-9f4f-46b2673e41bd@github.com>

On Mon, 9 Dec 2024 15:45:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.
>
>> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.
> 
> I'm not sure I understand what you mean. Are you saying that I did not update files that should have been updated, or that I updated files that should not have been updated?
> 
> The only 3rd party XML files I know about are the ones in `make/data/cldr`. They have certainly been updated in 2024 from upstream, but they do not carry an Oracle copyright header, so there is nothing there to update.

@magicus My question was about third party (xml) code used from Apache.
Joe's review and approval resolved that question.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2529462025

From vromero at openjdk.org  Mon Dec  9 22:11:13 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 9 Dec 2024 22:11:13 GMT
Subject: RFR: 8334756: javac crashed on call to non-existent generic method
 with explicit annotated type arg
Message-ID: <dpS0F2BmkoqPyc4VhFUVxNTejexBpOPs96AfHLMjb-w=.1e4ab78d-c299-4577-9d13-98427a574e40@github.com>

Please review this simple fix that is avoiding a CCE in javac while compiling a non-existent method annotated with type annotations,

TIA

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

Commit messages:
 - 8334756: javac crashed on call to non-existent generic method with explicit annotated type arg

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

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

From darcy at openjdk.org  Mon Dec  9 22:20:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 9 Dec 2024 22:20:40 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v8]
In-Reply-To: <NdcN2a6fhP929YpbPClZ5QfaZDJmjTn3ec-eN14aV_Y=.dfc15018-d90d-4bc3-a91f-b2e51398986f@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <NdcN2a6fhP929YpbPClZ5QfaZDJmjTn3ec-eN14aV_Y=.dfc15018-d90d-4bc3-a91f-b2e51398986f@github.com>
Message-ID: <1A--E365t_-y1kXsWKb_wotAzGiVatMGWyqjdaLkTK8=.72f824e4-07ae-4e5f-b8cc-713280df230d@github.com>

On Mon, 9 Dec 2024 19:18:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary warning suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update copyright years.
>  - Remove a few more @SuppressWarnings annotations.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/cc628a13...ee2862e5

Core reflection changes look fine; thanks for the cleanup @archiecobbs .

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2490237853

From jlu at openjdk.org  Mon Dec  9 23:01:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Dec 2024 23:01:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <GWjrBdyLJQ9FzJkSm8a68fiVZAVcVljFdJPmdRLTdrc=.3ef6fd4d-ead7-473f-8cf4-98f918711888@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Looked at the i18n changes (src, test, and 3rd party icu files w/ Oracle header) and they look correct to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2490302089

From almatvee at openjdk.org  Mon Dec  9 23:37:37 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 9 Dec 2024 23:37:37 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <7v84rQl0BjuUvn8npxHoWUgiJE58li_T3gH52wg9ql4=.c9815e11-fb0a-43f2-8a82-30e8c9e53d59@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

"jdk.jpackage" changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2490361583

From henryjen at openjdk.org  Tue Dec 10 00:47:38 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 10 Dec 2024 00:47:38 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <wMmxoyGUzJO2n0fsrJXJ_2wHXWP00bckY-MEuyRcBhA=.8fdf03f7-73eb-4e05-8268-e92fd01dede5@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
 <63vcWFd5fwCuIIAMsbD2q62_YVzviMzRFGt9qdg5CD0=.406630d5-ee2b-4f2e-af21-984770227578@github.com>
 <wMmxoyGUzJO2n0fsrJXJ_2wHXWP00bckY-MEuyRcBhA=.8fdf03f7-73eb-4e05-8268-e92fd01dede5@github.com>
Message-ID: <pr5q8IccY7al2s_gzkQ16uELgdpBMAUHJ6hHXW3caiA=.c28cdd57-07a9-4c51-b4e1-bd517fd18303@github.com>

On Fri, 6 Dec 2024 00:43:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> That's because the English source file had an update to introduce those double single quotes. (See https://cr.openjdk.org/~jlu/output/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.html). It's just being updated to match.
>
> Oh you're right. That's odd though. But the translations aren't wrong then.

`?? <package> ?\n????????.`
We use <package> here, but the args format is using Chinese translation,`= [-]<???>(,[-]<???>)*`

Should that be consistent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1876949210

From henryjen at openjdk.org  Tue Dec 10 00:47:41 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 10 Dec 2024 00:47:41 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <CDqZ3fHpuYbeSWeNdqGDa5Y1175-XHF1nVyJz_cftB4=.9af6f2dc-ce22-4d88-b775-99825865b90a@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties line 100:

> 98: err.date.out.of.range=--date {0} ?? 1980-01-01T00:00:02Z ? 2099-12-31T23:59:59Z ???????
> 99: err.compress.incorrect=--compress ????{0}
> 100: err.compress.wrong.mode=--??????????? compress

??????????? --compress

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 43:

> 41: resource.installdirnotemptydlg-wix-file=??????? WiX ??????
> 42: resource.launcher-as-service-wix-file=?????? WiX ????
> 43: resource.wix-src-conv=? WiX ?? WiX v3 ????? WiX v4 ??? XSLT ???

Nitpick: The sources here means source code, I would think ?? is more appropriate.
? WiX ?? WiX v3 ????? WiX v4 ??? XSLT ???
? WiX ??? WiX v3 ????? WiX v4 ??? XSLT ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1876975815
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1876981882

From duke at openjdk.org  Tue Dec 10 08:36:39 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Tue, 10 Dec 2024 08:36:39 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <X_pBqCQ10XFOS8-fKoZ5U80O2CgZTlzt3qzC53rOIl8=.c8105e97-68bc-40ab-a17e-a80e53088c8f@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

The `javap` changes in `jdk.jdeps` look good. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/22588#issuecomment-2530801024

From sgehwolf at openjdk.org  Tue Dec 10 09:32:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Dec 2024 09:32:41 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <BUI2a5rLSmY26du2TR8KS7BWfqRA18782mWQmUJ0OkI=.f457c388-f548-42d1-a1b8-3472e68db51d@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

I've only looked at the `jlink` resources and added my suggestions for German.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 68:

> 66: main.runtime.image.linking.cap.disabled=deaktiviert
> 67: main.runtime.image.linking.cap.sect.header=Funktionen:
> 68: main.runtime.image.linking.cap.msg=\      Verkn?pfung von Laufzeitimage {0}

Suggestion:

main.runtime.image.linking.cap.msg=\      Assemblierung von Laufzeitimage {0}

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 73:

> 71: warn.prefix=Warnung:
> 72: 
> 73: err.runtime.link.not.linkable.runtime=Dieses JDK unterst?tzt keine Verkn?pfung vom aktuellen Laufzeitimage

Suggestion:

err.runtime.link.not.linkable.runtime=Dieses JDK unterst?tzt keine Assemblierung vom aktuellen Laufzeitimage

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 74:

> 72: 
> 73: err.runtime.link.not.linkable.runtime=Dieses JDK unterst?tzt keine Verkn?pfung vom aktuellen Laufzeitimage
> 74: err.runtime.link.jdk.jlink.prohibited=Dieses JDK enth?lt keine als Package integrierten Module und kann nicht verwendet werden, um ein anderes Image mit dem Modul jdk.jlink zu erstellen

Suggestion:

err.runtime.link.jdk.jlink.prohibited=Dieses JDK enth?lt keine als Pakete verpackten Module und kann nicht verwendet werden, um ein anderes Image mit dem Modul jdk.jlink zu erstellen

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 75:

> 73: err.runtime.link.not.linkable.runtime=Dieses JDK unterst?tzt keine Verkn?pfung vom aktuellen Laufzeitimage
> 74: err.runtime.link.jdk.jlink.prohibited=Dieses JDK enth?lt keine als Package integrierten Module und kann nicht verwendet werden, um ein anderes Image mit dem Modul jdk.jlink zu erstellen
> 75: err.runtime.link.packaged.mods=Dieses JDK enth?lt keine als Package integrierten Module. "--keep-packaged-modules" wird nicht unterst?tzt

Suggestion:

err.runtime.link.packaged.mods=Dieses JDK enth?lt keine als Pakete verpackten Module. "--keep-packaged-modules" wird nicht unterst?tzt

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 76:

> 74: err.runtime.link.jdk.jlink.prohibited=Dieses JDK enth?lt keine als Package integrierten Module und kann nicht verwendet werden, um ein anderes Image mit dem Modul jdk.jlink zu erstellen
> 75: err.runtime.link.packaged.mods=Dieses JDK enth?lt keine als Package integrierten Module. "--keep-packaged-modules" wird nicht unterst?tzt
> 76: err.runtime.link.modified.file={0} wurde ge?ndert

Suggestion:

err.runtime.link.modified.file={0} wurde modifiziert

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 77:

> 75: err.runtime.link.packaged.mods=Dieses JDK enth?lt keine als Package integrierten Module. "--keep-packaged-modules" wird nicht unterst?tzt
> 76: err.runtime.link.modified.file={0} wurde ge?ndert
> 77: err.runtime.link.patched.module=Datei {0} nicht im Modulimage gefunden. "--patch-module" wird beim Verkn?pfen aus dem Laufzeitimage nicht unterst?tzt

This is an old translation. This has changed with https://bugs.openjdk.org/browse/JDK-8343839. My suggested translation would be:

Suggestion:

err.runtime.link.patched.module=jlink Assemblierung vom Laufzeitimage wird nicht unterst?tzt wenn das Laufzeitimage mit "--patch-module" ver?ndert ist.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 119:

> 117: providers.header=Provider
> 118: 
> 119: runtime.link.info=Verkn?pfung basierend auf dem aktuellen Laufzeitimage

Suggestion:

runtime.link.info=Assemblierung basierend auf dem aktuellen Laufzeitimage

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

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2491567949
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877669257
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877670922
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877679928
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877681883
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877683732
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877700959
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877703007

From psadhukhan at openjdk.org  Tue Dec 10 09:33:39 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 10 Dec 2024 09:33:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

not sure why client label is added, no java.desktop/accessibility files are in there

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2530994967

From prappo at openjdk.org  Tue Dec 10 10:06:50 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Dec 2024 10:06:50 GMT
Subject: Integrated: 8342987: Update --release 24 symbol information for JDK 24
 build 27
In-Reply-To: <5xzJhBuPr3norrdecIeY2ZbkMji5TZ986CsIRxfZIeY=.d5356fa8-a441-451f-a1f5-04724583b86d@github.com>
References: <5xzJhBuPr3norrdecIeY2ZbkMji5TZ986CsIRxfZIeY=.d5356fa8-a441-451f-a1f5-04724583b86d@github.com>
Message-ID: <T-uxQyCuy-incdNyUhujTpM-C8j5QT3srccHbZ5cXNo=.24bd64ab-9c9d-4374-9257-ad39352e2bfa@github.com>

On Mon, 9 Dec 2024 11:30:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

This pull request has now been integrated.

Changeset: 165fd848
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/165fd848c133e3281a13d55da77faa0641586b54
Stats:     225 lines in 6 files changed: 96 ins; 99 del; 30 mod

8342987: Update --release 24 symbol information for JDK 24 build 27

Reviewed-by: darcy, iris

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

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

From abimpoudis at openjdk.org  Tue Dec 10 10:18:39 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 10 Dec 2024 10:18:39 GMT
Subject: RFR: 8334756: javac crashed on call to non-existent generic method
 with explicit annotated type arg
In-Reply-To: <dpS0F2BmkoqPyc4VhFUVxNTejexBpOPs96AfHLMjb-w=.1e4ab78d-c299-4577-9d13-98427a574e40@github.com>
References: <dpS0F2BmkoqPyc4VhFUVxNTejexBpOPs96AfHLMjb-w=.1e4ab78d-c299-4577-9d13-98427a574e40@github.com>
Message-ID: <9LXO9gR7X1d9K3MQu6B9JJaFM3pfVZlUtKg8sQzyIvo=.5912870f-9992-4953-878f-e23a09fef09a@github.com>

On Mon, 9 Dec 2024 22:06:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is avoiding a CCE in javac while compiling a non-existent method annotated with type annotations,
> 
> TIA

LGTM

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22654#pullrequestreview-2491789866

From jlahoda at openjdk.org  Tue Dec 10 10:53:40 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 10 Dec 2024 10:53:40 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <pr5q8IccY7al2s_gzkQ16uELgdpBMAUHJ6hHXW3caiA=.c28cdd57-07a9-4c51-b4e1-bd517fd18303@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <Vqn0ltx1QI-s8h75cyQfhjkgLeKU8IRlsgDJcBYFukQ=.a6632513-e287-4027-a8b1-6de5a3c4f9f0@github.com>
 <63vcWFd5fwCuIIAMsbD2q62_YVzviMzRFGt9qdg5CD0=.406630d5-ee2b-4f2e-af21-984770227578@github.com>
 <wMmxoyGUzJO2n0fsrJXJ_2wHXWP00bckY-MEuyRcBhA=.8fdf03f7-73eb-4e05-8268-e92fd01dede5@github.com>
 <pr5q8IccY7al2s_gzkQ16uELgdpBMAUHJ6hHXW3caiA=.c28cdd57-07a9-4c51-b4e1-bd517fd18303@github.com>
Message-ID: <lEjlPIv3jxcolIWqVXG7J1qKWfQ0eMSmqB3jn2NtJIM=.1be59aaf-a8c7-4b77-b7b0-e3660f4648e0@github.com>

On Tue, 10 Dec 2024 00:05:45 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Oh you're right. That's odd though. But the translations aren't wrong then.
>
> `?? <package> ?\n????????.`
> We use <package> here, but the args format is using Chinese translation,`= [-]<???>(,[-]<???>)*`
> 
> Should that be consistent?

Regarding `''` - please see https://bugs.openjdk.org/browse/JDK-8343412. I believe this is intentional. (`'` needs to be "quoted" in `MessageFormat`.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877719268

From jlahoda at openjdk.org  Tue Dec 10 10:53:39 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 10 Dec 2024 10:53:39 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <bN8bFtynHVhvdBhq3h65RghUMrFm3kgT38jr4lhhSIY=.43c39e35-76b6-4a68-9a6a-83ed4d1a72bf@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

I don't speak any of the languages changed here, but I have looked at:
- the new concise helps for the `java` launcher, added some comments mostly on alignment
- in the `javac` message `transitive modifier for java.base`, `transitive` is a literal modifier appearing in the source, so possibly it should not be translated (we can enhance the English bundle to say that). There's also a comment inline on this.
- for JShell bundles, I note there's no update for Japanese - that's OK, just making sure its intentional. There was also a relatively late change to the JShell bundles:
https://github.com/openjdk/jdk/commit/bcebb0c53c1e4629ebde534e237a86c161130fff#diff-fd30aa079239d0b535a6eb014ee0bc8d16709969c87cc9f6c652f91d75aec769
I assume that change was too late for this drop.

Overall, I think the parts I checked are OK (to the degree I can understand it), with possible (future) improvements for consideration.

src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 44:

> 42: 
> 43: # Translators please note do not translate the options themselves
> 44: java.launcher.opt.concise.header  =   Verwendung: java [Java-Optionen...] <Anwendung> [Anwendungsargumente...]\n\nDabei ist <Anwendung> einer der folgenden Werte:\n  <Hauptklasse>                Zum Ausf?hren der Hauptmethode einer kompilierten Hauptklasse\n  -jar <JAR-Datei>.jar         Zum Ausf?hren der Hauptklasse eines JAR-Archivs\n  -m <Modul>[/<Hauptklasse>] Zum Ausf?hren der Hauptklasse eines Moduls\n  <Quelldatei>.java          Zum Kompilieren und Ausf?hren eines Quelldateiprogramms\n\nDabei sind die folgenden wichtigen Java-Optionen verf?gbar:\n  --class-path <Classpath>\n    <Classpath> ist eine durch "{0}" getrennte Liste der Verzeichnisse und JAR-Archive, in denen nach Klassendateien gesucht werden soll\n  --module-path <Modulpfad>\n    <Modulpfad> ist eine durch "{0}" getrennte Liste der Verzeichnisse und JAR-Archive, in denen nach Modulen gesucht werden soll\n  -version\n    Zum Ausgeben der Produktversion in den Fehlerstream und Beenden des Vorgangs\n\nF?r 
 weitere Verwendungshilfe:           java --help\nF?r eine interaktive Java-Umgebung:    jshell

This gives the following output:

Verwendung: java [Java-Optionen...] <Anwendung> [Anwendungsargumente...]

Dabei ist <Anwendung> einer der folgenden Werte:
  <Hauptklasse>                Zum Ausf?hren der Hauptmethode einer kompilierten Hauptklasse
  -jar <JAR-Datei>.jar         Zum Ausf?hren der Hauptklasse eines JAR-Archivs
  -m <Modul>[/<Hauptklasse>] Zum Ausf?hren der Hauptklasse eines Moduls
  <Quelldatei>.java          Zum Kompilieren und Ausf?hren eines Quelldateiprogramms

Dabei sind die folgenden wichtigen Java-Optionen verf?gbar:
  --class-path <Classpath>
    <Classpath> ist eine durch ":" getrennte Liste der Verzeichnisse und JAR-Archive, in denen nach Klassendateien gesucht werden soll
  --module-path <Modulpfad>
    <Modulpfad> ist eine durch ":" getrennte Liste der Verzeichnisse und JAR-Archive, in denen nach Modulen gesucht werden soll
  -version
    Zum Ausgeben der Produktversion in den Fehlerstream und Beenden des Vorgangs

F?r weitere Verwendungshilfe:           java --help
F?r eine interaktive Java-Umgebung:    jshell


It would be nicer if the `Zum ...` texts would be aligned, and the `java` and `jshell` at the end would be aligned. I.e.:


Verwendung: java [Java-Optionen...] <Anwendung> [Anwendungsargumente...]

Dabei ist <Anwendung> einer der folgenden Werte:
  <Hauptklasse>                Zum Ausf?hren der Hauptmethode einer kompilierten Hauptklasse
  -jar <JAR-Datei>.jar         Zum Ausf?hren der Hauptklasse eines JAR-Archivs
  -m <Modul>[/<Hauptklasse>]   Zum Ausf?hren der Hauptklasse eines Moduls
  <Quelldatei>.java            Zum Kompilieren und Ausf?hren eines Quelldateiprogramms

Dabei sind die folgenden wichtigen Java-Optionen verf?gbar:
  --class-path <Classpath>
    <Classpath> ist eine durch ":" getrennte Liste der Verzeichnisse und JAR-Archive, in denen nach Klassendateien gesucht werden soll
  --module-path <Modulpfad>
    <Modulpfad> ist eine durch ":" getrennte Liste der Verzeichnisse und JAR-Archive, in denen nach Modulen gesucht werden soll
  -version
    Zum Ausgeben der Produktversion in den Fehlerstream und Beenden des Vorgangs

F?r weitere Verwendungshilfe:          java --help
F?r eine interaktive Java-Umgebung:    jshell

src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties line 46:

> 44: 
> 45: # Translators please note do not translate the options themselves
> 46: java.launcher.opt.concise.header  =   ????: java [java options...] <application> [application arguments...]\n\n<application>?????????:\n  <mainclass>                ??????????????????????????????\n  -jar <jarfile>.jar         JAR???????????????????\n  -m <module>[/<mainclass>]  ???????????????????\n  <sourcefile>.java          ???????????????????????????\n\n???java??????????????:\n  --class-path <class path>\n    <class path>???????????????????????????JAR?????????????"{0}"???????\n  --module-path <module path>\n    <module path>????????????????????????JAR?????????????
 "{0}"???????\n  -version\n    ??????????????????????????\n\n??????????????????:           java --help\n????Java?????:    jshell

Similarly to the German version, the currently of `java` and `jshell` are not aligned:

????: java [java options...] <application> [application arguments...]

<application>?????????:
  <mainclass>                ??????????????????????????????
  -jar <jarfile>.jar         JAR???????????????????
  -m <module>[/<mainclass>]  ???????????????????
  <sourcefile>.java          ???????????????????????????

???java??????????????:
  --class-path <class path>
    <class path>???????????????????????????JAR?????????????":"???????
  --module-path <module path>
    <module path>????????????????????????JAR?????????????":"???????
  -version
    ??????????????????????????

??????????????????:           java --help
????Java?????:    jshell


It would be nicer if they did (assuming it is doable):

????: java [java options...] <application> [application arguments...]

<application>?????????:
  <mainclass>                ??????????????????????????????
  -jar <jarfile>.jar         JAR???????????????????
  -m <module>[/<mainclass>]  ???????????????????
  <sourcefile>.java          ???????????????????????????

???java??????????????:
  --class-path <class path>
    <class path>???????????????????????????JAR?????????????":"???????
  --module-path <module path>
    <module path>????????????????????????JAR?????????????":"???????
  -version
    ??????????????????????????

??????????????????:  java --help
????Java?????:             jshell

src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 44:

> 42: 
> 43: # Translators please note do not translate the options themselves
> 44: java.launcher.opt.concise.header  =   ???java [java options...] <application> [application arguments...]\n\n???<application> ???????\n  <mainclass>                ???????? main ??\n  -jar <jarfile>.jar         ?? JAR ?????\n  -m <module>[/<mainclass>]  ???????\n  <sourcefile>.java          ??????????\n\n?????? java ?????\n  --class-path <class path>\n    ???<class path> ???????????? JAR ?????? "{0}" ???\n  --module-path <module path>\n    ???<module path> ??????????? JAR ?????? "{0}" ???\n  -version\n    ??????????????\n\n????????????           java --help\n????? Java ???    jshell

It would be nicer if the  `java` and `jshell` could be aligned in the last section, but maybe it is not possible?

???java [java options...] <application> [application arguments...]

???<application> ???????
  <mainclass>                ???????? main ??
  -jar <jarfile>.jar         ?? JAR ?????
  -m <module>[/<mainclass>]  ???????
  <sourcefile>.java          ??????????

?????? java ?????
  --class-path <class path>
    ???<class path> ???????????? JAR ?????? ":" ???
  --module-path <module path>
    ???<module path> ??????????? JAR ?????? ":" ???
  -version
    ??????????????

????????????           java --help
????? Java ???    jshell

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

> 2300: compiler.misc.feature.module.imports=Modulimporte
> 2301: 
> 2302: compiler.misc.feature.java.base.transitive=Transitiver Modifikator f?r java.base

Here (and in other languages as well), maybe the `transitive` should remain intact? `transitive` is what literally appears in the source code - similar to e.g. `static` or `private`.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2491653435
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877841057
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877847825
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877854317
PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1877712280

From weijun at openjdk.org  Tue Dec 10 14:23:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 10 Dec 2024 14:23:40 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <_clBego0M3HtmxdP78pVQtPZlnS0zpsIYd_BrdIrA2s=.dbce28a2-ae9c-402a-a79e-b35270d9ce5d@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

The 3 zh_TW translations have not included the updated text.

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

PR Comment: https://git.openjdk.org/jdk/pull/22588#issuecomment-2531772251

From prappo at openjdk.org  Tue Dec 10 15:46:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Dec 2024 15:46:38 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <lBvy2qzHjgJeD5SAAvWvYVjKa-XtHunSilD8LBYKljE=.c4e088d4-9701-49c7-be7c-3f7a917e4d75@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

I cannot verify correctness of translation, but I can review this PR generally for `jdk.javadoc`.

>From what I can see, the changes are only to the property files, which is expected from the PR title. The keys from English files 1-1 match the keys from non-English files: there are no missing or extra keys.

>From that point of view, the changes to `jdk.javadoc` look good.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2492753063

From asemenyuk at openjdk.org  Tue Dec 10 16:11:39 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 10 Dec 2024 16:11:39 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <BLl3shag73M-ylOPwlLoohZtZ-RcS3dJEcurOb6ncnE=.675c79b5-1aba-4462-bb16-466832df2482@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

jpackage changes look good

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2492824562

From weijun at openjdk.org  Tue Dec 10 18:06:43 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 10 Dec 2024 18:06:43 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <iHBCiM3T0-eaBVgvozbubFh8igUEsWNq9Y_lkvF4oow=.d04c2f6d-98b4-4d84-ad73-8dbac89035bc@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java line 167:

> 165:         {"history.with.ts", "- \u7531 \"%1$s\" \u7B7E\u540D\n    \u6458\u8981\u7B97\u6CD5: %2$s\n    \u7B7E\u540D\u7B97\u6CD5: %3$s, %4$s\n  \u7531 \"%6$s\" \u4E8E %5$tc \u52A0\u65F6\u95F4\u6233\n    \u65F6\u95F4\u6233\u6458\u8981\u7B97\u6CD5: %7$s\n    \u65F6\u95F4\u6233\u7B7E\u540D\u7B97\u6CD5: %8$s, %9$s"},
> 166:         {"history.without.ts", "- \u7531 \"%1$s\" \u7B7E\u540D\n    \u6458\u8981\u7B97\u6CD5: %2$s\n    \u7B7E\u540D\u7B97\u6CD5: %3$s, %4$s"},
> 167:         {"history.nonexistent.entries", "    \u8B66\u544A\uFF1A\u7B7E\u540D\u6761\u76EE\u4E0D\u5B58\u5728\uFF1A"},

This string will be followed by a list of entry names, so the translation should be "????????: ".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1878576305

From jlu at openjdk.org  Tue Dec 10 19:35:21 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Dec 2024 19:35:21 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v2]
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <P7POGyDv4dp3Kce7Xx3XsQoPDK1sAAzkYvfqAkIWIJM=.9b9b68aa-5a4b-4e35-9333-28deea9be618@github.com>

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

Justin Lu has updated the pull request incrementally with four additional commits since the last revision:

 - implement Severin's review
   
   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
 - implement Jan's review
 - implement Henry's review
 - implement Weijun's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22588/files
  - new: https://git.openjdk.org/jdk/pull/22588/files/6472552b..143e22ea

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

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

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

From jlu at openjdk.org  Tue Dec 10 19:35:21 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Dec 2024 19:35:21 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v2]
In-Reply-To: <iHBCiM3T0-eaBVgvozbubFh8igUEsWNq9Y_lkvF4oow=.d04c2f6d-98b4-4d84-ad73-8dbac89035bc@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <iHBCiM3T0-eaBVgvozbubFh8igUEsWNq9Y_lkvF4oow=.d04c2f6d-98b4-4d84-ad73-8dbac89035bc@github.com>
Message-ID: <ZBgxnEy3YVVZkkLb9-zJB9TxkmNr8a8HhrsHXbMUS0A=.fdad5a07-1d55-4e0e-9e4e-43b5aa03a9f0@github.com>

On Tue, 10 Dec 2024 18:04:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - implement Severin's review
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - implement Jan's review
>>  - implement Henry's review
>>  - implement Weijun's review
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java line 167:
> 
>> 165:         {"history.with.ts", "- \u7531 \"%1$s\" \u7B7E\u540D\n    \u6458\u8981\u7B97\u6CD5: %2$s\n    \u7B7E\u540D\u7B97\u6CD5: %3$s, %4$s\n  \u7531 \"%6$s\" \u4E8E %5$tc \u52A0\u65F6\u95F4\u6233\n    \u65F6\u95F4\u6233\u6458\u8981\u7B97\u6CD5: %7$s\n    \u65F6\u95F4\u6233\u7B7E\u540D\u7B97\u6CD5: %8$s, %9$s"},
>> 166:         {"history.without.ts", "- \u7531 \"%1$s\" \u7B7E\u540D\n    \u6458\u8981\u7B97\u6CD5: %2$s\n    \u7B7E\u540D\u7B97\u6CD5: %3$s, %4$s"},
>> 167:         {"history.nonexistent.entries", "    \u8B66\u544A\uFF1A\u7B7E\u540D\u6761\u76EE\u4E0D\u5B58\u5728\uFF1A"},
> 
> This string will be followed by a list of entry names, so the translation should be "????????????".

Fixed in https://github.com/openjdk/jdk/pull/22588/commits/ba7732db04b966ff49d4b7f779d5120674443a6c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1878709957

From jlu at openjdk.org  Tue Dec 10 19:35:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Dec 2024 19:35:22 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v2]
In-Reply-To: <CDqZ3fHpuYbeSWeNdqGDa5Y1175-XHF1nVyJz_cftB4=.9af6f2dc-ce22-4d88-b775-99825865b90a@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <CDqZ3fHpuYbeSWeNdqGDa5Y1175-XHF1nVyJz_cftB4=.9af6f2dc-ce22-4d88-b775-99825865b90a@github.com>
Message-ID: <inzL0DZhz7pLzOdKaY9DqNkPTQ3XRRQkpbLYzVNonrE=.30980ee6-b645-4924-8703-e9f57f36fb91@github.com>

On Tue, 10 Dec 2024 00:40:23 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - implement Severin's review
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - implement Jan's review
>>  - implement Henry's review
>>  - implement Weijun's review
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 43:
> 
>> 41: resource.installdirnotemptydlg-wix-file=??????? WiX ??????
>> 42: resource.launcher-as-service-wix-file=?????? WiX ????
>> 43: resource.wix-src-conv=? WiX ?? WiX v3 ????? WiX v4 ??? XSLT ???
> 
> Nitpick: The sources here means source code, I would think ?? is more appropriate.
> ? WiX ?? WiX v3 ????? WiX v4 ??? XSLT ???
> ? WiX ??? WiX v3 ????? WiX v4 ??? XSLT ???

This and your other comments fixed in https://github.com/openjdk/jdk/pull/22588/commits/2d9653259d828d5899a1ffeb6af1c05fb5f4d10f. Regarding `"?? <package> ?\n????????."`, yes we should follow the args format, that is, do not translate the contents within < >. I'll speak to the translation team about your comments to get them fixed on their side.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1878712996

From sgehwolf at openjdk.org  Tue Dec 10 19:40:38 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 10 Dec 2024 19:40:38 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v2]
In-Reply-To: <P7POGyDv4dp3Kce7Xx3XsQoPDK1sAAzkYvfqAkIWIJM=.9b9b68aa-5a4b-4e35-9333-28deea9be618@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <P7POGyDv4dp3Kce7Xx3XsQoPDK1sAAzkYvfqAkIWIJM=.9b9b68aa-5a4b-4e35-9333-28deea9be618@github.com>
Message-ID: <7hfBIWh_GjV2lTDKsikRmcrxWeIX7iy5fpEFOky6kGM=.5e7f8ea8-c6da-4a06-83e7-05d0a5703353@github.com>

On Tue, 10 Dec 2024 19:35:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which contains the open L10n drop changes for RDP1.
>> 
>> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
>> 
>> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - implement Severin's review
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - implement Jan's review
>  - implement Henry's review
>  - implement Weijun's review

jlink l10n update looks fine.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2493399735

From jlu at openjdk.org  Tue Dec 10 19:40:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Dec 2024 19:40:39 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v2]
In-Reply-To: <bN8bFtynHVhvdBhq3h65RghUMrFm3kgT38jr4lhhSIY=.43c39e35-76b6-4a68-9a6a-83ed4d1a72bf@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <bN8bFtynHVhvdBhq3h65RghUMrFm3kgT38jr4lhhSIY=.43c39e35-76b6-4a68-9a6a-83ed4d1a72bf@github.com>
Message-ID: <3fgQkAcXuGlUTxRYAsumcS8TM5ZKn9BqJOKnRC2BBrE=.1df0a2b4-d759-452c-810c-b6f4e1c79ceb@github.com>

On Tue, 10 Dec 2024 09:31:57 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - implement Severin's review
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - implement Jan's review
>>  - implement Henry's review
>>  - implement Weijun's review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 2302:
> 
>> 2300: compiler.misc.feature.module.imports=Modulimporte
>> 2301: 
>> 2302: compiler.misc.feature.java.base.transitive=Transitiver Modifikator f?r java.base
> 
> Here (and in other languages as well), maybe the `transitive` should remain intact? `transitive` is what literally appears in the source code - similar to e.g. `static` or `private`.

Fixed in https://github.com/openjdk/jdk/pull/22588/commits/c7bd52950eeb85581aa7dc2c6fbbb02a4f4cff11.
I'll check in with the translation team to ask for it not to be translated, I also left a comment for translators. I only provided the fix for _de_, since it is not obvious to me how to correct it for _ja_ or _zh_CN_.

Regarding the jshell changes in this PR, they are a result of translation fixes we filed with the translation team from previous drops. You are correct that https://github.com/openjdk/jdk/commit/bcebb0c53c1e4629ebde534e237a86c161130fff did not make it in this PR because it was too late. The localized changes for that commit will come in the RDP2 drop.

Regarding the alignment issues in the translated versions, I don't think the translation team would adapt those changes because they are aesthetic, not functional, and this spacing is likely consistent with their l10n language/punctuation rules. If I made this change, we would have to manually adjust these on our side every drop which I don't think would be ideal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1878716896

From jlu at openjdk.org  Tue Dec 10 19:40:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 10 Dec 2024 19:40:41 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v2]
In-Reply-To: <BUI2a5rLSmY26du2TR8KS7BWfqRA18782mWQmUJ0OkI=.f457c388-f548-42d1-a1b8-3472e68db51d@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <BUI2a5rLSmY26du2TR8KS7BWfqRA18782mWQmUJ0OkI=.f457c388-f548-42d1-a1b8-3472e68db51d@github.com>
Message-ID: <rPMCZDtPzO2Hb_YUO4_1u2bVv_n1wu2sEmrDwCZUfrw=.90f8bbf1-ef92-4f40-924e-4da3d64f9d35@github.com>

On Tue, 10 Dec 2024 09:27:42 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - implement Severin's review
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - implement Jan's review
>>  - implement Henry's review
>>  - implement Weijun's review
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 77:
> 
>> 75: err.runtime.link.packaged.mods=Dieses JDK enth?lt keine als Package integrierten Module. "--keep-packaged-modules" wird nicht unterst?tzt
>> 76: err.runtime.link.modified.file={0} wurde ge?ndert
>> 77: err.runtime.link.patched.module=Datei {0} nicht im Modulimage gefunden. "--patch-module" wird beim Verkn?pfen aus dem Laufzeitimage nicht unterst?tzt
> 
> This is an old translation. This has changed with https://bugs.openjdk.org/browse/JDK-8343839. My suggested translation would be:
> 
> Suggestion:
> 
> err.runtime.link.patched.module=jlink Assemblierung vom Laufzeitimage wird nicht unterst?tzt wenn das Laufzeitimage mit "--patch-module" ver?ndert ist.

Excluding as we discussed on the JBS issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22588#discussion_r1878719899

From prr at openjdk.org  Tue Dec 10 21:11:39 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Dec 2024 21:11:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
 <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
Message-ID: <y5MxVqW2c_JJCwWbHTaY6bsutW7nMDH_NjpmXzBCzr0=.c833f43b-6d46-4c90-9a2c-c14521114297@github.com>

On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> not sure why client label is added, no java.desktop/accessibility files are in there

I was puzzling over that too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2532895836

From vromero at openjdk.org  Wed Dec 11 02:15:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Dec 2024 02:15:41 GMT
Subject: RFR: 8334756: javac crashed on call to non-existent generic method
 with explicit annotated type arg
In-Reply-To: <dpS0F2BmkoqPyc4VhFUVxNTejexBpOPs96AfHLMjb-w=.1e4ab78d-c299-4577-9d13-98427a574e40@github.com>
References: <dpS0F2BmkoqPyc4VhFUVxNTejexBpOPs96AfHLMjb-w=.1e4ab78d-c299-4577-9d13-98427a574e40@github.com>
Message-ID: <7l4xzHkX5fZSY5Ii6fwgXO2TFY3CAFUOG-i8ATO1MRg=.37f2b746-0c76-45b1-9e64-4955fd4dd5b6@github.com>

On Mon, 9 Dec 2024 22:06:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is avoiding a CCE in javac while compiling a non-existent method annotated with type annotations,
> 
> TIA

thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/22654#issuecomment-2533463460

From vromero at openjdk.org  Wed Dec 11 02:15:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Dec 2024 02:15:42 GMT
Subject: Integrated: 8334756: javac crashed on call to non-existent generic
 method with explicit annotated type arg
In-Reply-To: <dpS0F2BmkoqPyc4VhFUVxNTejexBpOPs96AfHLMjb-w=.1e4ab78d-c299-4577-9d13-98427a574e40@github.com>
References: <dpS0F2BmkoqPyc4VhFUVxNTejexBpOPs96AfHLMjb-w=.1e4ab78d-c299-4577-9d13-98427a574e40@github.com>
Message-ID: <vx7tilfXsWbKXtJMLmWRVtbfLYLLeJDm3J9o4D_mB9g=.650df366-a7c5-4349-aa0f-40ad606dfc73@github.com>

On Mon, 9 Dec 2024 22:06:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is avoiding a CCE in javac while compiling a non-existent method annotated with type annotations,
> 
> TIA

This pull request has now been integrated.

Changeset: abcd23f4
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/abcd23f4d65698f47fd79a95aed197a12edf2784
Stats:     29 lines in 3 files changed: 28 ins; 0 del; 1 mod

8334756: javac crashed on call to non-existent generic method with explicit annotated type arg

Reviewed-by: abimpoudis

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

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

From jlahoda at openjdk.org  Wed Dec 11 08:53:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 11 Dec 2024 08:53:09 GMT
Subject: RFR: 8345622:
 test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
 should set processorpath to work correctly in the agentvm mode
Message-ID: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>

There is a small difference in the `run main` action when the tests are run using the jtreg's `othervm` mode and `agentvm` mode: in the `othervm`, the test class(es) are load using the application `ClassLoader`, in the `agentvm` mode, the test class(es) are load using an additional jtreg's `ClassLoader`.

In most cases, this does not make much difference, but there's a difference when javac looks up annotation processors (or `Plugin`s): the `othervm` mode, javac can lookup the APs without any help, but in the `agentvm` mode, the `-processorpath` needs to be specified, so that the AP can be load from the correct place.

This patch undoes this (temporary) change:
https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900#diff-4a737e56ccac351e29c3b2c2313d854284ec489aa56c78f09d374d9e20bbb4ecR643

and sets the `-processorpath`, so that the AP can be load. This is consistent with how other similar javac's tests work.

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

Commit messages:
 - 8345622: test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java should set processorpath to work correctly in the agentvm mode

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

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

From mli at openjdk.org  Wed Dec 11 09:40:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 11 Dec 2024 09:40:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <tvt6RZcQwnigoiXNxV7oGeyYq0BSns6TkNEXDsBKiJw=.8e107751-d6c5-4630-8670-c832bc24b973@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Nice batch cleanup.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2494928848

From mcimadamore at openjdk.org  Wed Dec 11 11:38:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Dec 2024 11:38:21 GMT
Subject: RFR: 8345944: JEP 492: extending local class in a different static
 context should not be allowed
Message-ID: <CgUOvmUZ7GvImSxHmND762tXAWDuNvA71ne677hgy9k=.d20e9206-bb1b-4494-8073-66c3bb186c03@github.com>

This PR fixes a couple of issues associated with the implementation of the new stricter checks for local class creation defined by JEP 492.
There are two issues:
* the new checks do not apply to _all_ local classes, especially those whose owner happens to be a _variable_;
* the new checks do not apply when a class _extends_ a local class -- that's because javac only checks superclasses in the case the superclass is an _inner_ class

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

Commit messages:
 - Add tests
 - Initial push

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

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

From mcimadamore at openjdk.org  Wed Dec 11 11:38:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Dec 2024 11:38:22 GMT
Subject: RFR: 8345944: JEP 492: extending local class in a different static
 context should not be allowed
In-Reply-To: <CgUOvmUZ7GvImSxHmND762tXAWDuNvA71ne677hgy9k=.d20e9206-bb1b-4494-8073-66c3bb186c03@github.com>
References: <CgUOvmUZ7GvImSxHmND762tXAWDuNvA71ne677hgy9k=.d20e9206-bb1b-4494-8073-66c3bb186c03@github.com>
Message-ID: <keuMoebstRzzijOEAOyGt4s8QHrl_V_z0N718p9zmDw=.096da34e-739a-4140-91ef-c1defca0e7e9@github.com>

On Wed, 11 Dec 2024 11:29:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes a couple of issues associated with the implementation of the new stricter checks for local class creation defined by JEP 492.
> There are two issues:
> * the new checks do not apply to _all_ local classes, especially those whose owner happens to be a _variable_;
> * the new checks do not apply when a class _extends_ a local class -- that's because javac only checks superclasses in the case the superclass is an _inner_ class

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

> 2595:                 }
> 2596: 
> 2597:                 if (tree.meth.hasTag(IDENT)) {

I've moved this code outside the `if (encl != null)` so that now it can be applied to all kind of superclasses. Note that `checkNewInnerClass` will also check whether the target class is either inner or local, so we don't need to check anything else here.

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

> 3071: 
> 3072:         void checkNewInnerClass(DiagnosticPosition pos, Env<AttrContext> env, Type type, boolean isSuper) {
> 3073:             boolean isLocal = type.tsym.owner.kind == VAR || type.tsym.owner.kind == MTH;

Most local classes will have their owner set to some method symbols. But, in some corner cases where a local class is defined inside a field initializer, the owner can actually be a *variable* symbol too.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3837:

> 3835:     Symbol findLocalClassOwner(Env<AttrContext> env, TypeSymbol c) {
> 3836:         Symbol owner = c.owner;
> 3837:         Assert.check(owner.kind == MTH || owner.kind == VAR);

We now need to generalize this, so that it works for both method and variable owners.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22679#discussion_r1879929965
PR Review Comment: https://git.openjdk.org/jdk/pull/22679#discussion_r1879946657
PR Review Comment: https://git.openjdk.org/jdk/pull/22679#discussion_r1879950026

From lancea at openjdk.org  Wed Dec 11 11:41:40 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 11 Dec 2024 11:41:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <SnUMv7eXNRQU7c9T4Bi3BQkxaesNNYM1VxK3mY7ABJc=.102d4905-e86c-445e-8e31-e60a1a45249c@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2495330243

From vromero at openjdk.org  Wed Dec 11 14:42:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Dec 2024 14:42:42 GMT
Subject: RFR: 8345944: JEP 492: extending local class in a different static
 context should not be allowed
In-Reply-To: <CgUOvmUZ7GvImSxHmND762tXAWDuNvA71ne677hgy9k=.d20e9206-bb1b-4494-8073-66c3bb186c03@github.com>
References: <CgUOvmUZ7GvImSxHmND762tXAWDuNvA71ne677hgy9k=.d20e9206-bb1b-4494-8073-66c3bb186c03@github.com>
Message-ID: <bxMrjxX570BzILdXZngWuwcd4jgfcZyMbDDqMBUbe48=.14fbf96a-e081-4317-9217-97957affa0cd@github.com>

On Wed, 11 Dec 2024 11:29:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes a couple of issues associated with the implementation of the new stricter checks for local class creation defined by JEP 492.
> There are two issues:
> * the new checks do not apply to _all_ local classes, especially those whose owner happens to be a _variable_;
> * the new checks do not apply when a class _extends_ a local class -- that's because javac only checks superclasses in the case the superclass is an _inner_ class

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22679#pullrequestreview-2495878316

From darcy at openjdk.org  Wed Dec 11 17:47:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Dec 2024 17:47:11 GMT
Subject: RFR: 8345622:
 test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
 should set processorpath to work correctly in the agentvm mode
In-Reply-To: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>
References: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>
Message-ID: <UhWKbDzhseKw8kj83EX7rSJC-hQf7hueA-_CC7Uy0pc=.5d89c782-c85d-449d-b532-7fa5fa17aca6@github.com>

On Wed, 11 Dec 2024 08:48:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a small difference in the `run main` action when the tests are run using the jtreg's `othervm` mode and `agentvm` mode: in the `othervm`, the test class(es) are load using the application `ClassLoader`, in the `agentvm` mode, the test class(es) are load using an additional jtreg's `ClassLoader`.
> 
> In most cases, this does not make much difference, but there's a difference when javac looks up annotation processors (or `Plugin`s): the `othervm` mode, javac can lookup the APs without any help, but in the `agentvm` mode, the `-processorpath` needs to be specified, so that the AP can be load from the correct place.
> 
> This patch undoes this (temporary) change:
> https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900#diff-4a737e56ccac351e29c3b2c2313d854284ec489aa56c78f09d374d9e20bbb4ecR643
> 
> and sets the `-processorpath`, so that the AP can be load. This is consistent with how other similar javac's tests work.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22676#pullrequestreview-2496413809

From liach at openjdk.org  Wed Dec 11 18:22:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 11 Dec 2024 18:22:15 GMT
Subject: RFR: 8345622:
 test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
 should set processorpath to work correctly in the agentvm mode
In-Reply-To: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>
References: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>
Message-ID: <4nm-6fyYb1IZyvZhsEWGkoJ0CYZjob4DECvHM5vYcSE=.7c32cb64-3c2c-49eb-a32c-080813d054a5@github.com>

On Wed, 11 Dec 2024 08:48:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a small difference in the `run main` action when the tests are run using the jtreg's `othervm` mode and `agentvm` mode: in the `othervm`, the test class(es) are load using the application `ClassLoader`, in the `agentvm` mode, the test class(es) are load using an additional jtreg's `ClassLoader`.
> 
> In most cases, this does not make much difference, but there's a difference when javac looks up annotation processors (or `Plugin`s): the `othervm` mode, javac can lookup the APs without any help, but in the `agentvm` mode, the `-processorpath` needs to be specified, so that the AP can be load from the correct place.
> 
> This patch undoes this (temporary) change:
> https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900#diff-4a737e56ccac351e29c3b2c2313d854284ec489aa56c78f09d374d9e20bbb4ecR643
> 
> and sets the `-processorpath`, so that the AP can be load. This is consistent with how other similar javac's tests work.

Marked as reviewed by liach (Reviewer).

We might need to backport this to 24 too.

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

PR Review: https://git.openjdk.org/jdk/pull/22676#pullrequestreview-2496496975
PR Comment: https://git.openjdk.org/jdk/pull/22676#issuecomment-2536797963

From ihse at openjdk.org  Wed Dec 11 21:10:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:10:52 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
 <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
Message-ID: <m7oETe1RAtaoT1NyVmjhpbwEWCluWGDzOMgGKjgE-FU=.d15b5616-c416-47aa-89f5-c816d893f45e@github.com>

On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to binary files
>
> not sure why client label is added, no java.desktop/accessibility files are in there

@prsadhuk @prrace `src/java.base/share/classes/jdk/internal/access/JavaAWTFontAccess.java` matches the pattern `"src/java.base/share/classes/jdk/internal/access/\\w+AWT"` which is setup for `client` in the Skara `jdk.json` label configuration.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2537183864

From ihse at openjdk.org  Wed Dec 11 21:10:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:10:53 GMT
Subject: Integrated: 8345799: Update copyright year to 2024 for core-libs in
 files where it was missed
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <kZZWqqQs4ZIlaEEhWti7W4jqwB76v78dWz7Tk-kTzHE=.8da2847d-ec74-4fe4-b28e-e7c9a7b308b8@github.com>

On Mon, 9 Dec 2024 12:30:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

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

8345799: Update copyright year to 2024 for core-libs in files where it was missed

Reviewed-by: joehw, jlu, mli, lancea, kevinw

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

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

From ihse at openjdk.org  Wed Dec 11 21:31:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:31:37 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed [v2]
In-Reply-To: <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
 <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
Message-ID: <gUI6O3DLdlu4AdhDS-0B-cDMlrzYXg75SFi7EMrdj3w=.e530ac99-c013-4fa4-a6ab-a7f682524cd3@github.com>

On Mon, 9 Dec 2024 21:05:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

Any reviewers on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/22643#issuecomment-2537230906

From cstein at openjdk.org  Thu Dec 12 07:56:49 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 07:56:49 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in MR-JAR
 files
Message-ID: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>

Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version.

For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:

classfile release value of META-INF/versions/9/version/Version.class too high: 25
classfile release value of META-INF/versions/10/version/Version.class too high: 25
invalid multi-release jar file a.jar deleted


- [x] Implement check
- [x] Update failing tests

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

Commit messages:
 - Fix test to not produce an invalid MRJAR file
 - Introduce dedicated error message for "too high" check
 - Fix MultiReleaseJar.java
 - Fix MultiVersionError.java
 - Fix MissingDepsTest.java
 - Fix VersionValidatorTest.java
 - Fix Basic.java and Basic1.java
 - Fix ApiValidatorTest.java
 - Fix Basic.java
 - 8268611: jar --validate should check targeted classes in MR-JAR files

Changes: https://git.openjdk.org/jdk/pull/22103/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8268611
  Stats: 132 lines in 13 files changed: 41 ins; 23 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/22103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22103/head:pull/22103

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

From jlahoda at openjdk.org  Thu Dec 12 07:56:49 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 12 Dec 2024 07:56:49 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <2RI7ya3iG1kVdhnMvmGY82J-RI0U_zMpFtv3Qtg_zIo=.e37c942f-b8de-42b7-aa09-27bf4e9dfc91@github.com>

On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> - [x] Implement check
> - [x] Update failing tests

Makes sense to me. Might be better to have an error message for this separate from the existing error condition, in case the texts would need to differ at some point.

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

PR Comment: https://git.openjdk.org/jdk/pull/22103#issuecomment-2478134100

From mcimadamore at openjdk.org  Thu Dec 12 10:56:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Dec 2024 10:56:44 GMT
Subject: Integrated: 8345944: JEP 492: extending local class in a different
 static context should not be allowed
In-Reply-To: <CgUOvmUZ7GvImSxHmND762tXAWDuNvA71ne677hgy9k=.d20e9206-bb1b-4494-8073-66c3bb186c03@github.com>
References: <CgUOvmUZ7GvImSxHmND762tXAWDuNvA71ne677hgy9k=.d20e9206-bb1b-4494-8073-66c3bb186c03@github.com>
Message-ID: <3H5rvQcr5AVCTx6NH07Ag4a6oG2Dyg8QsSGvsPvBiv8=.3900727c-a43a-4583-8bf8-38a29ca00087@github.com>

On Wed, 11 Dec 2024 11:29:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes a couple of issues associated with the implementation of the new stricter checks for local class creation defined by JEP 492.
> There are two issues:
> * the new checks do not apply to _all_ local classes, especially those whose owner happens to be a _variable_;
> * the new checks do not apply when a class _extends_ a local class -- that's because javac only checks superclasses in the case the superclass is an _inner_ class

This pull request has now been integrated.

Changeset: 0ad64234
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ad64234e2fd19ec0435fb00340120153b928f9c
Stats:     275 lines in 6 files changed: 266 ins; 4 del; 5 mod

8345944: JEP 492: extending local class in a different static context should not be allowed
8345953: JEP 492: instantiating local classes in a different static context should not be allowed

Reviewed-by: vromero

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

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

From rgiulietti at openjdk.org  Thu Dec 12 11:43:38 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Dec 2024 11:43:38 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed [v2]
In-Reply-To: <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
 <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
Message-ID: <gRpzIP6Mlw0AxGgTQYihZikOGI73xvXWkpgaZ888ixw=.b2021a8e-40da-4a0f-aa05-19220a901240@github.com>

On Mon, 9 Dec 2024 21:05:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

LGTM

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22643#pullrequestreview-2499124132

From jvernee at openjdk.org  Thu Dec 12 12:01:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Dec 2024 12:01:36 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <gm2XLlA09Sj0mHEPiWLwlLeyueSulPaY__A7AYpNfyg=.c79c0e8d-6627-4f48-8ea7-1cca48b12675@github.com>

On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

I was wondering if this would have to be covered in the jar file spec, but it looks like it already is: https://docs.oracle.com/en/java/javase/23/docs/specs/jar/jar.html#multi-release-jar-files

> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.

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

PR Comment: https://git.openjdk.org/jdk/pull/22103#issuecomment-2538703496

From jlahoda at openjdk.org  Thu Dec 12 12:02:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 12 Dec 2024 12:02:43 GMT
Subject: RFR: 8345622:
 test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
 should set processorpath to work correctly in the agentvm mode
In-Reply-To: <4nm-6fyYb1IZyvZhsEWGkoJ0CYZjob4DECvHM5vYcSE=.7c32cb64-3c2c-49eb-a32c-080813d054a5@github.com>
References: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>
 <4nm-6fyYb1IZyvZhsEWGkoJ0CYZjob4DECvHM5vYcSE=.7c32cb64-3c2c-49eb-a32c-080813d054a5@github.com>
Message-ID: <RgTkrjKR9f1ll5xd5oLxvaW5EovsoJP58R21wAJPYSU=.975eef2a-cf0b-4ee8-a6e0-f9eb7771bfda@github.com>

On Wed, 11 Dec 2024 18:20:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> We might need to backport this to 24 too.

I don't think the need for a backport is very strong. While (I think) the tests more commonly set the processorpath, the code before this PR should work OK, and should be good enough.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22676#issuecomment-2538703868

From jlahoda at openjdk.org  Thu Dec 12 12:02:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 12 Dec 2024 12:02:44 GMT
Subject: Integrated: 8345622:
 test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
 should set processorpath to work correctly in the agentvm mode
In-Reply-To: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>
References: <RowaLKfUKgF0X6zGDdG7V2htVt4lv46UZc9pN8zWHEo=.b53fb861-8185-485d-8e7e-883ee1723c95@github.com>
Message-ID: <GlAhVseTANFfwUduzfysLXzqzzyv34hav7r9Fb-IJCM=.ad7ad4ec-c1c5-4807-9d2d-e33a19fd6678@github.com>

On Wed, 11 Dec 2024 08:48:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a small difference in the `run main` action when the tests are run using the jtreg's `othervm` mode and `agentvm` mode: in the `othervm`, the test class(es) are load using the application `ClassLoader`, in the `agentvm` mode, the test class(es) are load using an additional jtreg's `ClassLoader`.
> 
> In most cases, this does not make much difference, but there's a difference when javac looks up annotation processors (or `Plugin`s): the `othervm` mode, javac can lookup the APs without any help, but in the `agentvm` mode, the `-processorpath` needs to be specified, so that the AP can be load from the correct place.
> 
> This patch undoes this (temporary) change:
> https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900#diff-4a737e56ccac351e29c3b2c2313d854284ec489aa56c78f09d374d9e20bbb4ecR643
> 
> and sets the `-processorpath`, so that the AP can be load. This is consistent with how other similar javac's tests work.

This pull request has now been integrated.

Changeset: 1bdb7b42
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bdb7b4271098b02ee225c101ea7a12a432d0440
Stats:     3 lines in 1 file changed: 2 ins; 1 del; 0 mod

8345622: test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java should set processorpath to work correctly in the agentvm mode

Reviewed-by: darcy, liach

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

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

From jlahoda at openjdk.org  Thu Dec 12 12:05:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 12 Dec 2024 12:05:42 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed [v2]
In-Reply-To: <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
 <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
Message-ID: <Sly2_dYRsA0AQ9ZwQU_VFJmf5u_qXhqC3eEU2hV9lyo=.62c8f3ce-a319-4bd5-83f5-38faafb557bf@github.com>

On Mon, 9 Dec 2024 21:05:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

Looks sensible to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22643#pullrequestreview-2499212215

From ihse at openjdk.org  Thu Dec 12 12:09:40 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Dec 2024 12:09:40 GMT
Subject: RFR: 8345804: Update copyright year to 2024 for langtools in files
 where it was missed [v2]
In-Reply-To: <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
 <KyA2_DNRdbGRgca8eeOWjp4-uzNS8cDbVDH0VO7xM9M=.aa4bf350-7caf-4ba7-b4db-15b15f8a7f6a@github.com>
Message-ID: <Lk9sJErXWP5f2LWyGgXdF4LzronAIdEerea4S9JScg0=.edd548cb-8f98-4327-93dd-68c7af6a0579@github.com>

On Mon, 9 Dec 2024 21:05:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22643#issuecomment-2538720181

From ihse at openjdk.org  Thu Dec 12 12:09:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Dec 2024 12:09:41 GMT
Subject: Integrated: 8345804: Update copyright year to 2024 for langtools in
 files where it was missed
In-Reply-To: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
References: <ZotdOsq8WAVwBnEVa9-lzxTQwndjnSBRLf0dBEqclvE=.533c2c0d-6ffe-4812-914f-b307092017eb@github.com>
Message-ID: <aX56lxv8gQAJUVXSA5qyF6lfVUs7IqGu9Kh2e_444qo=.b2580109-1c23-44b4-925d-d3eb54d7c628@github.com>

On Mon, 9 Dec 2024 12:55:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

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

8345804: Update copyright year to 2024 for langtools in files where it was missed

Reviewed-by: rgiulietti, jlahoda

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

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

From cstein at openjdk.org  Thu Dec 12 12:10:35 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 12:10:35 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <ldg37zlDiob2FH3Opm-0VajLOMqp6NAVtI-03ccIL4s=.13c806a1-84c6-492c-9797-b07c0e78d618@github.com>

On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

Yes. It was and is specified, but not enforced at package/archive-time ... and always failed at runtime with a "class version error" or similar on a Java version "in between".

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

PR Comment: https://git.openjdk.org/jdk/pull/22103#issuecomment-2538723675

From mcimadamore at openjdk.org  Thu Dec 12 12:18:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Dec 2024 12:18:12 GMT
Subject: [jdk24] RFR: 8345944: JEP 492: extending local class in a different
 static context should not be allowed
Message-ID: <OEC4tR2kmnlz4w9Om4XwaLZ1pIqBq0TajCfAcTH0mqI=.bd11258d-4592-4f88-877f-52fba761b4b8@github.com>

8345944: JEP 492: extending local class in a different static context should not be allowed

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

Commit messages:
 - Backport 0ad64234e2fd19ec0435fb00340120153b928f9c

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

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

From jlahoda at openjdk.org  Thu Dec 12 13:15:47 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 12 Dec 2024 13:15:47 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v3]
In-Reply-To: <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
Message-ID: <9THvQQ1jDtBEUHwOHcXcmEmbU57eoiaFCapqOYJS9BQ=.e6b90736-6c6c-4c73-bdeb-bf4b836af80a@github.com>

On Fri, 6 Dec 2024 11:03:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add other missing lint categories

Looks sensible to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22553#pullrequestreview-2499499578

From asotona at openjdk.org  Thu Dec 12 13:29:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Dec 2024 13:29:39 GMT
Subject: RFR: 8344647: Make java.se participate in the preview language
 feature `requires transitive java.base`
In-Reply-To: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
References: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
Message-ID: <5rc6GndjuXVb_k55I7ptwgtViYvUGUz-VLyEPYYcRUM=.41dd4fca-f4b2-48fb-b940-744b9c847eb2@github.com>

On Fri, 22 Nov 2024 13:42:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

Looks good to me.
JEP 494 puts java.se into a special position related to the preview participation and that position should not depend on java.base internal annotation.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22322#pullrequestreview-2499578321

From jvernee at openjdk.org  Thu Dec 12 14:54:38 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Dec 2024 14:54:38 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>

On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

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

> 92:         unexpected versioned entry {0} for release {1}
> 93: error.release.value.toohigh.versioned.entry=\
> 94:         classfile release value of {0} too high: {1}

Not sure about the term 'release value' here. Is that defined somewhere?

Maybe leaning on 'class file major version' like this would work better?

Suggestion:

error.release.value.toohigh.versioned.entry=\
        class file {0} targeting version '{1}' must have a major version lower or equal to '{2}' , but was '{3}'


And then `{0}` is the entry, `{1}` is the `mrversion`, `{2}` is the class file major version associated with that `mrversion`, and `{3}` was the actual class file major version.

(also, 'class file' is two words)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882289038

From cstein at openjdk.org  Thu Dec 12 15:28:41 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 15:28:41 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
Message-ID: <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>

On Thu, 12 Dec 2024 14:47:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version.
>> 
>> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
>> 
>> classfile release value of META-INF/versions/9/version/Version.class too high: 25
>> classfile release value of META-INF/versions/10/version/Version.class too high: 25
>> invalid multi-release jar file a.jar deleted
>> 
>> 
>> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 94:
> 
>> 92:         unexpected versioned entry {0} for release {1}
>> 93: error.release.value.toohigh.versioned.entry=\
>> 94:         classfile release value of {0} too high: {1}
> 
> Not sure about the term 'release value' here. Is that defined somewhere?
> 
> Maybe leaning on 'class file major version' like this would work better?
> 
> Suggestion:
> 
> error.release.value.toohigh.versioned.entry=\
>         class file {0} targeting version '{1}' must have a major version lower or equal to '{2}' , but was '{3}'
> 
> 
> And then `{0}` is the entry, `{1}` is the `mrversion`, `{2}` is the class file major version associated with that `mrversion`, and `{3}` was the actual class file major version.
> 
> (also, 'class file' is two words)

In this context the actual class file major version doesn't add any value to communicate the issue to the user:
- `javac --release N` and
- `jar --release N` use the "Java release feature number" in their options, so does the
- `META-INF/versions/N` path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882367322

From cstein at openjdk.org  Thu Dec 12 15:28:41 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 15:28:41 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
Message-ID: <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>

On Thu, 12 Dec 2024 15:23:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 94:
>> 
>>> 92:         unexpected versioned entry {0} for release {1}
>>> 93: error.release.value.toohigh.versioned.entry=\
>>> 94:         classfile release value of {0} too high: {1}
>> 
>> Not sure about the term 'release value' here. Is that defined somewhere?
>> 
>> Maybe leaning on 'class file major version' like this would work better?
>> 
>> Suggestion:
>> 
>> error.release.value.toohigh.versioned.entry=\
>>         class file {0} targeting version '{1}' must have a major version lower or equal to '{2}' , but was '{3}'
>> 
>> 
>> And then `{0}` is the entry, `{1}` is the `mrversion`, `{2}` is the class file major version associated with that `mrversion`, and `{3}` was the actual class file major version.
>> 
>> (also, 'class file' is two words)
>
> In this context the actual class file major version doesn't add any value to communicate the issue to the user:
> - `javac --release N` and
> - `jar --release N` use the "Java release feature number" in their options, so does the
> - `META-INF/versions/N` path.

User-facing help messages read:

javac --help
...
  --release <release>
        Compile for the specified Java SE release.
        Supported releases:
            8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25


jar --help
...
      --release VERSION      Places all following files in a versioned directory
                             of the jar (i.e. META-INF/versions/VERSION/)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882372640

From cstein at openjdk.org  Thu Dec 12 15:32:35 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 15:32:35 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
 <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
Message-ID: <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>

On Thu, 12 Dec 2024 15:26:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> In this context the actual class file major version doesn't add any value to communicate the issue to the user:
>> - `javac --release N` and
>> - `jar --release N` use the "Java release feature number" in their options, so does the
>> - `META-INF/versions/N` path.
>
> User-facing help messages read:
> 
> javac --help
> ...
>   --release <release>
>         Compile for the specified Java SE release.
>         Supported releases:
>             8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25
> 
> 
> jar --help
> ...
>       --release VERSION      Places all following files in a versioned directory
>                              of the jar (i.e. META-INF/versions/VERSION/)

Maybe this reads better? `release version of {0} too high: {1}`:

release version of META-INF/versions/9/version/Version.class too high: 25
release version of META-INF/versions/10/version/Version.class too high: 25

Note that the path of the JAR entry contains the target release version number, and `Version.class` was compiled with `javac` 25 (with `--release 25`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882378353

From cstein at openjdk.org  Thu Dec 12 15:36:35 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 15:36:35 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
 <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
 <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>
Message-ID: <Y2wQKszOHWi7bfSP6bsUYXH-C8xBXQZLofUEhTHk1WQ=.0144b96d-f395-476a-a081-55b74fcabac8@github.com>

On Thu, 12 Dec 2024 15:29:33 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> User-facing help messages read:
>> 
>> javac --help
>> ...
>>   --release <release>
>>         Compile for the specified Java SE release.
>>         Supported releases:
>>             8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25
>> 
>> 
>> jar --help
>> ...
>>       --release VERSION      Places all following files in a versioned directory
>>                              of the jar (i.e. META-INF/versions/VERSION/)
>
> Maybe this reads better? `release version of {0} too high: {1}`:
> 
> release version of META-INF/versions/9/version/Version.class too high: 25
> release version of META-INF/versions/10/version/Version.class too high: 25
> 
> Note that the path of the JAR entry contains the target release version number, and `Version.class` was compiled with `javac` 25 (with `--release 25`).

Prior-art in the messages do read:

error.release.value.notnumber=\
        release {0} not valid
error.release.value.toosmall=\
        release {0} not valid, must be >= 9
error.release.unexpected.versioned.entry=\
        unexpected versioned entry {0} for release {1}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882383691

From cstein at openjdk.org  Thu Dec 12 15:36:36 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 15:36:36 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <Y2wQKszOHWi7bfSP6bsUYXH-C8xBXQZLofUEhTHk1WQ=.0144b96d-f395-476a-a081-55b74fcabac8@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
 <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
 <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>
 <Y2wQKszOHWi7bfSP6bsUYXH-C8xBXQZLofUEhTHk1WQ=.0144b96d-f395-476a-a081-55b74fcabac8@github.com>
Message-ID: <01HbESLE2Zla_4uKykaEmJzC_byo74tlePuBDbijl7k=.2592e38c-5207-4fcb-a973-efc38dda916b@github.com>

On Thu, 12 Dec 2024 15:32:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Maybe this reads better? `release version of {0} too high: {1}`:
>> 
>> release version of META-INF/versions/9/version/Version.class too high: 25
>> release version of META-INF/versions/10/version/Version.class too high: 25
>> 
>> Note that the path of the JAR entry contains the target release version number, and `Version.class` was compiled with `javac` 25 (with `--release 25`).
>
> Prior-art in the messages do read:
> 
> error.release.value.notnumber=\
>         release {0} not valid
> error.release.value.toosmall=\
>         release {0} not valid, must be >= 9
> error.release.unexpected.versioned.entry=\
>         unexpected versioned entry {0} for release {1}

According to above's prior-art, it could just read `release of {0} too high: {1}`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882386494

From vromero at openjdk.org  Thu Dec 12 15:58:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Dec 2024 15:58:37 GMT
Subject: [jdk24] RFR: 8345944: JEP 492: extending local class in a
 different static context should not be allowed
In-Reply-To: <OEC4tR2kmnlz4w9Om4XwaLZ1pIqBq0TajCfAcTH0mqI=.bd11258d-4592-4f88-877f-52fba761b4b8@github.com>
References: <OEC4tR2kmnlz4w9Om4XwaLZ1pIqBq0TajCfAcTH0mqI=.bd11258d-4592-4f88-877f-52fba761b4b8@github.com>
Message-ID: <-JOleBENKPnczOqoe-HVURX28MqPgmIj1ulN17IJUF4=.e8364019-05b8-4c80-a1b8-b716c6eedaac@github.com>

On Thu, 12 Dec 2024 12:12:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a simple backport of [this commit](https://github.com/openjdk/jdk/commit/0ad64234e2fd19ec0435fb00340120153b928f9c)

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22708#pullrequestreview-2500086553

From jvernee at openjdk.org  Thu Dec 12 16:06:35 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Dec 2024 16:06:35 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <01HbESLE2Zla_4uKykaEmJzC_byo74tlePuBDbijl7k=.2592e38c-5207-4fcb-a973-efc38dda916b@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
 <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
 <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>
 <Y2wQKszOHWi7bfSP6bsUYXH-C8xBXQZLofUEhTHk1WQ=.0144b96d-f395-476a-a081-55b74fcabac8@github.com>
 <01HbESLE2Zla_4uKykaEmJzC_byo74tlePuBDbijl7k=.2592e38c-5207-4fcb-a973-efc38dda916b@github.com>
Message-ID: <X79_A3rO7XYSddHEsqFmG3qKh_L1TLI_U85mDxrCCLU=.9eb01d8b-c5f6-4a84-9074-7690a4655cdf@github.com>

On Thu, 12 Dec 2024 15:34:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> `release of {0} too high: {1}`

I think this is better. Probably good enough.

My concern stems from the fact that 'release' doesn't seem to be defined for _class files_. I see that the term 'release' exists, and maps to a versioned directory, or you can compile classes _for_ a certain release, But, it seems that 'the release of a class file' is a new concept here. (after all, `javac` doesn't produce class files _with_ a certain release).

Maybe: `class file {fp.entryName()} compiled for release {fp.classReleaseVersion()}, is illegal in version directory {fp.mrversion()}`

(This is perhaps somewhat terse, but `javac` sets the precedent for that. A user could find out _why_ the version is illegal by referencing the jar file spec).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882434374

From cstein at openjdk.org  Thu Dec 12 16:30:46 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 12 Dec 2024 16:30:46 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <X79_A3rO7XYSddHEsqFmG3qKh_L1TLI_U85mDxrCCLU=.9eb01d8b-c5f6-4a84-9074-7690a4655cdf@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
 <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
 <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>
 <Y2wQKszOHWi7bfSP6bsUYXH-C8xBXQZLofUEhTHk1WQ=.0144b96d-f395-476a-a081-55b74fcabac8@github.com>
 <01HbESLE2Zla_4uKykaEmJzC_byo74tlePuBDbijl7k=.2592e38c-5207-4fcb-a973-efc38dda916b@github.com>
 <X79_A3rO7XYSddHEsqFmG3qKh_L1TLI_U85mDxrCCLU=.9eb01d8b-c5f6-4a84-9074-7690a4655cdf@github.com>
Message-ID: <35yoAdc5QoaJ6wXksaMaBD67DsjBUf-8CFXhkLVLYTc=.5578b4b7-6de3-481a-96c5-5aa52603a8f0@github.com>

On Thu, 12 Dec 2024 16:00:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> According to above's prior-art, it could just read `release of {0} too high: {1}`
>
>> `release of {0} too high: {1}`
> 
> I think this is better. Probably good enough.
> 
> My concern stems from the fact that 'release' doesn't seem to be defined for _class files_. I see that the term 'release' exists, and maps to a versioned directory, or you can compile classes _for_ a certain release, But, it seems that 'the release of a class file' is a new concept here. (after all, `javac` doesn't produce class files _with_ a certain release).
> 
> Maybe: `class file {fp.entryName()} compiled for release {fp.classReleaseVersion()}, is illegal in version directory {fp.mrversion()}`
> 
> (This is perhaps somewhat terse, but `javac` sets the precedent for that. A user could find out _why_ the version is illegal by referencing the jar file spec).

Let's try it out with the two examples from the initial description:


release version of META-INF/versions/9/version/Version.class too high: 25
release version of META-INF/versions/10/version/Version.class too high: 25



class file META-INF/versions/9/version/Version.class compiled for release 25, is illegal in version directory 9
class file META-INF/versions/10/version/Version.class compiled for release 25, is illegal in version directory 10

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882481827

From mchung at openjdk.org  Thu Dec 12 22:23:36 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 12 Dec 2024 22:23:36 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <35yoAdc5QoaJ6wXksaMaBD67DsjBUf-8CFXhkLVLYTc=.5578b4b7-6de3-481a-96c5-5aa52603a8f0@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
 <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
 <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>
 <Y2wQKszOHWi7bfSP6bsUYXH-C8xBXQZLofUEhTHk1WQ=.0144b96d-f395-476a-a081-55b74fcabac8@github.com>
 <01HbESLE2Zla_4uKykaEmJzC_byo74tlePuBDbijl7k=.2592e38c-5207-4fcb-a973-efc38dda916b@github.com>
 <X79_A3rO7XYSddHEsqFmG3qKh_L1TLI_U85mDxrCCLU=.9eb01d8b-c5f6-4a84-9074-7690a4655cdf@github.com>
 <35yoAdc5QoaJ6wXksaMaBD67DsjBUf-8CFXhkLVLYTc=.5578b4b7-6de3-481a-96c5-5aa52603a8f0@github.com>
Message-ID: <_7v5rhkJbbAFGSZpTqNkwxmrT54q9Ut_sRZ2c5zXc48=.2f9c1ece-4c8a-46d3-aa65-ba39da20dfce@github.com>

On Thu, 12 Dec 2024 16:27:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

>>> `release of {0} too high: {1}`
>> 
>> I think this is better. Probably good enough.
>> 
>> My concern stems from the fact that 'release' doesn't seem to be defined for _class files_. I see that the term 'release' exists, and maps to a versioned directory, or you can compile classes _for_ a certain release, But, it seems that 'the release of a class file' is a new concept here. (after all, `javac` doesn't produce class files _with_ a certain release).
>> 
>> Maybe: `class file {fp.entryName()} compiled for release {fp.classReleaseVersion()}, is illegal in version directory {fp.mrversion()}`
>> 
>> (This is perhaps somewhat terse, but `javac` sets the precedent for that. A user could find out _why_ the version is illegal by referencing the jar file spec).
>
> Let's try it out with the two examples from the initial description:
> 
> 
> release version of META-INF/versions/9/version/Version.class too high: 25
> release version of META-INF/versions/10/version/Version.class too high: 25
> 
> 
> 
> class file META-INF/versions/9/version/Version.class compiled for release 25, is illegal in version directory 9
> class file META-INF/versions/10/version/Version.class compiled for release 25, is illegal in version directory 10

What about:


META-INF/versions/9/version/Version.class of class file major version 69 is unsupported in versioned release 9; only supported in release >= 25
META-INF/versions/10/version/Version.class of class file major version 69 is unsupported in versioned release 10; only supported in release >= 25

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882967313

From dnguyen at openjdk.org  Thu Dec 12 22:38:39 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 12 Dec 2024 22:38:39 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v2]
In-Reply-To: <P7POGyDv4dp3Kce7Xx3XsQoPDK1sAAzkYvfqAkIWIJM=.9b9b68aa-5a4b-4e35-9333-28deea9be618@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <P7POGyDv4dp3Kce7Xx3XsQoPDK1sAAzkYvfqAkIWIJM=.9b9b68aa-5a4b-4e35-9333-28deea9be618@github.com>
Message-ID: <JGofv61s0LCQbQNfedEacM4hOtcXWew2ehkHGdMinxE=.49db38cc-3729-4630-b8fb-189845b79210@github.com>

On Tue, 10 Dec 2024 19:35:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which contains the open L10n drop changes for RDP1.
>> 
>> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
>> 
>> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - implement Severin's review
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - implement Jan's review
>  - implement Henry's review
>  - implement Weijun's review

Looks like there were additional changes. Good to catch all of these and re-updating each of these spots. Hopefully the translation team can differentiate content between `<>` since similar occurred before. LGTM

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2500910380

From alex.buckley at oracle.com  Thu Dec 12 23:35:39 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 12 Dec 2024 15:35:39 -0800
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <_7v5rhkJbbAFGSZpTqNkwxmrT54q9Ut_sRZ2c5zXc48=.2f9c1ece-4c8a-46d3-aa65-ba39da20dfce@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <VXnKmyBSnIaPBByDceizr2w6Gc_CL-dotORifWA0nE0=.d5d09265-584c-4b24-a803-512a0c0d1762@github.com>
 <vtJRHWQFHkKPQmyMRe7iNNqBTcwnoreO4HRkQRpMI3Y=.fea93e83-3914-4ed8-ba04-7fc8a980a674@github.com>
 <hZIsfyat26howadtnyZl475NyYwBdY3eIte5Lyr2bJw=.61392541-9696-4fc3-9a01-efd0500ccdbb@github.com>
 <FbYuSeSCp3BvdDgQrv2RtLJlEFpJ1rWBybzFkfEp8oc=.b8414953-8982-4147-be80-20ee1c5302cd@github.com>
 <Y2wQKszOHWi7bfSP6bsUYXH-C8xBXQZLofUEhTHk1WQ=.0144b96d-f395-476a-a081-55b74fcabac8@github.com>
 <01HbESLE2Zla_4uKykaEmJzC_byo74tlePuBDbijl7k=.2592e38c-5207-4fcb-a973-efc38dda916b@github.com>
 <X79_A3rO7XYSddHEsqFmG3qKh_L1TLI_U85mDxrCCLU=.9eb01d8b-c5f6-4a84-9074-7690a4655cdf@github.com>
 <35yoAdc5QoaJ6wXksaMaBD67DsjBUf-8CFXhkLVLYTc=.5578b4b7-6de3-481a-96c5-5aa52603a8f0@github.com>
 <_7v5rhkJbbAFGSZpTqNkwxmrT54q9Ut_sRZ2c5zXc48=.2f9c1ece-4c8a-46d3-aa65-ba39da20dfce@github.com>
Message-ID: <84ec9d9b-e128-4537-9b23-c07e918855fa@oracle.com>

Consider:

META-INF/versions/9/com/foo/Bar.class has class file version 69.0, but 
class file version 53.0 or less is required to target release 9 of the 
Java Platform

or, to use a term of art from the JAR File Spec:

com/foo/Bar.class in versioned directory META-INF/versions/9 has class 
file version 69.0, but class file version 53.0 or less is required

Alex

On 12/12/2024 2:23 PM, Mandy Chung wrote:
> On Thu, 12 Dec 2024 16:27:23 GMT, Christian Stein <cstein at openjdk.org> wrote:
> 
>>>> `release of {0} too high: {1}`
>>>
>>> I think this is better. Probably good enough.
>>>
>>> My concern stems from the fact that 'release' doesn't seem to be defined for _class files_. I see that the term 'release' exists, and maps to a versioned directory, or you can compile classes _for_ a certain release, But, it seems that 'the release of a class file' is a new concept here. (after all, `javac` doesn't produce class files _with_ a certain release).
>>>
>>> Maybe: `class file {fp.entryName()} compiled for release {fp.classReleaseVersion()}, is illegal in version directory {fp.mrversion()}`
>>>
>>> (This is perhaps somewhat terse, but `javac` sets the precedent for that. A user could find out _why_ the version is illegal by referencing the jar file spec).
>>
>> Let's try it out with the two examples from the initial description:
>>
>>
>> release version of META-INF/versions/9/version/Version.class too high: 25
>> release version of META-INF/versions/10/version/Version.class too high: 25
>>
>>
>>
>> class file META-INF/versions/9/version/Version.class compiled for release 25, is illegal in version directory 9
>> class file META-INF/versions/10/version/Version.class compiled for release 25, is illegal in version directory 10
> 
> What about:
> 
> 
> META-INF/versions/9/version/Version.class of class file major version 69 is unsupported in versioned release 9; only supported in release >= 25
> META-INF/versions/10/version/Version.class of class file major version 69 is unsupported in versioned release 10; only supported in release >= 25
> 
> -------------
> 
> PR Review Comment: https://git.openjdk.org/jdk/pull/22103#discussion_r1882967313


From mcimadamore at openjdk.org  Fri Dec 13 09:52:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Dec 2024 09:52:38 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v3]
In-Reply-To: <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
Message-ID: <WlckcNG4zHOOBtu-IqckTubcEzLYkRcMKCOXOvth5X8=.d1af773f-9f48-4fea-b7df-6690c56aa472@github.com>

On Fri, 6 Dec 2024 11:03:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
>> 
>> 
>> if (lint.isEnabled(LintCategory.DIVZERO) {
>>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
>> }
>> 
>> There are some issues with this approach:
>> 
>> * logging a lint warning has to be preceded by the correct `isEnabled` check
>> * the check and the `log::warning` call must share the same `LintCategory`
>> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
>> 
>> This PR addresses these issues, so that the above code is now written as follows:
>> 
>> 
>> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
>> 
>> 
>> The new idiom builds on a number of small improvements:
>> 
>> * the lint category is now tracked directly in the `compiler.properties` file;
>> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
>> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
>> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
>> 
>> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
>> 
>> Many thanks @archiecobbs for the useful discussions!
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add other missing lint categories

I'm ready to integrate. I have, however, a question. We also have other localized `compiler.properties` files:
* compiler_de.properties
* compiler_ja.properties
* compiler_zh.properties

Eyeballing, it seems that these files seem to also be correctly annotated. Should I do anything in particular here?

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

PR Comment: https://git.openjdk.org/jdk/pull/22553#issuecomment-2541019030

From jlahoda at openjdk.org  Fri Dec 13 11:47:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 13 Dec 2024 11:47:38 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v3]
In-Reply-To: <WlckcNG4zHOOBtu-IqckTubcEzLYkRcMKCOXOvth5X8=.d1af773f-9f48-4fea-b7df-6690c56aa472@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
 <WlckcNG4zHOOBtu-IqckTubcEzLYkRcMKCOXOvth5X8=.d1af773f-9f48-4fea-b7df-6690c56aa472@github.com>
Message-ID: <a4zdXPSCs-GYo9wZhuzdyKTZHPDCcl0EdpE1iA2r-nA=.efdbdcac-3665-4a67-af59-93491621c7fa@github.com>

On Fri, 13 Dec 2024 09:49:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I'm ready to integrate. I have, however, a question. We also have other localized `compiler.properties` files:
> 
>     * compiler_de.properties
> 
>     * compiler_ja.properties
> 
>     * compiler_zh.properties
> 
> 
> Eyeballing, it seems that these files seem to also be correctly annotated. Should I do anything in particular here?

I assume you mean the `# 0: symbol` annotations, right? I would expect that not to matter at all for the non-generic/non-English files: the generic/English properties bundle should be used to generate the access classes, and the other languages are only used for provide correct key->value mapping, and should be (I hope) ignored w.r.t. the annotations.

So, I would expect that there should be nothing to do? (And even if something was needed, we usually do not modify the language-specific property files.)

Do I miss something?

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

PR Comment: https://git.openjdk.org/jdk/pull/22553#issuecomment-2541266395

From jvernee at openjdk.org  Fri Dec 13 13:14:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Dec 2024 13:14:37 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <nNCz_fVUqFpIhbITyo4YeETKWfmKPglPkWYG1qbcYBc=.e8789aa9-463f-4ba0-ad03-cb919cc157ba@github.com>

On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
> 
>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

I think we have to restrict the message to talking about major class file versions. Version `53.<preview>` is fine to put into versioned directory `9`, but technically `53.<preview>` is greater than `53.0`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22103#issuecomment-2541434815

From cstein at openjdk.org  Fri Dec 13 15:31:36 2024
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 13 Dec 2024 15:31:36 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <GAlthAoAnspApFTIbJA-YshEUuic0qPgZjTmP6lnUdw=.c7fbf94e-acc6-44a1-862f-61d6cf7916a9@github.com>

On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
> 
>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

I'll update the message to read:
`META-INF/versions/9/com/foo/Bar.class has class file version 69 (Java 25), but class file version 53 or less is required to target release 9 of the Java Platform`

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

PR Comment: https://git.openjdk.org/jdk/pull/22103#issuecomment-2541702479

From cstein at openjdk.org  Fri Dec 13 16:37:51 2024
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 13 Dec 2024 16:37:51 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files [v2]
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <wLDTW9MBLhUdDSbqXAw_0phxkJYVu_wrCIaZ3RAucOo=.9909c40a-f618-4b0f-a4ec-aa58d5193eff@github.com>

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
> 
>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

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

  Improve error message as suggested

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22103/files
  - new: https://git.openjdk.org/jdk/pull/22103/files/478ef59c..d889660c

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

  Stats: 33 lines in 5 files changed: 11 ins; 12 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/22103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22103/head:pull/22103

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

From alex.buckley at oracle.com  Fri Dec 13 17:42:14 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 13 Dec 2024 09:42:14 -0800
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <GAlthAoAnspApFTIbJA-YshEUuic0qPgZjTmP6lnUdw=.c7fbf94e-acc6-44a1-862f-61d6cf7916a9@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <GAlthAoAnspApFTIbJA-YshEUuic0qPgZjTmP6lnUdw=.c7fbf94e-acc6-44a1-862f-61d6cf7916a9@github.com>
Message-ID: <a83ac11a-3a4c-4ad8-b933-b91fb26385ce@oracle.com>

On 12/13/2024 7:31 AM, Christian Stein wrote:
> I'll update the message to read:
> `META-INF/versions/9/com/foo/Bar.class has class file version 69 (Java 25), but class file version 53 or less is required to target release 9 of the Java Platform`

Saying "class file version 69" and "class file version 53" is good.

Please remove the informal "(Java 25)" clause. I spelled out "release 9 
of the Java Platform" precisely to avoid saying "Java 9". And please 
don't replace "(Java 25)" with "(release 25 of the Java Platform)".

Alex

From mcimadamore at openjdk.org  Fri Dec 13 18:41:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Dec 2024 18:41:40 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v3]
In-Reply-To: <a4zdXPSCs-GYo9wZhuzdyKTZHPDCcl0EdpE1iA2r-nA=.efdbdcac-3665-4a67-af59-93491621c7fa@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
 <WlckcNG4zHOOBtu-IqckTubcEzLYkRcMKCOXOvth5X8=.d1af773f-9f48-4fea-b7df-6690c56aa472@github.com>
 <a4zdXPSCs-GYo9wZhuzdyKTZHPDCcl0EdpE1iA2r-nA=.efdbdcac-3665-4a67-af59-93491621c7fa@github.com>
Message-ID: <gPqAGWtuQoNl7spVKaUFvFl3d2HrjwE8begkL0fmf4I=.2d67628b-6b31-417c-9b51-66d910395aa8@github.com>

On Fri, 13 Dec 2024 11:44:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> So, I would expect that there should be nothing to do? (And even if something was needed, we usually do not modify the language-specific property files.)
> 
> Do I miss something?

Our build process should not depend on that right. However I noted that these files do contain annotations already. Whose job it is to update those?

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

PR Comment: https://git.openjdk.org/jdk/pull/22553#issuecomment-2542037877

From mcimadamore at openjdk.org  Fri Dec 13 18:44:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Dec 2024 18:44:38 GMT
Subject: RFR: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings [v3]
In-Reply-To: <gPqAGWtuQoNl7spVKaUFvFl3d2HrjwE8begkL0fmf4I=.2d67628b-6b31-417c-9b51-66d910395aa8@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
 <A70xCPiuf8teomv93lkl4393843elSa0A1jWxW2ls08=.6c74b4be-c9e1-4565-85c6-00ef2963754a@github.com>
 <WlckcNG4zHOOBtu-IqckTubcEzLYkRcMKCOXOvth5X8=.d1af773f-9f48-4fea-b7df-6690c56aa472@github.com>
 <a4zdXPSCs-GYo9wZhuzdyKTZHPDCcl0EdpE1iA2r-nA=.efdbdcac-3665-4a67-af59-93491621c7fa@github.com>
 <gPqAGWtuQoNl7spVKaUFvFl3d2HrjwE8begkL0fmf4I=.2d67628b-6b31-417c-9b51-66d910395aa8@github.com>
Message-ID: <QgYnbj3M5cfvTZgJ_w9PJgqEn8gJfvMVLCnZ9p0JB3E=.92fe0d0f-af1b-4290-9a9c-77d93f56e306@github.com>

On Fri, 13 Dec 2024 18:39:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > So, I would expect that there should be nothing to do? (And even if something was needed, we usually do not modify the language-specific property files.)
> > Do I miss something?
> 
> Our build process should not depend on that right. However I noted that these files do contain annotations already. Whose job it is to update those?

To reply to my own question, it seems these properties are bulk-updated at the end of the release cycle. Here's the one for 24:

https://github.com/openjdk/jdk/pull/22588

So, this PR doesn't need to do anything there. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22553#issuecomment-2542041490

From eirbjo at openjdk.org  Sat Dec 14 12:56:47 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 14 Dec 2024 12:56:47 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
Message-ID: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>

Please review this cleanup PR which removes a property and a code comment left behind after the `jar --normalize` feature  was removed in JDK 14.

The feature was deprecated in JDK-8199871 and removed in JDK-8234542, along with removal of Pack200 tools and APIs.

This PR removes the now unused `main.help.opt.create.normalize` property and a code comment in `Main.java` referencing normalization.

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

Commit messages:
 - Remove leftovers from the --normalize feature

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

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

From alanb at openjdk.org  Sun Dec 15 08:42:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 15 Dec 2024 08:42:40 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
Message-ID: <4OM6tUw0N18TaBuFyNTBJWKq90iskDqvoj3cXUCYauY=.f4f01bd3-1fb7-4284-92f9-ff5ff02f6ae7@github.com>

On Sat, 14 Dec 2024 12:22:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes a property and a code comment left behind after the `jar --normalize` feature  was removed in JDK 14.
> 
> The feature was deprecated in JDK-8199871 and removed in JDK-8234542, along with removal of Pack200 tools and APIs.
> 
> This PR removes the now unused `main.help.opt.create.normalize` property and a code comment in `Main.java` referencing normalization.

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

> 286: \  -n, --normalize            Normalize information in the new jar archive\n\
> 287: \                             after creation. This option is deprecated, and is\n\
> 288: \                             planned for removal in a future JDK release

It does appear to be leftover from when the pack200 and the -n option were removed.

We don't usually touch the translated resources. Oracle updates the translations near the end of each release for the languages supported by Oracle JDK but there are a few translations that are probably out of date now. For removal then it's probably okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22751#discussion_r1885554315

From eirbjo at openjdk.org  Sun Dec 15 08:54:45 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 15 Dec 2024 08:54:45 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <4OM6tUw0N18TaBuFyNTBJWKq90iskDqvoj3cXUCYauY=.f4f01bd3-1fb7-4284-92f9-ff5ff02f6ae7@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
 <4OM6tUw0N18TaBuFyNTBJWKq90iskDqvoj3cXUCYauY=.f4f01bd3-1fb7-4284-92f9-ff5ff02f6ae7@github.com>
Message-ID: <kbV22N5eOdhBEW90s4-iEXdDxfHxiMDT0TAc6q1gFqY=.67b66366-3de2-46d2-b26c-e7204fcd6251@github.com>

On Sun, 15 Dec 2024 08:40:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this cleanup PR which removes a property and a code comment left behind after the `jar --normalize` feature  was removed in JDK 14.
>> 
>> The feature was deprecated in JDK-8199871 and removed in JDK-8234542, along with removal of Pack200 tools and APIs.
>> 
>> This PR removes the now unused `main.help.opt.create.normalize` property and a code comment in `Main.java` referencing normalization.
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 288:
> 
>> 286: \  -n, --normalize            Normalize information in the new jar archive\n\
>> 287: \                             after creation. This option is deprecated, and is\n\
>> 288: \                             planned for removal in a future JDK release
> 
> It does appear to be leftover from when the pack200 and the -n option were removed.
> 
> We don't usually touch the translated resources. Oracle updates the translations near the end of each release for the languages supported by Oracle JDK but there are a few translations that are probably out of date now. For removal then it's probably okay.

> We don't usually touch the translated resources. [...] For removal then it's probably okay.

What's your recommendation here? Happy to revert changes to translated files, keeping the delete in `jar.properties`, if so desirable.

This would rely on Oracle's translation update process catching the remval and update it, ideally in all translations, not only those supported by Oracle JDK, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22751#discussion_r1885558108

From alanb at openjdk.org  Sun Dec 15 09:26:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 15 Dec 2024 09:26:37 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <kbV22N5eOdhBEW90s4-iEXdDxfHxiMDT0TAc6q1gFqY=.67b66366-3de2-46d2-b26c-e7204fcd6251@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
 <4OM6tUw0N18TaBuFyNTBJWKq90iskDqvoj3cXUCYauY=.f4f01bd3-1fb7-4284-92f9-ff5ff02f6ae7@github.com>
 <kbV22N5eOdhBEW90s4-iEXdDxfHxiMDT0TAc6q1gFqY=.67b66366-3de2-46d2-b26c-e7204fcd6251@github.com>
Message-ID: <GTekWruuVIOvspi5Nw3Ptln6F-lutdzTXXsc0-qUNdg=.ebccfa15-ee6a-4ade-a2e8-4d31a22e3018@github.com>

On Sun, 15 Dec 2024 08:52:12 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> What's your recommendation here? Happy to revert changes to translated files, keeping the delete in `jar.properties`, if so desirable.
> 
> This would rely on Oracle's translation update process catching the remval and update it, ideally in all translations, not only those supported by Oracle JDK, right?

I think what you have is okay, I'm just saying that we don't usually touch translations when making changes. 

Oracle does a refresh the de, ja, and zh_CN translations in each release so I assume the lines you removed will get removed by the next update anyway.  @justin-curtis-lu knows more about this "process". I don't know if anyone funds or maintains the other translations now, it's possible that some of these have bit rotted in recent years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22751#discussion_r1885585908

From alanb at openjdk.org  Mon Dec 16 07:36:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Dec 2024 07:36:37 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
Message-ID: <untuprTI9WgdY9CoS_8eSp_qGP5gCeJa0RdgTqsdCSQ=.fbc10e87-9d95-4374-8f2e-96e64332fc8b@github.com>

On Sat, 14 Dec 2024 12:22:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes a property and a code comment left behind after the `jar --normalize` feature  was removed in JDK 14.
> 
> The feature was deprecated in JDK-8199871 and removed in JDK-8234542, along with removal of Pack200 tools and APIs.
> 
> This PR removes the now unused `main.help.opt.create.normalize` property and a code comment in `Main.java` referencing normalization.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22751#pullrequestreview-2505358247

From mcimadamore at openjdk.org  Mon Dec 16 10:20:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Dec 2024 10:20:45 GMT
Subject: [jdk24] Integrated: 8345944: JEP 492: extending local class in a
 different static context should not be allowed
In-Reply-To: <OEC4tR2kmnlz4w9Om4XwaLZ1pIqBq0TajCfAcTH0mqI=.bd11258d-4592-4f88-877f-52fba761b4b8@github.com>
References: <OEC4tR2kmnlz4w9Om4XwaLZ1pIqBq0TajCfAcTH0mqI=.bd11258d-4592-4f88-877f-52fba761b4b8@github.com>
Message-ID: <Qe0LKnXDQZv2Cf8X67-omUZEjHJtSD9iKaGdhDl3myc=.c40325d1-abc6-4817-b8a7-fc35232b0bec@github.com>

On Thu, 12 Dec 2024 12:12:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a simple backport of [this commit](https://github.com/openjdk/jdk/commit/0ad64234e2fd19ec0435fb00340120153b928f9c)

This pull request has now been integrated.

Changeset: 67b82516
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67b82516792f8c834d784283c1aa5629fba0a490
Stats:     275 lines in 6 files changed: 266 ins; 4 del; 5 mod

8345944: JEP 492: extending local class in a different static context should not be allowed
8345953: JEP 492: instantiating local classes in a different static context should not be allowed

Reviewed-by: vromero
Backport-of: 0ad64234e2fd19ec0435fb00340120153b928f9c

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

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

From mcimadamore at openjdk.org  Mon Dec 16 10:22:46 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Dec 2024 10:22:46 GMT
Subject: Integrated: 8345263: Make sure that lint categories are used correctly
 when logging lint warnings
In-Reply-To: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
References: <_Q8fCsFlyfGyd-9DSNhktlh7x6iGQCdl7WtxpEVbUQ0=.08936d3c-5611-4fd8-a5a3-7753f23bbbe7@github.com>
Message-ID: <wcqmfzyJ9dAzsQcXEK8bCPe5QRHTmpuF7_IuX9HS4fs=.72726134-70e0-497d-bc0e-5236a0518f4d@github.com>

On Wed, 4 Dec 2024 17:11:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR tightens up the logic by which javac reports lint warnings. Currently, lint warnings are typically emitted using the following idiom:
> 
> 
> if (lint.isEnabled(LintCategory.DIVZERO) {
>     log.warning(LintCategory.DIVZERO, pos, Warnings.DIVZERO);
> }
> 
> There are some issues with this approach:
> 
> * logging a lint warning has to be preceded by the correct `isEnabled` check
> * the check and the `log::warning` call must share the same `LintCategory`
> * the selected warning key in the `Warnings` class must also make sense for the selected `LintCategory`
> 
> This PR addresses these issues, so that the above code is now written as follows:
> 
> 
> lint.logIfEnabled(pos, LintWarnings.DIVZERO);
> 
> 
> The new idiom builds on a number of small improvements:
> 
> * the lint category is now tracked directly in the `compiler.properties` file;
> * a new `LintWarning` class is added to `JCDiagnostic` to model a warning key that is also associated with a speicfic `LintCategory` enum constant;
> * the `CompilerProperties` class has a new group of compiler keys, nested in the new `LintWarnings` class. This class defines the `LintWarning` objects for all the warning keys in `compiler.properties` that have a lint category set
> * A new method `Lint::logIfEnabled(Position, LintWarning)` is added - which simplifies the logging of lint warnings in many common cases, by merging the `isEnabled` check together with the logging.
> 
> As bonus points, the signatures of some methods in `Check` and `MandatoryWarningHandler` have been tightened to accept not just a `Warning`, but a `LintWarning`. This makes it impossible, for instance, to use `Check::warnUnchecked` with a warning that is not a true lint warning.
> 
> Many thanks @archiecobbs for the useful discussions!

This pull request has now been integrated.

Changeset: dbffe332
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbffe33251da4472945d97ab54c7e3354d7f42d2
Stats:     646 lines in 24 files changed: 254 ins; 116 del; 276 mod

8345263: Make sure that lint categories are used correctly when logging lint warnings

Reviewed-by: vromero, jlahoda

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

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

From mcimadamore at openjdk.org  Mon Dec 16 10:45:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Dec 2024 10:45:41 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v6]
In-Reply-To: <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
 <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
Message-ID: <Hjj_f_SfKt5yip8neldNgj9lm8jMQ8TFTz5S_mFSAeU=.b62f3047-e0d6-4a68-b5e1-da7ebaf0898f@github.com>

On Mon, 9 Dec 2024 19:20:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Apply change that was missed somehow.
>  - Undo change that will be moved to the core-libs branch.
>  - Remove unnecessary @SuppressWarnings annotations.

src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java line 223:

> 221:         }
> 222: 
> 223:         @SuppressWarnings("unchecked")

Tricky but correct :-) This relies on the special pleading for casts to "raw" `Class`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21851#discussion_r1886584666

From mcimadamore at openjdk.org  Mon Dec 16 10:50:46 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Dec 2024 10:50:46 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v6]
In-Reply-To: <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
 <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
Message-ID: <iQYBx-MTark03k0wUuy0R9BPUxHqA0X6IXxw8sMHk8Q=.ceeb14a0-82c2-4d14-8b48-4c9ce6e3a26e@github.com>

On Mon, 9 Dec 2024 19:20:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Apply change that was missed somehow.
>  - Undo change that will be moved to the core-libs branch.
>  - Remove unnecessary @SuppressWarnings annotations.

Looks good - nice cleanup!

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2894:

> 2892:     /**This method parses a statement appearing inside a block.
> 2893:      */
> 2894:     @SuppressWarnings("fallthrough")

This is a bit tricky. Yes, as things stand the suppression is redundant. But the switch does contain a case with fallthrough - only it's the last `case`, so the fallthrough does nothing. If a `default` is added (or some other `case` after the last) the fallthrough will become more apparent. (but then a warnings should be issued as well). Considering we have already a comment to indicate the fallthrough, this change is ok.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21851#pullrequestreview-2505813958
PR Review Comment: https://git.openjdk.org/jdk/pull/21851#discussion_r1886590561

From jpai at openjdk.org  Mon Dec 16 11:44:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Dec 2024 11:44:39 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
Message-ID: <BMr88PmNZC1hubDjUVpsrKF-j5gXRWJpaDSb6IMuV7E=.dafdc765-cf12-47a4-8478-7ca9e9f715e5@github.com>

On Sat, 14 Dec 2024 12:22:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes a property and a code comment left behind after the `jar --normalize` feature  was removed in JDK 14.
> 
> The feature was deprecated in JDK-8199871 and removed in JDK-8234542, along with removal of Pack200 tools and APIs.
> 
> This PR removes the now unused `main.help.opt.create.normalize` property and a code comment in `Main.java` referencing normalization.

This looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22751#pullrequestreview-2505948914

From cstein at openjdk.org  Mon Dec 16 12:34:52 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 16 Dec 2024 12:34:52 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files [v3]
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <kflYL0fzRkGc6MuRMBWOY6iNPKIbmvZwj0MkhFjtVlg=.2e6ea936-5ee3-4a58-9c5c-42cd00a38edb@github.com>

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
> 
>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

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

  Remove the informal "(Java N)" clause.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22103/files
  - new: https://git.openjdk.org/jdk/pull/22103/files/d889660c..1170fd9e

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

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

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

From cstein at openjdk.org  Mon Dec 16 14:23:26 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 16 Dec 2024 14:23:26 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files [v4]
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <0AsoWG0jNW-1YmAaxf2BjSWvN_eA0zowcSriPoOa8rE=.737ae442-777b-4ce6-9331-1c78ebf2f530@github.com>

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
> 
>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> classfile release value of META-INF/versions/9/version/Version.class too high: 25
> classfile release value of META-INF/versions/10/version/Version.class too high: 25
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

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

  Fix argument type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22103/files
  - new: https://git.openjdk.org/jdk/pull/22103/files/1170fd9e..dd554559

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

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

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

From acobbs at openjdk.org  Mon Dec 16 14:54:59 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 14:54:59 GMT
Subject: RFR: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler) [v6]
In-Reply-To: <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
 <ix-sARBkbTokPruVrPSnAlwd0fgm718MZnUpH7DCoIQ=.752c8fae-6d22-4997-9ba5-cb034ff2279f@github.com>
Message-ID: <G87wwjvtf9jSL0zlRtp1DW1gzfu0oLUYRGKdwqQz7ps=.1655ca92-b1f2-4e2f-a4c3-01d64bdc2284@github.com>

On Mon, 9 Dec 2024 19:20:35 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Merge branch 'master' into SuppressWarningsCleanup-compiler
>  - Apply change that was missed somehow.
>  - Undo change that will be moved to the core-libs branch.
>  - Remove unnecessary @SuppressWarnings annotations.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/21851#issuecomment-2545834274

From acobbs at openjdk.org  Mon Dec 16 14:54:59 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 14:54:59 GMT
Subject: Integrated: 8343477: Remove unnecessary @SuppressWarnings annotations
 (compiler)
In-Reply-To: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
References: <LpqEYVDNntQQ6HPa6LwxflHR8KxWKoPpFDOubS76BGk=.2d7ea3c0-3e52-47c3-89f2-82a2bea2b353@github.com>
Message-ID: <GdWcziA5v126gun62zQ2WUNiamkemWs_EypqSYBGhZI=.0c01d15b-fb41-4e37-96ee-b64535e4e72a@github.com>

On Sat, 2 Nov 2024 15:27:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

This pull request has now been integrated.

Changeset: d7379789
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d737978924f08f1aae280867e5106f2cfd0e9d31
Stats:     29 lines in 17 files changed: 0 ins; 18 del; 11 mod

8343477: Remove unnecessary @SuppressWarnings annotations (compiler)

Reviewed-by: darcy, mcimadamore

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

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

From acobbs at openjdk.org  Mon Dec 16 16:58:59 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 16:58:59 GMT
Subject: RFR: 8346294: Invalid lint category specified in compiler.properties
Message-ID: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>

Please review this fix for an incorrect `lint:` tag in `compiler.properties`, plus an adjustment to the build process to automatically detect and fail the build in case of any similar typos in the future.

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

Commit messages:
 - Fix invalid "lint" tag and update build to automatically detect.

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

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

From jlu at openjdk.org  Mon Dec 16 17:17:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Dec 2024 17:17:40 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <GTekWruuVIOvspi5Nw3Ptln6F-lutdzTXXsc0-qUNdg=.ebccfa15-ee6a-4ade-a2e8-4d31a22e3018@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
 <4OM6tUw0N18TaBuFyNTBJWKq90iskDqvoj3cXUCYauY=.f4f01bd3-1fb7-4284-92f9-ff5ff02f6ae7@github.com>
 <kbV22N5eOdhBEW90s4-iEXdDxfHxiMDT0TAc6q1gFqY=.67b66366-3de2-46d2-b26c-e7204fcd6251@github.com>
 <GTekWruuVIOvspi5Nw3Ptln6F-lutdzTXXsc0-qUNdg=.ebccfa15-ee6a-4ade-a2e8-4d31a22e3018@github.com>
Message-ID: <ThgC98CUcMXyTBqpfsh4VLnyZJ5CuIWkJXoB-1sUy-o=.55751694-2a02-4e9b-89bc-f44960e627cb@github.com>

On Sun, 15 Dec 2024 09:23:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> We don't usually touch the translated resources. [...] For removal then it's probably okay.
>> 
>> What's your recommendation here? Happy to revert changes to translated files, keeping the delete in `jar.properties`, if so desirable.
>> 
>> This would rely on Oracle's translation update process catching the remval and update it, ideally in all translations, not only those supported by Oracle JDK, right?
>
>> What's your recommendation here? Happy to revert changes to translated files, keeping the delete in `jar.properties`, if so desirable.
>> 
>> This would rely on Oracle's translation update process catching the remval and update it, ideally in all translations, not only those supported by Oracle JDK, right?
> 
> I think what you have is okay, I'm just saying that we don't usually touch translations when making changes. 
> 
> Oracle does a refresh the de, ja, and zh_CN translations in each release so I assume the lines you removed will get removed by the next update anyway.  @justin-curtis-lu knows more about this "process". I don't know if anyone funds or maintains the other translations now, it's possible that some of these have bit rotted in recent years.

Yes, removing them is fine here. Otherwise we would have caught them during the L10n update anyways.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22751#discussion_r1887205885

From eirbjo at openjdk.org  Mon Dec 16 18:06:43 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Dec 2024 18:06:43 GMT
Subject: RFR: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
Message-ID: <oX_2Hq09OViXeOGMO19ZpJi9_-E6Upb_R9i-_tub-GA=.2028c6f2-3f8c-4200-a378-44029265d956@github.com>

On Sat, 14 Dec 2024 12:22:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes a property and a code comment left behind after the `jar --normalize` feature  was removed in JDK 14.
> 
> The feature was deprecated in JDK-8199871 and removed in JDK-8234542, along with removal of Pack200 tools and APIs.
> 
> This PR removes the now unused `main.help.opt.create.normalize` property and a code comment in `Main.java` referencing normalization.

Thanks for Alan and Jaikiran for reviews and to Justin for the L10n clarification.

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

PR Comment: https://git.openjdk.org/jdk/pull/22751#issuecomment-2546296908

From eirbjo at openjdk.org  Mon Dec 16 18:06:43 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 16 Dec 2024 18:06:43 GMT
Subject: Integrated: 8346232: Remove leftovers of the jar --normalize feature
In-Reply-To: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
References: <qHuW066QQJQ6MaI6Z05cr766c5WBC9yCbXTbB6ZBSqQ=.a1430fce-63a5-4746-8874-0050d6fce932@github.com>
Message-ID: <AUqVJg4nx3bE51YBu3XEvWk0Y1HmyYkGzce-e-r06lY=.9efada20-fed0-4960-abc0-b4e11a369f0f@github.com>

On Sat, 14 Dec 2024 12:22:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes a property and a code comment left behind after the `jar --normalize` feature  was removed in JDK 14.
> 
> The feature was deprecated in JDK-8199871 and removed in JDK-8234542, along with removal of Pack200 tools and APIs.
> 
> This PR removes the now unused `main.help.opt.create.normalize` property and a code comment in `Main.java` referencing normalization.

This pull request has now been integrated.

Changeset: 51662c23
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51662c2384326749fb4ee7a792d98b01d64e56f1
Stats:     25 lines in 12 files changed: 0 ins; 15 del; 10 mod

8346232: Remove leftovers of the jar --normalize feature

Reviewed-by: alanb, jpai

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

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

From mcimadamore at openjdk.org  Mon Dec 16 18:40:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Dec 2024 18:40:41 GMT
Subject: RFR: 8346294: Invalid lint category specified in
 compiler.properties
In-Reply-To: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
References: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
Message-ID: <DVzG2jtluL8AXT2fH656xL-pDAd_dmP8-o5pONgnHLg=.cd729bf3-c803-4c06-af6a-9095fff9a460@github.com>

On Mon, 16 Dec 2024 16:54:46 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this fix for an incorrect `lint:` tag in `compiler.properties`, plus an adjustment to the build process to automatically detect and fail the build in case of any similar typos in the future.

Thanks for catching this

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

> 381:          * @throws IllegalArgumentException if no such lint category exists
> 382:          */
> 383:         public static LintCategory forOption(String option) {

Maybe we should call this "getOrThrow" ?

test/langtools/tools/javac/lint/LintWarningCategoryTest.java line 36:

> 34: import com.sun.tools.javac.resources.CompilerProperties.LintWarnings;
> 35: 
> 36: public class LintWarningCategoryTest {

Do we need this specific test? Or will either the build, or other tests fail in case there's a lint category/name mismatch?

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

PR Comment: https://git.openjdk.org/jdk/pull/22769#issuecomment-2546362030
PR Review Comment: https://git.openjdk.org/jdk/pull/22769#discussion_r1887316915
PR Review Comment: https://git.openjdk.org/jdk/pull/22769#discussion_r1887319068

From acobbs at openjdk.org  Mon Dec 16 19:00:58 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 19:00:58 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v5]
In-Reply-To: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
Message-ID: <NBBGRVFX6txzvVRFWcTQflRho7hHySTNPfk9WxF1d7Q=.718a27d4-c3a4-48b4-96e4-441f52f7b940@github.com>

> Please review these changes with some minor lint-related fixes and cleanups.
> 
> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.

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

 - Merge branch 'master' into JDK-8344079
 - Address review comment by being less Streamy.
 - Fold LintSuppression methods back into existing Lint class.
 - Merge branch 'master' into JDK-8344079
 - Fix typo in comment.
 - Minor lint-related cleanups.

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

Changes: https://git.openjdk.org/jdk/pull/22056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22056&range=04
  Stats: 159 lines in 3 files changed: 51 ins; 54 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/22056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22056/head:pull/22056

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

From acobbs at openjdk.org  Mon Dec 16 19:21:54 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 19:21:54 GMT
Subject: RFR: 8346294: Invalid lint category specified in
 compiler.properties [v2]
In-Reply-To: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
References: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
Message-ID: <q85u0DdBgT-lDRe9KVQW_F6jZa2Ef4XX0wckeX9Lj4U=.d208a679-b61b-4e90-aab8-0acb0b597cf2@github.com>

> Please review this fix for an incorrect `lint:` tag in `compiler.properties`, plus an adjustment to the build process to automatically detect and fail the build in case of any similar typos in the future.

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

  Cleanups & refactoring based on review suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22769/files
  - new: https://git.openjdk.org/jdk/pull/22769/files/1ce466fa..3f792a8b

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

  Stats: 61 lines in 3 files changed: 0 ins; 55 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22769.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22769/head:pull/22769

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

From acobbs at openjdk.org  Mon Dec 16 19:21:56 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 19:21:56 GMT
Subject: RFR: 8346294: Invalid lint category specified in
 compiler.properties [v2]
In-Reply-To: <DVzG2jtluL8AXT2fH656xL-pDAd_dmP8-o5pONgnHLg=.cd729bf3-c803-4c06-af6a-9095fff9a460@github.com>
References: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
 <DVzG2jtluL8AXT2fH656xL-pDAd_dmP8-o5pONgnHLg=.cd729bf3-c803-4c06-af6a-9095fff9a460@github.com>
Message-ID: <kCY_jD43PVWn7w45l2KCGNAFKpRV7D3Fhp1yU9_IpM8=.0d067335-8041-4562-9ce6-318bcd24fd78@github.com>

On Mon, 16 Dec 2024 18:35:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanups & refactoring based on review suggestions.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java line 383:
> 
>> 381:          * @throws IllegalArgumentException if no such lint category exists
>> 382:          */
>> 383:         public static LintCategory forOption(String option) {
> 
> Maybe we should call this "getOrThrow" ?

Yeah, or perhaps the most modern & proper thing to do would be to have `LintCategory.get()` return `Optional<LintCategory>`.

This method is only used in a couple of places so that refactoring seems safe.

Updated in 3f792a8b650.

> test/langtools/tools/javac/lint/LintWarningCategoryTest.java line 36:
> 
>> 34: import com.sun.tools.javac.resources.CompilerProperties.LintWarnings;
>> 35: 
>> 36: public class LintWarningCategoryTest {
> 
> Do we need this specific test? Or will either the build, or other tests fail in case there's a lint category/name mismatch?

We don't strictly need this test, because build will fail now if any `lint:` label is invalid, so the test is redundant.

But I also wasn't sure if it was OK to not have any test at all.

Another option would be to split this change two separate bugs/PRs, but that seems like overkill.

(flips through OpenJDK developer guide...) Maybe the best answer would to remove the test and add the `noreg-build` label, as this can be considered a build fix.

Let's try that route... updated in 3f792a8b650.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22769#discussion_r1887370472
PR Review Comment: https://git.openjdk.org/jdk/pull/22769#discussion_r1887370371

From jlu at openjdk.org  Mon Dec 16 19:23:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Dec 2024 19:23:55 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v3]
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <gS7zuTI-WZvlYjfZd-DxFyaOqpOwzuGLS26TaeZvxcw=.a39b0c14-1eb0-4859-bd44-5adcd78b0fa3@github.com>

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8345327-L10N' into JDK-8345327-L10N
 - implement Naoto's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22588/files
  - new: https://git.openjdk.org/jdk/pull/22588/files/143e22ea..463ef9fc

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

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

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

From naoto at openjdk.org  Mon Dec 16 19:23:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Dec 2024 19:23:55 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v3]
In-Reply-To: <gS7zuTI-WZvlYjfZd-DxFyaOqpOwzuGLS26TaeZvxcw=.a39b0c14-1eb0-4859-bd44-5adcd78b0fa3@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <gS7zuTI-WZvlYjfZd-DxFyaOqpOwzuGLS26TaeZvxcw=.a39b0c14-1eb0-4859-bd44-5adcd78b0fa3@github.com>
Message-ID: <DzK4hJaJDksKu80-Ke2Kej4r99gzPAVcwpsPLiIhDTQ=.2a7eb235-1303-4614-a162-fad361dbceaa@github.com>

On Mon, 16 Dec 2024 19:20:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which contains the open L10n drop changes for RDP1.
>> 
>> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
>> 
>> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8345327-L10N' into JDK-8345327-L10N
>  - implement Naoto's review

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22588#pullrequestreview-2507065268

From mcimadamore at openjdk.org  Mon Dec 16 19:29:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Dec 2024 19:29:36 GMT
Subject: RFR: 8346294: Invalid lint category specified in
 compiler.properties [v2]
In-Reply-To: <q85u0DdBgT-lDRe9KVQW_F6jZa2Ef4XX0wckeX9Lj4U=.d208a679-b61b-4e90-aab8-0acb0b597cf2@github.com>
References: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
 <q85u0DdBgT-lDRe9KVQW_F6jZa2Ef4XX0wckeX9Lj4U=.d208a679-b61b-4e90-aab8-0acb0b597cf2@github.com>
Message-ID: <khVMGey1vzdAqJxvF2dzlMuFX0gMRdumCX84L_OYsN8=.871bdaa5-d6a8-4628-94df-db3c55c7bec1@github.com>

On Mon, 16 Dec 2024 19:21:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this fix for an incorrect `lint:` tag in `compiler.properties`, plus an adjustment to the build process to automatically detect and fail the build in case of any similar typos in the future.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups & refactoring based on review suggestions.

Marked as reviewed by mcimadamore (Reviewer).

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

> 449:         public void visitConstant(Attribute.Constant value) {
> 450:             if (value.type.tsym == syms.stringType.tsym) {
> 451:                 LintCategory.get((String)value.value)

I think use of `Optional` makes sense here too, so bonus point for the extra consolidation!

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

PR Review: https://git.openjdk.org/jdk/pull/22769#pullrequestreview-2507083357
PR Review Comment: https://git.openjdk.org/jdk/pull/22769#discussion_r1887385740

From mcimadamore at openjdk.org  Mon Dec 16 19:29:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Dec 2024 19:29:37 GMT
Subject: RFR: 8346294: Invalid lint category specified in
 compiler.properties [v2]
In-Reply-To: <kCY_jD43PVWn7w45l2KCGNAFKpRV7D3Fhp1yU9_IpM8=.0d067335-8041-4562-9ce6-318bcd24fd78@github.com>
References: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
 <DVzG2jtluL8AXT2fH656xL-pDAd_dmP8-o5pONgnHLg=.cd729bf3-c803-4c06-af6a-9095fff9a460@github.com>
 <kCY_jD43PVWn7w45l2KCGNAFKpRV7D3Fhp1yU9_IpM8=.0d067335-8041-4562-9ce6-318bcd24fd78@github.com>
Message-ID: <Jw6d1PNoFLD-tmEQ0LO6r4MSvHJ2U6oakkuzk-Pdd7A=.cb106f83-cf9e-487e-b5e5-9cd52f60df84@github.com>

On Mon, 16 Dec 2024 19:18:25 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> test/langtools/tools/javac/lint/LintWarningCategoryTest.java line 36:
>> 
>>> 34: import com.sun.tools.javac.resources.CompilerProperties.LintWarnings;
>>> 35: 
>>> 36: public class LintWarningCategoryTest {
>> 
>> Do we need this specific test? Or will either the build, or other tests fail in case there's a lint category/name mismatch?
>
> We don't strictly need this test, because build will fail now if any `lint:` label is invalid, so the test is redundant.
> 
> But I also wasn't sure if it was OK to not have any test at all.
> 
> Another option would be to split this change two separate bugs/PRs, but that seems like overkill.
> 
> (flips through OpenJDK developer guide...) Maybe the best answer would to remove the test and add the `noreg-build` label, as this can be considered a build fix.
> 
> Let's try that route... updated in 3f792a8b650.

yeah, it's ok not to have a test, but you need some keyword, which you added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22769#discussion_r1887380257

From acobbs at openjdk.org  Mon Dec 16 20:48:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 20:48:35 GMT
Subject: RFR: 8346294: Invalid lint category specified in
 compiler.properties [v2]
In-Reply-To: <q85u0DdBgT-lDRe9KVQW_F6jZa2Ef4XX0wckeX9Lj4U=.d208a679-b61b-4e90-aab8-0acb0b597cf2@github.com>
References: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
 <q85u0DdBgT-lDRe9KVQW_F6jZa2Ef4XX0wckeX9Lj4U=.d208a679-b61b-4e90-aab8-0acb0b597cf2@github.com>
Message-ID: <OrrKvbRoSBbmwYK42g6RfSXfIamkGNvWaFVyobSEips=.a349236c-3fa8-4d75-89a3-590b998f85f8@github.com>

On Mon, 16 Dec 2024 19:21:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this fix for an incorrect `lint:` tag in `compiler.properties`, plus an adjustment to the build process to automatically detect and fail the build in case of any similar typos in the future.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups & refactoring based on review suggestions.

Thanks for the quick review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22769#issuecomment-2546710505

From jlu at openjdk.org  Mon Dec 16 21:03:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Dec 2024 21:03:43 GMT
Subject: RFR: 8345327: JDK 24 RDP1 L10n resource files update [v3]
In-Reply-To: <gS7zuTI-WZvlYjfZd-DxFyaOqpOwzuGLS26TaeZvxcw=.a39b0c14-1eb0-4859-bd44-5adcd78b0fa3@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
 <gS7zuTI-WZvlYjfZd-DxFyaOqpOwzuGLS26TaeZvxcw=.a39b0c14-1eb0-4859-bd44-5adcd78b0fa3@github.com>
Message-ID: <8dpjCH8cnuHNOyKchKDhnPunFlgWE4TtuWgyOUbP1mM=.19052704-1cad-472d-9546-60f908a143a6@github.com>

On Mon, 16 Dec 2024 19:23:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which contains the open L10n drop changes for RDP1.
>> 
>> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
>> 
>> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8345327-L10N' into JDK-8345327-L10N
>  - implement Naoto's review

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22588#issuecomment-2546751576

From jlu at openjdk.org  Mon Dec 16 21:03:44 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Dec 2024 21:03:44 GMT
Subject: Integrated: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
References: <eLKAoXA-rbqOivSnzn4BD48WxQ5tMcW1f0vsyif6fG0=.ff60d995-7aca-459b-87d6-83f2f886a990@github.com>
Message-ID: <Y4zzqYY05njIYl6cn8w8ITKFskd79f2WmHepM4K759Y=.0b2ec1eb-8f87-4c40-8d95-541b81dcc49a@github.com>

On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the open L10n drop changes for RDP1.
> 
> I recommend viewing the improved diffs which are built out by Jon's tool here: https://cr.openjdk.org/~jlu/output/.  As always, I can not confirm the correctness on the quality of the translations themselves.
> 
> Generally speaking, observed differences in punctuation can be attributed to language rules. Any keys requiring localization that came in after the JDK was submitted for translations will be handled in the RDP2 L10n drop.

This pull request has now been integrated.

Changeset: fd0207d5
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd0207d59309ae1af9539580f5bfcbc7627789cb
Stats:     402 lines in 46 files changed: 169 ins; 123 del; 110 mod

8345327: JDK 24 RDP1 L10n resource files update

Reviewed-by: naoto, dnguyen, joehw, almatvee, sgehwolf, jlahoda, prappo, asemenyuk

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

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

From jvernee at openjdk.org  Mon Dec 16 21:13:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 16 Dec 2024 21:13:37 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files [v4]
In-Reply-To: <0AsoWG0jNW-1YmAaxf2BjSWvN_eA0zowcSriPoOa8rE=.737ae442-777b-4ce6-9331-1c78ebf2f530@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <0AsoWG0jNW-1YmAaxf2BjSWvN_eA0zowcSriPoOa8rE=.737ae442-777b-4ce6-9331-1c78ebf2f530@github.com>
Message-ID: <7Bk688pCfJ1wytOdHPFj51LYnnfnFzCveXxFIhHG8ZE=.19e64db9-6993-4d35-8e0d-75f3aec3d7e2@github.com>

On Mon, 16 Dec 2024 14:23:26 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
>> 
>>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
>> 
>> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
>> 
>> classfile release value of META-INF/versions/9/version/Version.class too high: 25
>> classfile release value of META-INF/versions/10/version/Version.class too high: 25
>> invalid multi-release jar file a.jar deleted
>> 
>> 
>> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix argument type

I think the latest version looks good.

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22103#pullrequestreview-2507367888

From jlu at openjdk.org  Mon Dec 16 23:20:47 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Dec 2024 23:20:47 GMT
Subject: [jdk24] RFR: 8345327: JDK 24 RDP1 L10n resource files update
Message-ID: <KJF7JFEKuvapqiZlATOMlMcwCgB65tA4MlIUxnoVas4=.e9e315b2-9a66-4494-a908-554aac297823@github.com>

Hi all,

This pull request contains a backport of commit [fd0207d5](https://github.com/openjdk/jdk/commit/fd0207d59309ae1af9539580f5bfcbc7627789cb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Justin Lu on 16 Dec 2024 and was reviewed by Naoto Sato, Damon Nguyen, Joe Wang, Alexander Matveev, Severin Gehwolf, Jan Lahoda, Pavel Rappo and Alexey Semenyuk.

Thanks!

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

Commit messages:
 - Backport fd0207d59309ae1af9539580f5bfcbc7627789cb

Changes: https://git.openjdk.org/jdk/pull/22775/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22775&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345327
  Stats: 402 lines in 46 files changed: 169 ins; 123 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/22775.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22775/head:pull/22775

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

From acobbs at openjdk.org  Mon Dec 16 23:25:58 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 23:25:58 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v6]
In-Reply-To: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
Message-ID: <kii9PZuVJvr_ulW2EPSM8-SIvstT0YuibdXf5tt4ZN4=.b8627adb-293d-4772-abbd-8c5220e8fdc5@github.com>

> Please review these changes with some minor lint-related fixes and cleanups.
> 
> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.

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

 - Refactor to clarify handling of special flag "-XDwarnOnAccessToMembers".
 - Tighten up declared type of lexWarning() parameter.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22056/files
  - new: https://git.openjdk.org/jdk/pull/22056/files/d0d25725..c2f770b5

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

  Stats: 25 lines in 3 files changed: 19 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22056/head:pull/22056

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

From acobbs at openjdk.org  Mon Dec 16 23:46:20 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 16 Dec 2024 23:46:20 GMT
Subject: RFR: 8344148: Add an explicit compiler phase for warning
 generation [v2]
In-Reply-To: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
References: <p3VD4iwQmkI_JYDThcB8vOyldV00NDrQXs7II3h2IOc=.afced0df-ae5e-4205-9eb0-b4241bcc0f12@github.com>
Message-ID: <ShZE1O9UehGbmQkTGYdm5qtHNO4DCfRevs1X4Vm8CRw=.c875ce5e-031f-4d69-9815-3f50513815b0@github.com>

> Please review this patch which does some minor refactoring to the compiler:
> * Create a new `WARN` phase which can be a dedicated home for (new) lint/warning logic
> * Create a new `WarningAnalyzer` singleton whose job is to invoke such lint/warning logic
> * Move `ThisEscapeAnalyzer` out of `Flow` (where it doesn't belong) and into `WarningAnalyzer`
> * Refactor `ThisEscapeAnalyzer` to be a context singleton like all other such classes
> 
> See [JDK-8344148](https://bugs.openjdk.org/browse/JDK-8344148) for details.

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

 - Merge branch 'master' into JDK-8344148
 - Merge branch 'master' into JDK-8344148
 - Update copyright years.
 - Add an explicit compiler phase for warning generation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22088/files
  - new: https://git.openjdk.org/jdk/pull/22088/files/d48c552d..b1ca46d9

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

  Stats: 244382 lines in 5571 files changed: 148630 ins; 73957 del; 21795 mod
  Patch: https://git.openjdk.org/jdk/pull/22088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22088/head:pull/22088

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

From acobbs at openjdk.org  Tue Dec 17 03:21:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 17 Dec 2024 03:21:40 GMT
Subject: Integrated: 8346294: Invalid lint category specified in
 compiler.properties
In-Reply-To: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
References: <Empl4jNMCrp6jQfojm6-6pdLDlHEGStsnxA7AOfKgJ4=.e05f3107-3925-43ed-a692-9e6be327e618@github.com>
Message-ID: <rnDFqDu_IJ8sydZ8WfUhqd4pFnvSRL8Wd13g7g0e47I=.619e33a2-76cd-4972-b1d7-ea6244139452@github.com>

On Mon, 16 Dec 2024 16:54:46 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this fix for an incorrect `lint:` tag in `compiler.properties`, plus an adjustment to the build process to automatically detect and fail the build in case of any similar typos in the future.

This pull request has now been integrated.

Changeset: 87804f24
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87804f24b2afaf7de4a21c81ef01548b09ba81b0
Stats:     15 lines in 3 files changed: 7 ins; 1 del; 7 mod

8346294: Invalid lint category specified in compiler.properties

Reviewed-by: mcimadamore

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

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

From cstein at openjdk.org  Tue Dec 17 07:19:42 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Dec 2024 07:19:42 GMT
Subject: RFR: 8268611: jar --validate should check targeted classes in
 MR-JAR files [v4]
In-Reply-To: <0AsoWG0jNW-1YmAaxf2BjSWvN_eA0zowcSriPoOa8rE=.737ae442-777b-4ce6-9331-1c78ebf2f530@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
 <0AsoWG0jNW-1YmAaxf2BjSWvN_eA0zowcSriPoOa8rE=.737ae442-777b-4ce6-9331-1c78ebf2f530@github.com>
Message-ID: <IBcaz6WbjxzEroQXes_YaC8Pa9K0zZ3xPPkWphBi15w=.24958a5f-3acf-425d-98ce-efb09e364a83@github.com>

On Mon, 16 Dec 2024 14:23:26 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
>> 
>>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
>> 
>> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
>> 
>> META-INF/versions/9/com/foo/Bar.class has class file version 69.0, but class file version 53.0 or less is required to target release 9 of the Java Platform
>> invalid multi-release jar file a.jar deleted
>> 
>> 
>> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix argument type

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22103#issuecomment-2547669535

From cstein at openjdk.org  Tue Dec 17 07:19:43 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Dec 2024 07:19:43 GMT
Subject: Integrated: 8268611: jar --validate should check targeted classes in
 MR-JAR files
In-Reply-To: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
References: <nHHV-Eo4xBBsq5JkPCTkS59A3CR4oQmZhbuQxWj1xjc=.2a59d373-2634-4861-8583-b5c4d06b724e@github.com>
Message-ID: <fIbYOelR0pzOzj51mTqarNDSSb4yqDe9FbQfGwlM-1Y=.1c6f992e-39ff-496f-82ec-5e54148641e5@github.com>

On Thu, 14 Nov 2024 11:57:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change ensuring all targeted classes in a MR-JAR file should target the same or a lower classfile version. The [JAR File Specification](https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Multi-release) of JavaSE 9 reads:
> 
>> A class file under a versioned directory, of version N say, in a multi-release JAR must have a class file version less than or equal to the class file version associated with Nth major version of a Java platform release.
> 
> For example, having compiled source files with `javac` 25 without using the `--release` option (or with `--release 25`) and trying to archive them via a `jar --create --file a.jar --release 9 ... --release 10 ...` command now fails with:
> 
> META-INF/versions/9/com/foo/Bar.class has class file version 69.0, but class file version 53.0 or less is required to target release 9 of the Java Platform
> invalid multi-release jar file a.jar deleted
> 
> 
> This pull request contains fixes to existing tests which produced invalid MR-JAR files. Most of those fixes are achieved by adding an appropriate `--release N` option to the associated `javac` call. One of those fixes rewrites the classfile version bytes between the `javac` and `jar` calls.

This pull request has now been integrated.

Changeset: bd3c0be3
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd3c0be36d929fab5e5ca0158d53e50b2d206707
Stats:     156 lines in 14 files changed: 48 ins; 32 del; 76 mod

8268611: jar --validate should check targeted classes in MR-JAR files

Reviewed-by: jvernee

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

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

From acobbs at openjdk.org  Tue Dec 17 16:56:47 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 17 Dec 2024 16:56:47 GMT
Subject: RFR: 8344079: Minor fixes and cleanups to compiler lint-related
 code [v7]
In-Reply-To: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
References: <8E_905Q0BQeM5Ae-zYuRHtexDujRXZw41jKqZg0l4Cc=.bb7943a2-3db0-4536-9609-5b4d9944568e@github.com>
Message-ID: <MTiOEZoMQB8p0wBbJjFG5KDIsb5CRpedvTshWRZRDoI=.49e23b8c-520f-4ebc-9abd-cd00c98c646a@github.com>

> Please review these changes with some minor lint-related fixes and cleanups.
> 
> See [JDK-8344079](https://bugs.openjdk.org/browse/JDK-8344079) for a more detailed description.

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:

 - Merge branch 'master' into JDK-8344079
 - Refactor to clarify handling of special flag "-XDwarnOnAccessToMembers".
 - Tighten up declared type of lexWarning() parameter.
 - Merge branch 'master' into JDK-8344079
 - Address review comment by being less Streamy.
 - Fold LintSuppression methods back into existing Lint class.
 - Merge branch 'master' into JDK-8344079
 - Fix typo in comment.
 - Minor lint-related cleanups.

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

Changes: https://git.openjdk.org/jdk/pull/22056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22056&range=06
  Stats: 182 lines in 5 files changed: 72 ins; 56 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/22056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22056/head:pull/22056

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

From naoto at openjdk.org  Tue Dec 17 17:12:49 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Dec 2024 17:12:49 GMT
Subject: [jdk24] RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <KJF7JFEKuvapqiZlATOMlMcwCgB65tA4MlIUxnoVas4=.e9e315b2-9a66-4494-a908-554aac297823@github.com>
References: <KJF7JFEKuvapqiZlATOMlMcwCgB65tA4MlIUxnoVas4=.e9e315b2-9a66-4494-a908-554aac297823@github.com>
Message-ID: <WJAeoe84aElvqxZgCCVsNAM7GH77biE1ViVU6pjQQBE=.d5287016-eb82-438f-99ba-68e9185a5b0c@github.com>

On Mon, 16 Dec 2024 23:15:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fd0207d5](https://github.com/openjdk/jdk/commit/fd0207d59309ae1af9539580f5bfcbc7627789cb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 16 Dec 2024 and was reviewed by Naoto Sato, Damon Nguyen, Joe Wang, Alexander Matveev, Severin Gehwolf, Jan Lahoda, Pavel Rappo and Alexey Semenyuk.
> 
> Thanks!

Backport LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22775#pullrequestreview-2509542756

From dnguyen at openjdk.org  Tue Dec 17 23:22:36 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 17 Dec 2024 23:22:36 GMT
Subject: [jdk24] RFR: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <KJF7JFEKuvapqiZlATOMlMcwCgB65tA4MlIUxnoVas4=.e9e315b2-9a66-4494-a908-554aac297823@github.com>
References: <KJF7JFEKuvapqiZlATOMlMcwCgB65tA4MlIUxnoVas4=.e9e315b2-9a66-4494-a908-554aac297823@github.com>
Message-ID: <fAMZn65mmow6HrNN4feicODoaQTTO5Zeaauo3Bvd8nE=.9a89592c-4f15-44d7-8460-3baf6cf45daa@github.com>

On Mon, 16 Dec 2024 23:15:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fd0207d5](https://github.com/openjdk/jdk/commit/fd0207d59309ae1af9539580f5bfcbc7627789cb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 16 Dec 2024 and was reviewed by Naoto Sato, Damon Nguyen, Joe Wang, Alexander Matveev, Severin Gehwolf, Jan Lahoda, Pavel Rappo and Alexey Semenyuk.
> 
> Thanks!

Backports look good.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22775#pullrequestreview-2510380836

From darcy at openjdk.org  Wed Dec 18 05:35:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 18 Dec 2024 05:35:41 GMT
Subject: RFR: 8344647: Make java.se participate in the preview language
 feature `requires transitive java.base`
In-Reply-To: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
References: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
Message-ID: <t8gVzOPRDJ-d6NHEWEcykLLaqNlxZWhc-QFTIzuZ-j8=.09a1ac96-5fc9-436b-b170-cdb97a33e1eb@github.com>

On Fri, 22 Nov 2024 13:42:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22322#pullrequestreview-2510839671

From jlahoda at openjdk.org  Wed Dec 18 10:01:49 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 18 Dec 2024 10:01:49 GMT
Subject: RFR: 8344647: Make java.se participate in the preview language
 feature `requires transitive java.base`
In-Reply-To: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
References: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
Message-ID: <Uvnx5eQ0nQ0XkCotw50UbWIVZNbeR09mi7aIpnhO9OA=.a64a209c-c713-473d-b95d-3e9b8fd55bec@github.com>

On Fri, 22 Nov 2024 13:42:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22322#issuecomment-2550882937

From jlahoda at openjdk.org  Wed Dec 18 10:01:50 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 18 Dec 2024 10:01:50 GMT
Subject: Integrated: 8344647: Make java.se participate in the preview language
 feature `requires transitive java.base`
In-Reply-To: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
References: <bSYJVWIvBhy1qWfxqilGROcDflKkQm7kfDpRKpYN0yo=.defd7edb-2968-4410-913f-c4ec631da3bd@github.com>
Message-ID: <Y1InEhQmjsr-bSz7q-ieoduMURdeVvod5HYjh2Ku68Y=.f0b367e4-e4f9-45b6-a0a5-105dd379bd62@github.com>

On Fri, 22 Nov 2024 13:42:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

This pull request has now been integrated.

Changeset: d50b725a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d50b725ac0f228f5b04dd68c123c7f6b263c0d02
Stats:     61 lines in 8 files changed: 51 ins; 4 del; 6 mod

8344647: Make java.se participate in the preview language feature `requires transitive java.base`

Reviewed-by: asotona, darcy

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

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

From jlahoda at openjdk.org  Wed Dec 18 10:06:14 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 18 Dec 2024 10:06:14 GMT
Subject: [jdk24] RFR: 8344647: Make java.se participate in the preview language
 feature `requires transitive java.base`
Message-ID: <dWcIUnIk25P1ospOFfFek6U_S7YOvLy3C2K-slpJ-KY=.1855ce9d-7c56-4c31-8f2e-a2f60e17a404@github.com>

Hi all,

This pull request contains a backport of commit [d50b725a](https://github.com/openjdk/jdk/commit/d50b725ac0f228f5b04dd68c123c7f6b263c0d02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 18 Dec 2024 and was reviewed by Adam Sotona and Joe Darcy.

Thanks!

Description from the original PR:
There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.

This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.

So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

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

Commit messages:
 - Backport d50b725ac0f228f5b04dd68c123c7f6b263c0d02

Changes: https://git.openjdk.org/jdk/pull/22808/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22808&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344647
  Stats: 61 lines in 8 files changed: 51 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22808/head:pull/22808

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

From liach at openjdk.org  Wed Dec 18 10:32:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 18 Dec 2024 10:32:37 GMT
Subject: [jdk24] RFR: 8344647: Make java.se participate in the preview
 language feature `requires transitive java.base`
In-Reply-To: <dWcIUnIk25P1ospOFfFek6U_S7YOvLy3C2K-slpJ-KY=.1855ce9d-7c56-4c31-8f2e-a2f60e17a404@github.com>
References: <dWcIUnIk25P1ospOFfFek6U_S7YOvLy3C2K-slpJ-KY=.1855ce9d-7c56-4c31-8f2e-a2f60e17a404@github.com>
Message-ID: <DKJ0QrzEdiDm0SwTdD-881k5_q1l2LQP3Ort9F9x06E=.472cc3ce-e44f-4f0a-9b44-efa8669a3cfe@github.com>

On Wed, 18 Dec 2024 10:00:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d50b725a](https://github.com/openjdk/jdk/commit/d50b725ac0f228f5b04dd68c123c7f6b263c0d02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 18 Dec 2024 and was reviewed by Adam Sotona and Joe Darcy.
> 
> Thanks!
> 
> Description from the original PR:
> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22808#pullrequestreview-2511430406

From determann at protonmail.com  Wed Dec 18 11:06:05 2024
From: determann at protonmail.com (Determann)
Date: Wed, 18 Dec 2024 11:06:05 +0000
Subject: State of JEP 119
Message-ID: <k3yS3fJLlT4y2QXDxQKvNA2huWu__XxzZ49vfb5yrtYbPReWGX-5lbb_3GNLUGvmmldzQHjNDc51wsWe5lhF0uVTyRYbx8u0SNa-vHlvZoM=@protonmail.com>

Hi all,

I'm trying to build an API for any kind of meta-programming in Java.
An implementation of javax.lang.model backed by reflection might simplify that.

https://openjdk.org/jeps/119
The JEP is marked as Closed/Delivered with Release 8.
I only found prototypes, the last one for JDK 9.
https://hg.openjdk.org/jdk9/jdk9/langtools/file/82d0e10df078/src/sample/share/language/model/CoreReflectionFactory.java

What did I miss?

Lukas

From vromero at openjdk.org  Wed Dec 18 13:14:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 18 Dec 2024 13:14:41 GMT
Subject: [jdk24] RFR: 8344647: Make java.se participate in the preview
 language feature `requires transitive java.base`
In-Reply-To: <dWcIUnIk25P1ospOFfFek6U_S7YOvLy3C2K-slpJ-KY=.1855ce9d-7c56-4c31-8f2e-a2f60e17a404@github.com>
References: <dWcIUnIk25P1ospOFfFek6U_S7YOvLy3C2K-slpJ-KY=.1855ce9d-7c56-4c31-8f2e-a2f60e17a404@github.com>
Message-ID: <BCvBWFgoZMaazZ0or3XV4Ufgle6Pkglmfz8kT6RLvxw=.c7bc1fc1-177b-442a-b027-c782a063d615@github.com>

On Wed, 18 Dec 2024 10:00:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d50b725a](https://github.com/openjdk/jdk/commit/d50b725ac0f228f5b04dd68c123c7f6b263c0d02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 18 Dec 2024 and was reviewed by Adam Sotona and Joe Darcy.
> 
> Thanks!
> 
> Description from the original PR:
> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22808#pullrequestreview-2511788484

From jlahoda at openjdk.org  Wed Dec 18 13:48:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 18 Dec 2024 13:48:42 GMT
Subject: [jdk24] Integrated: 8344647: Make java.se participate in the preview
 language feature `requires transitive java.base`
In-Reply-To: <dWcIUnIk25P1ospOFfFek6U_S7YOvLy3C2K-slpJ-KY=.1855ce9d-7c56-4c31-8f2e-a2f60e17a404@github.com>
References: <dWcIUnIk25P1ospOFfFek6U_S7YOvLy3C2K-slpJ-KY=.1855ce9d-7c56-4c31-8f2e-a2f60e17a404@github.com>
Message-ID: <8u8Is7LIuQMVpAZY5QROpz9-CQWLsIr8CixBrSScn84=.a038ac17-117f-4e84-8e76-9d2e287bd8d6@github.com>

On Wed, 18 Dec 2024 10:00:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d50b725a](https://github.com/openjdk/jdk/commit/d50b725ac0f228f5b04dd68c123c7f6b263c0d02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 18 Dec 2024 and was reviewed by Adam Sotona and Joe Darcy.
> 
> Thanks!
> 
> Description from the original PR:
> There is a new preview language feature, `requires transitive java.base;`. And the `java.se` module is permitted to use the feature, without being marked as preview (i.e. the `java.se` module participates in preview). This is currently implemented by the common "participates in preview" way, by checking that `java.base` is exporting `jdk.internal.javac` package to `java.se`.
> 
> This common way works OK for internal preview feature and API usage, but turns out it may not be appropriate for this feature: the qualified export of the `jdk.internal.javac` package is not a specified API, it is an implementation detail; and the JLS itself specifies that the `java.se` module is participating in preview.
> 
> So this PR proposes to change the way javac handles the `java.se` module: it permits the use of the preview feature based on the module name, instead relying on the internal qualified export.

This pull request has now been integrated.

Changeset: 2cc14faa
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cc14faa21b32e594d5f8630f2e02daa9085b01f
Stats:     61 lines in 8 files changed: 51 ins; 4 del; 6 mod

8344647: Make java.se participate in the preview language feature `requires transitive java.base`

Reviewed-by: liach, vromero
Backport-of: d50b725ac0f228f5b04dd68c123c7f6b263c0d02

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

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

From ihse at openjdk.org  Wed Dec 18 17:06:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 18 Dec 2024 17:06:02 GMT
Subject: RFR: 8344191: Build code should not have classpath exception [v2]
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

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

 - Merge branch 'master' into remove-build-classpath-exception
 - Update build tools, data and IDE support
 - Update makefiles, autoconf, shell scripts, properties files and configuration files

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

Changes: https://git.openjdk.org/jdk/pull/22104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=01
  Stats: 1994 lines in 555 files changed: 0 ins; 1120 del; 874 mod
  Patch: https://git.openjdk.org/jdk/pull/22104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104

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

From asemenyuk at openjdk.org  Wed Dec 18 18:58:40 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 18 Dec 2024 18:58:40 GMT
Subject: RFR: 8344191: Build code should not have classpath exception [v2]
In-Reply-To: <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
 <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>
Message-ID: <Jzc-zFSvSRq41LPZQUXveoZoJSEMv30oszPC8Qm23mw=.f0743a79-082c-42b7-ac9d-e31515838f5f@github.com>

On Wed, 18 Dec 2024 17:06:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
>> 
>> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
>> 
>> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
>> 
>> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into remove-build-classpath-exception
>  - Update build tools, data and IDE support
>  - Update makefiles, autoconf, shell scripts, properties files and configuration files

jpackage changes look good. $0.02

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22104#pullrequestreview-2512625117

From cushon at google.com  Wed Dec 18 20:06:53 2024
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 18 Dec 2024 12:06:53 -0800
Subject: Redo of backport of JDK-8225377 (type annotations are not visible
 to javac plugins across compilation boundaries)
In-Reply-To: <CAJYRO=7=nTLNm=fn6h-5unb==Fc1eNU7Ey2RwO9_GMds+7BSzQ@mail.gmail.com>
References: <CAL4QsgtWqufynkRg_Yes2=UocHqjUSkBRiGzgBn-zkCFi1RYeA@mail.gmail.com>
 <CAFXXopOtXc_vpBx0h4L_0U78dONQ=iKh4sKoUAUTxO6OD8AvGg@mail.gmail.com>
 <CAJ_t5UacWsFb6iiWzcKKKsT2O153W5E4kqRStFOKxdJ2oqWCSA@mail.gmail.com>
 <CAEvq2np4V51Hc2M0Jp_uRNm9onMwx5dXOApAyayLa-LjhTcXFQ@mail.gmail.com>
 <CAJYRO=7=nTLNm=fn6h-5unb==Fc1eNU7Ey2RwO9_GMds+7BSzQ@mail.gmail.com>
Message-ID: <CAL4Qsgs3=gFXGiRpwguF_m+EPOfyk=uFQ5999pLxMDN4P67+RQ@mail.gmail.com>

I wrote up a CSR for the proposed redo of the backport:
https://bugs.openjdk.org/browse/JDK-8346471

There are drafts of the PRs for the individual changes here:

https://github.com/openjdk/jdk21u-dev/pull/1037
https://github.com/openjdk/jdk21u-dev/pull/1251
https://github.com/openjdk/jdk21u-dev/pull/1252
https://github.com/openjdk/jdk21u-dev/pull/1253

On Thu, Aug 1, 2024 at 9:31?AM Werner Dietl <wdietl at gmail.com> wrote:

> I would also be very happy if this were backported to earlier JDKs.
> The pluggable type system frameworks I work on mostly have work-arounds
> for this issue, but it would be much nicer to have correct type-use
> annotation information from javac directly.
> I also agree with Chris's comment on having a positive feedback loop. Any
> positive change has some danger of breaking existing code. This shouldn't
> stop us from fixing bugs, improving the type-use annotation infrastructure,
> and enabling more adoption.
>
> Best,
> cu, WMD.
>
> On Mon, Jul 29, 2024 at 11:22?AM Chris Povirk <cpovirk at google.com> wrote:
>
>> Manu spoke about the ability to annotate different positions (e.g.,
>> type-parameter bounds) for improved nullness checking. I'd also call out
>> that this affects even users who use nullness annotations on "basic"
>> locations like fields, parameters, and return types: Unless tools use
>> internal javac APIs, type-use annotations in even these basic locations in
>> class files are invisible until JDK 22. (And as Josiah points out, this
>> affects more tools than just "nullness checkers." We've also seen it with
>> AutoValue
>> <https://github.com/google/auto/blob/main/value/userguide/index.md>.)
>> This means that type-use annotations are worse than declaration annotations
>> in some ways, even as they're better in others. As a result, users can't
>> confidently pick even a set of nullness annotations without evaluating the
>> tradeoffs. It would be great to be able to tell users "Use type-use
>> annotations" without waiting for them all to update to JDK 22.
>>
>> Plus: Even if the fix is backported today, experience shows that users
>> will also have to wait for some annotation processors to be enhanced to
>> start looking for type-use annotations _at all_. I'd be happy to see us
>> continue to drive that positive feedback loop: As type-use annotations
>> become more visible to annotation processors, tools increasingly get
>> modified to recognize them, leading to more adoption of type-use
>> annotations and more opportunity to identify and iron out remaining
>> wrinkles.
>>
>> Thanks,
>> Chris
>>
>
>
> --
> https://ece.uwaterloo.ca/~wdietl/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241218/e2b8fd93/attachment.htm>

From mistria at redhat.com  Thu Dec 19 09:51:04 2024
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 19 Dec 2024 10:51:04 +0100
Subject: Any existing reusable & thread-safe JavaFileManager implementation
 for PlatformDescriptor?
Message-ID: <CAFr6BZRCSkiV3P1E-6sj0O=Pbo5JZ9s0_a2W31ftiaAFrf3RpQ@mail.gmail.com>

Hi all,

In our work using Javac inside Eclipse IDE in place of ECJ, I'm facing a
difficulty for which I have found ugly workarounds (described later) and
for which I wonder whether there are already good solutions in place I
could reuse instead.
The problem is that in the IDE, we do want the dependencies (jars, system
libraries) to be persisted in memory and reused across resolutions,
possibly by various threads and so on.
Sharing some file managers is not too hard, but making their underlying
jars or ct.sym reliably readable across usage is trickier.

The main issue we face is that all the ZipPath are interruptible by
default, which means that whenever a thread aborts (and that's relatively
frequent in the IDE), the underlying FileChannel in the ZipPath are closed,
making the zip path and then the JavaFileObjects unusable... crashing all
its further consumers.
The workaround we have in place is to use reflection to access the
FileChannel in the ZipPath and mark it as non-interruptible, but that code
is a bad smell and even the way we've used it remains fragile in term of
sequencing (there is still room for an interruption).

So I'm wondering whether someone has a better solution about such a
"JavaFileManagerSharingLibraries" (maybe some good implementation already
exists), or if someone has had similar concerns with interrupted
JavaFileObject and could recommend a better strategy than our workaround
based on reflection?

Thanks in advance
Mickael

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

From forax at univ-mlv.fr  Thu Dec 19 10:29:00 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 19 Dec 2024 11:29:00 +0100 (CET)
Subject: State of JEP 119
In-Reply-To: <k3yS3fJLlT4y2QXDxQKvNA2huWu__XxzZ49vfb5yrtYbPReWGX-5lbb_3GNLUGvmmldzQHjNDc51wsWe5lhF0uVTyRYbx8u0SNa-vHlvZoM=@protonmail.com>
References: <k3yS3fJLlT4y2QXDxQKvNA2huWu__XxzZ49vfb5yrtYbPReWGX-5lbb_3GNLUGvmmldzQHjNDc51wsWe5lhF0uVTyRYbx8u0SNa-vHlvZoM=@protonmail.com>
Message-ID: <835956977.29410021.1734604140239.JavaMail.zimbra@univ-eiffel.fr>

I'm not directly answering to your question but
are you aware of the OpenJDK babylon project
  https://openjdk.org/projects/babylon/

The code model of babylon is maybe what your are looking for.

regards,
R?mi

----- Original Message -----
> From: "Determann" <determann at protonmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Wednesday, December 18, 2024 12:06:05 PM
> Subject: State of JEP 119

> Hi all,
> 
> I'm trying to build an API for any kind of meta-programming in Java.
> An implementation of javax.lang.model backed by reflection might simplify that.
> 
> https://openjdk.org/jeps/119
> The JEP is marked as Closed/Delivered with Release 8.
> I only found prototypes, the last one for JDK 9.
> https://hg.openjdk.org/jdk9/jdk9/langtools/file/82d0e10df078/src/sample/share/language/model/CoreReflectionFactory.java
> 
> What did I miss?
> 
> Lukas

From acobbs at openjdk.org  Thu Dec 19 15:23:01 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 19 Dec 2024 15:23:01 GMT
Subject: RFR: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for() [v4]
In-Reply-To: <PrqG9pZw0UDmi7zxuipbUhY6HiSYwA-S7HJ2Pa2aAKA=.cca950a0-b30f-4eec-abb2-898007574fd8@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
 <PrqG9pZw0UDmi7zxuipbUhY6HiSYwA-S7HJ2Pa2aAKA=.cca950a0-b30f-4eec-abb2-898007574fd8@github.com>
Message-ID: <RiiZpLm9KwlmRJqwAokHAwTTTTJCPlxIHTop34eyoF0=.4db84969-d1d6-455a-935d-4035e55950f9@github.com>

On Sun, 13 Oct 2024 16:24:41 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
>> 
>> This allows code like this to compile:
>> 
>> for (int i = 1; i <= 3; i++) {
>>     Runnable r = () -> System.out.println(i);
>> }
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make "effectively final in the loop" work with try-with-resources statements.

We decided not to pursue this; closing this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/21415#issuecomment-2554580182

From acobbs at openjdk.org  Thu Dec 19 15:23:01 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 19 Dec 2024 15:23:01 GMT
Subject: Withdrawn: 8341782: Allow lambda capture of basic for() loop variables
 as with enhanced for()
In-Reply-To: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
References: <zJoYKBHdkn2qzAsSN2wExmeiiBtrfjDBNZ_qjDbP81c=.51ae2b6f-0778-4c54-bc0e-d67fef637efc@github.com>
Message-ID: <yinOaQh02H8w07c9HDDqT_MxbftW8h6hdvGod0Arsv4=.d47ac307-8e6c-47ca-aed8-741539d597a0@github.com>

On Tue, 8 Oct 2024 19:53:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR changes the compiler to allow basic `for()` loop iteration variables to be captured by lambdas in the loop body, even when their "effectively final" status is invalidated by modifications in the header of the loop.
> 
> This allows code like this to compile:
> 
> for (int i = 1; i <= 3; i++) {
>     Runnable r = () -> System.out.println(i);
> }

This pull request has been closed without being integrated.

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

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

From prappo at openjdk.org  Thu Dec 19 22:11:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 19 Dec 2024 22:11:37 GMT
Subject: RFR: 8174840: Elements.overrides does not check the return type of
 the methods [v3]
In-Reply-To: <mOvr18uhJbOPABS1VY30Vp9aY_z6Fom0TODIbewBAH8=.5eee8fc4-d0f6-4bd4-ba11-13e9f5514821@github.com>
References: <RTFbSLI6YB8RGCFGGhnmANm50wEfSQlx_wjRe5YIoeA=.4f1cbfbe-58f4-4ed8-bebc-8da45ff7ef7b@github.com>
 <mOvr18uhJbOPABS1VY30Vp9aY_z6Fom0TODIbewBAH8=.5eee8fc4-d0f6-4bd4-ba11-13e9f5514821@github.com>
Message-ID: <ji-jbrYDiOWc2z9BQFh0-F1WKGsI6KXG5zDgT4zJYSI=.b51a1809-3558-4b4d-b1d0-074f61a671f2@github.com>

On Thu, 21 Nov 2024 13:57:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this essentially doc only change.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve characterisation testcases

@jddarcy can we address this soon, or we should postpone this until after New Year?

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

PR Comment: https://git.openjdk.org/jdk/pull/22244#issuecomment-2555857785

From jlu at openjdk.org  Thu Dec 19 22:11:42 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Dec 2024 22:11:42 GMT
Subject: [jdk24] Integrated: 8345327: JDK 24 RDP1 L10n resource files update
In-Reply-To: <KJF7JFEKuvapqiZlATOMlMcwCgB65tA4MlIUxnoVas4=.e9e315b2-9a66-4494-a908-554aac297823@github.com>
References: <KJF7JFEKuvapqiZlATOMlMcwCgB65tA4MlIUxnoVas4=.e9e315b2-9a66-4494-a908-554aac297823@github.com>
Message-ID: <caO5L9I00CCGueckmL9E5Ys0lcogyUl4pHvHH7KpEjY=.015c897c-eddb-408b-8f2d-a007af93fc37@github.com>

On Mon, 16 Dec 2024 23:15:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [fd0207d5](https://github.com/openjdk/jdk/commit/fd0207d59309ae1af9539580f5bfcbc7627789cb) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Justin Lu on 16 Dec 2024 and was reviewed by Naoto Sato, Damon Nguyen, Joe Wang, Alexander Matveev, Severin Gehwolf, Jan Lahoda, Pavel Rappo and Alexey Semenyuk.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f0ada9f3
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0ada9f34e2a768c0dbcb2ed4ff0fe4019fdee9c
Stats:     402 lines in 46 files changed: 169 ins; 123 del; 110 mod

8345327: JDK 24 RDP1 L10n resource files update

Reviewed-by: naoto, dnguyen
Backport-of: fd0207d59309ae1af9539580f5bfcbc7627789cb

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

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

From jpai at openjdk.org  Fri Dec 20 06:44:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Dec 2024 06:44:16 GMT
Subject: RFR: 8302293: jar --create fails with IllegalArgumentException if
 archive name is shorter than 3 characters
Message-ID: <M8DXaCbnay1U77QMapCU__O1Ey1Vu8S3pYLtZZOPbVM=.80fcfb98-30c5-4334-81df-d8a7af49452a@github.com>

Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8302293?

As noted in the issue, when creating a temporary file during the "jar --create" operation, if the original file name is lesser than 3 characters, the temporary file creation which uses the original file's name as the temporary file name prefix, runs into an exception. The commit in this PR addresses that issue by ensuring that the temporary file name prefix is atleast 3 characters in length. Within the same file, an additional place was spotted where the code could potentially run into the same exception, so that too has been addressed in this change.

A new jtreg test has been introduced which reproduces the issue and verifies the fix.

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

Commit messages:
 - add comment to test method
 - 8302293: jar --create fails with IllegalAccessException if archive name is shorter than 3 characters

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

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

From cushon at openjdk.org  Fri Dec 20 17:32:15 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 20 Dec 2024 17:32:15 GMT
Subject: RFR: 8343882: BasicAnnoTests doesn't handle multiple annotations
 at the same position [v3]
In-Reply-To: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
References: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
Message-ID: <Ncez6OIfOsT0pvCiKcHzJdIC6naUySfm0CrfzedaY6I=.abe1b942-afbd-45ed-af82-8d2cd9e0a185@github.com>

> Please consider this fix to `test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java`. Due to a long-standing bug in the test, some test cases were not being processed if there were multiple assertions for annotations at the same position. All existing cases in the test still pass after this fix.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8343882
 - Merge remote-tracking branch 'origin/master' into JDK-8343882
 - 8343882: BasicAnnoTests doesn't handle multiple annotations at the same position

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21998/files
  - new: https://git.openjdk.org/jdk/pull/21998/files/3f215817..38b27e05

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

  Stats: 154903 lines in 4708 files changed: 110875 ins; 29228 del; 14800 mod
  Patch: https://git.openjdk.org/jdk/pull/21998.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21998/head:pull/21998

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

From cushon at openjdk.org  Fri Dec 20 20:55:44 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 20 Dec 2024 20:55:44 GMT
Subject: Integrated: 8343882: BasicAnnoTests doesn't handle multiple
 annotations at the same position
In-Reply-To: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
References: <kb0ooqfD3eYvCnkJW4rWpHcIp5jRuAoF6sb--M8lFLU=.e8294b97-5149-4f4c-82da-7a55d1c43b66@github.com>
Message-ID: <b98WP9Rj4HtgiXkLJhlvcJqBDNvrrMGFy6XfqtLQNLM=.f10997ec-48e5-4625-b71f-177dbfed5f70@github.com>

On Sat, 9 Nov 2024 20:53:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please consider this fix to `test/langtools/tools/javac/processing/model/type/BasicAnnoTests.java`. Due to a long-standing bug in the test, some test cases were not being processed if there were multiple assertions for annotations at the same position. All existing cases in the test still pass after this fix.

This pull request has now been integrated.

Changeset: d562d3c7
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d562d3c7a9e1e857c095ef908b0957b033972949
Stats:     18 lines in 1 file changed: 5 ins; 4 del; 9 mod

8343882: BasicAnnoTests doesn't handle multiple annotations at the same position

Reviewed-by: darcy

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

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

From qxing at openjdk.org  Mon Dec 23 09:50:10 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Mon, 23 Dec 2024 09:50:10 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
Message-ID: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>

This patch fixes unmatched brackets in some source files.

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

Commit messages:
 - Fix unmatched brackets in source files.

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

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

From erikj at openjdk.org  Mon Dec 23 14:05:35 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 23 Dec 2024 14:05:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some source files.

I can really only review the doc files and the Makefile.

doc/hotspot-unit-tests.md line 175:

> 173: there is no need to have them in error messages. Asserts print only
> 174: compared values, they do not print any of interim variables, e.g.
> 175: `ASSERT_TRUE(val1 == val2 && isFail(foo(8)) || i == 18)` prints only

Looking at this expression, I believe the intention is this.
Suggestion:

`ASSERT_TRUE((val1 == val2 && isFail(foo(8))) || i == 18)` prints only

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

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2520648246
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1895785097

From nbenalla at openjdk.org  Mon Dec 23 16:13:04 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 23 Dec 2024 16:13:04 GMT
Subject: RFR: 8346295: Update --release 24 symbol information for JDK 24 build
 29
Message-ID: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>

Usual symbol file update for a new JDK build.

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

Commit messages:
 - Update --release 24 symbol information for JDK 24 build 29

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

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

From jlu at openjdk.org  Mon Dec 23 17:13:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Dec 2024 17:13:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some source files.

make/data/cldr/common/main/kn.xml line 1085:

> 1083: 			<type key="calendar" type="islamic">????????? ??????????</type>
> 1084: 			<type key="calendar" type="islamic-civil">?????????-?????? ??????????</type>
> 1085: 			<type key="calendar" type="islamic-rgsa" draft="contributed">?????????? ??????????? (???? ???????, ????????)</type>

Hi, we would not modify the contents of upstream data from CLDR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1895964999

From kbarrett at openjdk.org  Mon Dec 23 19:36:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Dec 2024 19:36:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some source files.

I strongly suggest avoiding omnibus changes like this when possible (which it
is here). Just because it's all about one "kind" of change doesn't make it a
cohesive change. This is touching many distinct areas of the JDK, and several
different languages as well. That makes it harder to review and to manage the
review, because it is large and affects a wide range of areas, so may need
many reviewers. And the whole thing might get stalled by discussion of one
piece.

There is also no mention of what testing has been done for this PR. Some of
the changes are in executable code, and need to be tested.

I think that all of the files in make/data/cldr/common are from the Unicode
Consortium, and should not be modified here.

doc/hotspot-unit-tests.html line 248:

> 246: so there is no need to have them in error messages. Asserts print only
> 247: compared values, they do not print any of interim variables, e.g.
> 248: <code>ASSERT_TRUE(val1 == val2 &amp;&amp; isFail(foo(8)) || i == 18)</code>

This file is generated from the .md file, and should not be edited directly.

test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:

> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
> 49:     $(TESTLIBRARY_DIR)/jtreg \
> 50:     -maxdepth 1 -name '*.java')

I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
close-paren?

test/jaxp/javax/xml/jaxp/unittest/transform/Bug8169112.xsl line 65:

> 63:           @page { margin: 0.1in; }
> 64: 
> 65:           }

Does this affect the behavior of the test this is part of?

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:

> 1: <?xml version="1.0" encoding="UTF-8"?>
> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"

I can't tell whether anything was changed in this file other than the modification of all the end of
line indicators. I've no idea whether changing those is appropriate or not, but this file came from
a 3rd party, so might not be appropriate to change here.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:

> 1: <?xml version="1.0" encoding="UTF-8"?>
> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"

Does this change affect the behavior of the associated test(s)?

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2521031190
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896040106
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896050113
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896061137
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896064083
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896064580

From kbarrett at openjdk.org  Mon Dec 23 19:45:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Dec 2024 19:45:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>

On Mon, 23 Dec 2024 19:33:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.

And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2560215378

From prr at openjdk.org  Mon Dec 23 20:33:34 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 20:33:34 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
Message-ID: <PFz3alfIjjgTruEYo0zh1sF7VlmWQfYSm5zVAbgWMZM=.16f79e13-f7ca-4311-81f5-a66874094766@github.com>

On Mon, 23 Dec 2024 19:42:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.
> 
> And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

I think at the very least this needs multiple reviewers. Even 2 isn't enough considering it is so cross-area.
It went to 7 different mailing lists, so that should tell you something !

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2560263514

From prr at openjdk.org  Mon Dec 23 20:33:36 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 20:33:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>

On Mon, 23 Dec 2024 19:30:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
> 
>> 1: <?xml version="1.0" encoding="UTF-8"?>
>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
> 
> Does this change affect the behavior of the associated test(s)?

I was also wondering how this was tested.

> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
> 
>> 1: <?xml version="1.0" encoding="UTF-8"?>
>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
> 
> I can't tell whether anything was changed in this file other than the modification of all the end of
> line indicators. I've no idea whether changing those is appropriate or not, but this file came from
> a 3rd party, so might not be appropriate to change here.

+1 to all of that. This change is un-reviewable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896100629
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896100936

From prr at openjdk.org  Mon Dec 23 22:18:35 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 22:18:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
Message-ID: <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>

On Mon, 23 Dec 2024 20:29:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
>> 
>>> 1: <?xml version="1.0" encoding="UTF-8"?>
>>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
>> 
>> Does this change affect the behavior of the associated test(s)?
>
> I was also wondering how this was tested.

FYI, the way to test this is ..
cd test/jdk
jtreg sanity/client/SwingSet/src/TableDemoTest.java

I tried converting all ^M to \n in this file another repo and comparing with your patch but every line was different so I just can't review this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896162028

From qxing at openjdk.org  Tue Dec 24 03:26:23 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:23 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>

> This patch fixes unmatched brackets in some source files.

Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:

 - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
 - Do not touch files in test.
 - Do not touch upstream data from CLDR.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22861/files
  - new: https://git.openjdk.org/jdk/pull/22861/files/540312c4..ec3e6aa5

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

  Stats: 2235 lines in 19 files changed: 2 ins; 2211 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22861/head:pull/22861

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

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <qToKH3NIiVa0fL7Lyd8VoUIjdMf1kohn_JEMNJE5A4s=.1fd147f1-fe89-46f0-8ffa-57aeef5d2d24@github.com>

On Mon, 23 Dec 2024 18:57:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> doc/hotspot-unit-tests.html line 248:
> 
>> 246: so there is no need to have them in error messages. Asserts print only
>> 247: compared values, they do not print any of interim variables, e.g.
>> 248: <code>ASSERT_TRUE(val1 == val2 &amp;&amp; isFail(foo(8)) || i == 18)</code>
> 
> This file is generated from the .md file, and should not be edited directly.

Updated both `.md` and `.html` using `make update-build-docs` in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896332803

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>
Message-ID: <4QfTqVdt_-vwDpQQAaeiElZLvHDDBabcyBtISbLrmPo=.7aa033a5-d09b-4193-9d2e-1336167a10ce@github.com>

On Mon, 23 Dec 2024 14:00:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> doc/hotspot-unit-tests.md line 175:
> 
>> 173: there is no need to have them in error messages. Asserts print only
>> 174: compared values, they do not print any of interim variables, e.g.
>> 175: `ASSERT_TRUE(val1 == val2 && isFail(foo(8)) || i == 18)` prints only
> 
> Looking at this expression, I believe the intention is this.
> Suggestion:
> 
> `ASSERT_TRUE((val1 == val2 && isFail(foo(8))) || i == 18)` prints only

Thanks for the suggestion, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896331528

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>
Message-ID: <rjeNtZS_8Tl4gLjpg0W0gwCSOIHIHcU0VfNB1_P9D1Y=.69d45611-fded-4d4d-96d5-89e33ab6addc@github.com>

On Mon, 23 Dec 2024 17:11:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> make/data/cldr/common/main/kn.xml line 1085:
> 
>> 1083: 			<type key="calendar" type="islamic">????????? ??????????</type>
>> 1084: 			<type key="calendar" type="islamic-civil">?????????-?????? ??????????</type>
>> 1085: 			<type key="calendar" type="islamic-rgsa" draft="contributed">?????????? ??????????? (???? ???????, ????????)</type>
> 
> Hi, we would not modify the contents of upstream data from CLDR.

Sorry, I've reverted these changes in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896331971

From qxing at openjdk.org  Tue Dec 24 03:32:36 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:32:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>

On Mon, 23 Dec 2024 19:13:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:
> 
>> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
>> 49:     $(TESTLIBRARY_DIR)/jtreg \
>> 50:     -maxdepth 1 -name '*.java')
> 
> I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
> close-paren?

I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.

I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.

> test/jaxp/javax/xml/jaxp/unittest/transform/Bug8169112.xsl line 65:
> 
>> 63:           @page { margin: 0.1in; }
>> 64: 
>> 65:           }
> 
> Does this affect the behavior of the test this is part of?

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896336118
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896337303

From qxing at openjdk.org  Tue Dec 24 03:35:47 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:35:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
 <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>
Message-ID: <bs7fuVeUaVtrunvJFhOMsam8pz9Oi43_cTdEk0c2Wsc=.276f1181-a283-4d29-b8b5-bbe45a4eccf6@github.com>

On Mon, 23 Dec 2024 22:16:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> I was also wondering how this was tested.
>
> FYI, the way to test this is ..
> cd test/jdk
> jtreg sanity/client/SwingSet/src/TableDemoTest.java
> 
> I tried converting all ^M to \n in this file another repo and comparing with your patch but every line was different so I just can't review this.

For safety reasons I've restored this file as well as all the files in unit tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896338401

From syan at openjdk.org  Tue Dec 24 06:17:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 24 Dec 2024 06:17:12 GMT
Subject: [jdk24] RFR: 8343882: BasicAnnoTests doesn't handle multiple
 annotations at the same position
Message-ID: <qFxT51lsTVhqTbTnIP3qLP0L9STJQExXRBw3Gv0cV8s=.c2c6752f-dd73-4dc9-8676-f75457d44b82@github.com>

Hi all,

This pull request contains a backport of commit [d562d3c7](https://github.com/openjdk/jdk/commit/d562d3c7a9e1e857c095ef908b0957b033972949) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. Test-fix only, no risk.

The commit being backported was authored by Liam Miller-Cushon on 20 Dec 2024 and was reviewed by Joe Darcy.

Thanks!

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

Commit messages:
 - Backport d562d3c7a9e1e857c095ef908b0957b033972949

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

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

From liach at openjdk.org  Tue Dec 24 06:49:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Dec 2024 06:49:38 GMT
Subject: RFR: 8346295: Update --release 24 symbol information for JDK 24
 build 29
In-Reply-To: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>
References: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>
Message-ID: <oZ_KjfzVp4Fmx16c0SYOdCZH3tCY2LnjxNW7nUC4XgM=.eddee96a-2a20-4392-9ccb-34163a6e52d7@github.com>

On Mon, 23 Dec 2024 15:58:20 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

The signature changes for late ClassFile API changes look good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22867#pullrequestreview-2521556558

From nbenalla at openjdk.org  Tue Dec 24 13:13:14 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 24 Dec 2024 13:13:14 GMT
Subject: RFR: 8346295: Update --release 24 symbol information for JDK 24
 build 29 [v2]
In-Reply-To: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>
References: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>
Message-ID: <lI88MPeB_nxX81bL0h9ZA6LriwkyGqmXTTmKa-afKbo=.efa938d2-bb6d-4dcc-a69d-dfcd2cdb0ad9@github.com>

> Usual symbol file update for a new JDK build.

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

  Empty commit to trigger GHA - change already passes tier 1-3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22867/files
  - new: https://git.openjdk.org/jdk/pull/22867/files/8d68fbcf..5de61d43

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

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

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

From erikj at openjdk.org  Tue Dec 24 14:57:36 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 24 Dec 2024 14:57:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <LWyDWVBvPHM-9HkpB7pI5vh4Ppr-pNufCTbqGlBEhBE=.9917b618-876d-4744-8d1f-f59b137984c8@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

I've reviewed doc/hotspot-unit-tests.* and the Makefile.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522037503

From liach at openjdk.org  Tue Dec 24 15:48:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Dec 2024 15:48:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <dlNpmJp8MDFrFYWDsN0BOkDNw5MOiJB1AoEx6VfQC5g=.794bdb89-b349-49a3-88aa-9f41dc5bfc23@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

Thanks for the ctw fix.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522077710

From liach at openjdk.org  Tue Dec 24 15:48:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Dec 2024 15:48:38 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
Message-ID: <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>

On Tue, 24 Dec 2024 03:28:31 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:
>> 
>>> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
>>> 49:     $(TESTLIBRARY_DIR)/jtreg \
>>> 50:     -maxdepth 1 -name '*.java')
>> 
>> I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
>> close-paren?
>
> I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.
> 
> I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.

Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896838026

From nbenalla at openjdk.org  Tue Dec 24 18:26:08 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 24 Dec 2024 18:26:08 GMT
Subject: Integrated: 8346295: Update --release 24 symbol information for JDK 24
 build 29
In-Reply-To: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>
References: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>
Message-ID: <VhEA9AUh5jp69PZ3lW2piEfY-gXQUFDoI8MCVrE937o=.ba282083-111b-451f-bb11-62f91b6ff772@github.com>

On Mon, 23 Dec 2024 15:58:20 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: 1a32654f
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a32654faf6f6f0256fd7f42e6351adf914d8337
Stats:     4 lines in 2 files changed: 2 ins; 0 del; 2 mod

8346295: Update --release 24 symbol information for JDK 24 build 29

Reviewed-by: liach

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

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

From nbenalla at openjdk.org  Tue Dec 24 18:26:07 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 24 Dec 2024 18:26:07 GMT
Subject: RFR: 8346295: Update --release 24 symbol information for JDK 24
 build 29 [v2]
In-Reply-To: <lI88MPeB_nxX81bL0h9ZA6LriwkyGqmXTTmKa-afKbo=.efa938d2-bb6d-4dcc-a69d-dfcd2cdb0ad9@github.com>
References: <93rgv4SICCEcz9Gk572OsMdN-A3GeZ2eYlQ6ergijPI=.00b98207-359e-406c-b013-07dd0462f411@github.com>
 <lI88MPeB_nxX81bL0h9ZA6LriwkyGqmXTTmKa-afKbo=.efa938d2-bb6d-4dcc-a69d-dfcd2cdb0ad9@github.com>
Message-ID: <VmK8mlrlmtuDLmKJ4T08H9s-9zwRuAeZ4OnQb6gR9Fo=.77380540-25f4-415f-82d5-39adaa97fdd4@github.com>

On Tue, 24 Dec 2024 13:13:14 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 one additional commit since the last revision:
> 
>   Empty commit to trigger GHA - change already passes tier 1-3

All checks pass, thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/22867#issuecomment-2561335324

From kbarrett at openjdk.org  Tue Dec 24 20:30:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 20:30:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
Message-ID: <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>

On Tue, 24 Dec 2024 15:45:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.
>> 
>> I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.
>
> Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.

Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
fixing it in isolation, and backporting that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896952109

From kbarrett at openjdk.org  Tue Dec 24 22:25:41 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 22:25:41 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
 <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
Message-ID: <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>

On Tue, 24 Dec 2024 20:27:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.
>
> Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
> fixing it in isolation, and backporting that.

The purpose of this Makefile seems to be to build ctw.jar. So far as I can tell, nothing in the JDK uses that jar,
or invokes that Makefile. There are some tests for the ctw component in hotspot/jtreg/testlibrary_tests/ctw. I
think if you ran tier4 testing that you would hit those. Or you could use `TEST=hotspot:hotspot_misc`, or
specify that directory.  But those tests don't appear to use that jar. So I think there isn't a test that touches
this Makefile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896981987

From kbarrett at openjdk.org  Tue Dec 24 22:36:47 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 22:36:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <5RJCjU8mibDWRUFIu_5QaivS78cZGFT1ECjS4_f2Z8E=.a8ff6fd5-cba0-40f5-b754-9bdb6f7e8d4b@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

The fix for the ctw Makefile should not be included in this PR.  It's a bug, and needs
to be fixed separately and backported to 24 to fix the introduction there via the
backport of JDK-8334733 from 25 to 24, without dragging the rest of this back to 24.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522228423

From lmesnik at openjdk.org  Wed Dec 25 01:47:37 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Dec 2024 01:47:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
 <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
 <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>
Message-ID: <7rkkA5WQNof4ipfVB0NnpXU1o_nHsPmW3rulRPp78ZU=.593fc62d-f6ae-4885-b6db-09822cfb45ef@github.com>

On Tue, 24 Dec 2024 22:22:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
>> fixing it in isolation, and backporting that.
>
> The purpose of this Makefile seems to be to build ctw.jar. So far as I can tell, nothing in the JDK uses that jar,
> or invokes that Makefile. There are some tests for the ctw component in hotspot/jtreg/testlibrary_tests/ctw. I
> think if you ran tier4 testing that you would hit those. Or you could use `TEST=hotspot:hotspot_misc`, or
> specify that directory.  But those tests don't appear to use that jar. So I think there isn't a test that touches
> this Makefile.

This makefile is not used by jtreg tests. The ctw code is compiled with 
`@library /test/lib / /testlibrary/ctw/src`
so jtreg compiled the ctw library files itself.
This makefile might be used for standalone build if needed.
Thanks for fixing this!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1897036236

From qxing at openjdk.org  Wed Dec 25 02:34:16 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Wed, 25 Dec 2024 02:34:16 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>

> This patch fixes unmatched brackets in some source files.

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

  Revert fix in the CTW Makefile.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22861/files
  - new: https://git.openjdk.org/jdk/pull/22861/files/ec3e6aa5..7f85c5e3

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

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

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

From qxing at openjdk.org  Wed Dec 25 02:37:41 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Wed, 25 Dec 2024 02:37:41 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
Message-ID: <lfbJHjq8KIOjVlG1hsR_nMbCSJ98DVHO8psUkvciZ88=.afbd9575-ea1a-4a19-a483-999917c01510@github.com>

On Mon, 23 Dec 2024 19:42:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I strongly suggest avoiding omnibus changes like this when possible (which it
>> is here). Just because it's all about one "kind" of change doesn't make it a
>> cohesive change. This is touching many distinct areas of the JDK, and several
>> different languages as well. That makes it harder to review and to manage the
>> review, because it is large and affects a wide range of areas, so may need
>> many reviewers. And the whole thing might get stalled by discussion of one
>> piece.
>> 
>> There is also no mention of what testing has been done for this PR. Some of
>> the changes are in executable code, and need to be tested.
>> 
>> I think that all of the files in make/data/cldr/common are from the Unicode
>> Consortium, and should not be modified here.
>
>> That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.
> 
> And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

@kimbarrett @liach Thanks for your suggestions!

I've moved the fix for the CTW Makefile to a separate pull request: https://github.com/openjdk/jdk/pull/22878, please check it.

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2561558033

From kbarrett at openjdk.org  Wed Dec 25 04:57:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 25 Dec 2024 04:57:39 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <RqSpJLzAEPtdnM_px2zUHBK8OWqoSsBiQABho0fLUAY=.f409be95-8db4-4e5b-9337-313a7256461e@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522326924

From alanb at openjdk.org  Thu Dec 26 07:30:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Dec 2024 07:30:42 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

The title on the JBS issue is a mis-leading as it's now about man pages, docs, and a comment. Looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522898115

From qxing at openjdk.org  Thu Dec 26 07:47:37 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Thu, 26 Dec 2024 07:47:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
 <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>
Message-ID: <IUYSixbdrVq_VN1BgMfj3kE9DJb17d4aQ6_eg1w_-7U=.1841076e-3ed7-432c-af9b-a38bd4c6e8e4@github.com>

On Thu, 26 Dec 2024 07:27:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert fix in the CTW Makefile.
>
> The title on the JBS issue is a mis-leading as it's now about man pages, docs, and a comment. Looks okay.

@AlanBateman Thanks for the review! I updated the title of the JBS issue and this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2562270247

From liach at openjdk.org  Fri Dec 27 08:41:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 27 Dec 2024 08:41:44 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v7]
In-Reply-To: <R6SVN7t6Z0aACoWYoC9CpvJegysiCcuUQsgb5BJWMWU=.f878b315-1c43-48b2-bd4a-f14f6aa8dae6@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <R6SVN7t6Z0aACoWYoC9CpvJegysiCcuUQsgb5BJWMWU=.f878b315-1c43-48b2-bd4a-f14f6aa8dae6@github.com>
Message-ID: <yf2F77dUj7p3xHCpZuPtOtmd9WTBqVY3nwqSIglv6vs=.2ac49ba4-2e0c-4fec-a225-267bc10c0320@github.com>

On Thu, 5 Dec 2024 17:54:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
>> 
>> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
>> 
>> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
>> 
>> Here are some actions:
>> 1. Add section for hierarchy overview for both Type and AnnotatedType
>> 2. Specify the underlying type for different AnnotatedType subinterfaces
>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>> 5. Minor improvements to `ParameterizedType::getRawType`
>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>> 
>> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Problems with owner type, kevin suggestions

This attracts fewer reviews because the APIs are already widely used, but these improvements still clarify a lot of confusions and establish clear relations from the API models to the JLS.

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

PR Comment: https://git.openjdk.org/jdk/pull/19977#issuecomment-2563463492

From liach at openjdk.org  Sun Dec 29 01:09:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 29 Dec 2024 01:09:40 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v7]
In-Reply-To: <R6SVN7t6Z0aACoWYoC9CpvJegysiCcuUQsgb5BJWMWU=.f878b315-1c43-48b2-bd4a-f14f6aa8dae6@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
 <R6SVN7t6Z0aACoWYoC9CpvJegysiCcuUQsgb5BJWMWU=.f878b315-1c43-48b2-bd4a-f14f6aa8dae6@github.com>
Message-ID: <K5ueVC6saRk7aG5uInBJ-bzvUd7XCGUFm3cgDtk-m9I=.bd2cd59b-e3ac-4853-96a0-5a21d2b7a157@github.com>

On Thu, 5 Dec 2024 17:54:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
>> 
>> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
>> 
>> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
>> 
>> Here are some actions:
>> 1. Add section for hierarchy overview for both Type and AnnotatedType
>> 2. Specify the underlying type for different AnnotatedType subinterfaces
>> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
>> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
>> 5. Minor improvements to `ParameterizedType::getRawType`
>> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
>> 
>> ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Problems with owner type, kevin suggestions

src/java.base/share/classes/java/lang/reflect/AnnotatedType.java line 90:

> 88:  * method returns a {@link Class}.
> 89:  * <p>
> 90:  * For example, an annotated use {@code @TB Outer. at TA Inner} has an annotation

... is such an instance, and ...

src/java.base/share/classes/java/lang/reflect/AnnotatedWildcardType.java line 39:

> 37:  * For example, an annotated use {@code @TA ? extends @TB Number} has an
> 38:  * annotation {@code @TA} and represents the wildcard type argument {@code ?
> 39:  * extends Number}.  Its lower bound is the annotated use {@code @TB Number}

"lower" -> "upper", similar for "no upper bound" below

src/java.base/share/classes/java/lang/reflect/ParameterizedType.java line 124:

> 122:      * class or interface declaration} and have equal {@linkplain
> 123:      * #getActualTypeArguments() type parameters}, including those from the
> 124:      * {@linkplain #getOwnerType() enclosing classes}.

... if they are non-static nested types. (etc.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19977#discussion_r1899044102
PR Review Comment: https://git.openjdk.org/jdk/pull/19977#discussion_r1899043987
PR Review Comment: https://git.openjdk.org/jdk/pull/19977#discussion_r1899044212

From pravin at zensoftech.co.in  Thu Dec 26 17:29:48 2024
From: pravin at zensoftech.co.in (Pravin)
Date: Thu, 26 Dec 2024 17:29:48 -0000
Subject: Clarification regarding identifier ignorable characters for keywords
Message-ID: <19404044b14.100f495a1669.6623665012016985276@zensoftech.co.in>

Hello sir/madam,



In Section 3.9 Keywords



it states that "51 character sequences, formed from ASCII characters, are reserved for use as keyword and cannot be used as

identifiers. Another 17 character sequences, also formed from ASCII characters, may be interpreted as keywords or as other

tokens, depending on the context in which they appear."



This fails to mention that these character sequences are formed after ignoring the ignorable characters.



e.g.



public is equivalent to pu\u00adblic (\u00ad is the soft-hypen and would be rendered as pu?blic (looks the same)

i.e. an ignorable character for identifiers as mentioned in section 3.8 for identifiers with the help of the statement



"Two identifiers are the same only if, after ignoring characters that are

ignorable, the identifiers have the same Unicode character for each letter

or digit. An ignorable character is a character for which the method

Character.isIdentifierIgnorable(int) returns true."



This is true for all keywords also.

Basically all identifier ignorable characters are valid identifier part but they are not valid identifier start.



??? IntStream.range(0,0x10ffff).filter(Character::isIdentifierIgnorable).allMatch(Character::isJavaIdentifierPart)

??? returns true



??? IntStream.range(0,0x10ffff).filter(Character::isIdentifierIgnorable).anyMatch(Character::isJavaIdentifierStart)

??? returns false



This allows someone to embed these characters without changing the equivalence for identifiers.

Interestingly the same is also true for keywords.

There is one exception in the contextual keyword (non-sealed) which is made up of three tokens, in this case the

identifier ignorable character can be embedded except at the beginning of the third token sealed

i.e. non-\u00adsealed is invalid keyword

but non\u00ad-sealed is valid keyword.



Request to make a clarification about the keywords being equivalent to the ASCII sequence provided after ignoring the ignorable characters.



Thanks and regards,

Pravin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20241226/2d7eb165/attachment.htm>