From serb at openjdk.org  Thu Jan  1 04:24:19 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 1 Jan 2026 04:24:19 GMT
Subject: Withdrawn: 8374324: Update copyright year to 2025 for jdk.compiler in
 files where it was missed
In-Reply-To: <VthsgIYKrGuYdDZiCbfO_O9rnCa26sryY8UwIcWErGY=.56d4ca81-901b-4ac2-8cc3-fa1318606adb@github.com>
References: <VthsgIYKrGuYdDZiCbfO_O9rnCa26sryY8UwIcWErGY=.56d4ca81-901b-4ac2-8cc3-fa1318606adb@github.com>
Message-ID: <S8CwKX3mQeViWyfESqIM3aG8HGdxOaWgZiG81DNVZaA=.739ef45d-ac90-47a5-b328-b39f49202c9e@github.com>

On Wed, 24 Dec 2025 05:56:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "jdk.compiler" files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Tue Jan  6 06:50:51 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jan 2026 06:50:51 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
Message-ID: <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>

On Fri, 19 Dec 2025 17:37:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove wildcard imports

This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3629653398

From djelinski at openjdk.org  Wed Jan  7 09:05:34 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 09:05:34 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
Message-ID: <04gf4mIw4A8ibXD8SGV_8CrNDyiNiriuGlIGTa1I3JA=.d5eaaabc-e0f0-4ddd-b381-f8aea75f7dca@github.com>

On Fri, 19 Dec 2025 17:37:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove wildcard imports

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3633935001

From vyazici at openjdk.org  Wed Jan  7 09:07:26 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:07:26 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
Message-ID: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>

> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Update copyright years
 - Migrate forgotten `ClearTextServerSSL`
 - Merge remote-tracking branch 'upstream/master' into simpleSslRest
 - Remove wildcard imports
 - Merge remote-tracking branch 'upstream/master' into simpleSslRest
 - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
 - Make sure `get()` returns the same instance
 - Reverted all changes and only kept `SimpleSSLContext` enhancements
 - Overhaul `SimpleSSLContext` and its usages

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

Changes: https://git.openjdk.org/jdk/pull/28905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28905&range=02
  Stats: 77 lines in 12 files changed: 4 ins; 39 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/28905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28905/head:pull/28905

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

From djelinski at openjdk.org  Wed Jan  7 09:12:15 2026
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jan 2026 09:12:15 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
Message-ID: <48aZoJx-DQzKIw3ZBTis2I56oNJHZax_Zh1PVKHhZuM=.abd44f14-aaf9-4d3c-8b86-385105cede40@github.com>

On Wed, 7 Jan 2026 09:07:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update copyright years
>  - Migrate forgotten `ClearTextServerSSL`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Remove wildcard imports
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
>  - Make sure `get()` returns the same instance
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28905#pullrequestreview-3633955099

From vyazici at openjdk.org  Wed Jan  7 09:25:04 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 09:25:04 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v3]
In-Reply-To: <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <AWn8AOcMjbME7sMsop7iqxdCNDv432Taw_-D19qIAFM=.bbaff579-eb41-46d3-80fc-541ad25f23b5@github.com>
Message-ID: <GBpdvibXcfk6QgI_JLki-rvzjtkIVFCFw3IgRIs03ec=.d2ea029e-02f4-419f-94c1-afada6af3c21@github.com>

On Wed, 7 Jan 2026 09:07:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
>> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
>> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
>> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
>> 
>> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
>> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
>> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update copyright years
>  - Migrate forgotten `ClearTextServerSSL`
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Remove wildcard imports
>  - Merge remote-tracking branch 'upstream/master' into simpleSslRest
>  - Restore all non-`httpclient`, non-`httpserver` changes in `test/`
>  - Make sure `get()` returns the same instance
>  - Reverted all changes and only kept `SimpleSSLContext` enhancements
>  - Overhaul `SimpleSSLContext` and its usages

test/jdk/com/sun/net/httpserver/ClearTextServerSSL.java line 1:

