From nbenalla at openjdk.org  Mon Dec  1 08:53:37 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 1 Dec 2025 08:53:37 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>

> Get JDK 27 underway.

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

 - problem list failing test
 - Merge branch 'master' into start-of-release-27
 - expand start of release documentation
 - Merge branch 'master' into start-of-release-27
 - Changes required for hard 80 character line limit
 - Update --release 26 symbol information for JDK 26 build 25
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
 - revert MAX_COLUMNS to 80
 - Update LATEST_MAJOR_VERSION in Versions.java
 - Merge branch 'master' into start-of-release-27
 - Merge branch 'master' into start-of-release-27
 - ... and 7 more: https://git.openjdk.org/jdk/compare/41b7823d...e5214614

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/78895b2b..e5214614

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

  Stats: 11187 lines in 367 files changed: 7430 ins; 1793 del; 1964 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From liach at openjdk.org  Mon Dec  1 16:03:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 Dec 2025 16:03:38 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
Message-ID: <qmRu0EEyT0f9KXcPudW3DmNh0n3GUGMZ292vwknPT5g=.53b45677-75dd-472c-85f6-bab12f06aad6@github.com>

On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - Merge branch 'master' into start-of-release-27
>  - Changes required for hard 80 character line limit
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3c6406b2...e5214614

bin/generate-symbol-data.sh line 41:

> 39: # - open a terminal program and run these commands:
> 40: #     cd "${JDK_CHECKOUT}"/src/jdk.compiler/share/data/symbols
> 41: #     bash ../../../../../bin/generate-symbol-data.sh "${JDK_N_INSTALL}"

Same, extract to 26

doc/starting-next-release.md line 68:

> 66:    update annotation processor extended by `javac` tests to cover the new source version
> 67: * `test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out` and `test/langtools/tools/javac/preview/classReaderTest/Client.preview.out`: update expected messages for preview errors and warnings
> 68: * `test/langtools/tools/javac/versions/Versions.java`: add new source version to the set of valid sources and add new enum constant for the new class file version.

Same remark, extract to 26

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

> 380:      *
> 381:      * @see <a
> 382:      * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html">

This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated.

src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1:

> 1: /*

Let's extract this change to 26

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

> 1: #

Let's extract this for 26.

src/jdk.compiler/share/data/symbols/README line 1:

> 1: This directory contains history data for -release.

Let's extract this for 26.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577666303
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577665823
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577662551
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577673512
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577675100
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577674956

From nbenalla at openjdk.org  Mon Dec  1 16:03:40 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 1 Dec 2025 16:03:40 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <qmRu0EEyT0f9KXcPudW3DmNh0n3GUGMZ292vwknPT5g=.53b45677-75dd-472c-85f6-bab12f06aad6@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
 <qmRu0EEyT0f9KXcPudW3DmNh0n3GUGMZ292vwknPT5g=.53b45677-75dd-472c-85f6-bab12f06aad6@github.com>
Message-ID: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com>

On Mon, 1 Dec 2025 15:52:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - problem list failing test
>>  - Merge branch 'master' into start-of-release-27
>>  - expand start of release documentation
>>  - Merge branch 'master' into start-of-release-27
>>  - Changes required for hard 80 character line limit
>>  - Update --release 26 symbol information for JDK 26 build 25
>>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>>  - revert MAX_COLUMNS to 80
>>  - Update LATEST_MAJOR_VERSION in Versions.java
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3c6406b2...e5214614
>
> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382:
> 
>> 380:      *
>> 381:      * @see <a
>> 382:      * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html">
> 
> This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated.

Great idea Chen, I will open a PR for this today

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577683094

From iris at openjdk.org  Mon Dec  1 17:15:11 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 1 Dec 2025 17:15:11 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
Message-ID: <GNhKTQAkmbs2gEqyZexa-zc6vWZE4Dre_GDEKUIBOcA=.0a64275a-41a9-4d84-a2af-3e2e59374b62@github.com>

On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - Merge branch 'master' into start-of-release-27
>  - Changes required for hard 80 character line limit
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/3b597a10...e5214614

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3526121001

From jjg3 at pobox.com  Mon Dec  1 17:15:16 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Mon, 01 Dec 2025 09:15:16 -0800
Subject: End position storage in javac
In-Reply-To: <1e9cec1e-eb8d-4745-86ef-ebc0c1c6f5fc@oracle.com>
References: <CAL4QsgtwRf+xLCvpiZ5j8qKJPOUHZKPfhZpq5Kxv0d21VdMAHg@mail.gmail.com>
 <1e9cec1e-eb8d-4745-86ef-ebc0c1c6f5fc@oracle.com>
Message-ID: <d0b4329b-a6ca-4d28-ae1d-24fad01af816@app.fastmail.com>

Names are (have always been) uniquified.  IIRC, back in the day, interned strings were less efficient than now and never GC-ed.  Now, an impediment is that `Name` has effectively leaked into the public API, via `javax.lang.model` and would be hard to replace.

Generally, this "version" of javac dates back to JDK 3/JDK 4 days, when standard collections were less pervasive, and software engineering was ever so much simpler, both in terms of impl design and tools (who remembers emacs?). That being said, it is a testament to that early design that it has endured so long with many pervasive incremental upgrades.

-- Jon

On Thu, Nov 27, 2025, at 5:45 AM, Maurizio Cimadamore wrote:
> For names I'm less sure, 
> but maybe somebody else knows the answer there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251201/2e448713/attachment-0001.htm>

From jjg3 at pobox.com  Mon Dec  1 17:32:29 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Mon, 01 Dec 2025 09:32:29 -0800
Subject: End position storage in javac
In-Reply-To: <CANSoFxuV4Ue3=kCTTY+QWWT0dKhARk_1+wCKkUbQ72jgi_N2_A@mail.gmail.com>
References: <CAL4QsgtwRf+xLCvpiZ5j8qKJPOUHZKPfhZpq5Kxv0d21VdMAHg@mail.gmail.com>
 <CANSoFxuV4Ue3=kCTTY+QWWT0dKhARk_1+wCKkUbQ72jgi_N2_A@mail.gmail.com>
Message-ID: <fca5e53d-37b6-4604-8126-0313482135ff@app.fastmail.com>



On Wed, Nov 26, 2025, at 12:46 PM, Archie Cobbs wrote:
> Rhetorical question: if space really is so precious, then why not get rid of all the "Tag" fields and just use instanceof instead?
> 
> I'm assuming the original rationale for "Tag" fields was because instanceof was too slow? If so, is that still true? 

IIRC, while performance was an issue at one point in the past, it was not the reason to avoid instanceof.

The performance issue was that field/member access was seen to be faster than virtual method calls, and thus justified the field.

instanceof was deemed to be less reliable than tag usage. Not unreliable in the determini*s*tic sense, but because there were some design choices in javac and other similar tools where "poor use of interface inheritance" could mean that instanceof would return the wrong answer compared to examining the tag in some way. I remember fixing those issues in javac.

Also remember that in the original design, up through JDK 5, javac was "just" a closed batch mode compiler. java files in, class files out; that was it. That definitely affected design choices back then. It was only as we started opening up javac as a software component in JDK 6 onwards that some of those design choices (like end positions) became less than ideal, and were worked around to some degree, 

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251201/0974b303/attachment.htm>

From darcy at openjdk.org  Mon Dec  1 19:48:53 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 1 Dec 2025 19:48:53 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
Message-ID: <J-DRBORFbEdZCZxrBgltGWUdxo1c56HiBX1ANfPwOLM=.b1a265bb-eb16-4e86-95d1-b583be1e2fbc@github.com>

On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - Merge branch 'master' into start-of-release-27
>  - Changes required for hard 80 character line limit
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/bec8ec07...e5214614

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

> 392:      *
> 393:      * @see <a
> 394:      * href="https://docs.oracle.com/en/java/javase/27/docs/specs/jvms/index.html">

Presumably the analagous URL update should be done here as in ClassFileFormatVersion for the JLS instead of the JVMS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578389248

From darcy at openjdk.org  Mon Dec  1 19:52:54 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 1 Dec 2025 19:52:54 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
Message-ID: <9vzVbgAOcM7Svoy5DoqhDVY4Tn2bysq9WAYpMsBcenc=.441a1ba8-3e46-41d2-bf77-afb86fe8515c@github.com>

On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - Merge branch 'master' into start-of-release-27
>  - Changes required for hard 80 character line limit
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/04b667ed...e5214614

src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1368:

> 1366:     }
> 1367: 
> 1368:     private static String formatAbbreviatedList(Collection<String> values) {

I think changing the policy here is okay, but it should be better documented in comments here.

Additionally, it assume there will be a dense collection of supported values between the 4 th and (n-3) rd. That is currently the de facto policy, but is not ironclad. This assumption should also be documented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578399308

From erikj at openjdk.org  Mon Dec  1 22:24:07 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 1 Dec 2025 22:24:07 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
Message-ID: <nqU_dKfwMwAq4IPGXqwpLxA7ImsG0cF_TaseFMb3kZo=.245f1df7-3255-46bd-991b-198c6a257bdd@github.com>

On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - Merge branch 'master' into start-of-release-27
>  - Changes required for hard 80 character line limit
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/193bb114...e5214614

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

> 38: DEFAULT_VERSION_CLASSFILE_MINOR=0
> 39: DEFAULT_VERSION_DOCS_API_SINCE=11
> 40: DEFAULT_ACCEPTABLE_BOOT_VERSIONS="25 26"

Need to add 27 to this line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578923651

From dlsmith at openjdk.org  Mon Dec  1 23:36:54 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Mon, 1 Dec 2025 23:36:54 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
 <qmRu0EEyT0f9KXcPudW3DmNh0n3GUGMZ292vwknPT5g=.53b45677-75dd-472c-85f6-bab12f06aad6@github.com>
 <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com>
Message-ID: <vryu2X5c7JH8Q_MKMU-drbBrgj08iAeiuEi2YKOvVQs=.38a2a133-29c2-4c49-884e-88a8d6f5c89b@github.com>

On Mon, 1 Dec 2025 15:58:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382:
>> 
>>> 380:      *
>>> 381:      * @see <a
>>> 382:      * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html">
>> 
>> This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated.
>
> Great idea Chen, I will open a PR for this today

Better to use a relative url now and stop bumping the version with each release: 


href="../../../../specs/jvms/index.html"


(Check my work on the number of dots, may be one or two off.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579082529

From darcy at openjdk.org  Mon Dec  1 23:52:47 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 1 Dec 2025 23:52:47 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <vryu2X5c7JH8Q_MKMU-drbBrgj08iAeiuEi2YKOvVQs=.38a2a133-29c2-4c49-884e-88a8d6f5c89b@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
 <qmRu0EEyT0f9KXcPudW3DmNh0n3GUGMZ292vwknPT5g=.53b45677-75dd-472c-85f6-bab12f06aad6@github.com>
 <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com>
 <vryu2X5c7JH8Q_MKMU-drbBrgj08iAeiuEi2YKOvVQs=.38a2a133-29c2-4c49-884e-88a8d6f5c89b@github.com>
Message-ID: <BhdX-v2SB2c-214GqQhbMgXqajBSVEJ8JGce8c4xiq4=.94fafa80-0472-46a1-b5a6-f8e9378f5564@github.com>

On Mon, 1 Dec 2025 23:34:16 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Great idea Chen, I will open a PR for this today
>
> Better to use a relative url now and stop bumping the version with each release: 
> 
> 
> href="../../../../specs/jvms/index.html"
> 
> 
> (Check my work on the number of dots, may be one or two off.)

I assume there is going to be some canonical publication of the JLS and JVMS specs per release. If so, these URLs should refer to that release. In JDK ($N+1) will will still want the links to JLS $N to resolve to JLS $N and _not_ JLS ($N + 1).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579106368

From dlsmith at openjdk.org  Tue Dec  2 00:35:54 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Tue, 2 Dec 2025 00:35:54 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <BhdX-v2SB2c-214GqQhbMgXqajBSVEJ8JGce8c4xiq4=.94fafa80-0472-46a1-b5a6-f8e9378f5564@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
 <qmRu0EEyT0f9KXcPudW3DmNh0n3GUGMZ292vwknPT5g=.53b45677-75dd-472c-85f6-bab12f06aad6@github.com>
 <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com>
 <vryu2X5c7JH8Q_MKMU-drbBrgj08iAeiuEi2YKOvVQs=.38a2a133-29c2-4c49-884e-88a8d6f5c89b@github.com>
 <BhdX-v2SB2c-214GqQhbMgXqajBSVEJ8JGce8c4xiq4=.94fafa80-0472-46a1-b5a6-f8e9378f5564@github.com>
Message-ID: <D8FtQ4vL3l_06pQ4XDjmP1FdN1D68IpVSmyK9npBWnM=.2da9276e-ee1a-4e55-aa5f-ce9b153a659f@github.com>

On Mon, 1 Dec 2025 23:50:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Better to use a relative url now and stop bumping the version with each release: 
>> 
>> 
>> href="../../../../specs/jvms/index.html"
>> 
>> 
>> (Check my work on the number of dots, may be one or two off.)
>
> I assume there is going to be some canonical publication of the JLS and JVMS specs per release. If so, these URLs should refer to that release. In JDK ($N+1) will will still want the links to JLS $N to resolve to JLS $N and _not_ JLS ($N + 1).

Oh, yes, thanks Joe, I'd missed that context. If the goal is to have a stable URL that will always point to the snapshot for a given version, yes, you want the full URL, and this updated URL looks like the correct one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579166554

From darcy at openjdk.org  Tue Dec  2 01:04:57 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Dec 2025 01:04:57 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language evolution
 history for changes in 26
Message-ID: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>

Include source-level comments about per-release language changes, or lack thereof.

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

Commit messages:
 - JDK-8372850: Update comment in SourceVersion for language evolution history for changes in 26

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

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

From liach at openjdk.org  Tue Dec  2 01:47:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 01:47:49 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26
In-Reply-To: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
Message-ID: <OYrKubJWIVtBfGshg1EaRlWoDQp5dHgy3XdrJlk-HSI=.6c7e66b8-cdd8-4b9b-ab74-c5fd1d0d6df7@github.com>

On Tue, 2 Dec 2025 00:59:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Include source-level comments about per-release language changes, or lack thereof.

Changes requested by liach (Reviewer).

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

> 85:      *      instance main methods, and flexible constructor bodies
> 86:      *      (primitive Types in Patterns, instanceof, and switch in
> 87:      *      second preview, module Import Declarations in third

module import was already finalized in 25, and primitive type in patterns... was in 3rd preview in 25.

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

> 88:      *      preview)
> 89:      *  26: no changes (primitive Types in Patterns, instanceof, and
> 90:      *      switch in second preview, module Import Declarations in fourth

4th preview now, no module import changes

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

PR Review: https://git.openjdk.org/jdk/pull/28594#pullrequestreview-3527798030
PR Review Comment: https://git.openjdk.org/jdk/pull/28594#discussion_r2579293201
PR Review Comment: https://git.openjdk.org/jdk/pull/28594#discussion_r2579293686

From cstein at openjdk.org  Tue Dec  2 13:35:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 2 Dec 2025 13:35:51 GMT
Subject: Integrated: 8371470: Java Launcher does not fail when running compact
 java-file with private no-arg constructor
In-Reply-To: <88t6iQiwL_FM1LOuw6-OgiGZTbVSUz95hZnlNoEpIiU=.4ad93426-b6ce-4530-813d-7e1799e1564d@github.com>
References: <88t6iQiwL_FM1LOuw6-OgiGZTbVSUz95hZnlNoEpIiU=.4ad93426-b6ce-4530-813d-7e1799e1564d@github.com>
Message-ID: <GTSr3_zC-9YtXj05t5BudoJX_AXfdZgKhn6NVGQ7x4A=.81bcbfbb-1395-4ad7-b699-14223299e3cc@github.com>

On Thu, 13 Nov 2025 11:46:45 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to synchronize the behaviour in `java`'s source launch mode to fail when a non-arg constructor with `private` access modifier is defined - like it does in class launch mode.
> 
> Find the prior-art check performed in class launch mode at [LauncherHelper.java#L958-L961](https://github.com/openjdk/jdk/blob/8102f436f5586253302cd8cef49bfe2b4af41693/src/java.base/share/classes/sun/launcher/LauncherHelper.java#L958-L961):
> 
> 
> Constructor<?> constructor = mainClass.getDeclaredConstructor();
> if (Modifier.isPrivate(constructor.getModifiers())) {
>     abort(null, "java.launcher.cls.error6", className);
> }

This pull request has now been integrated.

Changeset: c97d53a9
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c97d53a9529d9148aacd85a3b31d694f04df0758
Stats:     45 lines in 3 files changed: 34 ins; 9 del; 2 mod

8371470: Java Launcher does not fail when running compact java-file with private no-arg constructor

Reviewed-by: jpai

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

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

From nbenalla at openjdk.org  Tue Dec  2 14:23:38 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 14:23:38 GMT
Subject: RFR: 8372940: Update symbol data script references
Message-ID: <H3Huc-VxnpWptsUAU5RAHs5ORXaN36U3gO-ULB5wtuA=.50ff9d53-2182-459a-bee1-71250503013c@github.com>

Update path to the generate symbols script, and expand the start of release doc.

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

Commit messages:
 - doc updates

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

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

From nbenalla at openjdk.org  Tue Dec  2 14:23:48 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 14:23:48 GMT
Subject: RFR: 8372937: Abbreviate list of supported releases
Message-ID: <VINQw0HIaIxthMlYhE-PxuCvifL9CV5qV1wcLEUkcb4=.393cfad4-1529-4eff-9dbe-30dea70572d1@github.com>

Abbreviating the list of supported released to be under 80 columns

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

Commit messages:
 - set a hard 80 char limit

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

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

From nbenalla at openjdk.org  Tue Dec  2 14:23:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 14:23:57 GMT
Subject: RFR: 8372939: Update JDK 26 spec URLs
Message-ID: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com>

Updating the JDK 26 JLS and JVMS links

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

Commit messages:
 - update jdk 26 spec links

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

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

From nbenalla at openjdk.org  Tue Dec  2 14:57:43 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 14:57:43 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v8]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <8Fxjqxz7uHKELjvLEjJg4Zvkbs38Bz52UcbJJYkkN4I=.09b0c42a-4b86-4ba9-9a31-d0a7b60af3fe@github.com>

> Get JDK 27 underway.

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

 - Merge branch 'master' into start-of-release-27
 - problem list failing test
 - Merge branch 'master' into start-of-release-27
 - expand start of release documentation
 - Merge branch 'master' into start-of-release-27
 - Changes required for hard 80 character line limit
 - Update --release 26 symbol information for JDK 26 build 25
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
 - revert MAX_COLUMNS to 80
 - Update LATEST_MAJOR_VERSION in Versions.java
 - Merge branch 'master' into start-of-release-27
 - ... and 8 more: https://git.openjdk.org/jdk/compare/759d7098...b47b9ee9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/e5214614..b47b9ee9

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

  Stats: 7726 lines in 83 files changed: 2728 ins; 4423 del; 575 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From jan.lahoda at oracle.com  Tue Dec  2 15:06:54 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 2 Dec 2025 16:06:54 +0100
Subject: End position storage in javac
In-Reply-To: <1e9cec1e-eb8d-4745-86ef-ebc0c1c6f5fc@oracle.com>
References: <CAL4QsgtwRf+xLCvpiZ5j8qKJPOUHZKPfhZpq5Kxv0d21VdMAHg@mail.gmail.com>
 <1e9cec1e-eb8d-4745-86ef-ebc0c1c6f5fc@oracle.com>
Message-ID: <01dc3b81-22e6-4d67-a8ba-f1a692cee7ba@oracle.com>

Hi,


Yes, I think it would make sense to look into moving the end positions 
into the trees, as the types of compilations that don't use end 
positions are, I think, getting rarer. I took a peek at the draft PR, 
and overall it seems reasonable to me. (I'd need a more detailed pass to 
fully review, though.)


Thanks,

 ? ? Jan


On 11/27/25 14:45, Maurizio Cimadamore wrote:
> Hi Liam, Archie
> I believe this came up also in the recent discussions on lint 
> warnings, where we needed to expand the set of end positions retained 
> by default.
>
> I think the long term solution here is, as you say (and I think Jan 
> supports that too) that end positions should be just stored by default 
> in the trees.
>
> There's a lot of things javac does "its own way" for reasons sometimes 
> good, sometimes less good. For instance, javac had to use its own 
> `List` because when it was written generics were not yet available. 
> That said, one issue with using just a plain j.l.List (like ArrayList) 
> in javac is that (a) javac typically operates on very small lists, 
> where the overhead of array lists might be too big and (b) j.u.List is 
> very bad for recursing algorithms, which is what javac is all about. 
> So, I believe using a custom List impl there seems to be a good trade 
> off.
>
> Other areas that are brought up from time to time are:
>
> * use of special data structures for scopes -- why not just maps?
> * use of special data structures for names -- why not just strings?
>
> I believe we did some experiments on the former, and concluded that 
> javac implementation was still better than a hashmap (as javac 
> requirement are specialized, and scopes need to be traversed in 
> different ways, and somtimes a new scope needs to be "pushed" on top 
> of an old one -- reusing the undelrying entries). For names I'm less 
> sure, but maybe somebody else knows the answer there.
>
> Then there's the general lack of data-orientedness of the javac 
> design. Lots of classes with lots of visitors everywhere, and various 
> ways to query "are you a T". I would like very much, one day, to make 
> the Type/Symbol/Tree hierarchies sealed, and get rid of all the 
> various kinds/tags, etc. and maybe even see if we can get rid of 
> visitors and just use plain code with pattern matching.
>
> Maurizio
>
>
> On 26/11/2025 13:01, Liam Miller-Cushon wrote:
>> Hi,
>>
>> I wanted to discuss how javac handles end positions, and get input on 
>> the possibility of having the compiler unconditionally store end 
>> positions in a field on JCTree instead of in a separate map.
>>
>> Currently end position information is not stored by default, but is 
>> enabled in certain modes: if?-Xjcov is set, or if the compilation 
>> includes diagnostic listeners, task listeners, or annotation 
>> processors (since they may want end positions).
>>
>> The hash table used to store the end positions?was optimized in JDK 9 
>> in?JDK-8033287, and there was some related discussion on 
>> compiler-dev@ about the motivation?for making end positions?optional 
>> at that time.
>>
>> As I understand it, the goal is to?save memory in the case where end 
>> positions aren't needed. That savings comes with?a trade-off when end 
>> positions are needed, though, since the map is less efficient than 
>> storing the position directly in JCTree.
>>
>> Today, many invocations of javac will need end position information 
>> (annotation processing is common, when javac is used programatically 
>> in IDEs end positions will be enabled). For the invocations that do 
>> not need end positions, typical developer machines are less memory 
>> constrained than they were when the optimization for end positions 
>> was first introduced.
>>
>> Looking at the compilation of java.base, it contains about 3000 files 
>> and creates about 3 million AST nodes, so adding an int field to 
>> JCTree to store end positions would take about 12MB.
>>
>> What do you think? Would it make sense to consider adding a field to 
>> JCTree to store end positions, instead of using EndPosTable?
>>
>> I have a draft PR of the approach here: 
>> https://github.com/openjdk/jdk/pull/28506
>>
>> Having end position information always available might enable some 
>> potential improvements to javac. For example, some compilers indicate 
>> a span of source text for some diagnostics, for example the 'range 
>> highlighting' described in these clang docs: 
>> https://clang.llvm.org/diagnostics.html

From nbenalla at openjdk.org  Tue Dec  2 15:07:11 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 15:07:11 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v9]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - revert changes to avoid conflict
 - add 27 to the acceptable boot versions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/b47b9ee9..1237304b

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

  Stats: 49 lines in 4 files changed: 8 ins; 29 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From nbenalla at openjdk.org  Tue Dec  2 15:07:16 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 15:07:16 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <nqU_dKfwMwAq4IPGXqwpLxA7ImsG0cF_TaseFMb3kZo=.245f1df7-3255-46bd-991b-198c6a257bdd@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
 <nqU_dKfwMwAq4IPGXqwpLxA7ImsG0cF_TaseFMb3kZo=.245f1df7-3255-46bd-991b-198c6a257bdd@github.com>
Message-ID: <tTVYGqAF97WOV48qWxX4OnM9itnnsAI-ovycnhpZ3vU=.68f8588c-05d6-4c3e-8cc9-7f6dab94fe02@github.com>

On Mon, 1 Dec 2025 22:20:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - problem list failing test
>>  - Merge branch 'master' into start-of-release-27
>>  - expand start of release documentation
>>  - Merge branch 'master' into start-of-release-27
>>  - Changes required for hard 80 character line limit
>>  - Update --release 26 symbol information for JDK 26 build 25
>>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>>  - revert MAX_COLUMNS to 80
>>  - Update LATEST_MAJOR_VERSION in Versions.java
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8736a894...e5214614
>
> make/conf/version-numbers.conf line 40:
> 
>> 38: DEFAULT_VERSION_CLASSFILE_MINOR=0
>> 39: DEFAULT_VERSION_DOCS_API_SINCE=11
>> 40: DEFAULT_ACCEPTABLE_BOOT_VERSIONS="25 26"
> 
> Need to add 27 to this line.

Fixed in https://github.com/openjdk/jdk/pull/28130/commits/061986c2fa56bcf1411f479c5b76602f63dc93c3, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2581577462

From liach at openjdk.org  Tue Dec  2 15:56:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 15:56:14 GMT
Subject: RFR: 8372940: Update symbol data script references
In-Reply-To: <H3Huc-VxnpWptsUAU5RAHs5ORXaN36U3gO-ULB5wtuA=.50ff9d53-2182-459a-bee1-71250503013c@github.com>
References: <H3Huc-VxnpWptsUAU5RAHs5ORXaN36U3gO-ULB5wtuA=.50ff9d53-2182-459a-bee1-71250503013c@github.com>
Message-ID: <bGA4i_VnCqOrARTVtZMPiNiMt89D0eaeDjPYzogKEjU=.1e802ddb-77e0-454e-a9d0-3af0eaaa2a39@github.com>

On Tue, 2 Dec 2025 14:05:51 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Update path to the generate symbols script, and expand the start of release doc.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28606#pullrequestreview-3530884832

From cushon at google.com  Tue Dec  2 15:59:17 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 2 Dec 2025 16:59:17 +0100
Subject: End position storage in javac
In-Reply-To: <01dc3b81-22e6-4d67-a8ba-f1a692cee7ba@oracle.com>
References: <CAL4QsgtwRf+xLCvpiZ5j8qKJPOUHZKPfhZpq5Kxv0d21VdMAHg@mail.gmail.com>
 <1e9cec1e-eb8d-4745-86ef-ebc0c1c6f5fc@oracle.com>
 <01dc3b81-22e6-4d67-a8ba-f1a692cee7ba@oracle.com>
Message-ID: <CAL4QsgsBY7Va1-KZb=LCNrNMadKD05WKRJQbm8RiHVQZFbRAAw@mail.gmail.com>

Thanks for the thoughts on this! I have filed JDK-8372948 to track the
potential change to end positions.

> That being said, it is a testament to that early design that it has
endured so long with many pervasive incremental upgrades.

I think this is well put, and the example of linked lists in List and Scope
that Mauritzio raised seems like a good example of those decisions holding
up.

I did some more archeology, and storing end positions in a separate map was
present in the first version of the OpenJDK sources that there's git
history for, which I think predates the introduction of annotation
processing. I think it can both be the case that it was a good decision at
the time (memory was more constrained, and the compiler was primarily a
batch compiler), and that it's a reasonable time to revisit it.

> Then there's the general lack of data-orientedness of the javac design.

I have worked on some compiler-adjacent tools that lean more into being
data oriented, representing symbols and types as immutable data, then
putting information computed during compilation passes in separate tables
keyed off symbols or types. I have found it to be pleasant to reason about,
compared to having more mutable and lazily computed state directly in the
symbol and type representations.

Going through separate maps doesn't provide as nice an object oriented API
as having getters directly on Symbol/Type, and I don't think that approach
necessarily makes sense for javac, but it does seem interesting to consider
areas where javac could benefit from being more data-oriented.

On Tue, Dec 2, 2025 at 4:07?PM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Hi,
>
>
> Yes, I think it would make sense to look into moving the end positions
> into the trees, as the types of compilations that don't use end
> positions are, I think, getting rarer. I took a peek at the draft PR,
> and overall it seems reasonable to me. (I'd need a more detailed pass to
> fully review, though.)
>
>
> Thanks,
>
>      Jan
>
>
> On 11/27/25 14:45, Maurizio Cimadamore wrote:
> > Hi Liam, Archie
> > I believe this came up also in the recent discussions on lint
> > warnings, where we needed to expand the set of end positions retained
> > by default.
> >
> > I think the long term solution here is, as you say (and I think Jan
> > supports that too) that end positions should be just stored by default
> > in the trees.
> >
> > There's a lot of things javac does "its own way" for reasons sometimes
> > good, sometimes less good. For instance, javac had to use its own
> > `List` because when it was written generics were not yet available.
> > That said, one issue with using just a plain j.l.List (like ArrayList)
> > in javac is that (a) javac typically operates on very small lists,
> > where the overhead of array lists might be too big and (b) j.u.List is
> > very bad for recursing algorithms, which is what javac is all about.
> > So, I believe using a custom List impl there seems to be a good trade
> > off.
> >
> > Other areas that are brought up from time to time are:
> >
> > * use of special data structures for scopes -- why not just maps?
> > * use of special data structures for names -- why not just strings?
> >
> > I believe we did some experiments on the former, and concluded that
> > javac implementation was still better than a hashmap (as javac
> > requirement are specialized, and scopes need to be traversed in
> > different ways, and somtimes a new scope needs to be "pushed" on top
> > of an old one -- reusing the undelrying entries). For names I'm less
> > sure, but maybe somebody else knows the answer there.
> >
> > Then there's the general lack of data-orientedness of the javac
> > design. Lots of classes with lots of visitors everywhere, and various
> > ways to query "are you a T". I would like very much, one day, to make
> > the Type/Symbol/Tree hierarchies sealed, and get rid of all the
> > various kinds/tags, etc. and maybe even see if we can get rid of
> > visitors and just use plain code with pattern matching.
> >
> > Maurizio
> >
> >
> > On 26/11/2025 13:01, Liam Miller-Cushon wrote:
> >> Hi,
> >>
> >> I wanted to discuss how javac handles end positions, and get input on
> >> the possibility of having the compiler unconditionally store end
> >> positions in a field on JCTree instead of in a separate map.
> >>
> >> Currently end position information is not stored by default, but is
> >> enabled in certain modes: if -Xjcov is set, or if the compilation
> >> includes diagnostic listeners, task listeners, or annotation
> >> processors (since they may want end positions).
> >>
> >> The hash table used to store the end positions was optimized in JDK 9
> >> in JDK-8033287, and there was some related discussion on
> >> compiler-dev@ about the motivation for making end positions optional
> >> at that time.
> >>
> >> As I understand it, the goal is to save memory in the case where end
> >> positions aren't needed. That savings comes with a trade-off when end
> >> positions are needed, though, since the map is less efficient than
> >> storing the position directly in JCTree.
> >>
> >> Today, many invocations of javac will need end position information
> >> (annotation processing is common, when javac is used programatically
> >> in IDEs end positions will be enabled). For the invocations that do
> >> not need end positions, typical developer machines are less memory
> >> constrained than they were when the optimization for end positions
> >> was first introduced.
> >>
> >> Looking at the compilation of java.base, it contains about 3000 files
> >> and creates about 3 million AST nodes, so adding an int field to
> >> JCTree to store end positions would take about 12MB.
> >>
> >> What do you think? Would it make sense to consider adding a field to
> >> JCTree to store end positions, instead of using EndPosTable?
> >>
> >> I have a draft PR of the approach here:
> >> https://github.com/openjdk/jdk/pull/28506
> >>
> >> Having end position information always available might enable some
> >> potential improvements to javac. For example, some compilers indicate
> >> a span of source text for some diagnostics, for example the 'range
> >> highlighting' described in these clang docs:
> >> https://clang.llvm.org/diagnostics.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251202/73b2683e/attachment-0001.htm>

From liach at openjdk.org  Tue Dec  2 16:06:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 16:06:55 GMT
Subject: RFR: 8372939: Update JDK 26 spec URLs
In-Reply-To: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com>
References: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com>
Message-ID: <N4Lv4qVVyo8M5_5JAnN3iRXgLA2JPKy3imzYMsFJSIw=.5922bf6d-73ff-4089-b55c-52296043ef69@github.com>

On Tue, 2 Dec 2025 14:05:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Updating the JDK 26 JLS and JVMS links

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28605#pullrequestreview-3530947007

From liach at openjdk.org  Tue Dec  2 16:06:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 16:06:56 GMT
Subject: RFR: 8372937: Abbreviate list of supported releases
In-Reply-To: <VINQw0HIaIxthMlYhE-PxuCvifL9CV5qV1wcLEUkcb4=.393cfad4-1529-4eff-9dbe-30dea70572d1@github.com>
References: <VINQw0HIaIxthMlYhE-PxuCvifL9CV5qV1wcLEUkcb4=.393cfad4-1529-4eff-9dbe-30dea70572d1@github.com>
Message-ID: <IKqVHWDy69PnD9igHPny6t9cwjXFrVNzk1ooghy44P0=.b7397ad5-10ec-4813-8a4e-bb7a74245faa@github.com>

On Tue, 2 Dec 2025 14:05:16 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Abbreviating the list of supported released to be under 80 columns

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28604#pullrequestreview-3530949040

From cushon at openjdk.org  Tue Dec  2 16:12:58 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 2 Dec 2025 16:12:58 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree
Message-ID: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>

This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html).

I performed the refactoring in stages, preserving existing semantics at each step.

There are two known places where this changes existing behaviour that are reflected in changes to tests:

* `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that.

* `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment

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

Commit messages:
 - 8372948: Store end positions directly in JCTree

Changes: https://git.openjdk.org/jdk/pull/28610/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372948
  Stats: 563 lines in 33 files changed: 7 ins; 437 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/28610.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610

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

From jjg3 at pobox.com  Tue Dec  2 16:19:04 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Tue, 02 Dec 2025 08:19:04 -0800
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
Message-ID: <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com>

Without looking in detail at this specific proposal, I wonder if you considered the alternative to only store end positions in the subtypes of JCTree that actually "need" them.  In other words, you only need store end positions in tree nodes that "end" in a lexical token and not in a child tree node.  Effectively, you only need store the end position in tree nodes that would otherwise have entries in the EndPosTable.

-- Jon

On Tue, Dec 2, 2025, at 8:12 AM, Liam Miller-Cushon wrote:
> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html).
> 
> I performed the refactoring in stages, preserving existing semantics at each step.
> 
> There are two known places where this changes existing behaviour that are reflected in changes to tests:
> 
> * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that.
> 
> * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment
> 
> -------------
> 
> Commit messages:
> - 8372948: Store end positions directly in JCTree
> 
> Changes: https://git.openjdk.org/jdk/pull/28610/files
>   Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28610&range=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8372948
>   Stats: 563 lines in 33 files changed: 7 ins; 437 del; 119 mod
>   Patch: https://git.openjdk.org/jdk/pull/28610.diff
>   Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610
> 
> PR: https://git.openjdk.org/jdk/pull/28610
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251202/41630644/attachment-0001.htm>

From cushon at openjdk.org  Tue Dec  2 16:30:49 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 2 Dec 2025 16:30:49 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com>
Message-ID: <VXUtajCV74hrJw7F1DNU6Z3OosCQ1YDFD1KSsXT-GZg=.1fe8c181-20fa-4868-8602-98190877a7c6@github.com>

On Tue, 2 Dec 2025 16:21:21 GMT, Jonathan Gibbons <jjg3 at pobox.com> wrote:

> Without looking in detail at this specific proposal, I wonder if you considered the alternative to only store end positions in the subtypes of JCTree that actually "need" them. In other words, you only need store end positions in tree nodes that "end" in a lexical token and not in a child tree node. Effectively, you only need store the end position in tree nodes that would otherwise have entries in the EndPosTable.

Good question--I hadn't investigated that option. It seems do-able, perhaps with a shared interface for subtypes that needed end positions to simplify the handling of them.

What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory?

Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3602921946

From jjg3 at pobox.com  Tue Dec  2 16:36:30 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Tue, 02 Dec 2025 08:36:30 -0800
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <VXUtajCV74hrJw7F1DNU6Z3OosCQ1YDFD1KSsXT-GZg=.1fe8c181-20fa-4868-8602-98190877a7c6@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com>
 <VXUtajCV74hrJw7F1DNU6Z3OosCQ1YDFD1KSsXT-GZg=.1fe8c181-20fa-4868-8602-98190877a7c6@github.com>
Message-ID: <a2ee7c30-1dc2-46d6-a6db-1ab1fae96888@app.fastmail.com>

> What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory?

Probably, yes, as well as just being a closer equivalent to the existing code.

>Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well?

Every JCTree node already has a 'pos' field, representing the position of the first character that is unique to the tree node.  That means it is the 'start' position for those nodes that begin with a lexical token, and so no additional field is necessary.

The asymmetry between start and end positions is indicative of why there is only an EndPosTable, without any need for a StartPosTable.

-- Jon

On Tue, Dec 2, 2025, at 8:30 AM, Liam Miller-Cushon wrote:
> On Tue, 2 Dec 2025 16:21:21 GMT, Jonathan Gibbons <jjg3 at pobox.com> wrote:
> 
> > Without looking in detail at this specific proposal, I wonder if you considered the alternative to only store end positions in the subtypes of JCTree that actually "need" them. In other words, you only need store end positions in tree nodes that "end" in a lexical token and not in a child tree node. Effectively, you only need store the end position in tree nodes that would otherwise have entries in the EndPosTable.
> 
> Good question--I hadn't investigated that option. It seems do-able, perhaps with a shared interface for subtypes that needed end positions to simplify the handling of them.
> 
> What tradeoffs do you see here, would only declaring the field on trees that need it be mostly about saving memory?
> 
> Also is that unique to end positions? Or could javac potentially avoid storing start positions for nodes that don't start with a lexical token as well?
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3602921946
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251202/0d4fee58/attachment.htm>

From jjg3 at pobox.com  Tue Dec  2 16:41:56 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Tue, 02 Dec 2025 08:41:56 -0800
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <VXUtajCV74hrJw7F1DNU6Z3OosCQ1YDFD1KSsXT-GZg=.1fe8c181-20fa-4868-8602-98190877a7c6@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <639ae9cc-527a-40f5-88fb-a5ade5d48ea7@app.fastmail.com>
 <VXUtajCV74hrJw7F1DNU6Z3OosCQ1YDFD1KSsXT-GZg=.1fe8c181-20fa-4868-8602-98190877a7c6@github.com>
Message-ID: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>

I'm not sure a shared interface gets you anything significant, since you cannot inherit a shared field that way.

Instead, you could have a `setEndPos` on `JCTree` that is a no-op on subtypes that do not need it, and which sets a locally declared field on subtypes that do need it.

-- Jon

On Tue, Dec 2, 2025, at 8:30 AM, Liam Miller-Cushon wrote:
> Good question--I hadn't investigated that option. It seems do-able, perhaps with a shared interface for subtypes that needed end positions to simplify the handling of them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251202/88ae10e9/attachment-0001.htm>

From erikj at openjdk.org  Tue Dec  2 18:10:00 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 2 Dec 2025 18:10:00 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v9]
In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
Message-ID: <qf0LmFCI9lwig2IUpFrhKrSK2g18iXBbjfVux5S-agc=.7ebf0f12-9dcb-4d93-8c56-7af6c22f8bf4@github.com>

On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert changes to avoid conflict
>  - add 27 to the acceptable boot versions

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3531491706

From darcy at openjdk.org  Tue Dec  2 18:23:40 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Dec 2025 18:23:40 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26 [v2]
In-Reply-To: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
Message-ID: <Gsb9vsiADxi4rl0u1PaTUlfYIrxbHQ0xeRhnteaYGt4=.a9976b28-14d7-43f0-a4c4-ffb3fb8f9467@github.com>

> Include source-level comments about per-release language changes, or lack thereof.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28594/files
  - new: https://git.openjdk.org/jdk/pull/28594/files/5178cf5b..bec28d31

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

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

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

From darcy at openjdk.org  Tue Dec  2 18:23:41 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Dec 2025 18:23:41 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26 [v2]
In-Reply-To: <OYrKubJWIVtBfGshg1EaRlWoDQp5dHgy3XdrJlk-HSI=.6c7e66b8-cdd8-4b9b-ab74-c5fd1d0d6df7@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
 <OYrKubJWIVtBfGshg1EaRlWoDQp5dHgy3XdrJlk-HSI=.6c7e66b8-cdd8-4b9b-ab74-c5fd1d0d6df7@github.com>
Message-ID: <7yTAXs--5prhZt0AEKrWAiiK0_PnW2alJMe_nee37EQ=.51efaa4f-4744-4c23-a7d9-8bcb23c3f771@github.com>

On Tue, 2 Dec 2025 01:45:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 90:
> 
>> 88:      *      preview)
>> 89:      *  26: no changes (primitive Types in Patterns, instanceof, and
>> 90:      *      switch in second preview, module Import Declarations in fourth
> 
> 4th preview now, no module import changes

Good catch; fixed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28594#discussion_r2582336446

From darcy at openjdk.org  Tue Dec  2 20:03:18 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Dec 2025 20:03:18 GMT
Subject: RFR: 8372940: Update symbol data script references
In-Reply-To: <H3Huc-VxnpWptsUAU5RAHs5ORXaN36U3gO-ULB5wtuA=.50ff9d53-2182-459a-bee1-71250503013c@github.com>
References: <H3Huc-VxnpWptsUAU5RAHs5ORXaN36U3gO-ULB5wtuA=.50ff9d53-2182-459a-bee1-71250503013c@github.com>
Message-ID: <SpvGaM0O9y6t2CTT7XUb-IgUVQ2tXjHFBHJ8U33LG0k=.67d74cfc-2775-40ad-852f-d6f8f4285b19@github.com>

On Tue, 2 Dec 2025 14:05:51 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Update path to the generate symbols script, and expand the start of release doc.

Looks fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28606#pullrequestreview-3531898375

From nbenalla at openjdk.org  Tue Dec  2 20:54:33 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 20:54:33 GMT
Subject: Integrated: 8372939: Update JDK 26 spec URLs
In-Reply-To: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com>
References: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com>
Message-ID: <yiI3nzOXxNTyFEi6R0IeN83DWkGebSVBi_4ksnAsI1g=.7d29002a-c778-4b49-b1d3-acc5a0d64a8f@github.com>

On Tue, 2 Dec 2025 14:05:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Updating the JDK 26 JLS and JVMS links

This pull request has now been integrated.

Changeset: a2ad5ca9
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2ad5ca93ef82797ecf3141d00216ef639a9e92d
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8372939: Update JDK 26 spec URLs

Reviewed-by: liach

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

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

From nbenalla at openjdk.org  Tue Dec  2 20:55:30 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 20:55:30 GMT
Subject: Integrated: 8372940: Update symbol data script references
In-Reply-To: <H3Huc-VxnpWptsUAU5RAHs5ORXaN36U3gO-ULB5wtuA=.50ff9d53-2182-459a-bee1-71250503013c@github.com>
References: <H3Huc-VxnpWptsUAU5RAHs5ORXaN36U3gO-ULB5wtuA=.50ff9d53-2182-459a-bee1-71250503013c@github.com>
Message-ID: <y8FCy2l_0xgkTGOG8OEpfvUmWGB6DW0_3yX9svUyLCg=.0cbd36e6-c508-4959-bb1e-6633c415dd1d@github.com>

On Tue, 2 Dec 2025 14:05:51 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Update path to the generate symbols script, and expand the start of release doc.

This pull request has now been integrated.

Changeset: 0fe1ffdc
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0fe1ffdc485e742eb3937f9fb26d14d6a11a76c4
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8372940: Update symbol data script references

Reviewed-by: liach, darcy

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

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

From nbenalla at openjdk.org  Tue Dec  2 20:55:29 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 2 Dec 2025 20:55:29 GMT
Subject: Integrated: 8372937: Abbreviate list of supported releases
In-Reply-To: <VINQw0HIaIxthMlYhE-PxuCvifL9CV5qV1wcLEUkcb4=.393cfad4-1529-4eff-9dbe-30dea70572d1@github.com>
References: <VINQw0HIaIxthMlYhE-PxuCvifL9CV5qV1wcLEUkcb4=.393cfad4-1529-4eff-9dbe-30dea70572d1@github.com>
Message-ID: <TaHKF5-dhWvNpZCClQH98B3vre5FdKl28mZPw6aKJfc=.c1b2e85d-b820-427b-977d-a1e7ee745abd@github.com>

On Tue, 2 Dec 2025 14:05:16 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Abbreviating the list of supported released to be under 80 columns

This pull request has now been integrated.

Changeset: 8a28a764
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a28a76451b2bbde49c1c051cb66c784f9e3cdd2
Stats:     60 lines in 3 files changed: 41 ins; 8 del; 11 mod

8372937: Abbreviate list of supported releases

Reviewed-by: liach

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

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

From iris at openjdk.org  Tue Dec  2 21:27:38 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 2 Dec 2025 21:27:38 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26 [v2]
In-Reply-To: <Gsb9vsiADxi4rl0u1PaTUlfYIrxbHQ0xeRhnteaYGt4=.a9976b28-14d7-43f0-a4c4-ffb3fb8f9467@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
 <Gsb9vsiADxi4rl0u1PaTUlfYIrxbHQ0xeRhnteaYGt4=.a9976b28-14d7-43f0-a4c4-ffb3fb8f9467@github.com>
Message-ID: <VkixSyk7RcfPLX49iF8Ig5ecL1ozmtxDE6wItbJuaT4=.ca55ec19-1cde-42fa-a3e8-df1099f05c1c@github.com>

On Tue, 2 Dec 2025 18:23:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Include source-level comments about per-release language changes, or lack thereof.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

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

> 87:      *      third preview)
> 88:      *  26: no changes (primitive Types in Patterns, instanceof, and
> 89:      *      switch in second preview in fourth preview)

I think you want to drop the "in second preview".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28594#discussion_r2582822973

From darcy at openjdk.org  Tue Dec  2 22:31:44 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Dec 2025 22:31:44 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26 [v3]
In-Reply-To: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
Message-ID: <qI7HDEdOXH1m_GSjY77URMSav2Ld8veVGH8-OAEP14U=.cc26df3f-0675-4f1b-a101-cfc4b8fdc7fd@github.com>

> Include source-level comments about per-release language changes, or lack thereof.

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

  Respond to more review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28594/files
  - new: https://git.openjdk.org/jdk/pull/28594/files/bec28d31..cfa5e8d3

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

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

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

From darcy at openjdk.org  Tue Dec  2 22:31:46 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Dec 2025 22:31:46 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26 [v2]
In-Reply-To: <VkixSyk7RcfPLX49iF8Ig5ecL1ozmtxDE6wItbJuaT4=.ca55ec19-1cde-42fa-a3e8-df1099f05c1c@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
 <Gsb9vsiADxi4rl0u1PaTUlfYIrxbHQ0xeRhnteaYGt4=.a9976b28-14d7-43f0-a4c4-ffb3fb8f9467@github.com>
 <VkixSyk7RcfPLX49iF8Ig5ecL1ozmtxDE6wItbJuaT4=.ca55ec19-1cde-42fa-a3e8-df1099f05c1c@github.com>
Message-ID: <8OCVtHQlBPxUmi94h56E7-RAWUwqTpXj_aWIEB6WaTA=.f34a499d-58c9-452b-af68-1feb4f105df4@github.com>

On Tue, 2 Dec 2025 21:24:52 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 89:
> 
>> 87:      *      third preview)
>> 88:      *  26: no changes (primitive Types in Patterns, instanceof, and
>> 89:      *      switch in second preview in fourth preview)
> 
> I think you want to drop the "in second preview".

Whoops; meant to fix that the first time. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28594#discussion_r2582968981

From liach at openjdk.org  Tue Dec  2 23:15:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 23:15:44 GMT
Subject: RFR: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26 [v3]
In-Reply-To: <qI7HDEdOXH1m_GSjY77URMSav2Ld8veVGH8-OAEP14U=.cc26df3f-0675-4f1b-a101-cfc4b8fdc7fd@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
 <qI7HDEdOXH1m_GSjY77URMSav2Ld8veVGH8-OAEP14U=.cc26df3f-0675-4f1b-a101-cfc4b8fdc7fd@github.com>
Message-ID: <JjqntzEeg1CFsHzNUU1GQY4n3KEJEHnUFXZYfjDQlgc=.82118f11-c7bd-4bb0-b269-ec3c3389aee6@github.com>

On Tue, 2 Dec 2025 22:31:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Include source-level comments about per-release language changes, or lack thereof.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to more review feedback.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28594#pullrequestreview-3532379791

From darcy at openjdk.org  Wed Dec  3 00:30:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Dec 2025 00:30:51 GMT
Subject: Integrated: 8372850: Update comment in SourceVersion for language
 evolution history for changes in 26
In-Reply-To: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
References: <3Rd50CZ0jQ-z9mUjaKTdj5a6fXMZ4PMzme9iGJT-NnY=.e780f0f8-9d1c-424a-bf37-b3d83b20f7d2@github.com>
Message-ID: <2mKT6l5hm3h7kSngeLwzD-GPw_YdPjuYMQGpx4t0UNo=.ceab0f6d-53ef-4793-8ec0-2a3170a91d4f@github.com>

On Tue, 2 Dec 2025 00:59:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Include source-level comments about per-release language changes, or lack thereof.

This pull request has now been integrated.

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

8372850: Update comment in SourceVersion for language evolution history for changes in 26

Reviewed-by: liach

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

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

From darcy at openjdk.org  Wed Dec  3 01:34:19 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Dec 2025 01:34:19 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v9]
In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
Message-ID: <PB2FlF8ipTAvYXqR5h0hYp2gFUzn7YHccOJHzBBZB2g=.e87436fa-1aa0-4adc-b9f6-0cd0156de48d@github.com>

On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert changes to avoid conflict
>  - add 27 to the acceptable boot versions

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

> 481:      */
> 482:     RELEASE_26,
> 483: 