> 1: /*

This should have been addressed in [JDK-8373537], but forgotten. Doing it here.

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

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28905#discussion_r2667658921

From cushon at openjdk.org  Wed Jan  7 09:42:28 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 7 Jan 2026 09:42:28 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v5]
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: <pcIQpEM5xCNirBH44emVUVC860DVvvu7g1LSZylIHU0=.a473e362-446e-4f66-a929-24222f730cf9@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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - Fix DiagnosticGetEndPosition on windows
 - Debug DiagnosticGetEndPosition.java on windows
 - 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/a86c0446..b6497095

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

  Stats: 52134 lines in 3104 files changed: 24176 ins; 8684 del; 19274 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 lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

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

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From vyazici at openjdk.org  Wed Jan  7 15:41:20 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 15:41:20 GMT
Subject: Integrated: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods
In-Reply-To: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
Message-ID: <X8OYy1PDIL2dy5b_mrT5hQnBs5UbLpGinvMEGY3ZWNE=.b6038750-3c14-4d6f-872c-140e97deac8e@github.com>

On Thu, 18 Dec 2025 18:32:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> 1. [JDK-8372661] introduced null-safe static factory methods to `SimpleSSLContext`
> 2. [JDK-8373515] migrated `test/jdk/java/net/httpclient/` to these new methods
> 3. [JDK-8373537] migrated `test/jdk/com/sun/net/httpserver/` to these new methods
> 4. This PR migrates all remaining `SimpleSSLContext` usages, *and* removes nullable `SimpleSSLContext` factory methods
> 
> [JDK-8372661]: https://bugs.openjdk.org/browse/JDK-8372661
> [JDK-8373515]: https://bugs.openjdk.org/browse/JDK-8373515
> [JDK-8373537]: https://bugs.openjdk.org/browse/JDK-8373537

This pull request has now been integrated.

Changeset: 3541bc86
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3541bc8635ad8f5f4151758de3a134c9c105cebd
Stats:     77 lines in 12 files changed: 4 ins; 39 del; 34 mod

8373538: Migrate all tests to null-safe "SimpleSSLContext" methods

Reviewed-by: djelinski, jpai

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

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

From vyazici at openjdk.org  Wed Jan  7 15:41:19 2026
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 7 Jan 2026 15:41:19 GMT
Subject: RFR: 8373538: Migrate all tests to null-safe "SimpleSSLContext"
 methods [v2]
In-Reply-To: <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>
References: <sCGLPJ2ukUUzfQpzoU0CIzVJBGaIJuJEgKFaJF_By5g=.1ca2a9a1-80c0-455a-a252-28753d80e5d0@github.com>
 <BRyzrKsKPujdxXTgh7H_e-1rUcJdHBHmN2Pbb35wZNw=.5b8fb104-bd1f-4f88-954d-b202c091e5ed@github.com>
 <Du9iQRzUMlXeAP8mMzYOQh8nDRFq37ueXSc_Z5nu07c=.210ec2d1-cfc6-462a-a824-4f6b990fa81b@github.com>
Message-ID: <L2UJUrYrTSIoMJkOm2xLVkIghe89aZ6lfXsTsknwPe4=.78a2c70f-73b0-4e3b-9516-c29f2b29c8ac@github.com>

On Tue, 6 Jan 2026 06:48:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove wildcard imports
>
> This looks good to me.

@jaikiran, @djelinski, thanks so much for the reviews, and patience.
`SimpleSSLContext` null-safe static factory methods saga ends with this commit.

Tier 1-2 are clear on 76dae687368.

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

PR Comment: https://git.openjdk.org/jdk/pull/28905#issuecomment-3719466520

From sjohanss at openjdk.org  Fri Jan  9 08:47:01 2026
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 9 Jan 2026 08:47:01 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3]
In-Reply-To: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:
> 
>  - Merge branch '8373253' into 8367993
>  - Merge branch 'master' into _8373253
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

Thanks for looking into this Leo. 

Overall I think it looks good, just some small questions and suggestions.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637:

> 1635: 
> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const {
> 1637:   assert(_cm != nullptr, "thread must exist in order to check if mark is terminating");

I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427:

> 2425:   if (_cm->is_fully_initialized()) {
> 2426:     tc->do_thread(_cm->cm_thread());
> 2427:   }

Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549:

> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) {
> 2548:   assert(!_cm->in_progress(), "Can not start concurrent operation while in progress");
> 2549:   assert(_cm->is_fully_initialized(), "sanity");

Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert.

src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46:

> 44:     return false;
> 45:   }
> 46: 

Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right?

src/hotspot/share/gc/g1/g1Policy.cpp line 744:

> 742:   if (!_g1h->concurrent_mark()->is_fully_initialized()) {
> 743:     return false;
> 744:   }

Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127:

> 1125: 
> 1126: void G1YoungCollector::collect() {
> 1127:   _g1h->_cm->fully_initialize();

I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)`

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630

From stefank at openjdk.org  Fri Jan  9 12:09:22 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 12:09:22 GMT
Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2]
In-Reply-To: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into _8367993
>>  - 8366058: Outdated comment in WinCAPISeedGenerator
>>    
>>    Reviewed-by: mullan
>>  - 8357258: x86: Improve receiver type profiling reliability
>>    
>>    Reviewed-by: kvn, vlivanov
>>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>>    
>>    Reviewed-by: lucy, jpai
>>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>>    
>>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>>    
>>    Reviewed-by: alanb, dholmes
>>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>>    
>>    Reviewed-by: kbarrett
>>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>>    
>>    Reviewed-by: djelinski, mpowers, ascarpino
>>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>>    
>>    Reviewed-by: aboldtch
>>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>>    
>>    Reviewed-by: serb, aivanov, dnguyen
>>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767
>
> I will redo the merge, I have done something strange.

@lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels?

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315

From duke at openjdk.org  Wed Jan 14 08:48:17 2026
From: duke at openjdk.org (duke)
Date: Wed, 14 Jan 2026 08:48:17 GMT
Subject: Withdrawn: 8304408: Javadoc unexpectedly reports that hybrid snippet
 contents mismatch
In-Reply-To: <Rb4HUt_ygJ0F1Fa0NqXHekg6IHdi3aaGQCJeE3kXAYM=.0908c221-1a02-493e-b1bb-96261b7ad6f4@github.com>
References: <Rb4HUt_ygJ0F1Fa0NqXHekg6IHdi3aaGQCJeE3kXAYM=.0908c221-1a02-493e-b1bb-96261b7ad6f4@github.com>
Message-ID: <3NmtZzpj5k3C6ll6PSZ8EhRAhH0yMe_YidWsfkKPFBY=.2cbc860d-0939-4508-bb73-671ea96cbb30@github.com>

On Mon, 17 Nov 2025 17:12:45 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to ignore leading and trailing line breaks when comparing inline and external snippet contents in a hybrid snippets. It is often hard to get leading/trailing linebreaks identical between the two, and it is generally not a significant aspect in terms of consistency. 
> 
> There is an open CSR for this issue to update the section about hybrid snippets in the doc comment spec.

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.org  Thu Jan 22 11:17:30 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 22 Jan 2026 11:17:30 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v5]
In-Reply-To: <pcIQpEM5xCNirBH44emVUVC860DVvvu7g1LSZylIHU0=.a473e362-446e-4f66-a929-24222f730cf9@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <pcIQpEM5xCNirBH44emVUVC860DVvvu7g1LSZylIHU0=.a473e362-446e-4f66-a929-24222f730cf9@github.com>
Message-ID: <4szVQCAO8jEYAXogFsbCrzy4i7sdHzlTY-WzOFaB69o=.9b968dc9-86f5-432d-979b-4e29af19b333@github.com>

On Wed, 7 Jan 2026 09:42:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> 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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.
>
> 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>  - Fix DiagnosticGetEndPosition on windows
>  - Debug DiagnosticGetEndPosition.java on windows
>  - 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

As I was playing with `VirtualParser` some more, it occurred to me that storing end positions in the AST (and getting rid of the pos table) is a significant advantage in that setup, as we won't have to pay for "merging" different end pos tables (e.g. that of the VirtualParser with the one of the parent JavacParser).

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

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

From cushon at openjdk.org  Thu Jan 22 11:55:15 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 22 Jan 2026 11:55:15 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
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: <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - Fix DiagnosticGetEndPosition on windows
 - Debug DiagnosticGetEndPosition.java on windows
 - 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/b6497095..fc2f82c4

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

  Stats: 51031 lines in 956 files changed: 32094 ins; 10392 del; 8545 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 hannesw at openjdk.org  Thu Jan 22 15:30:51 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 22 Jan 2026 15:30:51 GMT
Subject: RFR: 8373679: Link color accessibility issue in dark theme
Message-ID: <0Oyqyz4GcXv2sUubB5oLYrFdFg4QehD5Yne08BseQRE=.8569c460-cec9-46e7-9696-00cbd02bb0a1@github.com>

Please review a workaround for an accessibility issue in the JavaDoc dark theme. The color used for links in the dark theme does not have enough contrast from normal text according to WCAG 2. The workaround adds underlining to links in mixed content in the dark theme to make links easier to recognize. The change is implemented with a single nested CSS rule in the block that defines the dark theme settings.

Generated documentation can be viewed here: 
https://cr.openjdk.org/~hannesw/8373679/api.00/java.base/java/lang/package-summary.html
(java.base module only, change affects dark modse only)

Compliance of generated docs with WCAG 2 contrast requirements was tested with various A11Y tools.

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

Commit messages:
 - 8373679: Link color accessibility issue in dark theme

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

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

From liach at openjdk.org  Fri Jan 23 16:07:27 2026
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jan 2026 16:07:27 GMT
Subject: RFR: 8373679: Link color accessibility issue in dark theme
In-Reply-To: <0Oyqyz4GcXv2sUubB5oLYrFdFg4QehD5Yne08BseQRE=.8569c460-cec9-46e7-9696-00cbd02bb0a1@github.com>
References: <0Oyqyz4GcXv2sUubB5oLYrFdFg4QehD5Yne08BseQRE=.8569c460-cec9-46e7-9696-00cbd02bb0a1@github.com>
Message-ID: <OPc4gwhH4-ruL2qLTLy2yoyscZotGjBrXZUdxDpz_sw=.154dba38-342b-4dc6-85fa-6f46446ae769@github.com>

On Thu, 22 Jan 2026 15:21:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a workaround for an accessibility issue in the JavaDoc dark theme. The color used for links in the dark theme does not have enough contrast from normal text according to WCAG 2. The workaround adds underlining to links in mixed content in the dark theme to make links easier to recognize. The change is implemented with a single nested CSS rule in the block that defines the dark theme settings.
> 
> Generated documentation can be viewed here: 
> https://cr.openjdk.org/~hannesw/8373679/api.00/java.base/java/lang/package-summary.html
> (java.base module only, change affects dark modse only)
> 
> Compliance of generated docs with WCAG 2 contrast requirements was tested with various A11Y tools.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29364#pullrequestreview-3698303275

From nbenalla at openjdk.org  Fri Jan 23 17:07:22 2026
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 23 Jan 2026 17:07:22 GMT
Subject: RFR: 8373679: Link color accessibility issue in dark theme
In-Reply-To: <0Oyqyz4GcXv2sUubB5oLYrFdFg4QehD5Yne08BseQRE=.8569c460-cec9-46e7-9696-00cbd02bb0a1@github.com>
References: <0Oyqyz4GcXv2sUubB5oLYrFdFg4QehD5Yne08BseQRE=.8569c460-cec9-46e7-9696-00cbd02bb0a1@github.com>
Message-ID: <ppBjqFt1yZ0YjCI_U9vALaaA1aGbAsZKO2nePP017o4=.bd9792e9-a87f-4c88-8436-13989fe1630b@github.com>

On Thu, 22 Jan 2026 15:21:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a workaround for an accessibility issue in the JavaDoc dark theme. The color used for links in the dark theme does not have enough contrast from normal text according to WCAG 2. The workaround adds underlining to links in mixed content in the dark theme to make links easier to recognize. The change is implemented with a single nested CSS rule in the block that defines the dark theme settings.
> 
> Generated documentation can be viewed here: 
> https://cr.openjdk.org/~hannesw/8373679/api.00/java.base/java/lang/package-summary.html
> (java.base module only, change affects dark modse only)
> 
> Compliance of generated docs with WCAG 2 contrast requirements was tested with various A11Y tools.

Marked as reviewed by nbenalla (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29364#pullrequestreview-3698627961

From liach at openjdk.org  Sun Jan 25 19:13:05 2026
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jan 2026 19:13:05 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement
Message-ID: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>

We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:


@jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions


Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.

As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.

I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

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

Commit messages:
 - 8376274: JSpec preview support and output enhancement

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

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

From mcimadamore at openjdk.org  Mon Jan 26 11:22:57 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 11:22:57 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
Message-ID: <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>

On Thu, 22 Jan 2026 11:55:15 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>  - Fix DiagnosticGetEndPosition on windows
>  - Debug DiagnosticGetEndPosition.java on windows
>  - 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

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2058:

> 2056:             T result = super.translate(tree);
> 2057:             if (result != null && result != tree) {
> 2058:                 result.endpos = tree.endpos;

No more ad-hoc end pos management stuff like `replaceTree` :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 113:

> 111:     private Names names;
> 112: 
> 113:     protected int errorEndPos = Position.NOPOS;

Using a simple field for error end pos makes the code more readable!

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ParserFactory.java line 92:

> 90:     }
> 91: 
> 92:     public JavacParser newParser(CharSequence input, boolean keepDocComments, boolean keepLineMap) {

Unrelated to this PR, but I wonder how much value there is in having two different factories here where the only difference is the omission of a trailing boolean param

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 675:

> 673:             case PREINC:
> 674:             case PREDEC:
> 675:                 return getEndPos(((JCOperatorExpression) tree).getOperand(RIGHT));

Is this big switch still needed? When would an end position not be set in this new world?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727231890
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727229660
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727223961
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727225292

From jlahoda at openjdk.org  Mon Jan 26 11:25:45 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 26 Jan 2026 11:25:45 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
Message-ID: <lwSYvoS3fL2JrPpdBWcTEb-Ju_4mRJK_XhMLfFbNlY8=.772bcb2f-ed55-4b54-a4e5-f21072369722@github.com>

On Thu, 22 Jan 2026 11:55:15 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>  - Fix DiagnosticGetEndPosition on windows
>  - Debug DiagnosticGetEndPosition.java on windows
>  - 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

I think this is very good, thanks. I've left two comments inline - one about the `parse` then `call`, and one nit in the other test. I also would like to run some more tests/experiments.

test/langtools/tools/javac/api/TestJavacTask_Lock.java line 72:

> 70:         fm = comp.getStandardFileManager(null, null, null);
> 71:         try {
> 72:             MethodKind first = MethodKind.CALL;

I think it would be good to preserve the behavior (i.e. prevent `parse` followed by `call` or `parse`). Otherwise, I am not sure if there may not be some a bit surprising effects (like calling `parse`, then `analyze` then `parse` again and `analyze` again might lead to some weird errors). If there would be a reason to relax this restriction, it would probably merit its own PR and own investigation of effects.

test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java line 127:

> 125:                     int line = (int) d.getLineNumber();
> 126:                     int col = (int) d.getColumnNumber();
> 127:                     String substring = implCode.split("\\R")[line - 1].substring(col - 1, col);

Nit - there could be a check that `d.getEndPosition() - d.getStartPosition()` is equal to `1`, that would make the test a bit stricter.

But this is a great change, I think!

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

PR Review: https://git.openjdk.org/jdk/pull/28610#pullrequestreview-3705362948
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727037870
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727004535

From cushon at openjdk.org  Mon Jan 26 12:13:05 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 26 Jan 2026 12:13:05 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
Message-ID: <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>

On Mon, 26 Jan 2026 11:17:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Fix DiagnosticGetEndPosition on windows
>>  - Debug DiagnosticGetEndPosition.java on windows
>>  - 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
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 675:
> 
>> 673:             case PREINC:
>> 674:             case PREDEC:
>> 675:                 return getEndPos(((JCOperatorExpression) tree).getOperand(RIGHT));
> 
> Is this big switch still needed? When would an end position not be set in this new world?

`JavacParser` is still only recording end positions for the trees where it calls `storeEnd`, so the same kinds of trees have end positions recorded in the new world. I think that potentially `JavacParser` could start recording end positions for all trees, and then this switch could be removed. I will investigate that more. If it works out, I wonder if it might be better as a separate follow-up change, to keep the initial refactoring to remove the end pos table as behaviour preserving as possible. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727365379

From cushon at openjdk.org  Mon Jan 26 13:09:54 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 26 Jan 2026 13:09:54 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v7]
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: <GtN58RJGeWzB40LIJ5C6vlsYUnHAVKOtlTOi4yCm90M=.e4354f0b-477b-41d7-a659-aee0980282fa@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.

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

  Review feedback
  
  * Improve valiation in JavacTaskImpl and revert workaround in TestJavacTask_Lock.java
  * Add an assertion to DiagnosticGetEndPosition.java
  * Update test/langtools/tools/javac/6304921/TestLog.java for EndPosTable removal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28610/files
  - new: https://git.openjdk.org/jdk/pull/28610/files/fc2f82c4..3432b139

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

  Stats: 9 lines in 3 files changed: 6 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  Mon Jan 26 13:09:59 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 26 Jan 2026 13:09:59 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <lwSYvoS3fL2JrPpdBWcTEb-Ju_4mRJK_XhMLfFbNlY8=.772bcb2f-ed55-4b54-a4e5-f21072369722@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <lwSYvoS3fL2JrPpdBWcTEb-Ju_4mRJK_XhMLfFbNlY8=.772bcb2f-ed55-4b54-a4e5-f21072369722@github.com>
Message-ID: <H1oZQw88pdU--g01PYPQOP_VXusmqn6HsGENC3T0drs=.116cf0c7-8c6f-44dd-a3b6-8b89a0bd22aa@github.com>

On Mon, 26 Jan 2026 10:13:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Fix DiagnosticGetEndPosition on windows
>>  - Debug DiagnosticGetEndPosition.java on windows
>>  - 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
>
> test/langtools/tools/javac/api/TestJavacTask_Lock.java line 72:
> 
>> 70:         fm = comp.getStandardFileManager(null, null, null);
>> 71:         try {
>> 72:             MethodKind first = MethodKind.CALL;
> 
> I think it would be good to preserve the behavior (i.e. prevent `parse` followed by `call` or `parse`). Otherwise, I am not sure if there may not be some a bit surprising effects (like calling `parse`, then `analyze` then `parse` again and `analyze` again might lead to some weird errors). If there would be a reason to relax this restriction, it would probably merit its own PR and own investigation of effects.

Thanks, I had meant to look into this more if there was interest in the overall change, so this seems like a good time to revisit it.

Currently it works because a repeated call to `PARSE`, or calling `CALL` after `PARSE`, will fail with `IllegalStateException: endPosTable already set`. I reverted the workaround in the test and added an explicit check to replace the dependency on the `EndPosTable`:


+        if (used.get())
+            throw new IllegalStateException();


I also noticed that there's no validation to disallow repeated calls to `ANALZYE`, I wonder if there should be?

> test/langtools/tools/javac/diags/DiagnosticGetEndPosition.java line 127:
> 
>> 125:                     int line = (int) d.getLineNumber();
>> 126:                     int col = (int) d.getColumnNumber();
>> 127:                     String substring = implCode.split("\\R")[line - 1].substring(col - 1, col);
> 
> Nit - there could be a check that `d.getEndPosition() - d.getStartPosition()` is equal to `1`, that would make the test a bit stricter.
> 
> But this is a great change, I think!

Thanks, done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727533728
PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2727533953

From hannesw at openjdk.org  Mon Jan 26 13:31:07 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 26 Jan 2026 13:31:07 GMT
Subject: Integrated: 8373679: Link color accessibility issue in dark theme
In-Reply-To: <0Oyqyz4GcXv2sUubB5oLYrFdFg4QehD5Yne08BseQRE=.8569c460-cec9-46e7-9696-00cbd02bb0a1@github.com>
References: <0Oyqyz4GcXv2sUubB5oLYrFdFg4QehD5Yne08BseQRE=.8569c460-cec9-46e7-9696-00cbd02bb0a1@github.com>
Message-ID: <5aAQA9lzcFzvso4fdcvPwussPNLXfi9fAg3eYgLE7Lk=.cc522754-fec8-4551-8c0d-1f1fa8b7e682@github.com>

On Thu, 22 Jan 2026 15:21:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a workaround for an accessibility issue in the JavaDoc dark theme. The color used for links in the dark theme does not have enough contrast from normal text according to WCAG 2. The workaround adds underlining to links in mixed content in the dark theme to make links easier to recognize. The change is implemented with a single nested CSS rule in the block that defines the dark theme settings.
> 
> Generated documentation can be viewed here: 
> https://cr.openjdk.org/~hannesw/8373679/api.00/java.base/java/lang/package-summary.html
> (java.base module only, change affects dark theme only)
> 
> Compliance of generated docs with WCAG 2 contrast requirements was tested with various A11Y tools.

This pull request has now been integrated.

Changeset: 37cb2282
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37cb22826a8f644c699228b8a68852b59933ead5
Stats:     8 lines in 2 files changed: 7 ins; 0 del; 1 mod

8373679: Link color accessibility issue in dark theme

Reviewed-by: liach, nbenalla

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

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

From mcimadamore at openjdk.org  Mon Jan 26 16:15:00 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 16:15:00 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
 <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
Message-ID: <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>

On Mon, 26 Jan 2026 12:09:47 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 675:
>> 
>>> 673:             case PREINC:
>>> 674:             case PREDEC:
>>> 675:                 return getEndPos(((JCOperatorExpression) tree).getOperand(RIGHT));
>> 
>> Is this big switch still needed? When would an end position not be set in this new world?
>
> `JavacParser` is still only recording end positions for the trees where it calls `storeEnd`, so the same kinds of trees have end positions recorded in the new world. I think that potentially `JavacParser` could start recording end positions for all trees, and then this switch could be removed. I will investigate that more. If it works out, I wonder if it might be better as a separate follow-up change, to keep the initial refactoring to remove the end pos table as behaviour preserving as possible. What do you think?

I think it's ok to start simple and refine as we go. As part of this change it would be perhaps helpful to at least simplify the method so that "unreachable cases" are removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2728246474

From mcimadamore at openjdk.org  Mon Jan 26 16:33:10 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 16:33:10 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
 <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
 <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>
Message-ID: <s9341kOv1a2x4sR0BuvrU4kure2cY5u_YzbwzOA7YYk=.c4ab618a-ab57-4c09-8d4c-e06f01d705c2@github.com>

On Mon, 26 Jan 2026 16:11:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `JavacParser` is still only recording end positions for the trees where it calls `storeEnd`, so the same kinds of trees have end positions recorded in the new world. I think that potentially `JavacParser` could start recording end positions for all trees, and then this switch could be removed. I will investigate that more. If it works out, I wonder if it might be better as a separate follow-up change, to keep the initial refactoring to remove the end pos table as behaviour preserving as possible. What do you think?
>
> I think it's ok to start simple and refine as we go. As part of this change it would be perhaps helpful to at least simplify the method so that "unreachable cases" are removed?

(longer term, (as discussed offline with @lahodaj ) I think it would be nice to have end positions set up correctly by parser for all trees, since now it doesn't cost extra to do so)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2728321043

From cushon at openjdk.org  Mon Jan 26 16:42:40 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 26 Jan 2026 16:42:40 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <s9341kOv1a2x4sR0BuvrU4kure2cY5u_YzbwzOA7YYk=.c4ab618a-ab57-4c09-8d4c-e06f01d705c2@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
 <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
 <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>
 <s9341kOv1a2x4sR0BuvrU4kure2cY5u_YzbwzOA7YYk=.c4ab618a-ab57-4c09-8d4c-e06f01d705c2@github.com>
Message-ID: <pFbtjciKFvHlDtnJH6C4TWfn-3Cyx3s8A9Otcg-ocVk=.7e738110-eee4-4701-89b1-a9cf6345a963@github.com>

On Mon, 26 Jan 2026 16:29:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I think it's ok to start simple and refine as we go. As part of this change it would be perhaps helpful to at least simplify the method so that "unreachable cases" are removed?
>
> (longer term, (as discussed offline with @lahodaj ) I think it would be nice to have end positions set up correctly by parser for all trees, since now it doesn't cost extra to do so)

> As part of this change it would be perhaps helpful to at least simplify the method so that "unreachable cases" are removed?

I double checked that `test/langtools/tools/javac/tree/TreePosTest.java` is exercising all of the cases in the switch here except for `TOPLEVEL` and `ERRONEOUS`, which I think my be gaps in test coverage rather than truly dead code. Do you see more unreachable cases here that I'm missing?

> (longer term, (as discussed offline with @lahodaj ) I think it would be nice to have end positions set up correctly by parser for all trees, since now it doesn't cost extra to do so)

That sounds like a good direction to me!

I was also wondering how feasible it would be to make the `pos`/`endpos` fields field final, instead of having the parser set them after the instances are constructed, but I haven't looked closely at how much refactoring that would take.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2728355597

From cushon at openjdk.org  Mon Jan 26 16:42:39 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 26 Jan 2026 16:42:39 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v8]
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: <h2DGR_rtFrIeaB8mZ5uBMR0vGCC3NAOJAlnloYfCsUU=.79cae686-f941-4d3b-9f07-47a4cd8ed929@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.

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

  Rename mapPos to endpos, there is no longer an end position map

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28610/files
  - new: https://git.openjdk.org/jdk/pull/28610/files/3432b139..e217e5f3

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

  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 liach at openjdk.org  Mon Jan 26 18:07:28 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jan 2026 18:07:28 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
Message-ID: <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>

> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
> 
> 
> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
> 
> 
> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
> 
> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
> 
> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

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

  Remove redundant dot

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29402/files
  - new: https://git.openjdk.org/jdk/pull/29402/files/f76fa06c..74af3243

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

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

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

From mcimadamore at openjdk.org  Mon Jan 26 19:33:57 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 19:33:57 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <pFbtjciKFvHlDtnJH6C4TWfn-3Cyx3s8A9Otcg-ocVk=.7e738110-eee4-4701-89b1-a9cf6345a963@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
 <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
 <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>
 <s9341kOv1a2x4sR0BuvrU4kure2cY5u_YzbwzOA7YYk=.c4ab618a-ab57-4c09-8d4c-e06f01d705c2@github.com>
 <pFbtjciKFvHlDtnJH6C4TWfn-3Cyx3s8A9Otcg-ocVk=.7e738110-eee4-4701-89b1-a9cf6345a963@github.com>
Message-ID: <n9XDOwvxJw7IWQ06xpa2Nv1b849DaB8d1AABAWGEZvA=.ad578e63-d784-47ef-bd0a-030316b1ddd9@github.com>

On Mon, 26 Jan 2026 16:38:54 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> (longer term, (as discussed offline with @lahodaj ) I think it would be nice to have end positions set up correctly by parser for all trees, since now it doesn't cost extra to do so)
>
>> As part of this change it would be perhaps helpful to at least simplify the method so that "unreachable cases" are removed?
> 
> I double checked that `test/langtools/tools/javac/tree/TreePosTest.java` is exercising all of the cases in the switch here except for `TOPLEVEL` and `ERRONEOUS`, which I think my be gaps in test coverage rather than truly dead code. Do you see more unreachable cases here that I'm missing?
> 
>> (longer term, (as discussed offline with @lahodaj ) I think it would be nice to have end positions set up correctly by parser for all trees, since now it doesn't cost extra to do so)
> 
> That sounds like a good direction to me!
> 
> I was also wondering how feasible it would be to make the `pos`/`endpos` fields field final, instead of having the parser set them after the instances are constructed, but I haven't looked closely at how much refactoring that would take.

`TreePosTest` exercises all code shapes that are present within all javac tests (I think). In practice, I think that should account for basically all the cases in the switch -- given that the compiler will have at least some tests for each of the trees involved (I hope!!)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2728903492

From cushon at openjdk.org  Mon Jan 26 19:34:03 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 26 Jan 2026 19:34:03 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <n9XDOwvxJw7IWQ06xpa2Nv1b849DaB8d1AABAWGEZvA=.ad578e63-d784-47ef-bd0a-030316b1ddd9@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
 <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
 <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>
 <s9341kOv1a2x4sR0BuvrU4kure2cY5u_YzbwzOA7YYk=.c4ab618a-ab57-4c09-8d4c-e06f01d705c2@github.com>
 <pFbtjciKFvHlDtnJH6C4TWfn-3Cyx3s8A9Otcg-ocVk=.7e738110-eee4-4701-89b1-a9cf6345a963@github.com>
 <n9XDOwvxJw7IWQ06xpa2Nv1b849DaB8d1AABAWGEZvA=.ad578e63-d784-47ef-bd0a-030316b1ddd9@github.com>
Message-ID: <WQU9hA8tjklwB44xOrDVYqWUhMc_Mk5iqS62O9wzgDY=.97b28439-56c9-4474-b8fc-01987745b1aa@github.com>

On Mon, 26 Jan 2026 19:14:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> As part of this change it would be perhaps helpful to at least simplify the method so that "unreachable cases" are removed?
>> 
>> I double checked that `test/langtools/tools/javac/tree/TreePosTest.java` is exercising all of the cases in the switch here except for `TOPLEVEL` and `ERRONEOUS`, which I think my be gaps in test coverage rather than truly dead code. Do you see more unreachable cases here that I'm missing?
>> 
>>> (longer term, (as discussed offline with @lahodaj ) I think it would be nice to have end positions set up correctly by parser for all trees, since now it doesn't cost extra to do so)
>> 
>> That sounds like a good direction to me!
>> 
>> I was also wondering how feasible it would be to make the `pos`/`endpos` fields field final, instead of having the parser set them after the instances are constructed, but I haven't looked closely at how much refactoring that would take.
>
> `TreePosTest` exercises all code shapes that are present within all javac tests (I think). In practice, I think that should account for basically all the cases in the switch -- given that the compiler will have at least some tests for each of the trees involved (I hope!!)

Ok, thanks! So if I'm understanding, the cases in the switch are currently necessary, and longer term cases can be removed as the parser is updated to store end positions directly on the additional AST node kinds. Does that sound right, or are there additional changes here that should be made now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2728947302

From mcimadamore at openjdk.org  Mon Jan 26 19:53:58 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jan 2026 19:53:58 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <WQU9hA8tjklwB44xOrDVYqWUhMc_Mk5iqS62O9wzgDY=.97b28439-56c9-4474-b8fc-01987745b1aa@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
 <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
 <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>
 <s9341kOv1a2x4sR0BuvrU4kure2cY5u_YzbwzOA7YYk=.c4ab618a-ab57-4c09-8d4c-e06f01d705c2@github.com>
 <pFbtjciKFvHlDtnJH6C4TWfn-3Cyx3s8A9Otcg-ocVk=.7e738110-eee4-4701-89b1-a9cf6345a963@github.com>
 <n9XDOwvxJw7IWQ06xpa2Nv1b849DaB8d1AABAWGEZvA=.ad578e63-d784-47ef-bd0a-030316b1ddd9@github.com>
 <WQU9hA8tjklwB44xOrDVYqWUhMc_Mk5iqS62O9wzgDY=.97b28439-56c9-4474-b8fc-01987745b1aa@github.com>
Message-ID: <bTrCTcRaVO_9mJ8nrP05lFaL-zYSkId5NGrie8nhbwc=.044e7d33-5f02-4fa3-9a14-c8cb2fb84dbc@github.com>

On Mon, 26 Jan 2026 19:29:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Ok, thanks! So if I'm understanding, the cases in the switch are currently necessary, and longer term cases can be removed as the parser is updated to store end positions directly on the additional AST node kinds. Does that sound right, or are there additional changes here that should be made now?

That is my understanding as well. (I was hoping some of them would be redundant -- but it seems that's not the case)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2729011926

From hannesw at openjdk.org  Tue Jan 27 09:17:38 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 Jan 2026 09:17:38 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
Message-ID: <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>

On Mon, 26 Jan 2026 18:07:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
>> 
>> 
>> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
>> 
>> 
>> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
>> 
>> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
>> 
>> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant dot

The change looks technically good. I have some questions regarding formatting of link labels which I have commented inline.

make/jdk/src/classes/build/tools/taglet/JSpec.java line 198:

> 196:                         // Change whole text to "?chapter.x" in inline tags.
> 197:                         literal = sectionSign + chapter + section;
> 198:                     }

What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)?

For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript <sup>PREVIEW</sup> tag like we use in API references.

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

PR Review: https://git.openjdk.org/jdk/pull/29402#pullrequestreview-3709994788
PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2730997254

From liach at openjdk.org  Tue Jan 27 13:34:12 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 13:34:12 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
Message-ID: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>

On Tue, 27 Jan 2026 09:08:14 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant dot
>
> make/jdk/src/classes/build/tools/taglet/JSpec.java line 198:
> 
>> 196:                         // Change whole text to "?chapter.x" in inline tags.
>> 197:                         literal = sectionSign + chapter + section;
>> 198:                     }
> 
> What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)?
> 
> For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript <sup>PREVIEW</sup> tag like we use in API references.

I don't add section sign before full title because that's how jls/jvms menu entries render.

For preview, you have a great point. I will add the superscript!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732028380

From liach at openjdk.org  Tue Jan 27 13:34:13 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 13:34:13 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
 <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
Message-ID: <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>

On Tue, 27 Jan 2026 13:30:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/taglet/JSpec.java line 198:
>> 
>>> 196:                         // Change whole text to "?chapter.x" in inline tags.
>>> 197:                         literal = sectionSign + chapter + section;
>>> 198:                     }
>> 
>> What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)?
>> 
>> For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript <sup>PREVIEW</sup> tag like we use in API references.
>
> I don't add section sign before full title because that's how jls/jvms menu entries render.
> 
> For preview, you have a great point. I will add the superscript!

I don't add section sign before full title because that's how jls/jvms menu entries render.

For preview, you have a great point. I will add the superscript!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732028494

From hannesw at openjdk.org  Tue Jan 27 13:51:33 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 Jan 2026 13:51:33 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
 <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
 <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>
Message-ID: <NSqEC9auz8AdsQ4Go831AclUYTXVNCoWfzLwKOWV_i8=.7daba0f6-c0fc-4f09-9664-69f96fb21dbe@github.com>

On Tue, 27 Jan 2026 13:30:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't add section sign before full title because that's how jls/jvms menu entries render.
>> 
>> For preview, you have a great point. I will add the superscript!
>
> I don't add section sign before full title because that's how jls/jvms menu entries render.
> 
> For preview, you have a great point. I will add the superscript!

Following the spec way of rendering section links sounds reasonable to me.

If you want to use the default style for the PREVIEW superscript the following should work: `<sup class="preview-mark">PREVIEW</sup>`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732101521

From jlahoda at openjdk.org  Tue Jan 27 14:07:44 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 14:07:44 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v8]
In-Reply-To: <h2DGR_rtFrIeaB8mZ5uBMR0vGCC3NAOJAlnloYfCsUU=.79cae686-f941-4d3b-9f07-47a4cd8ed929@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <h2DGR_rtFrIeaB8mZ5uBMR0vGCC3NAOJAlnloYfCsUU=.79cae686-f941-4d3b-9f07-47a4cd8ed929@github.com>
Message-ID: <I2NE9nmlghfpFZMFrhsanz_bBxh8JY4ux8lyzUIa0YU=.f6d45e20-9922-4e92-bf3a-6963a9067a62@github.com>

On Mon, 26 Jan 2026 16:42:39 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename mapPos to endpos, there is no longer an end position map

Looks good to me, thanks!

(Please give Maurizio and others some time to add more comments if needed.)

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28610#pullrequestreview-3711398649

From jlahoda at openjdk.org  Tue Jan 27 14:07:47 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Jan 2026 14:07:47 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <H1oZQw88pdU--g01PYPQOP_VXusmqn6HsGENC3T0drs=.116cf0c7-8c6f-44dd-a3b6-8b89a0bd22aa@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <lwSYvoS3fL2JrPpdBWcTEb-Ju_4mRJK_XhMLfFbNlY8=.772bcb2f-ed55-4b54-a4e5-f21072369722@github.com>
 <H1oZQw88pdU--g01PYPQOP_VXusmqn6HsGENC3T0drs=.116cf0c7-8c6f-44dd-a3b6-8b89a0bd22aa@github.com>
Message-ID: <2sgtijhuh49yjrJYGR6KlS_scZq73_1FK2IWYDhvzFc=.44c17b3c-9de6-409c-aec6-46299ec5e827@github.com>

On Mon, 26 Jan 2026 13:04:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> test/langtools/tools/javac/api/TestJavacTask_Lock.java line 72:
>> 
>>> 70:         fm = comp.getStandardFileManager(null, null, null);
>>> 71:         try {
>>> 72:             MethodKind first = MethodKind.CALL;
>> 
>> I think it would be good to preserve the behavior (i.e. prevent `parse` followed by `call` or `parse`). Otherwise, I am not sure if there may not be some a bit surprising effects (like calling `parse`, then `analyze` then `parse` again and `analyze` again might lead to some weird errors). If there would be a reason to relax this restriction, it would probably merit its own PR and own investigation of effects.
>
> Thanks, I had meant to look into this more if there was interest in the overall change, so this seems like a good time to revisit it.
> 
> Currently it works because a repeated call to `PARSE`, or calling `CALL` after `PARSE`, will fail with `IllegalStateException: endPosTable already set`. I reverted the workaround in the test and added an explicit check to replace the dependency on the `EndPosTable`:
> 
> 
> +        if (used.get())
> +            throw new IllegalStateException();
> 
> 
> I also noticed that there's no validation to disallow repeated calls to `ANALZYE`, I wonder if there should be?

Thanks! Calling `analyze` multiple time should not break anything, I think - that don't necessarily mean it is a good idea, but I suspect calling `parse` multiple times could lead to weird outcomes, so that one was more important.

I think adhering to the current behavior for now is good - we can thing and decide separately whether we want to make `parse` safe to call multiple times, restrict `analyze`, or let things be.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2732160099

From liach at openjdk.org  Tue Jan 27 14:10:05 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 14:10:05 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v2]
In-Reply-To: <NSqEC9auz8AdsQ4Go831AclUYTXVNCoWfzLwKOWV_i8=.7daba0f6-c0fc-4f09-9664-69f96fb21dbe@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <dMufV7rbWbjmu5WK9p87uPaznRBb_1w00ausOX5D5PA=.1e4ac888-eecb-42c8-8f7d-c48f008e34b5@github.com>
 <YCm3L492aMI3zQqu-rIc3IRmabhWHCcggHKz6OZDFTc=.5f8fcc59-9015-4415-898a-c1a8f47aedfd@github.com>
 <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com>
 <iUrvB91L8IAVyNmIuL7YRwhx_grFcTTJmlsIkFl05A0=.4542f907-d5f3-407f-84af-81544fe7a13d@github.com>
 <NSqEC9auz8AdsQ4Go831AclUYTXVNCoWfzLwKOWV_i8=.7daba0f6-c0fc-4f09-9664-69f96fb21dbe@github.com>
Message-ID: <ekyStJqs2mmMUd3Ka4zYMxEBQB7bxBGzJK1CLGxdDWk=.e5533909-8be4-4165-b570-7bd8cbea2876@github.com>

On Tue, 27 Jan 2026 13:48:12 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> I don't add section sign before full title because that's how jls/jvms menu entries render.
>> 
>> For preview, you have a great point. I will add the superscript!
>
> Following the spec way of rendering section links sounds reasonable to me.
> 
> If you want to use the default style for the PREVIEW superscript the following should work: `<sup class="preview-mark">PREVIEW</sup>`

Indeed, double checked, seems we cannot link to something else for the sup unlike for regular html preview links.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732183226

From cushon at openjdk.org  Tue Jan 27 14:19:58 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 27 Jan 2026 14:19:58 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v9]
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: <zB304RNwFOxwsfxus8nHE1iw4L6BHlor_cbacel_gmk=.179d7f04-bf48-41b4-8592-b221b8d797af@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.

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

 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - Rename mapPos to endpos, there is no longer an end position map
 - Review feedback
   
   * Improve valiation in JavacTaskImpl and revert workaround in TestJavacTask_Lock.java
   * Add an assertion to DiagnosticGetEndPosition.java
   * Update test/langtools/tools/javac/6304921/TestLog.java for EndPosTable removal
 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - Fix DiagnosticGetEndPosition on windows
 - Debug DiagnosticGetEndPosition.java on windows
 - 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/e217e5f3..cc227d38

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

  Stats: 13777 lines in 417 files changed: 4811 ins; 2704 del; 6262 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 Jan 27 14:26:41 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 14:26:41 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v3]
In-Reply-To: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
Message-ID: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>

> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
> 
> 
> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
> 
> 
> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
> 
> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
> 
> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

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

 - Add preview superscript when applicable
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance
 - Remove redundant dot
 - 8376274: JSpec preview support and output enhancement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29402/files
  - new: https://git.openjdk.org/jdk/pull/29402/files/74af3243..1e414f9f

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

  Stats: 3783 lines in 168 files changed: 1984 ins; 859 del; 940 mod
  Patch: https://git.openjdk.org/jdk/pull/29402.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29402/head:pull/29402

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

From hannesw at openjdk.org  Tue Jan 27 14:54:21 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 27 Jan 2026 14:54:21 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v3]
In-Reply-To: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
Message-ID: <YZjERbRgc-IVqfOFvjhmw74jYjSczBe5TZzJRjxu8yI=.62966e34-275f-457b-9da7-8b73d4804e56@github.com>

On Tue, 27 Jan 2026 14:26:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
>> 
>> 
>> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
>> 
>> 
>> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
>> 
>> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
>> 
>> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Add preview superscript when applicable
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance
>  - Remove redundant dot
>  - 8376274: JSpec preview support and output enhancement

Looks good to me!

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29402#pullrequestreview-3711671933

From liach at openjdk.org  Tue Jan 27 15:08:24 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 15:08:24 GMT
Subject: Integrated: 8376274: JSpec preview support and output enhancement
In-Reply-To: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
Message-ID: <FFg7pV-oZqDhecnVT6jCMeOBRCC78AEdewUSluWjEKQ=.c48096be-9854-4a59-8786-e7a9cdca7d44@github.com>

On Sun, 25 Jan 2026 19:06:26 GMT, Chen Liang <liach at openjdk.org> wrote:

> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
> 
> 
> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
> 
> 
> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
> 
> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
> 
> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!

This pull request has now been integrated.

Changeset: a5d0b051
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5d0b05136e34871366441a8c8e6bda5f20c617c
Stats:     65 lines in 2 files changed: 47 ins; 3 del; 15 mod

8376274: JSpec preview support and output enhancement

Reviewed-by: hannesw

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

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

From liach at openjdk.org  Tue Jan 27 15:08:22 2026
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jan 2026 15:08:22 GMT
Subject: RFR: 8376274: JSpec preview support and output enhancement [v3]
In-Reply-To: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
References: <XKjbLnYU7nmCqJMJgnIerDUxmANGwV7OoukmExTX-XE=.31e62b6f-85d8-40f5-989c-8e200fcf14f0@github.com>
 <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com>
Message-ID: <yIucgMDkRMmafW7qO21qng3T8MLeK6exQrFf7KXhK5w=.e58b55ee-9dea-418f-b6c2-2193756ade37@github.com>

On Tue, 27 Jan 2026 14:26:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR:
>> 
>> 
>> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions
>> 
>> 
>> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists.
>> 
>> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags.
>> 
>> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review!
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Add preview superscript when applicable
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance
>  - Remove redundant dot
>  - 8376274: JSpec preview support and output enhancement

Thanks for the review! I need this for Valhalla (somewhat desperately) so I will integrate immediately.

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

PR Comment: https://git.openjdk.org/jdk/pull/29402#issuecomment-3805721235

From cushon at openjdk.org  Wed Jan 28 11:24:16 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 28 Jan 2026 11:24:16 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <bTrCTcRaVO_9mJ8nrP05lFaL-zYSkId5NGrie8nhbwc=.044e7d33-5f02-4fa3-9a14-c8cb2fb84dbc@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
 <ZkcFO4C8LFrYJ9M4NeH_pqv84Qo7Qk7fxpIg2ufTuFs=.5d010bb1-6a80-43e1-a182-490c894d8842@github.com>
 <LpClHSYLJXJ8s7V_DR2lIyfXi_NG3X73DsH7WQebRMw=.48769885-568a-405c-974e-9246b4ae0c7c@github.com>
 <s9341kOv1a2x4sR0BuvrU4kure2cY5u_YzbwzOA7YYk=.c4ab618a-ab57-4c09-8d4c-e06f01d705c2@github.com>
 <pFbtjciKFvHlDtnJH6C4TWfn-3Cyx3s8A9Otcg-ocVk=.7e738110-eee4-4701-89b1-a9cf6345a963@github.com>
 <n9XDOwvxJw7IWQ06xpa2Nv1b849DaB8d1AABAWGEZvA=.ad578e63-d784-47ef-bd0a-030316b1ddd9@github.com>
 <WQU9hA8tjklwB44xOrDVYqWUhMc_Mk5iqS62O9wzgDY=.97b28439-56c9-4474-b8fc-01987745b1aa@github.com>
 <bTrCTcRaVO_9mJ8nrP05lFaL-zYSkId5NGrie8nhbwc=.044e7d33-5f02-4fa3-9a14-c8cb2fb84dbc@github.com>
Message-ID: <TIwTNC_2ERnkAsJRxJg6d8PvEbUmvi3x-uw2wl7MgEA=.b7319d59-ddd4-479a-b9c8-790c5936bc04@github.com>

On Mon, 26 Jan 2026 19:50:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Ok, thanks! So if I'm understanding, the cases in the switch are currently necessary, and longer term cases can be removed as the parser is updated to store end positions directly on the additional AST node kinds. Does that sound right, or are there additional changes here that should be made now?
>
>> Ok, thanks! So if I'm understanding, the cases in the switch are currently necessary, and longer term cases can be removed as the parser is updated to store end positions directly on the additional AST node kinds. Does that sound right, or are there additional changes here that should be made now?
> 
> That is my understanding as well. (I was hoping some of them would be redundant -- but it seems that's not the case)

I filed https://bugs.openjdk.org/browse/JDK-8372948 to keep track of this, and have a draft in https://github.com/openjdk/jdk/pull/29463 in that passes tests. I need to give more thought to how to ensure the invariants we want are being maintained, and that nodes that should have end positions always have them after that change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2736177100

From hannesw at openjdk.org  Wed Jan 28 19:22:40 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 Jan 2026 19:22:40 GMT
Subject: [jdk26] RFR: 8373679: Link color accessibility issue in dark theme
Message-ID: <6O77v7JaQ6_Fmubv1444qkgl1C_wsMY2sJIA84KWTxM=.7f41446a-6686-4890-945b-56be8aa7d2b5@github.com>

Hi all,

This pull request contains a backport of commit 37cb22826a8f644c699228b8a68852b59933ead5 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Hannes Wallnoefer on 26 Jan 2026 and was reviewed by Chen Liang and Nizar Benalla.

Thanks!

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

Commit messages:
 - Backport 37cb22826a8f644c699228b8a68852b59933ead5

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

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

From liach at openjdk.org  Wed Jan 28 19:28:11 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jan 2026 19:28:11 GMT
Subject: [jdk26] RFR: 8373679: Link color accessibility issue in dark theme
In-Reply-To: <6O77v7JaQ6_Fmubv1444qkgl1C_wsMY2sJIA84KWTxM=.7f41446a-6686-4890-945b-56be8aa7d2b5@github.com>
References: <6O77v7JaQ6_Fmubv1444qkgl1C_wsMY2sJIA84KWTxM=.7f41446a-6686-4890-945b-56be8aa7d2b5@github.com>
Message-ID: <TD-pzgAlIFm84RvY_65ITGtr6J255QBm2V3BZhI3TfY=.9dcc3568-7b18-4f31-a434-0898c675e267@github.com>

On Wed, 28 Jan 2026 19:14:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 37cb22826a8f644c699228b8a68852b59933ead5 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hannes Wallnoefer on 26 Jan 2026 and was reviewed by Chen Liang and Nizar Benalla.
> 
> Thanks!

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29470#pullrequestreview-3718670784

From nbenalla at openjdk.org  Wed Jan 28 19:40:34 2026
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 28 Jan 2026 19:40:34 GMT
Subject: [jdk26] RFR: 8373679: Link color accessibility issue in dark theme
In-Reply-To: <6O77v7JaQ6_Fmubv1444qkgl1C_wsMY2sJIA84KWTxM=.7f41446a-6686-4890-945b-56be8aa7d2b5@github.com>
References: <6O77v7JaQ6_Fmubv1444qkgl1C_wsMY2sJIA84KWTxM=.7f41446a-6686-4890-945b-56be8aa7d2b5@github.com>
Message-ID: <KULbtU3ARRBlctggegyaPGbksETdYM5IDhHCs332148=.5aee0aca-c84f-490f-bc03-5db6e5919925@github.com>

On Wed, 28 Jan 2026 19:14:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 37cb22826a8f644c699228b8a68852b59933ead5 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hannes Wallnoefer on 26 Jan 2026 and was reviewed by Chen Liang and Nizar Benalla.
> 
> Thanks!

This is a safe workaround for the issue.

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

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29470#pullrequestreview-3718745212

From hannesw at openjdk.org  Wed Jan 28 20:55:20 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 28 Jan 2026 20:55:20 GMT
Subject: [jdk26] Integrated: 8373679: Link color accessibility issue in dark
 theme
In-Reply-To: <6O77v7JaQ6_Fmubv1444qkgl1C_wsMY2sJIA84KWTxM=.7f41446a-6686-4890-945b-56be8aa7d2b5@github.com>
References: <6O77v7JaQ6_Fmubv1444qkgl1C_wsMY2sJIA84KWTxM=.7f41446a-6686-4890-945b-56be8aa7d2b5@github.com>
Message-ID: <SAVN6skmy7cu_BjuIRlDw2Ove1HwheSs-UoR-KdW4GA=.a5728f9e-e5e4-403c-9e07-3fa0b4481fa2@github.com>

On Wed, 28 Jan 2026 19:14:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 37cb22826a8f644c699228b8a68852b59933ead5 from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Hannes Wallnoefer on 26 Jan 2026 and was reviewed by Chen Liang and Nizar Benalla.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 4cc46607
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4cc4660724427c8a13b0a0f20872786c508b26c7
Stats:     8 lines in 2 files changed: 7 ins; 0 del; 1 mod

8373679: Link color accessibility issue in dark theme

Reviewed-by: liach, nbenalla
Backport-of: 37cb22826a8f644c699228b8a68852b59933ead5

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

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

From cushon at openjdk.org  Fri Jan 30 23:00:52 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 30 Jan 2026 23:00:52 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v10]
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: <qPwYvXWLH5PgP2mdqxWeSrszc6YgrbK4giTarpIcUTA=.e4abdd43-a787-4712-8089-e8bd59942cdc@github.com>

> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this compiler-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. Also the test logic didn't handle platform specific line ending variations correctly, so I updated it to work on windows now that end positions are present.

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

  Update newParser call sites

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28610/files
  - new: https://git.openjdk.org/jdk/pull/28610/files/cc227d38..9f1d44fd

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

  Stats: 5 lines in 2 files changed: 0 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  Fri Jan 30 23:00:56 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 30 Jan 2026 23:00:56 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <imuictogskvB5N5EmUDLwekgd0Jaokj_4WR3-wznInQ=.f08eab71-fff9-4ab8-be6f-699306047976@github.com>
 <aZBveiNUvD46DBMzISp7zs43xEmjPIVoSkG69PbQ7Bw=.f17b5bf7-95f6-47d9-9531-c5dc92d90ef7@github.com>
Message-ID: <o9J1XcaYWJxVlDXejv6y5k0hYwGA9NIKqkcQHyNm-C4=.fb3eb4cf-1ef1-4d09-9b50-483c32e21b97@github.com>

On Mon, 26 Jan 2026 11:17:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>>  - Fix DiagnosticGetEndPosition on windows
>>  - Debug DiagnosticGetEndPosition.java on windows
>>  - 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
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/ParserFactory.java line 92:
> 
>> 90:     }
>> 91: 
>> 92:     public JavacParser newParser(CharSequence input, boolean keepDocComments, boolean keepLineMap) {
> 
> Unrelated to this PR, but I wonder how much value there is in having two different factories here where the only difference is the omission of a trailing boolean param

Another thing about these overloads I just realized is that before and after this change there is an overload that takes three boolean parameters, but the meaning of them has changed: `keepDocComments, keepEndPos, keepLineMap` vs `keepDocComments, keepLineMap, parseModuleInfo`.

I'd forgotten to update some call sites because they still compiled. I have fixed them now, and it didn't matter in those cases because they were passing `false` for all of the options, but it does show these overloads could be bug-prone.

I'd be happy to try to improve this as a follow up if you think that'd be worthwhile. Having a single `newParser` overload could be safer because it forces callers to update if the signature changes again. Another possibility might be something like `parserFactory.newParser(input).keepDocComments(true).keepLineMap(true).parse()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28610#discussion_r2748297774