At the top of the file where the per-release changes are all listed, please add a

"27: tbd"

entry after syncing in the changes from mainline which add an entry for JDK 26. (Also, as part of the sync please fix the "in in" stutter typo in the 26 entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2583333814

From iris at openjdk.org  Wed Dec  3 02:12:00 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 3 Dec 2025 02:12:00 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v9]
In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
Message-ID: <HOFyDJfNUVlVJmy_aisXYSM_IgCunAPEE1rHfDoJh1w=.9092f1f6-ad22-4c24-9f95-2e7b23cf7a4e@github.com>

On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert changes to avoid conflict
>  - add 27 to the acceptable boot versions

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3532863059

From dholmes at openjdk.org  Wed Dec  3 04:12:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Dec 2025 04:12:59 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v9]
In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
Message-ID: <uVFT552TTr8htWbrMjQhTjeV56we-lmJTt2_xNfcn5U=.32e30ee2-8e5e-4877-b23e-d69dffc1da1e@github.com>

On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert changes to avoid conflict
>  - add 27 to the acceptable boot versions

Hotspot changes trivially fine.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3533103238

From cushon at openjdk.org  Wed Dec  3 09:47:11 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 3 Dec 2025 09:47:11 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>
Message-ID: <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>

On Tue, 2 Dec 2025 16:43:43 GMT, Jonathan Gibbons <jjg3 at pobox.com> wrote:

> I'm not sure a shared interface gets you anything significant, since you cannot inherit a shared field that way.

Partly I was thinking the interface could make helpers that set end positions type safe, e.g. for the `storeEnd` method in `JavacParser` if we could write something like:


protected <T extends JCTree & JCTree.HasEndPos> T storeEnd(T tree, int endpos) { ... }


But there are other places that store end positions on a `JCTree` instead of a specific subtype, so that approach only goes so far.

> Instead, you could have a `setEndPos` on `JCTree` that is a no-op on subtypes that do not need it, and which sets a locally declared field on subtypes that do need it.

I think the set of trees that end positions are stored for is: `JCAnnotation`, `JCArrayAccess`, `JCArrayTypeTree`, `JCAssert`, `JCAssign`, `JCBinary`, `JCBindingPattern`, `JCBlock`, `JCBreak`, `JCCase`, `JCClassDecl`, `JCConstantCaseLabel`, `JCContinue`, `JCDefaultCaseLabel`, `JCDoWhileLoop`, `JCExports`, `JCExpressionStatement`, `JCFieldAccess`, `JCIdent`, `JCIf`, `JCImport`, `JCLambda`, `JCLiteral`, `JCMemberReference`, `JCMethodDecl`, `JCMethodInvocation`, `JCModifiers`, `JCModuleDecl`, `JCNewArray`, `JCNewClass`, `JCOpens`, `JCPackageDecl`, `JCParens`, `JCPatternCaseLabel`, `JCPrimitiveTypeTree`, `JCProvides`, `JCRequires`, `JCReturn`, `JCSkip`, `JCSwitch`, `JCThrow`, `JCTypeApply`, `JCTypeParameter`, `JCTypeUnion`, `JCUnary`, `JCUses`, `JCVariableDecl`, `JCWildcard`, `TypeBoundKind`

I got that by instrumenting `SimpleEndPosTable` and building the JDK, it's possible it missed a few.

And then we could add the following snippet to all of those classes:


    private int endpos;

    public int getEndPos() {
        return endpos;
    }

    public void setEndPos(int endpso) {
        this.endpos = endpos;
    }


My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3605955451

From nbenalla at openjdk.org  Wed Dec  3 10:18:16 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 3 Dec 2025 10:18:16 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v10]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <1NKVGfCOckDGbbnQKtz0LfvPFhh5SjyUauWyvbsw2yM=.ad2c7571-4ab3-4b1f-b8d7-5ab0814635c7@github.com>

> Get JDK 27 underway.

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

 - Merge branch 'master' into start-of-release-27
 - revert changes to avoid conflict
 - add 27 to the acceptable boot versions
 - Merge branch 'master' into start-of-release-27
 - problem list failing test
 - Merge branch 'master' into start-of-release-27
 - expand start of release documentation
 - Merge branch 'master' into start-of-release-27
 - Changes required for hard 80 character line limit
 - Update --release 26 symbol information for JDK 26 build 25
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
 - ... and 11 more: https://git.openjdk.org/jdk/compare/443e5643...8bbe15f2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/1237304b..8bbe15f2

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

  Stats: 3514 lines in 111 files changed: 2399 ins; 621 del; 494 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From nbenalla at openjdk.org  Wed Dec  3 10:31:18 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 3 Dec 2025 10:31:18 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v11]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <VEfwA8h71F0Yj-pce0H_LpgCjsd_hOUh-0yHrBWdRro=.969b7485-1d48-4b88-be7e-fa61d0dedb27@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - fix jls 27 link
 - fix typo and add entry for 27

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/8bbe15f2..4bf97a8a

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

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

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

From nbenalla at openjdk.org  Wed Dec  3 10:31:24 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 3 Dec 2025 10:31:24 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v7]
In-Reply-To: <J-DRBORFbEdZCZxrBgltGWUdxo1c56HiBX1ANfPwOLM=.b1a265bb-eb16-4e86-95d1-b583be1e2fbc@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <bLG3SPRjRvkggZqWDJsdazYICygw-ubJQBKkFcQyF8M=.4e98d9d0-f45f-4e86-9c9e-5b394a1c8320@github.com>
 <J-DRBORFbEdZCZxrBgltGWUdxo1c56HiBX1ANfPwOLM=.b1a265bb-eb16-4e86-95d1-b583be1e2fbc@github.com>
Message-ID: <gl_9LNo8HNnpVvjaj0oxC0gOFsk9pyF2fB269B8b3g4=.09e04e1c-d0e1-49bb-8230-01ed69d14ddb@github.com>

On Mon, 1 Dec 2025 19:46:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - problem list failing test
>>  - Merge branch 'master' into start-of-release-27
>>  - expand start of release documentation
>>  - Merge branch 'master' into start-of-release-27
>>  - Changes required for hard 80 character line limit
>>  - Update --release 26 symbol information for JDK 26 build 25
>>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>>  - revert MAX_COLUMNS to 80
>>  - Update LATEST_MAJOR_VERSION in Versions.java
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/eae9329d...e5214614
>
> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 394:
> 
>> 392:      *
>> 393:      * @see <a
>> 394:      * href="https://docs.oracle.com/en/java/javase/27/docs/specs/jvms/index.html">
> 
> Presumably the analagous URL update should be done here as in ClassFileFormatVersion for the JLS instead of the JVMS.

Fixed in https://github.com/openjdk/jdk/pull/28130/commits/4bf97a8ab5a134ab592f7a84b7e1dc130d04a845; Good catch!

> src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1368:
> 
>> 1366:     }
>> 1367: 
>> 1368:     private static String formatAbbreviatedList(Collection<String> values) {
> 
> I think changing the policy here is okay, but it should be better documented in comments here.
> 
> Additionally, it assume there will be a dense collection of supported values between the 4 th and (n-3) rd. That is currently the de facto policy, but is not ironclad. This assumption should also be documented.

Extracted and fixed in a separate issue  https://github.com/openjdk/jdk/commit/8a28a76451b2bbde49c1c051cb66c784f9e3cdd2

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584514802
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584513205

From nbenalla at openjdk.org  Wed Dec  3 10:31:27 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 3 Dec 2025 10:31:27 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v9]
In-Reply-To: <PB2FlF8ipTAvYXqR5h0hYp2gFUzn7YHccOJHzBBZB2g=.e87436fa-1aa0-4adc-b9f6-0cd0156de48d@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com>
 <PB2FlF8ipTAvYXqR5h0hYp2gFUzn7YHccOJHzBBZB2g=.e87436fa-1aa0-4adc-b9f6-0cd0156de48d@github.com>
Message-ID: <RIIVR3QX0CUP-IsjlAQwXMCDMTIeWLgwrft9PrW47BU=.ba397743-6be0-45dc-86e3-b8206808674e@github.com>

On Wed, 3 Dec 2025 01:32:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert changes to avoid conflict
>>  - add 27 to the acceptable boot versions
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 483:
> 
>> 481:      */
>> 482:     RELEASE_26,
>> 483: 
> 
> At the top of the file where the per-release changes are all listed, please add a
> 
> "27: tbd"
> 
> entry after syncing in the changes from mainline which add an entry for JDK 26. (Also, as part of the sync please fix the "in in" stutter typo in the 26 entry.

Fixed in https://github.com/openjdk/jdk/pull/28130/commits/4b14a7593c9cbc6f67d400e823d47d23e304d564

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584507508

From nbenalla at openjdk.org  Wed Dec  3 15:48:23 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 3 Dec 2025 15:48:23 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v12]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <T5_OUi395oZKXoNGNoGTMlRZA2pBdcyLnaTl_lo8e_s=.2bcae357-e31c-4a53-bfe1-8c7e949e94e0@github.com>

> Get JDK 27 underway.

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

 - Merge branch 'master' into start-of-release-27
 - fix jls 27 link
 - fix typo and add entry for 27
 - Merge branch 'master' into start-of-release-27
 - revert changes to avoid conflict
 - add 27 to the acceptable boot versions
 - Merge branch 'master' into start-of-release-27
 - problem list failing test
 - Merge branch 'master' into start-of-release-27
 - expand start of release documentation
 - ... and 14 more: https://git.openjdk.org/jdk/compare/0351ed87...444cc1c8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/4bf97a8a..444cc1c8

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

  Stats: 819 lines in 34 files changed: 424 ins; 271 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From darcy at openjdk.org  Wed Dec  3 16:36:16 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Dec 2025 16:36:16 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v12]
In-Reply-To: <T5_OUi395oZKXoNGNoGTMlRZA2pBdcyLnaTl_lo8e_s=.2bcae357-e31c-4a53-bfe1-8c7e949e94e0@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <T5_OUi395oZKXoNGNoGTMlRZA2pBdcyLnaTl_lo8e_s=.2bcae357-e31c-4a53-bfe1-8c7e949e94e0@github.com>
Message-ID: <14VgrwjksW2UO1LtpHGyX6sTjHbaplRnV7ZgmcyiRIQ=.b06ebf9a-2f95-4e95-89b9-981562ceef06@github.com>

On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Merge branch 'master' into start-of-release-27
>  - fix jls 27 link
>  - fix typo and add entry for 27
>  - Merge branch 'master' into start-of-release-27
>  - revert changes to avoid conflict
>  - add 27 to the acceptable boot versions
>  - Merge branch 'master' into start-of-release-27
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/659ebef2...444cc1c8

Marked as reviewed by darcy (Reviewer).

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535940924
PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535946905

From liach at openjdk.org  Wed Dec  3 16:44:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 16:44:15 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v12]
In-Reply-To: <T5_OUi395oZKXoNGNoGTMlRZA2pBdcyLnaTl_lo8e_s=.2bcae357-e31c-4a53-bfe1-8c7e949e94e0@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <T5_OUi395oZKXoNGNoGTMlRZA2pBdcyLnaTl_lo8e_s=.2bcae357-e31c-4a53-bfe1-8c7e949e94e0@github.com>
Message-ID: <jeMyNRKycDQpyetKZDI3mYBZCVAVAbDRazZgbnS8XM8=.94171197-a44e-41a0-baec-4df8b32d7f24@github.com>

On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Merge branch 'master' into start-of-release-27
>  - fix jls 27 link
>  - fix typo and add entry for 27
>  - Merge branch 'master' into start-of-release-27
>  - revert changes to avoid conflict
>  - add 27 to the acceptable boot versions
>  - Merge branch 'master' into start-of-release-27
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/c61f404d...444cc1c8

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535980615

From iris at openjdk.org  Wed Dec  3 16:56:43 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 3 Dec 2025 16:56:43 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v12]
In-Reply-To: <T5_OUi395oZKXoNGNoGTMlRZA2pBdcyLnaTl_lo8e_s=.2bcae357-e31c-4a53-bfe1-8c7e949e94e0@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <T5_OUi395oZKXoNGNoGTMlRZA2pBdcyLnaTl_lo8e_s=.2bcae357-e31c-4a53-bfe1-8c7e949e94e0@github.com>
Message-ID: <r3dTfdevSf3XA7v3YfwTxAS7ZuH4921n8POIDieg2eA=.cc7aab50-6fb4-459e-a593-5e4e809e414b@github.com>

On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Merge branch 'master' into start-of-release-27
>  - fix jls 27 link
>  - fix typo and add entry for 27
>  - Merge branch 'master' into start-of-release-27
>  - revert changes to avoid conflict
>  - add 27 to the acceptable boot versions
>  - Merge branch 'master' into start-of-release-27
>  - problem list failing test
>  - Merge branch 'master' into start-of-release-27
>  - expand start of release documentation
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/afcc5cbc...444cc1c8

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3536041848

From mcimadamore at openjdk.org  Wed Dec  3 19:13:30 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 Dec 2025 19:13:30 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>
 <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>
Message-ID: <NOm4G2DOhIAfef9ss_UfLzQoq9lRFTBAoaXPL1YXXX4=.4fdb6a1f-814f-48b9-8099-8e51bb8167b0@github.com>

On Wed, 3 Dec 2025 09:44:44 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> 
> My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it.

I tend to agree with your assessment. Having code duplication is kind of bad, unless we can somehow "common" the code -- and that's is probably possible, but not straightforward due the JCStatement vs. JCExpression split (and also JCFunctionalExpression).

Also, it's hard to estimate which trees might need this... for instance the trees you show in your analysis don't include some patterns (e.g. record patterns), but that's just because probably there's no record pattern in the JDK, not because the end pos is not useful there.

If we exclude JCSkip and maybe LetExpr (as that's only used by the backend), I'm not sure there's much stuff that actually doesn't require an end position? Perhaps with some keywords like `break`, `continue`, ... we might be able to infer the end pos (given it's just start pos + number of chars in the keyword). But not sure how much we are willing to bend the code for special cases like these?

One more interesting experiment could be to try to enable end position in all trees, then run the JDK build and compare with mainline, to see what the memory usage looks like (maybe enabling `-verbose:gc` and looking where it peaks).

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

PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3608408811

From jjg3 at pobox.com  Wed Dec  3 19:54:34 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Wed, 03 Dec 2025 11:54:34 -0800
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>
 <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>
Message-ID: <d618c806-36f1-4057-90da-d0f1564fbca3@app.fastmail.com>



On Wed, Dec 3, 2025, at 1:47 AM, Liam Miller-Cushon wrote:
> My feeling is that perhaps it's worth the extra memory to not have to duplicate that code for all of those `JCTree`s, and also to avoid the risk of trying to store end positions on trees that don't support it. But I am open to making those changes if there's a preference for it.

Yeah, you've done the analysis I think I would have done. And, it does seem l;ke there has been a fundamental shift in the desire/need to keep end positions around since times past.

Simplicity says to go with a field in every JCTree these days. A more informed opinion would probably require more detailed analysis. I note that you can offset the space of the endPos fields that are not strictly required against the savings of the EndPosTable itself.

I also wonder, just for curiousity sake, whether this would help with some of the (uncommon) problem cases in the existing situation, where the endPos of a non-terminal end element might not be the endPos of the entire tree -- IIRC, the issue was with C-style array declarations.

The one test I would suggest to add (if necessary) in the "tree position" set of tests would be to verify that the new field is set in all applicable cases, with maybe some thought being given to synthetic nodes.

-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251203/1a697c9d/attachment.htm>

From jjg3 at pobox.com  Wed Dec  3 19:56:45 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Wed, 03 Dec 2025 11:56:45 -0800
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <NOm4G2DOhIAfef9ss_UfLzQoq9lRFTBAoaXPL1YXXX4=.4fdb6a1f-814f-48b9-8099-8e51bb8167b0@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>
 <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>
 <NOm4G2DOhIAfef9ss_UfLzQoq9lRFTBAoaXPL1YXXX4=.4fdb6a1f-814f-48b9-8099-8e51bb8167b0@github.com>
Message-ID: <2ad5ebc7-9d1a-4eb1-affe-ee04a1db9919@app.fastmail.com>



On Wed, Dec 3, 2025, at 11:13 AM, Maurizio Cimadamore wrote:
> Perhaps with some keywords like `break`, `continue`, ... we might be able to infer the end pos (given it's just start pos + number of chars in the keyword). But not sure how much we are willing to bend the code for special cases like these?

Doesn't the endPos records the position of the semicolon, not the end of the keyword?

-- Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251203/124197b6/attachment-0001.htm>

From jjg3 at pobox.com  Wed Dec  3 20:02:46 2025
From: jjg3 at pobox.com (Jonathan Gibbons)
Date: Wed, 03 Dec 2025 12:02:46 -0800
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <2ad5ebc7-9d1a-4eb1-affe-ee04a1db9919@app.fastmail.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>
 <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>
 <NOm4G2DOhIAfef9ss_UfLzQoq9lRFTBAoaXPL1YXXX4=.4fdb6a1f-814f-48b9-8099-8e51bb8167b0@github.com>
 <2ad5ebc7-9d1a-4eb1-affe-ee04a1db9919@app.fastmail.com>
Message-ID: <7eb48261-03f9-448f-9124-496ad2e06e9b@app.fastmail.com>



On Wed, Dec 3, 2025, at 11:56 AM, Jonathan Gibbons wrote:
> 
> 
> On Wed, Dec 3, 2025, at 11:13 AM, Maurizio Cimadamore wrote:
>> Perhaps with some keywords like `break`, `continue`, ... we might be able to infer the end pos (given it's just start pos + number of chars in the keyword). But not sure how much we are willing to bend the code for special cases like these?
> 
> Doesn't the endPos records the position of the semicolon, not the end of the keyword?
> 
> -- Jon

A useful heuristic is to check the `visit...` methods in `JCPretty`.   If there is a call to `print(String)` or `print(char)` before the `} catch (IOException` then the node should have an endPos.  In other words, an endPos is required for all nodes that end in a specific lexical token.

For example, compare this from `visitLambda`


    printExpr(tree.body);
} catch (IOException e) {

and this from `visitParens`


    print(')');
} catch (IOException e) {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251203/d9402e9d/attachment.htm>

From cushon at openjdk.org  Thu Dec  4 14:09:26 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 4 Dec 2025 14:09:26 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree
In-Reply-To: <NOm4G2DOhIAfef9ss_UfLzQoq9lRFTBAoaXPL1YXXX4=.4fdb6a1f-814f-48b9-8099-8e51bb8167b0@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <4b6f2678-9e0c-44fe-88f0-239c1aee290d@app.fastmail.com>
 <iHwOHY8If9iJpU-5-K18Oypb15LBDPKKKtcp_ZeRj1g=.130f0a64-27b2-452c-8b5b-04a31c17af06@github.com>
 <NOm4G2DOhIAfef9ss_UfLzQoq9lRFTBAoaXPL1YXXX4=.4fdb6a1f-814f-48b9-8099-8e51bb8167b0@github.com>
Message-ID: <BZdNRwkEqAjYSyk1PG2RLaWjzC1TVU9fKY8ageV0jCg=.6028c618-087c-4174-a45d-d5b80f57d4e6@github.com>

On Wed, 3 Dec 2025 19:11:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> One more interesting experiment could be to try to enable end position in all trees, then run the JDK build and compare with mainline, to see what the memory usage looks like (maybe enabling -verbose:gc and looking where it peaks).

I attempted this experiment. I ran configure with `--disable-javac-server` and added `-verbose:gc` to the javac args with the change below. Then I made trivial edits to `src/java.base/share/classes/java/lang/String.java` and rebuilt.

With this PR the output was something like


Compiling up to 3385 files for java.base
[0.003s][info][gc] Using G1
[0.239s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 34M->4M(64M) 2.704ms
[0.415s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 31M->10M(64M) 4.419ms
[0.531s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 37M->16M(64M) 4.672ms
[0.568s][info][gc] GC(3) Pause Young (Concurrent Start) (Metadata GC Threshold) 24M->18M(64M) 2.825ms
[0.568s][info][gc] GC(4) Concurrent Mark Cycle
[0.573s][info][gc] GC(4) Pause Remark 19M->19M(64M) 1.349ms
[0.575s][info][gc] GC(4) Pause Cleanup 19M->19M(64M) 0.007ms
[0.575s][info][gc] GC(4) Concurrent Mark Cycle 6.227ms


And without these changes, it looks like it peaked at 36M instead of 37M


[info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 36M->16M(64M)


---


diff --git a/make/common/JavaCompilation.gmk b/make/common/JavaCompilation.gmk
index 33f5d10535a..e9a800bce5a 100644
--- a/make/common/JavaCompilation.gmk
+++ b/make/common/JavaCompilation.gmk
@@ -254,7 +254,7 @@ define SetupJavaCompilationBody
           javacserver.Main --conf=$$($1_JAVAC_SERVER_CONFIG)
     else
       # No javac server
-      $1_JAVAC := $$(INTERIM_LANGTOOLS_ARGS) -m jdk.compiler.interim/com.sun.tools.javac.Main
+      $1_JAVAC := -verbose:gc $$(INTERIM_LANGTOOLS_ARGS) -m jdk.compiler.interim/com.sun.tools.javac.Main

       ifeq ($$($1_SMALL_JAVA), true)
         $1_JAVAC_CMD := $$(JAVA_SMALL) $$($1_JAVA_FLAGS) $$($1_JAVAC)

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

PR Comment: https://git.openjdk.org/jdk/pull/28610#issuecomment-3612431977

From jlahoda at openjdk.org  Thu Dec  4 14:44:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Dec 2025 14:44:08 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v8]
In-Reply-To: <QTpAR7CBk3PzNvKyN15w8bRHDc1lhTHFaz90UZvWJ2U=.b7a82dc0-821f-4c39-a20c-3bc73ef69eeb@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <kXKNgGzy6vQ-JIAua1t7GLTNuUaZ_h4sNzoQD8Mr930=.09499f7a-d9ea-4bc4-b986-7a17ab1993b7@github.com>
 <8dZbRs3s5I3mI8Iwlq1NW30PJEw8huzJE9zzlCoQrS4=.5e78a559-b585-4eee-b02f-087e586b0f5c@github.com>
 <QTpAR7CBk3PzNvKyN15w8bRHDc1lhTHFaz90UZvWJ2U=.b7a82dc0-821f-4c39-a20c-3bc73ef69eeb@github.com>
Message-ID: <VIAVfI_Aoabvwc0AhdEEu7N03uf9cjt8nMlwDCwzMVw=.21768857-757d-402d-85f1-beb3463ce4cf@github.com>

On Wed, 19 Nov 2025 16:15:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 832:
>> 
>>> 830:                                                     Set.of(defaultPattern));
>>> 831:         } catch (TimeoutException ex) {
>>> 832:             return ex.missingPatterns != null ? ex.missingPatterns : Set.of();
>> 
>> Instead of a timeout, I wonder if you could instead cut the recursion at a specific threshold. It seems to me that recursing more will provide more precision _at the nested level_, so it's a trade off between when do we want to stop. 
>> 
>> Overload resolution provides some kind of precedent:
>> 
>> 
>> error: incompatible types: String cannot be converted to int
>>       m("Hello");
>>         ^
>> Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
>> 1 error
>> 
>> 
>> (We "compress" the diagnostic whenever we can somehow figure out if an overload is "better" than the others). Then if you provide the option, you get the full thing:
>> 
>> 
>> error: no suitable method found for m(String)
>>       m("Hello");
>>       ^
>>     method Test.m() is not applicable
>>       (actual and formal argument lists differ in length)
>>     method Test.m(int) is not applicable
>>       (argument mismatch; String cannot be converted to int)
>>     method Test.m(int,int) is not applicable
>>       (actual and formal argument lists differ in length)
>>     method Test.m(int,int,int) is not applicable
>>       (actual and formal argument lists differ in length)
>>     method Test.m(int,int,int,int) is not applicable
>>       (actual and formal argument lists differ in length)
>>     method Test.m(int,int,int,int,int) is not applicable
>>       (actual and formal argument lists differ in length)
>>     method Test.m(int,int,int,int,int,int) is not applicable
>>       (actual and formal argument lists differ in length)
>> 
>> 
>> But, also, maybe putting an upper bound on the recursion, no matter what, might be a good idea?
>
> While I agree that having a timeout in weird/non-standard in javac, I believe it is the first time when we have a process that a) can run for a very long time; b) is not required for correctness. In all other cases I can recall, if some process is slow (including e.g. verifying exhaustiveness), then it is required for correctness. And so we cannot skip it based on criteria like time.
> 
> The timeout here provides a way to say how much real-world time is the user willing to invest to get the outcome - if more time is invested, more detailed missing patterns may possibly be computed. It is a somewhat weird approach for javac, but it is a limit that (I think) the user and javac can agree on.
> 
> We could introduce a limit on e.g. the depth to which we expand, but adding one level of nesting may affect performance significantly or almost not at all, depending on e.g. the record type form/shape.
> 
> E.g. having a record with many components, where each component is a sealed type with many permitted subtypes, one level of nesting may lead to a high number of newly generated patterns possibly taking a lot of time to go through them. But having a record that has a single component that is not a sealed type should only generate one pattern, and so have minimal impact.

As an example, if I have:

package exhaustiveness.test;

public class Deep {

    public record Box0(Box1 v) {}
    public record Box1(Box2 v) {}
    public record Box2(Box3 v) {}
    public record Box3(Box4 v) {}
    public record Box4(Box5 v) {}
    public record Box5(Box6 v) {}
    public record Box6(Box7 v) {}
    public record Box7(Box8 v) {}
    public record Box8(Box9 v) {}
    public record Box9(I v) {}
    public sealed interface I {}
    public final class C1 implements I {}
    public final class C2 implements I {}

    public int test(Box0 box0) {
        return switch (box0) {
            case Box0(Box1(Box2(Box3(Box4(Box5(Box6(Box7(Box8(Box9(C1 _)))))))))) -> 0;
        };
    }
}


this runs very quickly on my laptop <1s in total, despite recursing quite deep (and it finds the one missing pattern). If I have something like:

package exhaustiveness.test;

public class Shallow {

    public sealed interface Base {}

    public sealed interface I0 extends Base {}
    public non-sealed interface L0 extends Base {}

    public non-sealed interface L1 extends I0 {}
    public non-sealed interface L2 extends I0 {}
    public non-sealed interface L3 extends I0 {}
//    public non-sealed interface L4 extends I0 {}
//    public non-sealed interface L5 extends I0 {}
//    public non-sealed interface L6 extends I0 {}
//    public non-sealed interface L7 extends I0 {}
//    public non-sealed interface L8 extends I0 {}
//    public non-sealed interface L9 extends I0 {}
    public record Data(Base b1, Base b2, Base b3, Base b4) {}
    public int test(Data d) {
        return switch (d) {
            case Data(I0 _, I0 _, I0 _, I0 _) -> 0;
            case Data(L0 _, L0 _, L0 _, L0 _) -> 0;
            case Data(I0 _,    _,    _,    _) -> 0;
        };
    }
}


the current run time on my laptop is ~25s; if I un-comment L4, the time is ~2m15s. Also, in this case it is relatively difficult to reduce details, as if the record pattern is not expanded, the less-detailed version is simply `Data _`.

So, while there may be a way to estimate complexity, it depends on many factors - the depth, the number of sealed types, but also the user-written patterns (as those may make exhaustiveness computation faster or slower). And, to me, it feels like a heuristic to the real factor, which is what duration can be reasonably spent by this computation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2589353598

From nbenalla at openjdk.org  Thu Dec  4 17:06:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 4 Dec 2025 17:06:54 GMT
Subject: Integrated: 8370890: Start of release updates for JDK 27
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <u8hqx2Pa_b8wSp8PHgcy8Tpb_tV7Nsvx7UIoIHNYQOc=.dc41d4f1-d85f-4d5f-90bf-ec9528030ca7@github.com>

On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 27 underway.

This pull request has now been integrated.

Changeset: c55287d1
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c55287d197ef024033f8dfbb5a365cb091bc67fb
Stats:     1233 lines in 50 files changed: 1157 ins; 0 del; 76 mod

8370890: Start of release updates for JDK 27
8370893: Add SourceVersion.RELEASE_27
8370894: Add source 27 and target 27 to javac

Reviewed-by: darcy, iris, liach, erikj, dholmes

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

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

From duke at openjdk.org  Thu Dec  4 22:24:44 2025
From: duke at openjdk.org (David Alayachew)
Date: Thu, 4 Dec 2025 22:24:44 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v8]
In-Reply-To: <VIAVfI_Aoabvwc0AhdEEu7N03uf9cjt8nMlwDCwzMVw=.21768857-757d-402d-85f1-beb3463ce4cf@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <kXKNgGzy6vQ-JIAua1t7GLTNuUaZ_h4sNzoQD8Mr930=.09499f7a-d9ea-4bc4-b986-7a17ab1993b7@github.com>
 <8dZbRs3s5I3mI8Iwlq1NW30PJEw8huzJE9zzlCoQrS4=.5e78a559-b585-4eee-b02f-087e586b0f5c@github.com>
 <QTpAR7CBk3PzNvKyN15w8bRHDc1lhTHFaz90UZvWJ2U=.b7a82dc0-821f-4c39-a20c-3bc73ef69eeb@github.com>
 <VIAVfI_Aoabvwc0AhdEEu7N03uf9cjt8nMlwDCwzMVw=.21768857-757d-402d-85f1-beb3463ce4cf@github.com>
Message-ID: <gARIIoYnZymMj9LadJj2lcDVhHbT2Mg-pTg9HlddhH8=.de19decc-cd5a-47ce-87c2-60dd847672f5@github.com>

On Thu, 4 Dec 2025 14:40:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> While I agree that having a timeout in weird/non-standard in javac, I believe it is the first time when we have a process that a) can run for a very long time; b) is not required for correctness. In all other cases I can recall, if some process is slow (including e.g. verifying exhaustiveness), then it is required for correctness. And so we cannot skip it based on criteria like time.
>> 
>> The timeout here provides a way to say how much real-world time is the user willing to invest to get the outcome - if more time is invested, more detailed missing patterns may possibly be computed. It is a somewhat weird approach for javac, but it is a limit that (I think) the user and javac can agree on.
>> 
>> We could introduce a limit on e.g. the depth to which we expand, but adding one level of nesting may affect performance significantly or almost not at all, depending on e.g. the record type form/shape.
>> 
>> E.g. having a record with many components, where each component is a sealed type with many permitted subtypes, one level of nesting may lead to a high number of newly generated patterns possibly taking a lot of time to go through them. But having a record that has a single component that is not a sealed type should only generate one pattern, and so have minimal impact.
>
> As an example, if I have:
> 
> package exhaustiveness.test;
> 
> public class Deep {
> 
>     public record Box0(Box1 v) {}
>     public record Box1(Box2 v) {}
>     public record Box2(Box3 v) {}
>     public record Box3(Box4 v) {}
>     public record Box4(Box5 v) {}
>     public record Box5(Box6 v) {}
>     public record Box6(Box7 v) {}
>     public record Box7(Box8 v) {}
>     public record Box8(Box9 v) {}
>     public record Box9(I v) {}
>     public sealed interface I {}
>     public final class C1 implements I {}
>     public final class C2 implements I {}
> 
>     public int test(Box0 box0) {
>         return switch (box0) {
>             case Box0(Box1(Box2(Box3(Box4(Box5(Box6(Box7(Box8(Box9(C1 _)))))))))) -> 0;
>         };
>     }
> }
> 
> 
> this runs very quickly on my laptop <1s in total, despite recursing quite deep (and it finds the one missing pattern). If I have something like:
> 
> package exhaustiveness.test;
> 
> public class Shallow {
> 
>     public sealed interface Base {}
> 
>     public sealed interface I0 extends Base {}
>     public non-sealed interface L0 extends Base {}
> 
>     public non-sealed interface L1 extends I0 {}
>     public non-sealed interface L2 extends I0 {}
>     public non-sealed interface L3 extends I0 {}
> //    public non-sealed interface L4 extends I0 {}
> //    public non-sealed interface L5 extends I0 {}
> //    public non-sealed interface L6 extends I0 {}
> //    public non-sealed interface L7 extends I0 {}
> //    public non-sealed interface L8 extends I0 {}
> //    public non-sealed interface L9 extends I0 {}
>     public record Data(Base b1, Base b2, Base b3, Base b4) {}
>     public int test(Data d) {
>         return switch (d) {
>             case Data(I0 _, I0 _, I0 _, I0 _) -> 0;
>             case Data(L0 _, L0 _, L0 _, L0 _) -> 0;
>             case Data(I0 _,    _,    _,    _) -> 0;
>         };
>     }
> }
> 
> 
> the current run time on my laptop is ~25s; if I un-comment L4, the time is ~2m15s. Also, in this case it is relatively difficult to reduce details, as if the record pattern is not expanded, the less-detailed version is simply `Data _`.
> 
> So, while there may be a way to estimate complexity, it depends on many factors - the depth, the number of sealed types, but also the user-written patterns (as those may make exhaustiveness computation faster or slower). And, to me, it feels like a heuristic to the real factor, which is what duration can be reasonably spent by this computation.

Hello. I have multiple very deep and wide real-world hierarchies that I could run this against as a simple test. They mix sealed interfaces, enums, and records. In case we want to see which commandline option is a better fit. For example, one project in particular that very much needed this example generator went up to about L6, but only 3 Data slots, and not quite as wide. I have multiple that are ready to test right now. The data might be useful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2590781125

From jlahoda at openjdk.org  Fri Dec  5 16:39:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Dec 2025 16:39:46 GMT
Subject: RFR: 8373094: javac may fail because of unattributed break in a loop
Message-ID: <8mqMkx4hXxKTVX-vsNJQpqcXgizmUeQtKjLRlprTSlM=.7809c9ad-5ca3-4cc8-b4ab-659e4ad7a730@github.com>

Consider a case like this:

package test;
public class Intermediate<T> extends Base<T> {}

package test;
public class Base<T> {
    public void t(Missing<T> m) {}
}
package test;
public class Missing<T> {}

this is compiled, and then `Missing` is deleted. Then a test file is compiled with the above classes on the classpath:

$ cat src/test/Test.java 
package test;
public class Test extends Intermediate<String> {
    private void test() {
        while (true) { break; }
    }
}
$ javac -XDdev -XDshould-stop.at=FLOW -d classes -classpath classes src/test/Test.java
src/test/Test.java:2: error: cannot access Missing
public class Test extends Intermediate<String> {
       ^
  class file for test.Missing not found
1 error
An exception has occurred in the compiler (25.0.1). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
        at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.clearPendingExits(Flow.java:631)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:619)
...


The reason is that the `CompletionFailure` will be thrown from `chk.checkCompatibleSupertypes(tree.pos(), c.type);`, and since that's before attributing the method bodies, the method bodies will remain blank. And hence the `break` will have no target set, and `Flow` will fail on it.

I spent some time trying to figure out if we could improve handling on `CompletionFailure`s more generally, so that we would not need to catch them on more-or-less arbitrary places. But everything I was able to do so far didn't really improve the situation. So the proposal herein is to catch and handle the `CompletionFailure` on some place.

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

Commit messages:
 - Improving test.
 - 8373094: javac may fail because of unattributed break in a loop

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

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

From vromero at openjdk.org  Fri Dec  5 23:21:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 Dec 2025 23:21:54 GMT
Subject: RFR: 8373094: javac may fail because of unattributed break in a
 loop
In-Reply-To: <8mqMkx4hXxKTVX-vsNJQpqcXgizmUeQtKjLRlprTSlM=.7809c9ad-5ca3-4cc8-b4ab-659e4ad7a730@github.com>
References: <8mqMkx4hXxKTVX-vsNJQpqcXgizmUeQtKjLRlprTSlM=.7809c9ad-5ca3-4cc8-b4ab-659e4ad7a730@github.com>
Message-ID: <-rRRxliEdaPtsB8G-UUb2t9kD5mz4lJ2C1uOQfPVpQw=.a1ccc26d-a609-4a36-be1d-f0ff62f8682d@github.com>

On Fri, 5 Dec 2025 16:32:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a case like this:
> 
> package test;
> public class Intermediate<T> extends Base<T> {}
> 
> package test;
> public class Base<T> {
>     public void t(Missing<T> m) {}
> }
> package test;
> public class Missing<T> {}
> 
> this is compiled, and then `Missing` is deleted. Then a test file is compiled with the above classes on the classpath:
> 
> $ cat src/test/Test.java 
> package test;
> public class Test extends Intermediate<String> {
>     private void test() {
>         while (true) { break; }
>     }
> }
> $ javac -XDdev -XDshould-stop.at=FLOW -d classes -classpath classes src/test/Test.java
> src/test/Test.java:2: error: cannot access Missing
> public class Test extends Intermediate<String> {
>        ^
>   class file for test.Missing not found
> 1 error
> An exception has occurred in the compiler (25.0.1). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.clearPendingExits(Flow.java:631)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:619)
> ...
> 
> 
> The reason is that the `CompletionFailure` will be thrown from `chk.checkCompatibleSupertypes(tree.pos(), c.type);`, and since that's before attributing the method bodies, the method bodies will remain blank. And hence the `break` will have no target set, and `Flow` will fail on it.
> 
> I spent some time trying to figure out if we could improve handling on `CompletionFailure`s more generally, so that we would not need to catch them on more-or-less arbitrary places. But everything I was able to do so far didn't really improve the situation. So the proposal herein is to catch and handle the `CompletionFailure` on some place.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28680#pullrequestreview-3546716029

From cstein at openjdk.org  Mon Dec  8 07:14:06 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 8 Dec 2025 07:14:06 GMT
Subject: RFR: 8373097: Save command should create missing parent directories
Message-ID: <Kn-6-fFGpnQQFnaFT9sUWH9nVlYzbdIShSBZTIZFc6A=.0119fb6d-8838-478c-b6c6-6490cd52d6f6@github.com>

Please review this change enhancing the `/save <file>` command in JShell to create missing parent directories.

Prior to this change, when the <file> argument of a `/save` command starts with a list of directory names, of which at least one does not exist, the command fails with an exception reading:

| File 'some/path/Snippet.java' for '/save' threw exception: java.nio.file.NoSuchFileException: some\path\Snippet.java


Any exception happening during the creation of missing parent directories (using `Files.createDirectories` API) is caught and transformed into file-related error message.

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

Commit messages:
 - Clean up
 - Add file with parent directories to `/save` test
 - 8373097: Save command should create missing parent directories

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

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

From jlahoda at openjdk.org  Mon Dec  8 10:08:18 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 8 Dec 2025 10:08:18 GMT
Subject: Integrated: 8373094: javac may fail because of unattributed break in a
 loop
In-Reply-To: <8mqMkx4hXxKTVX-vsNJQpqcXgizmUeQtKjLRlprTSlM=.7809c9ad-5ca3-4cc8-b4ab-659e4ad7a730@github.com>
References: <8mqMkx4hXxKTVX-vsNJQpqcXgizmUeQtKjLRlprTSlM=.7809c9ad-5ca3-4cc8-b4ab-659e4ad7a730@github.com>
Message-ID: <isepwcdHXnb1AuVT705K32VTG50Djks1FiJFTrwjkPc=.094d402e-2a06-4b08-89bc-d5deee4f2fdb@github.com>

On Fri, 5 Dec 2025 16:32:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a case like this:
> 
> package test;
> public class Intermediate<T> extends Base<T> {}
> 
> package test;
> public class Base<T> {
>     public void t(Missing<T> m) {}
> }
> package test;
> public class Missing<T> {}
> 
> this is compiled, and then `Missing` is deleted. Then a test file is compiled with the above classes on the classpath:
> 
> $ cat src/test/Test.java 
> package test;
> public class Test extends Intermediate<String> {
>     private void test() {
>         while (true) { break; }
>     }
> }
> $ javac -XDdev -XDshould-stop.at=FLOW -d classes -classpath classes src/test/Test.java
> src/test/Test.java:2: error: cannot access Missing
> public class Test extends Intermediate<String> {
>        ^
>   class file for test.Missing not found
> 1 error
> An exception has occurred in the compiler (25.0.1). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.clearPendingExits(Flow.java:631)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:619)
> ...
> 
> 
> The reason is that the `CompletionFailure` will be thrown from `chk.checkCompatibleSupertypes(tree.pos(), c.type);`, and since that's before attributing the method bodies, the method bodies will remain blank. And hence the `break` will have no target set, and `Flow` will fail on it.
> 
> I spent some time trying to figure out if we could improve handling on `CompletionFailure`s more generally, so that we would not need to catch them on more-or-less arbitrary places. But everything I was able to do so far didn't really improve the situation. So the proposal herein is to catch and handle the `CompletionFailure` on some place.

This pull request has now been integrated.

Changeset: 35001508
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/350015088281eb9e6e9e3a9811f38adac5f7a975
Stats:     167 lines in 2 files changed: 160 ins; 0 del; 7 mod

8373094: javac may fail because of unattributed break in a loop

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Tue Dec  9 15:13:21 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Dec 2025 15:13:21 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables
Message-ID: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>

Consider case like:

Object o = ...;

//synthetic variable for the instanceof's expression
boolean b = o.toString() instanceof String str && str.isEmpty();

Runnable r = () -> {
        //synthetic variable for the instanceof's expression
        boolean b = o.toString() instanceof String str && str.isEmpty();
};


There are synthetic variables generated for `o.toString()`, to ensure the method is invoked only once for each `instanceof`. These variables are marked as synthetic in `TransPatterns` (and then consequently omitted in `LocalVariableTable`), but when the flag is lost for the variable in the lambda.

This PR proposes to keep the flag, as suggested in the bug.

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

Commit messages:
 - 8372635: Lambdas do not copy over SYNTHETIC flag for local variables

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

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

From vromero at openjdk.org  Tue Dec  9 20:05:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 9 Dec 2025 20:05:07 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables
In-Reply-To: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
Message-ID: <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>

On Tue, 9 Dec 2025 15:04:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider case like:
> 
> Object o = ...;
> 
> //synthetic variable for the instanceof's expression
> boolean b = o.toString() instanceof String str && str.isEmpty();
> 
> Runnable r = () -> {
>         //synthetic variable for the instanceof's expression
>         boolean b = o.toString() instanceof String str && str.isEmpty();
> };
> 
> 
> There are synthetic variables generated for `o.toString()`, to ensure the method is invoked only once for each `instanceof`. These variables are marked as synthetic in `TransPatterns` (and then consequently omitted in `LocalVariableTable`), but when the flag is lost for the variable in the lambda.
> 
> This PR proposes to keep the flag, as suggested in the bug.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1155:

> 1153:                     break;
> 1154:                 case LOCAL_VAR:
> 1155:                     ret = new VarSymbol(sym.flags() & (SYNTHETIC | FINAL), sym.name, sym.type, translatedSym);

this will effectively make synthetic all local variables, should we do this starting from source 27?, what about the parameter being generated below? should be it synthetic too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2604141496

From cushon at openjdk.org  Tue Dec  9 20:49:50 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 9 Dec 2025 20:49:50 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v2]
In-Reply-To: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
Message-ID: <4Z4TrcNpEYWdduRS8Z11mQGMmbb1Qqwka_RcYuW7H7U=.b6b71c6f-b815-4c14-b27c-a149b05a3253@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html).
> 
> I performed the refactoring in stages, preserving existing semantics at each step.
> 
> There are two known places where this changes existing behaviour that are reflected in changes to tests:
> 
> * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that.
> 
> * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment

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:

 - Update assertion for test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java
 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - 8372948: Store end positions directly in JCTree

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28610/files
  - new: https://git.openjdk.org/jdk/pull/28610/files/cd10d5a0..0c8e996c

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

  Stats: 25966 lines in 503 files changed: 17838 ins; 6154 del; 1974 mod
  Patch: https://git.openjdk.org/jdk/pull/28610.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28610/head:pull/28610

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

From liach at openjdk.org  Tue Dec  9 21:52:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Dec 2025 21:52:11 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables
In-Reply-To: <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
Message-ID: <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>

On Tue, 9 Dec 2025 20:02:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Consider case like:
>> 
>> Object o = ...;
>> 
>> //synthetic variable for the instanceof's expression
>> boolean b = o.toString() instanceof String str && str.isEmpty();
>> 
>> Runnable r = () -> {
>>         //synthetic variable for the instanceof's expression
>>         boolean b = o.toString() instanceof String str && str.isEmpty();
>> };
>> 
>> 
>> There are synthetic variables generated for `o.toString()`, to ensure the method is invoked only once for each `instanceof`. These variables are marked as synthetic in `TransPatterns` (and then consequently omitted in `LocalVariableTable`), but when the flag is lost for the variable in the lambda.
>> 
>> This PR proposes to keep the flag, as suggested in the bug.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1155:
> 
>> 1153:                     break;
>> 1154:                 case LOCAL_VAR:
>> 1155:                     ret = new VarSymbol(sym.flags() & (SYNTHETIC | FINAL), sym.name, sym.type, translatedSym);
> 
> this will effectively make synthetic all local variables, should we do this starting from source 27?, what about the parameter being generated below? should it be synthetic too?

This only preserves the SYNTHETIC or FINAL flags of the original sym. I don't think it makes all local vars synthetic, but we should check if these two are the only flags we want to propagate. Or should we switch to a blacklist where we explicitly remove the unwanted flags?

Also this flag processing should probably be shared by LOCAL_VAR and PARAM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2604484669

From cushon at openjdk.org  Tue Dec  9 23:00:59 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 9 Dec 2025 23:00:59 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v3]
In-Reply-To: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
Message-ID: <Tw0roTzxgbkrJwBtlxgGugS4HUGw7LJdZnIB-USGFRI=.ea87d85e-e407-492f-b880-9ec9efa7579d@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html).
> 
> I performed the refactoring in stages, preserving existing semantics at each step.
> 
> There are two known places where this changes existing behaviour that are reflected in changes to tests:
> 
> * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that.
> 
> * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Debug DiagnosticGetEndPosition.java on windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28610/files
  - new: https://git.openjdk.org/jdk/pull/28610/files/0c8e996c..6c5665cb

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

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

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

From cushon at openjdk.org  Wed Dec 10 01:06:53 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 10 Dec 2025 01:06:53 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v4]
In-Reply-To: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
Message-ID: <KD0LyEk-13GxCDmQ4FQw0Aj7Utetm2YAYzHQ20MMUBc=.7a8d2a48-417b-4ced-8e78-08ee8b26b16b@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compile-dev@ thread](https://mail.openjdk.org/pipermail/compiler-dev/2025-November/032254.html).
> 
> I performed the refactoring in stages, preserving existing semantics at each step.
> 
> There are two known places where this changes existing behaviour that are reflected in changes to tests:
> 
> * `test/langtools/tools/javac/api/TestJavacTask_Lock.java` - this test asserts that calling `JavacTask#parse` first and then calling `#call` or `#parse` second will fail. The assertion that the test is currently expecting is thrown when the `EndPosTable` gets set a second time, and this change means that no longer results in an exception. If desired `JavacTask#parse` could be updated to explicitly check if it is called twice and fail, instead of indirectly relying on the `EndPosTable` for that.
> 
> * `test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java` - there's a comment that 'ideally would be "0", but the positions are not fully set yet', and with the new approach the end position is available to the test, so it resolves the comment

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Fix DiagnosticGetEndPosition on windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28610/files
  - new: https://git.openjdk.org/jdk/pull/28610/files/6c5665cb..a86c0446

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

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

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

From cushon at openjdk.org  Wed Dec 10 09:00:25 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 10 Dec 2025 09:00:25 GMT
Subject: RFR: 8370800: Downgrade cant.attach.type.annotations diagnostics
 to warnings [v8]
In-Reply-To: <czd4slPmpeYjaiDx2Lf5fHalYpVurMP22tAO3P9XY6s=.88d89fca-aa5d-49b0-b246-459a7ab78fef@github.com>
References: <-ml93dDR1Xpnk6kMW1VVNP3vJQL0inYhS5QPAdlNukk=.3027b692-a069-43f3-8c0a-0216022ebea4@github.com>
 <czd4slPmpeYjaiDx2Lf5fHalYpVurMP22tAO3P9XY6s=.88d89fca-aa5d-49b0-b246-459a7ab78fef@github.com>
Message-ID: <6HYeMYW0nNWw9qii8NvL4L8qQicHXzpwwCNLMn7xjqE=.0ed0bc49-d432-4610-8341-0afe5ec7dcc6@github.com>

On Sun, 9 Nov 2025 18:30:53 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Hi, please consider this fix for [JDK-8370800: Downgrade cant.attach.type.annotations diagnostics to warnings](https://bugs.openjdk.org/browse/JDK-8370800).
>> 
>> As discussed in the, this reduces the compatibility impact of these diagnostics for builds that deliberately omit transitive annotation dependencies, for example if they are only referenced through javadoc `@link` tags, or by frameworks that conditionally load the classes.
>> 
>> The PR changes the existing error diagnostic to an unconditional warning. Another alternative would be to make it an optional xlint diagnostic, perhaps as part of `-Xlint:classfile`, or as another category.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Complete symbols returned by getAllMembers

I'm still unsure what the best approach here is.

> in practice the issues that have come up are all with method (and maybe fields), but not classes. I think eagerly attaching TAs to classes and only lazily attaching TAs for methods/fields would address the complaints

I also recognize there are other downsides of using field/method completers (including that it would make it hard to use them for other things in the future, and it requires a lot of care to ensure completion happens at the right times).

I don't see a clear favourite among the options:

1. Completers (see above)
2. Downgrade to warnings 
    * missing types are ignored, annotations are missing from model elements
    * some clients will be running with `-Werror` and will want to be warnings clean, which is an issue from library owners that are currently relying on the lenient handling of missing types referenced by fields/methods. Putting this behind an `-Xlint:` category doesn't full solve that problem
3. Do nothing for now
    * avoids implementation tradeoffs around using completers, or downgrading diagnostics for missing classes
    * doesn't address the problem for library owners

I think (1) best addresses the problem that's been reported by library authors. But I am not sure if that's going to have a bug tail of subtle completer issues, or cause problems later if there's another use-case for completers on fields/methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/28018#issuecomment-3636033828

From jlahoda at openjdk.org  Wed Dec 10 14:22:31 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Dec 2025 14:22:31 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables
In-Reply-To: <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
 <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>
Message-ID: <N3tLpvbYkGJfkeV0TEAalVV48v_6RbhRHcWJ_sYD5ko=.513bf144-3783-407d-93f3-b8490147c58b@github.com>

On Tue, 9 Dec 2025 21:48:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 1155:
>> 
>>> 1153:                     break;
>>> 1154:                 case LOCAL_VAR:
>>> 1155:                     ret = new VarSymbol(sym.flags() & (SYNTHETIC | FINAL), sym.name, sym.type, translatedSym);
>> 
>> this will effectively make synthetic all local variables, should we do this starting from source 27?, what about the parameter being generated below? should it be synthetic too?
>
> This only preserves the SYNTHETIC or FINAL flags of the original sym. I don't think it makes all local vars synthetic, but we should check if these two are the only flags we want to propagate. Or should we switch to a blacklist where we explicitly remove the unwanted flags?
> 
> Also this flag processing should probably be shared by LOCAL_VAR and PARAM.

Exactly - this code should copy the specified flags, if they are set. I.e. if the original variable is not synthetic, the new one won't be synthetic either. If the original variable is synthetic, the flag will be transferred to the new variable.

Given the handling of local variables and parameters is slightly different, I am not sure unifying the flags manipulation is quite feasible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2606855355

From duke at openjdk.org  Wed Dec 10 15:00:07 2025
From: duke at openjdk.org (covers1624)
Date: Wed, 10 Dec 2025 15:00:07 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables
In-Reply-To: <N3tLpvbYkGJfkeV0TEAalVV48v_6RbhRHcWJ_sYD5ko=.513bf144-3783-407d-93f3-b8490147c58b@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
 <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>
 <N3tLpvbYkGJfkeV0TEAalVV48v_6RbhRHcWJ_sYD5ko=.513bf144-3783-407d-93f3-b8490147c58b@github.com>
Message-ID: <0oxmKE9dP21VZHzLBXrvFwzf3md5Tfta9pgSAf1r3FA=.a7df35fb-7b88-49fd-9c18-1fcd999b6a72@github.com>

On Wed, 10 Dec 2025 14:19:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This only preserves the SYNTHETIC or FINAL flags of the original sym. I don't think it makes all local vars synthetic, but we should check if these two are the only flags we want to propagate. Or should we switch to a blacklist where we explicitly remove the unwanted flags?
>> 
>> Also this flag processing should probably be shared by LOCAL_VAR and PARAM.
>
> Exactly - this code should copy the specified flags, if they are set. I.e. if the original variable is not synthetic, the new one won't be synthetic either. If the original variable is synthetic, the flag will be transferred to the new variable.
> 
> Given the handling of local variables and parameters is slightly different, I am not sure unifying the flags manipulation is quite feasible.

Hi, I was the one who found this bug and filed it via @sciwhiz12 on the issue tracker.

I was a bit confused by these flags, and didn't dig deep enough, but I'm not overly sure why these aren't just preserved as-is. Considering these are all Javac internal flags, my knowledge here is limited.

Are there any flags applicable to locals that shouldn't be copied when lowering lambdas?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2606927722

From liach at openjdk.org  Wed Dec 10 15:00:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 15:00:07 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables
In-Reply-To: <0oxmKE9dP21VZHzLBXrvFwzf3md5Tfta9pgSAf1r3FA=.a7df35fb-7b88-49fd-9c18-1fcd999b6a72@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
 <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>
 <N3tLpvbYkGJfkeV0TEAalVV48v_6RbhRHcWJ_sYD5ko=.513bf144-3783-407d-93f3-b8490147c58b@github.com>
 <0oxmKE9dP21VZHzLBXrvFwzf3md5Tfta9pgSAf1r3FA=.a7df35fb-7b88-49fd-9c18-1fcd999b6a72@github.com>
Message-ID: <5fx_QHNT-w_Wj5z_m1KE-5PDiOBCaCH2uWCgNrl9YnU=.f04b24f2-a775-4c06-a17e-5323341d0177@github.com>

On Wed, 10 Dec 2025 14:38:46 GMT, covers1624 <duke at openjdk.org> wrote:

>> Exactly - this code should copy the specified flags, if they are set. I.e. if the original variable is not synthetic, the new one won't be synthetic either. If the original variable is synthetic, the flag will be transferred to the new variable.
>> 
>> Given the handling of local variables and parameters is slightly different, I am not sure unifying the flags manipulation is quite feasible.
>
> Hi, I was the one who found this bug and filed it via @sciwhiz12 on the issue tracker.
> 
> I was a bit confused by these flags, and didn't dig deep enough, but I'm not overly sure why these aren't just preserved as-is. Considering these are all Javac internal flags, my knowledge here is limited.
> 
> Are there any flags applicable to locals that shouldn't be copied when lowering lambdas?

The `& FINAL` mask seems to be originally from [JDK-8026749](https://bugs.openjdk.org/browse/JDK-8026749) ([commit](https://github.com/openjdk/jdk/commit/cf30c203379008ebae37bf00f1839a69cd53ca26)). That patch just aimed to create an LVT for debugger and did not copy over any flag, and incorrectly set the final flag which was subsequently fixed.

I don't know why the original patch did not pass over all flags. Maybe it was limited to debugger support and never anticipated actual use of these variables' flags. Yet I don't see a reason in the original issue for not reusing the flags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2606998563

From vromero at openjdk.org  Wed Dec 10 16:33:25 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 10 Dec 2025 16:33:25 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables
In-Reply-To: <5fx_QHNT-w_Wj5z_m1KE-5PDiOBCaCH2uWCgNrl9YnU=.f04b24f2-a775-4c06-a17e-5323341d0177@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
 <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>
 <N3tLpvbYkGJfkeV0TEAalVV48v_6RbhRHcWJ_sYD5ko=.513bf144-3783-407d-93f3-b8490147c58b@github.com>
 <0oxmKE9dP21VZHzLBXrvFwzf3md5Tfta9pgSAf1r3FA=.a7df35fb-7b88-49fd-9c18-1fcd999b6a72@github.com>
 <5fx_QHNT-w_Wj5z_m1KE-5PDiOBCaCH2uWCgNrl9YnU=.f04b24f2-a775-4c06-a17e-5323341d0177@github.com>
Message-ID: <Nn87Z1ARZt6gGtRTWPlqh38htnlKhSQmbKnT2hoftDg=.6787fcff-aaed-4d53-b764-06ace72090eb@github.com>

On Wed, 10 Dec 2025 14:54:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi, I was the one who found this bug and filed it via @sciwhiz12 on the issue tracker.
>> 
>> I was a bit confused by these flags, and didn't dig deep enough, but I'm not overly sure why these aren't just preserved as-is. Considering these are all Javac internal flags, my knowledge here is limited.
>> 
>> Are there any flags applicable to locals that shouldn't be copied when lowering lambdas?
>
> The `& FINAL` mask seems to be originally from [JDK-8026749](https://bugs.openjdk.org/browse/JDK-8026749) ([commit](https://github.com/openjdk/jdk/commit/cf30c203379008ebae37bf00f1839a69cd53ca26)). That patch just aimed to create an LVT for debugger and did not copy over any flag, and incorrectly set the final flag which was subsequently fixed.
> 
> I don't know why the original patch did not pass over all flags. Maybe it was limited to debugger support and never anticipated actual use of these variables' flags. Yet I don't see a reason in the original issue for not reusing the flags.

yep I originally misread the code. I'm also wondering now why we didn't pass all the original flags to the new symbol. We should probably check what breaks if all the flags are just passed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2607365429

From nbenalla at openjdk.org  Wed Dec 10 18:32:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 10 Dec 2025 18:32:50 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26 build
 27
Message-ID: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>

Usual symbol file update for a new JDK build.

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

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

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

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

From iris at openjdk.org  Wed Dec 10 18:57:27 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 10 Dec 2025 18:57:27 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27
In-Reply-To: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
Message-ID: <qJMghfyxwvKw2EyGfyRTpM8hKN_4o4kLxVBMR_qIMmQ=.9feaaa1a-a4ca-4dfd-923c-98a7930b7cac@github.com>

On Wed, 10 Dec 2025 17:51:17 GMT, Nizar Benalla <nbenalla 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/28753#pullrequestreview-3564048978

From darcy at openjdk.org  Wed Dec 10 21:06:35 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Dec 2025 21:06:35 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27
In-Reply-To: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
Message-ID: <0aS1ZjWbsLnqupeSG72tiLPB3PHPf2Kz5aONyCfj5vc=.0ef57769-5fa0-4503-b5d8-fe8f625510a3@github.com>

On Wed, 10 Dec 2025 17:51:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

Looks plausible.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28753#pullrequestreview-3564472851

From jlahoda at openjdk.org  Wed Dec 10 21:23:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Dec 2025 21:23:36 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27
In-Reply-To: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
Message-ID: <LKqkz3JaoxJjVKadZVv4sKcQjLJA5HtnrQyx_4q1iW8=.a490d9ff-f5c6-4806-a160-b6e58d35df71@github.com>

On Wed, 10 Dec 2025 17:51:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

I am sorry, but some files appear to be missing from the change. Like `src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-Q.sym.txt`, but a few others as well (sql, jpackage).

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

PR Comment: https://git.openjdk.org/jdk/pull/28753#issuecomment-3639007284

From nbenalla at openjdk.org  Wed Dec 10 21:46:24 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 10 Dec 2025 21:46:24 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27
In-Reply-To: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
Message-ID: <5r4-pQ5PNqa0Y8dzMVO4My42PvFtwd1ulRzK1TDK2v8=.73afa15b-7062-40e9-ad1b-074407a5b43e@github.com>

On Wed, 10 Dec 2025 17:51:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Usual symbol file update for a new JDK build.

Sorry about that, I had some untracked files in my workspace and didn't notice that the script produced a few new ones.
I've included the missing files now.

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

PR Comment: https://git.openjdk.org/jdk/pull/28753#issuecomment-3639084978

From nbenalla at openjdk.org  Wed Dec 10 21:54:38 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 10 Dec 2025 21:54:38 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27 [v2]
In-Reply-To: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
Message-ID: <YOAa7_CjXr-qywyDhjEsr6vvHrfP0k8eZNavkF5RWTE=.531c379c-cbd3-400d-9b99-cea0552412dc@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:

  add missing files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28753/files
  - new: https://git.openjdk.org/jdk/pull/28753/files/cb9fb85c..48e2dd69

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

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

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

From darcy at openjdk.org  Thu Dec 11 02:01:25 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 11 Dec 2025 02:01:25 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27
In-Reply-To: <LKqkz3JaoxJjVKadZVv4sKcQjLJA5HtnrQyx_4q1iW8=.a490d9ff-f5c6-4806-a160-b6e58d35df71@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
 <LKqkz3JaoxJjVKadZVv4sKcQjLJA5HtnrQyx_4q1iW8=.a490d9ff-f5c6-4806-a160-b6e58d35df71@github.com>
Message-ID: <nXMCEzJTBmIJyh6fvT8Rle4ekDsJv8LhEaXbQ1Y6wps=.c65c988d-9a96-45ad-af8d-bf19244496c8@github.com>

On Wed, 10 Dec 2025 21:21:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I am sorry, but some files appear to be missing from the change. Like `src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-Q.sym.txt`, but a few others as well (sql, jpackage).

Good catch Jan; thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/28753#issuecomment-3639703982

From darcy at openjdk.org  Thu Dec 11 05:32:25 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 11 Dec 2025 05:32:25 GMT
Subject: RFR: 8370800: Downgrade cant.attach.type.annotations diagnostics
 to warnings [v8]
In-Reply-To: <czd4slPmpeYjaiDx2Lf5fHalYpVurMP22tAO3P9XY6s=.88d89fca-aa5d-49b0-b246-459a7ab78fef@github.com>
References: <-ml93dDR1Xpnk6kMW1VVNP3vJQL0inYhS5QPAdlNukk=.3027b692-a069-43f3-8c0a-0216022ebea4@github.com>
 <czd4slPmpeYjaiDx2Lf5fHalYpVurMP22tAO3P9XY6s=.88d89fca-aa5d-49b0-b246-459a7ab78fef@github.com>
Message-ID: <sMm0o7KpghYW7thJl-kffu_OigpDFzr2vMosfsCtdjA=.a4712761-22bd-451b-9bda-fcea3e039e96@github.com>

On Sun, 9 Nov 2025 18:30:53 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Hi, please consider this fix for [JDK-8370800: Downgrade cant.attach.type.annotations diagnostics to warnings](https://bugs.openjdk.org/browse/JDK-8370800).
>> 
>> As discussed in the, this reduces the compatibility impact of these diagnostics for builds that deliberately omit transitive annotation dependencies, for example if they are only referenced through javadoc `@link` tags, or by frameworks that conditionally load the classes.
>> 
>> The PR changes the existing error diagnostic to an unconditional warning. Another alternative would be to make it an optional xlint diagnostic, perhaps as part of `-Xlint:classfile`, or as another category.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Complete symbols returned by getAllMembers

Hmm. Catching up on this PR has been on to-do list for a while. Generally there are conditions in the JLS that justify rejecting (or accepting) a program.

What do the relevant specifications say here?

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

PR Comment: https://git.openjdk.org/jdk/pull/28018#issuecomment-3640205522

From jlahoda at openjdk.org  Thu Dec 11 06:49:29 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Dec 2025 06:49:29 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27 [v2]
In-Reply-To: <YOAa7_CjXr-qywyDhjEsr6vvHrfP0k8eZNavkF5RWTE=.531c379c-cbd3-400d-9b99-cea0552412dc@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
 <YOAa7_CjXr-qywyDhjEsr6vvHrfP0k8eZNavkF5RWTE=.531c379c-cbd3-400d-9b99-cea0552412dc@github.com>
Message-ID: <GOx-7P2FYSSGZ8280VjxIViWQtJTUMxi3xY6JzqeGU4=.0843d0bf-c9a6-46b6-a043-1fcab5fac73a@github.com>

On Wed, 10 Dec 2025 21:54:38 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:
> 
>   add missing files

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28753#pullrequestreview-3565969908

From jlahoda at openjdk.org  Thu Dec 11 08:36:42 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Dec 2025 08:36:42 GMT
Subject: RFR: 8373436: Cleanup JRTIndex usages
Message-ID: <s1jPtyrC96cCgJLgdjc9pGcUcRrXnA7CpHrQRtx-GKA=.a761d4ce-3919-412b-8889-12b3c21c5bae@github.com>

The `com.sun.tools.javac.file.JRTIndex` class serves two purposes: a) the keeps a package-oriented cache of directories and files inside the JRT FileSystem; b) allows to get the additional flags for classes in packages on the default classpath. Sadly, it is not easy to completely disentangle these two purposes, as the directories cache also holds the additional flags.

The `JRTIndex` is used on two places, the `ClassFinder`, and in `JavacFileManager`, but the former is only using the additional flags, and the latter is using the cache/index. The logic determining whether the `JRTIndex` is used in `ClassFinder` is also not trivial.

The goal of this PR is to attempt to clean this a bit:
- there's a separate abstraction for getting the additional flags (`LegacyCtPropertiesAccess`), with the non-trivial implementation residing in `JavacFileManager`. This allows to concentrate the complex almost completely  inside the file manager.
- the `JRTIndex` itself is now a package-private class inside the `....file` package.

It is not a goal of this PR to change the behavior, just make the implementation more understandable.

Note this removal from `ClassFinder`:

-        if (fm instanceof DelegatingJavaFileManager delegatingJavaFileManager) {
-            fm = delegatingJavaFileManager.getBaseFileManager();
-        }


The `DelegatingJavaFileManager` is used when `--release` is specified, so this allows to get the underlying base file manager. But, regardless of the underlying base manager, the system classes should always come from the `--release` data, which are not in the underlying base manager, and hence (ultimately), the `JRTIndex` data should not be used by `ClassFinder` when `--release` is used. The removal makes this more obvious.

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

Commit messages:
 - Cleanup.
 - Attempting to clarify how legacy ct.sym data/JRTIndex is used.

Changes: https://git.openjdk.org/jdk/pull/28761/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373436
  Stats: 291 lines in 5 files changed: 202 ins; 65 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/28761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28761/head:pull/28761

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

From mcimadamore at openjdk.org  Thu Dec 11 10:07:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Dec 2025 10:07:33 GMT
Subject: RFR: 8373436: Cleanup JRTIndex usages
In-Reply-To: <s1jPtyrC96cCgJLgdjc9pGcUcRrXnA7CpHrQRtx-GKA=.a761d4ce-3919-412b-8889-12b3c21c5bae@github.com>
References: <s1jPtyrC96cCgJLgdjc9pGcUcRrXnA7CpHrQRtx-GKA=.a761d4ce-3919-412b-8889-12b3c21c5bae@github.com>
Message-ID: <1-A3-Gzm-G501aRQBH8_wmETJ_Wq9oNQD58S1mm3HBA=.767454c6-972b-4bf4-9dd3-3cc068972c32@github.com>

On Thu, 11 Dec 2025 08:29:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `com.sun.tools.javac.file.JRTIndex` class serves two purposes: a) the keeps a package-oriented cache of directories and files inside the JRT FileSystem; b) allows to get the additional flags for classes in packages on the default classpath. Sadly, it is not easy to completely disentangle these two purposes, as the directories cache also holds the additional flags.
> 
> The `JRTIndex` is used on two places, the `ClassFinder`, and in `JavacFileManager`, but the former is only using the additional flags, and the latter is using the cache/index. The logic determining whether the `JRTIndex` is used in `ClassFinder` is also not trivial.
> 
> The goal of this PR is to attempt to clean this a bit:
> - there's a separate abstraction for getting the additional flags (`LegacyCtPropertiesAccess`), with the non-trivial implementation residing in `JavacFileManager`. This allows to concentrate the complex almost completely  inside the file manager.
> - the `JRTIndex` itself is now a package-private class inside the `....file` package.
> 
> It is not a goal of this PR to change the behavior, just make the implementation more understandable.
> 
> Note this removal from `ClassFinder`:
> 
> -        if (fm instanceof DelegatingJavaFileManager delegatingJavaFileManager) {
> -            fm = delegatingJavaFileManager.getBaseFileManager();
> -        }
> 
> 
> The `DelegatingJavaFileManager` is used when `--release` is specified, so this allows to get the underlying base file manager. But, regardless of the underlying base manager, the system classes should always come from the `--release` data, which are not in the underlying base manager, and hence (ultimately), the `JRTIndex` data should not be used by `ClassFinder` when `--release` is used. The removal makes this more obvious.

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

> 464:                 private final JRTIndex jrtIndex = getJRTIndex();
> 465:                 @Override
> 466:                 public boolean supportsLegacyFlags(JavaFileObject fo) {

Question (possibly naive) -- couldn't `LegacyCtProperties` access be an interface that is implemented directly by `JRTIndex` ? Then this method could return the jrtIndex -- and that would also be a `LegacyCtPropertiesAccess`. You still achieve the separation you are aiming for, but a bit more directly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28761#discussion_r2609964379

From jlahoda at openjdk.org  Thu Dec 11 10:35:31 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Dec 2025 10:35:31 GMT
Subject: RFR: 8373436: Cleanup JRTIndex usages [v2]
In-Reply-To: <s1jPtyrC96cCgJLgdjc9pGcUcRrXnA7CpHrQRtx-GKA=.a761d4ce-3919-412b-8889-12b3c21c5bae@github.com>
References: <s1jPtyrC96cCgJLgdjc9pGcUcRrXnA7CpHrQRtx-GKA=.a761d4ce-3919-412b-8889-12b3c21c5bae@github.com>
Message-ID: <svsLJIFhDXOXlgX5GiF22rVQSAJrkGLpElr2ucYu5CI=.cfa1f773-3f82-4904-9679-3323cc4bd596@github.com>

> The `com.sun.tools.javac.file.JRTIndex` class serves two purposes: a) the keeps a package-oriented cache of directories and files inside the JRT FileSystem; b) allows to get the additional flags for classes in packages on the default classpath. Sadly, it is not easy to completely disentangle these two purposes, as the directories cache also holds the additional flags.
> 
> The `JRTIndex` is used on two places, the `ClassFinder`, and in `JavacFileManager`, but the former is only using the additional flags, and the latter is using the cache/index. The logic determining whether the `JRTIndex` is used in `ClassFinder` is also not trivial.
> 
> The goal of this PR is to attempt to clean this a bit:
> - there's a separate abstraction for getting the additional flags (`LegacyCtPropertiesAccess`), with the non-trivial implementation residing in `JavacFileManager`. This allows to concentrate the complex almost completely  inside the file manager.
> - the `JRTIndex` itself is now a package-private class inside the `....file` package.
> 
> It is not a goal of this PR to change the behavior, just make the implementation more understandable.
> 
> Note this removal from `ClassFinder`:
> 
> -        if (fm instanceof DelegatingJavaFileManager delegatingJavaFileManager) {
> -            fm = delegatingJavaFileManager.getBaseFileManager();
> -        }
> 
> 
> The `DelegatingJavaFileManager` is used when `--release` is specified, so this allows to get the underlying base file manager. But, regardless of the underlying base manager, the system classes should always come from the `--release` data, which are not in the underlying base manager, and hence (ultimately), the `JRTIndex` data should not be used by `ClassFinder` when `--release` is used. The removal makes this more obvious.

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

  Cleanup: JRTIndex implements LegacyCtPropertiesAccess directly, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28761/files
  - new: https://git.openjdk.org/jdk/pull/28761/files/b9aa5bf4..dc275831

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

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

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

From jlahoda at openjdk.org  Thu Dec 11 10:35:34 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Dec 2025 10:35:34 GMT
Subject: RFR: 8373436: Cleanup JRTIndex usages [v2]
In-Reply-To: <1-A3-Gzm-G501aRQBH8_wmETJ_Wq9oNQD58S1mm3HBA=.767454c6-972b-4bf4-9dd3-3cc068972c32@github.com>
References: <s1jPtyrC96cCgJLgdjc9pGcUcRrXnA7CpHrQRtx-GKA=.a761d4ce-3919-412b-8889-12b3c21c5bae@github.com>
 <1-A3-Gzm-G501aRQBH8_wmETJ_Wq9oNQD58S1mm3HBA=.767454c6-972b-4bf4-9dd3-3cc068972c32@github.com>
Message-ID: <uMTdwI1vPF4KAY1QC1ii__QQvsHrTKPwPMdnwnaO3Sk=.ac8c32c7-2cbe-4542-b0d6-472ee95aaa27@github.com>

On Thu, 11 Dec 2025 10:04:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup: JRTIndex implements LegacyCtPropertiesAccess directly, as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 466:
> 
>> 464:                 private final JRTIndex jrtIndex = getJRTIndex();
>> 465:                 @Override
>> 466:                 public boolean supportsLegacyFlags(JavaFileObject fo) {
> 
> Question (possibly naive) -- couldn't `LegacyCtProperties` access be an interface that is implemented directly by `JRTIndex` ? Then this method could return the jrtIndex -- and that would also be a `LegacyCtPropertiesAccess`. You still achieve the separation you are aiming for, but a bit more directly?

Yes, I think that's doable. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28761#discussion_r2610041280

From jlahoda at openjdk.org  Thu Dec 11 13:58:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Dec 2025 13:58:28 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables [v2]
In-Reply-To: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
Message-ID: <ZDTJZ58Wh1slq4PbwIeu6CvFpNu2WgFFbf1CZnl-9zM=.b3f8eeb3-4a57-44e7-b9b1-0ee9f5d9a79c@github.com>

> Consider case like:
> 
> Object o = ...;
> 
> //synthetic variable for the instanceof's expression
> boolean b = o.toString() instanceof String str && str.isEmpty();
> 
> Runnable r = () -> {
>         //synthetic variable for the instanceof's expression
>         boolean b = o.toString() instanceof String str && str.isEmpty();
> };
> 
> 
> There are synthetic variables generated for `o.toString()`, to ensure the method is invoked only once for each `instanceof`. These variables are marked as synthetic in `TransPatterns` (and then consequently omitted in `LocalVariableTable`), but when the flag is lost for the variable in the lambda.
> 
> This PR proposes to keep the flag, as suggested in the bug.

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

  Copy all flags when creating lambda local var/parameter.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28724/files
  - new: https://git.openjdk.org/jdk/pull/28724/files/28cda46f..9aa6642a

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

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

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

From jlahoda at openjdk.org  Thu Dec 11 13:58:42 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Dec 2025 13:58:42 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables [v2]
In-Reply-To: <Nn87Z1ARZt6gGtRTWPlqh38htnlKhSQmbKnT2hoftDg=.6787fcff-aaed-4d53-b764-06ace72090eb@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
 <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>
 <N3tLpvbYkGJfkeV0TEAalVV48v_6RbhRHcWJ_sYD5ko=.513bf144-3783-407d-93f3-b8490147c58b@github.com>
 <0oxmKE9dP21VZHzLBXrvFwzf3md5Tfta9pgSAf1r3FA=.a7df35fb-7b88-49fd-9c18-1fcd999b6a72@github.com>
 <5fx_QHNT-w_Wj5z_m1KE-5PDiOBCaCH2uWCgNrl9YnU=.f04b24f2-a775-4c06-a17e-5323341d0177@github.com>
 <Nn87Z1ARZt6gGtRTWPlqh38htnlKhSQmbKnT2hoftDg=.6787fcff-aaed-4d53-b764-06ace72090eb@github.com>
Message-ID: <m0YGA5IxocevcIK4799nZy_fqpkxxl0ut2nAeb4quHE=.6355fa4f-1d1a-46ca-83e4-a59d397f743e@github.com>

On Wed, 10 Dec 2025 16:28:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The `& FINAL` mask seems to be originally from [JDK-8026749](https://bugs.openjdk.org/browse/JDK-8026749) ([commit](https://github.com/openjdk/jdk/commit/cf30c203379008ebae37bf00f1839a69cd53ca26)). That patch just aimed to create an LVT for debugger and did not copy over any flag, and incorrectly set the final flag which was subsequently fixed.
>> 
>> I don't know why the original patch did not pass over all flags. Maybe it was limited to debugger support and never anticipated actual use of these variables' flags. Yet I don't see a reason in the original issue for not reusing the flags.
>
> yep I originally misread the code. I'm also wondering now why we didn't pass all the original flags to the new symbol. We should probably check what breaks if all the flags are just passed

Good question whether we can copy all flags. I went through the flags, and there's nothing I would know would be problematic (the flag would need to be significant for the backend/codegen, and there's very limited number of such flags). Tests also seem fine with copying all flags, so I've adjusted the PR to copy all flags.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2610683634

From vromero at openjdk.org  Thu Dec 11 14:11:33 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Dec 2025 14:11:33 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables [v2]
In-Reply-To: <ZDTJZ58Wh1slq4PbwIeu6CvFpNu2WgFFbf1CZnl-9zM=.b3f8eeb3-4a57-44e7-b9b1-0ee9f5d9a79c@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <ZDTJZ58Wh1slq4PbwIeu6CvFpNu2WgFFbf1CZnl-9zM=.b3f8eeb3-4a57-44e7-b9b1-0ee9f5d9a79c@github.com>
Message-ID: <58qhybGjn4j3OyRUNQHpIxHubfLLf5ji30-gXHvdD6k=.a5ecf18d-47b2-41eb-9389-1bbcee062dc6@github.com>

On Thu, 11 Dec 2025 13:58:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider case like:
>> 
>> Object o = ...;
>> 
>> //synthetic variable for the instanceof's expression
>> boolean b = o.toString() instanceof String str && str.isEmpty();
>> 
>> Runnable r = () -> {
>>         //synthetic variable for the instanceof's expression
>>         boolean b = o.toString() instanceof String str && str.isEmpty();
>> };
>> 
>> 
>> There are synthetic variables generated for `o.toString()`, to ensure the method is invoked only once for each `instanceof`. These variables are marked as synthetic in `TransPatterns` (and then consequently omitted in `LocalVariableTable`), but when the flag is lost for the variable in the lambda.
>> 
>> This PR proposes to keep the flag, as suggested in the bug.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copy all flags when creating lambda local var/parameter.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28724#pullrequestreview-3567621558

From vromero at openjdk.org  Thu Dec 11 14:11:35 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Dec 2025 14:11:35 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables [v2]
In-Reply-To: <m0YGA5IxocevcIK4799nZy_fqpkxxl0ut2nAeb4quHE=.6355fa4f-1d1a-46ca-83e4-a59d397f743e@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <jWnTw9060ayAWwba4KzcXAAJaAhD1UW9D2YICqUruiQ=.2cbbf98a-d602-4cb3-88bd-4ee97d2db064@github.com>
 <596SFPkLWdQVj9ANQaxHcVw-R6rbWO02fKcTqCqoBqQ=.e8dbbc2a-e91a-4636-b732-6f5e43b69cf5@github.com>
 <N3tLpvbYkGJfkeV0TEAalVV48v_6RbhRHcWJ_sYD5ko=.513bf144-3783-407d-93f3-b8490147c58b@github.com>
 <0oxmKE9dP21VZHzLBXrvFwzf3md5Tfta9pgSAf1r3FA=.a7df35fb-7b88-49fd-9c18-1fcd999b6a72@github.com>
 <5fx_QHNT-w_Wj5z_m1KE-5PDiOBCaCH2uWCgNrl9YnU=.f04b24f2-a775-4c06-a17e-5323341d0177@github.com>
 <Nn87Z1ARZt6gGtRTWPlqh38htnlKhSQmbKnT2hoftDg=.6787fcff-aaed-4d53-b764-06ace72090eb@github.com>
 <m0YGA5IxocevcIK4799nZy_fqpkxxl0ut2nAeb4quHE=.6355fa4f-1d1a-46ca-83e4-a59d397f743e@github.com>
Message-ID: <W0A5HYRLUNWMu_UAFs6cO4PaMm-VjAfFF6z-8tSmhzU=.ec5518d3-7193-4c2b-a1e8-cc98a184678d@github.com>

On Thu, 11 Dec 2025 13:55:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> yep I originally misread the code. I'm also wondering now why we didn't pass all the original flags to the new symbol. We should probably check what breaks if all the flags are just passed
>
> Good question whether we can copy all flags. I went through the flags, and there's nothing I would know would be problematic (the flag would need to be significant for the backend/codegen, and there's very limited number of such flags). Tests also seem fine with copying all flags, so I've adjusted the PR to copy all flags.
> 
> Thanks!

nice, thanks for doing the experiment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28724#discussion_r2610734417

From mcimadamore at openjdk.org  Thu Dec 11 14:32:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Dec 2025 14:32:58 GMT
Subject: RFR: 8373436: Cleanup JRTIndex usages [v2]
In-Reply-To: <svsLJIFhDXOXlgX5GiF22rVQSAJrkGLpElr2ucYu5CI=.cfa1f773-3f82-4904-9679-3323cc4bd596@github.com>
References: <s1jPtyrC96cCgJLgdjc9pGcUcRrXnA7CpHrQRtx-GKA=.a761d4ce-3919-412b-8889-12b3c21c5bae@github.com>
 <svsLJIFhDXOXlgX5GiF22rVQSAJrkGLpElr2ucYu5CI=.cfa1f773-3f82-4904-9679-3323cc4bd596@github.com>
Message-ID: <tsjKTRc0J4ZK34AI3K12P-ylt6ZmKi8TMMGpltA-qUA=.c178059a-1bbc-4f7e-8323-2041a19a8578@github.com>

On Thu, 11 Dec 2025 10:35:31 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The `com.sun.tools.javac.file.JRTIndex` class serves two purposes: a) the keeps a package-oriented cache of directories and files inside the JRT FileSystem; b) allows to get the additional flags for classes in packages on the default classpath. Sadly, it is not easy to completely disentangle these two purposes, as the directories cache also holds the additional flags.
>> 
>> The `JRTIndex` is used on two places, the `ClassFinder`, and in `JavacFileManager`, but the former is only using the additional flags, and the latter is using the cache/index. The logic determining whether the `JRTIndex` is used in `ClassFinder` is also not trivial.
>> 
>> The goal of this PR is to attempt to clean this a bit:
>> - there's a separate abstraction for getting the additional flags (`LegacyCtPropertiesAccess`), with the non-trivial implementation residing in `JavacFileManager`. This allows to concentrate the complex almost completely  inside the file manager.
>> - the `JRTIndex` itself is now a package-private class inside the `....file` package.
>> 
>> It is not a goal of this PR to change the behavior, just make the implementation more understandable.
>> 
>> Note this removal from `ClassFinder`:
>> 
>> -        if (fm instanceof DelegatingJavaFileManager delegatingJavaFileManager) {
>> -            fm = delegatingJavaFileManager.getBaseFileManager();
>> -        }
>> 
>> 
>> The `DelegatingJavaFileManager` is used when `--release` is specified, so this allows to get the underlying base file manager. But, regardless of the underlying base manager, the system classes should always come from the `--release` data, which are not in the underlying base manager, and hence (ultimately), the `JRTIndex` data should not be used by `ClassFinder` when `--release` is used. The removal makes this more obvious.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup: JRTIndex implements LegacyCtPropertiesAccess directly, as suggested.

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28761#pullrequestreview-3567723858

From jlahoda at openjdk.org  Thu Dec 11 14:35:15 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Dec 2025 14:35:15 GMT
Subject: RFR: 8370800: Downgrade cant.attach.type.annotations diagnostics
 to warnings [v8]
In-Reply-To: <sMm0o7KpghYW7thJl-kffu_OigpDFzr2vMosfsCtdjA=.a4712761-22bd-451b-9bda-fcea3e039e96@github.com>
References: <-ml93dDR1Xpnk6kMW1VVNP3vJQL0inYhS5QPAdlNukk=.3027b692-a069-43f3-8c0a-0216022ebea4@github.com>
 <czd4slPmpeYjaiDx2Lf5fHalYpVurMP22tAO3P9XY6s=.88d89fca-aa5d-49b0-b246-459a7ab78fef@github.com>
 <sMm0o7KpghYW7thJl-kffu_OigpDFzr2vMosfsCtdjA=.a4712761-22bd-451b-9bda-fcea3e039e96@github.com>
Message-ID: <FnpVMQYIlDZc9RUzTQoSv8Em1q0bzD_39-Oo7DhqHaM=.007a41e4-dfb6-48d9-a906-86ea896838db@github.com>

On Thu, 11 Dec 2025 05:29:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Complete symbols returned by getAllMembers
>
> Hmm. Catching up on this PR has been on to-do list for a while. Generally there are conditions in the JLS that justify rejecting (or accepting) a program.
> 
> What do the relevant specifications say here?

@jddarcy, I am afraid this is a bit in a gray zone. Consider this sequence of projects/files:

----------- ./prj1/src/A.java
public class A<T> {}

----------- ./prj2/src/B.java
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;
import java.util.List;

public class B {
    private void test (A<String> a) {}
}
@Target(ElementType.TYPE_USE)
@interface TA {}

----------- ./prj3/src/C.java
public class C {
    public B b;
    public void test() {
        b.toString();
    }
}


And the a sequence of compilations like (this is a standing behavior, unrelated to this PR):

$ javac -d prj1/classes prj1/src/A.java 
$ javac -d prj2/classes -cp prj1/classes/ prj2/src/B.java 
$ javac -d prj3/classes -cp prj2/classes/ prj3/src/C.java


note:
- there are no errors
- `A` is not on the compile classpath when compiling `C`, but `B` depends on `A`

When compiling `C`, if javac looked at `B` in the source form, it would be uncompilable, as `A` would not be resolvable. But, since `B` is load from a classfile, javac doesn't proactively check whether `A` exists, until it has a "reason" to look for `A` (at which point it will find out it can't find the definition, and will produce a compile-time error).

AFAIK JLS sees compilation units only it their source form, so strictly speaking, I believe we could always produce an error for any missing class - but the long-standing behavior is that javac only looks for classes/interfaces that are referred to by classfiles if it has a reason to do so.

Now, consider I do this change in `B.java`:

    private void test (A<String> a) {}
=>
    private void test (@TA A<String> a) {}


The compilations now will be (JDK 25):

$ javac -d prj1/classes prj1/src/A.java 
$ javac -d prj2/classes -cp prj1/classes/ prj2/src/B.java 
$ javac -d prj3/classes -cp prj2/classes/ prj3/src/C.java
prj2/classes/B.class: error: Cannot attach type annotations @TA to B.test:
  class file for A not found
1 error


And while technically speaking, I think javac can produce this error, there's a question whether it is reasonable. Especially in this case, where all that was done was adding a type annotation to a type in a private method, and the outcome is that the compilation passed before and now fails.

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

PR Comment: https://git.openjdk.org/jdk/pull/28018#issuecomment-3642207754

From nbenalla at openjdk.org  Thu Dec 11 15:29:27 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 11 Dec 2025 15:29:27 GMT
Subject: RFR: 8373443: Update --release 26 symbol information for JDK 26
 build 27 [v2]
In-Reply-To: <YOAa7_CjXr-qywyDhjEsr6vvHrfP0k8eZNavkF5RWTE=.531c379c-cbd3-400d-9b99-cea0552412dc@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
 <YOAa7_CjXr-qywyDhjEsr6vvHrfP0k8eZNavkF5RWTE=.531c379c-cbd3-400d-9b99-cea0552412dc@github.com>
Message-ID: <Asxb8tk5f5VmLxRDqT_9twu70agvg82Corm37pezTS4=.3b05a9d3-dd79-4a6b-9b15-ef97ade7984d@github.com>

On Wed, 10 Dec 2025 21:54:38 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:
> 
>   add missing files

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28753#issuecomment-3642456716

From nbenalla at openjdk.org  Thu Dec 11 15:33:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 11 Dec 2025 15:33:26 GMT
Subject: Integrated: 8373443: Update --release 26 symbol information for JDK 26
 build 27
In-Reply-To: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
References: <_xQzCFOM8Omxp20d0Mh4QgDoSADVlYmBxU6sD4m5ow0=.32c97499-6eed-4a66-ac87-41dc6ef34fd3@github.com>
Message-ID: <eG8zPDlNPbEC5pbJKRUo2Z94XOpemzs8lPYl9U5yLxs=.8d588d47-7725-4547-a4db-3fda44054124@github.com>

On Wed, 10 Dec 2025 17:51:17 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: 692edc48
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/692edc4879489d44a477a03028eb3e7ef9dff388
Stats:     183 lines in 5 files changed: 182 ins; 0 del; 1 mod

8373443: Update --release 26 symbol information for JDK 26 build 27

Reviewed-by: jlahoda, iris, darcy

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

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

From liach at openjdk.org  Thu Dec 11 18:20:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Dec 2025 18:20:55 GMT
Subject: RFR: 8372635: Lambdas do not copy over SYNTHETIC flag for local
 variables [v2]
In-Reply-To: <ZDTJZ58Wh1slq4PbwIeu6CvFpNu2WgFFbf1CZnl-9zM=.b3f8eeb3-4a57-44e7-b9b1-0ee9f5d9a79c@github.com>
References: <_OijaZ3G0DDv5CGDtu9_DP9ZFG1axLlD2AswPFwyKJw=.6626b06c-6ca5-4537-8302-95831647881c@github.com>
 <ZDTJZ58Wh1slq4PbwIeu6CvFpNu2WgFFbf1CZnl-9zM=.b3f8eeb3-4a57-44e7-b9b1-0ee9f5d9a79c@github.com>
Message-ID: <RAvjOTbf5pVAawSr22MX-RNCSIRXV5roJ0-vi1CpzyE=.a940ead5-45cf-4a3c-89c9-fd7115804392@github.com>

On Thu, 11 Dec 2025 13:58:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider case like:
>> 
>> Object o = ...;
>> 
>> //synthetic variable for the instanceof's expression
>> boolean b = o.toString() instanceof String str && str.isEmpty();
>> 
>> Runnable r = () -> {
>>         //synthetic variable for the instanceof's expression
>>         boolean b = o.toString() instanceof String str && str.isEmpty();
>> };
>> 
>> 
>> There are synthetic variables generated for `o.toString()`, to ensure the method is invoked only once for each `instanceof`. These variables are marked as synthetic in `TransPatterns` (and then consequently omitted in `LocalVariableTable`), but when the flag is lost for the variable in the lambda.
>> 
>> This PR proposes to keep the flag, as suggested in the bug.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copy all flags when creating lambda local var/parameter.

Lgtm assuming there is no test failure

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28724#pullrequestreview-3568730903

From jpai at openjdk.org  Fri Dec 12 05:32:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 05:32:31 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
Message-ID: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>

Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?

As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.

tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

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

Commit messages:
 - replace deprecated -verify with -Xverify:all

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

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

From serb at openjdk.org  Fri Dec 12 16:43:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Dec 2025 16:43:51 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <dLFHhbJxKDGiXeA2U9AkwMLcEtZ12IHmnhKzWVml5_E=.d595bfe5-e47a-49bc-b17a-ad6a5eab43bd@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3572713212

From prr at openjdk.org  Fri Dec 12 18:04:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:04:54 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <dIONKF2kQv5hpJlIwjLhfFnH4Z48OTth3gOeGk7e7zQ=.93ebdbef-716a-4014-bc62-627fd764bb2e@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3573006281

From dnguyen at openjdk.org  Fri Dec 12 21:40:21 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 12 Dec 2025 21:40:21 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update
Message-ID: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>

Open l10n drop. Files have been updated with translated versions.

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

Commit messages:
 - Fix single quote
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/28802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373119
  Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod
  Patch: https://git.openjdk.org/jdk/pull/28802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802

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

From dnguyen at openjdk.org  Fri Dec 12 21:40:23 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 12 Dec 2025 21:40:23 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update
In-Reply-To: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
Message-ID: <ID6pwTFMCklS-Fi_Q4qRwVyyTuTbDFWTk0iTJcMeF24=.a3019601-ddc7-4317-ba59-738ea588b8bb@github.com>

On Fri, 12 Dec 2025 20:43:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Open l10n drop. Files have been updated with translated versions.

src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46:

> 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben
> 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben
> 46: Subject.=Subject:\n

This change reverts what was previously changed in the last l10n drop. There was a request to change word "Subject" to "Subjekt" at the time, and this was manually adjusted. This issue was brought up to the translation team but was ultimately rejected. So, to align with upstream, I will leave this as is.

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

> 207: javac.opt.prefer=??????, ???????????????????
> 208: # L10N: do not localize: ''preview''
> 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ?????

I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 230:

> 228: doclet.search_in_documentation=In Dokumentation suchen
> 229: doclet.search_reset=Zur?cksetzen
> 230: doclet.Member=Member

Similar to above with security.properties, this change was brought up to the localization team and rejected. I intend to keep this as is for the same reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615537125
PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615533659
PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615538518

From naoto at openjdk.org  Fri Dec 12 22:07:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Dec 2025 22:07:51 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update
In-Reply-To: <ID6pwTFMCklS-Fi_Q4qRwVyyTuTbDFWTk0iTJcMeF24=.a3019601-ddc7-4317-ba59-738ea588b8bb@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
 <ID6pwTFMCklS-Fi_Q4qRwVyyTuTbDFWTk0iTJcMeF24=.a3019601-ddc7-4317-ba59-738ea588b8bb@github.com>
Message-ID: <wOq3l5krrBWZXsAviXYB33yi55waVZHddc7AMy0LK4k=.f1bbd844-655f-4973-94c7-9203f91f3fef@github.com>

On Fri, 12 Dec 2025 20:45:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209:
> 
>> 207: javac.opt.prefer=??????, ???????????????????
>> 208: # L10N: do not localize: ''preview''
>> 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ?????
> 
> I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it.

Since this is an apparent l10n mistake, I'd just replace "??" with ''preview''

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615696431

From dnguyen at openjdk.org  Fri Dec 12 22:34:10 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 12 Dec 2025 22:34:10 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2]
In-Reply-To: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
Message-ID: <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>

> Open l10n drop. Files have been updated with translated versions.

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

  Revert Chinese preview change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28802/files
  - new: https://git.openjdk.org/jdk/pull/28802/files/6a280e17..83100f94

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

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

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

From dnguyen at openjdk.org  Fri Dec 12 22:34:12 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 12 Dec 2025 22:34:12 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2]
In-Reply-To: <wOq3l5krrBWZXsAviXYB33yi55waVZHddc7AMy0LK4k=.f1bbd844-655f-4973-94c7-9203f91f3fef@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
 <ID6pwTFMCklS-Fi_Q4qRwVyyTuTbDFWTk0iTJcMeF24=.a3019601-ddc7-4317-ba59-738ea588b8bb@github.com>
 <wOq3l5krrBWZXsAviXYB33yi55waVZHddc7AMy0LK4k=.f1bbd844-655f-4973-94c7-9203f91f3fef@github.com>
Message-ID: <4jc-NxobKK8qRpYSujoOwgvRw7kj4mZVbkNnaf6X--I=.77f68671-384e-4168-9bd6-71566817ad55@github.com>

On Fri, 12 Dec 2025 22:04:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209:
>> 
>>> 207: javac.opt.prefer=??????, ???????????????????
>>> 208: # L10N: do not localize: ''preview''
>>> 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ?????
>> 
>> I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it.
>
> Since this is an apparent l10n mistake, I'd just replace "??" with ''preview''

Thanks. Updated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615744326

From jlu at openjdk.org  Fri Dec 12 22:51:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Dec 2025 22:51:52 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2]
In-Reply-To: <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
 <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>
Message-ID: <zYrI3WYfTWbzbGRXftkczVzKalvM9rswoZs6ajonzKk=.86007669-e9bc-469e-8540-44a44dec43dc@github.com>

On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Chinese preview change

Identified some errors/inconsistencies you might bring to the translation team.

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

> 61: javac.opt.source=Liefert Quellkompatibilit?t mit dem angegebenen Release von Java SE.\nUnterst?tzte Releases: \n    {0}
> 62: javac.opt.Werror=Kompilierung beenden, wenn Warnungen auftreten
> 63: javac.opt.arg.Werror=<Schl?ssel>(,<Schl?ssel>)*

This value is translated for `de`, but not for `ja` or `zh_CN`. It would be ideal for to have consistency.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties line 173:

> 171: plugin.opt.disable-plugin=\      --disable-plugin <Plug-in-Name>     Deaktiviert das angegebene Plug-in
> 172: 
> 173: plugin.opt.compress=\      --compress <Komprimierung>             Komprimiert alle Ressourcen im Ausgabeimage:\n                                        Zul?ssige Werte:\n                                        zip-'{0-9}', wobei "zip-0" f?r keine Komprimierung\n                                        und "zip-9" f?r die beste Komprimierung steht.\n                                        Standardwert ist "zip-6."\n                                        Veraltete Werte, die in einem zuk?nftigen Release entfernt werden:\n                                        0:  Keine Komprimierung. Verwenden Sie stattdessen "zip-0".\n                                        1:  Gemeinsame Verwendung konstanter Zeichenfolgen\n                                        2:  ZIP. Verwenden Sie stattdessen "zip-6".

`<compress>` is translated here, but untouched in `ja` and `zh_CN`. Also it is odd the period was inserted within the `"zip-6"` string. -> `"zip-6."`

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

PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3573817418
PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615760993
PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615770109

From dnguyen at openjdk.org  Fri Dec 12 23:00:55 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 12 Dec 2025 23:00:55 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2]
In-Reply-To: <zYrI3WYfTWbzbGRXftkczVzKalvM9rswoZs6ajonzKk=.86007669-e9bc-469e-8540-44a44dec43dc@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
 <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>
 <zYrI3WYfTWbzbGRXftkczVzKalvM9rswoZs6ajonzKk=.86007669-e9bc-469e-8540-44a44dec43dc@github.com>
Message-ID: <yWJKnsO6Ee3UDHse2aZ_zHHVWanIiAPETfsmQNMJFyo=.72ffe025-d1fd-43f9-9bf2-fed4f2404fb4@github.com>

On Fri, 12 Dec 2025 22:38:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert Chinese preview change
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 63:
> 
>> 61: javac.opt.source=Liefert Quellkompatibilit?t mit dem angegebenen Release von Java SE.\nUnterst?tzte Releases: \n    {0}
>> 62: javac.opt.Werror=Kompilierung beenden, wenn Warnungen auftreten
>> 63: javac.opt.arg.Werror=<Schl?ssel>(,<Schl?ssel>)*
> 
> This value is translated for `de`, but not for `ja` or `zh_CN`. It would be ideal for to have consistency.

Thanks for finding this. I agree. I'll report this to the translation team so the Japanese and Chinese versions can be picked up as well. If it's not fixed in time for this drop, I'll include it in the next drop.

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties line 173:
> 
>> 171: plugin.opt.disable-plugin=\      --disable-plugin <Plug-in-Name>     Deaktiviert das angegebene Plug-in
>> 172: 
>> 173: plugin.opt.compress=\      --compress <Komprimierung>             Komprimiert alle Ressourcen im Ausgabeimage:\n                                        Zul?ssige Werte:\n                                        zip-'{0-9}', wobei "zip-0" f?r keine Komprimierung\n                                        und "zip-9" f?r die beste Komprimierung steht.\n                                        Standardwert ist "zip-6."\n                                        Veraltete Werte, die in einem zuk?nftigen Release entfernt werden:\n                                        0:  Keine Komprimierung. Verwenden Sie stattdessen "zip-0".\n                                        1:  Gemeinsame Verwendung konstanter Zeichenfolgen\n                                        2:  ZIP. Verwenden Sie stattdessen "zip-6".
> 
> `<compress>` is translated here, but untouched in `ja` and `zh_CN`. Also it is odd the period was inserted within the `"zip-6"` string. -> `"zip-6."`

The extra period is definitely strange. Like with above, I'll report this as well under the same issue since it seems to only be for Japanese and Chinese again. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615791381
PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615792622

From weijun at openjdk.org  Fri Dec 12 23:53:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 12 Dec 2025 23:53:59 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2]
In-Reply-To: <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
 <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>
Message-ID: <znnsJhxsw0pvRukAHz2JuWbuyt_CDTD7RZAgJmbOln8=.c3ec7c5e-a823-4de9-b4b8-38fd73e415fd@github.com>

On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Chinese preview change

src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53:

> 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1}
> 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2}
> 53: java.launcher.cls.error6=????? {0} ???? non-private ??????\n?????????? private???????\n   public {0}()

Shall we translate "non-private" into Chinese?

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

> 1635: # 0: symbol, 1: file object
> 1636: # lint: classfile
> 1637: compiler.warn.inconsistent.inner.classes={1} ? {0} ? InnerClasses ?????????\n??????? {0} ???? {1}?

I am a little unsure of this. The English value has "({1} may need to be recompiled with {0})", which can be interpreted as "compiling 1 along with 0" but the Chinese translation sounds like "compiling 1 using 0". I tried to find where this is used but cannot.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 251:

> 249: doclet.filter_table_of_contents=????
> 250: doclet.filter_reset=??
> 251: doclet.sort_table_of_contents=????????????????

Seems incorrectly copied from line 244.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615834067
PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615850080
PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615854313

From asemenyuk at openjdk.org  Sat Dec 13 04:01:51 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 13 Dec 2025 04:01:51 GMT
Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2]
In-Reply-To: <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>
References: <tf9BYo2ADy43fisszXfI2D6cqCzQpUz31fVOrcKZ7ZY=.507928e7-057a-48b7-9d7b-e83348a80ff4@github.com>
 <s9pMA1fM81ky0-NN20LeS4sFiCfSRR_JLch2HZRtuyE=.a153426e-ec16-4029-ab82-0a05c87b0ac2@github.com>
Message-ID: <WoKFNEjNWrKkiUlGDuM1yPs0y6jbEPRNaG9aeztS9XI=.65932f11-c0d5-44b5-a3f0-df38192c0105@github.com>

On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Open l10n drop. Files have been updated with translated versions.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Chinese preview change

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good: all keys are in place and translated. Can't comment on translations, though. I don't speak any of these languages.

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

PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3574161659
PR Comment: https://git.openjdk.org/jdk/pull/28802#issuecomment-3648886796