From shade at openjdk.org  Mon Feb  2 07:45:03 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Feb 2026 07:45:03 GMT
Subject: RFR: 8376355: Update to use jtreg 8.2.1
In-Reply-To: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
References: <dyYpHQfiCIDTwVouMHgEd7tIH2ZODtzHHmbkvi0gNF8=.1471e4d3-d4b0-4117-9257-c929480a59e0@github.com>
Message-ID: <EVYNFQU-7ISvX5Pq3Z-s772BaYmiW6W02_eW3y4B_dk=.36312348-2e66-4ff2-9bb1-4b71ed37ee31@github.com>

On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 8.2.1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

Nice to see no actual test changes are required for compatibility.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3737777336

From jlahoda at openjdk.org  Tue Feb  3 10:11:08 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Feb 2026 10:11:08 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <o9J1XcaYWJxVlDXejv6y5k0hYwGA9NIKqkcQHyNm-C4=.fb3eb4cf-1ef1-4d09-9b50-483c32e21b97@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>
 <o9J1XcaYWJxVlDXejv6y5k0hYwGA9NIKqkcQHyNm-C4=.fb3eb4cf-1ef1-4d09-9b50-483c32e21b97@github.com>
Message-ID: <6zy9MUKvY9TI0qeScmP1blGj3Dx4Y_bYOOMrrHXa1bY=.215eb030-625b-44f5-b6f6-538ce0a04b2c@github.com>

On Fri, 30 Jan 2026 22:55:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> 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()`.

For me - I think there was a time where the idea was that some of the internal APIs (like to parser factories) would be evolved somewhat "compatibly". I don't think that's necessary anymore (and compatible evolution is not being done anyway), esp. for things like parser factories. So, for me: we can clear the factories and only keep one, that's OK and will improve maintainability.

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

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

From cushon at openjdk.org  Tue Feb  3 10:23:32 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 3 Feb 2026 10:23:32 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v11]
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: <ieyt1waLMEyn6-GrZ3zLdalW-AGl_7jI74bW7S6vc4w=.a450dab0-8d77-4762-b85b-84a5793e6209@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:

  Remove overload of ParserFactor#newParser

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

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

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

  Stats: 10 lines in 3 files changed: 0 ins; 5 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 jlahoda at openjdk.org  Tue Feb  3 10:23:33 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Feb 2026 10:23:33 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v10]
In-Reply-To: <qPwYvXWLH5PgP2mdqxWeSrszc6YgrbK4giTarpIcUTA=.e4abdd43-a787-4712-8089-e8bd59942cdc@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <qPwYvXWLH5PgP2mdqxWeSrszc6YgrbK4giTarpIcUTA=.e4abdd43-a787-4712-8089-e8bd59942cdc@github.com>
Message-ID: <7lfw2Vo5NBOmtDLn_QMogw5ez_EtGh_e7Q33LiIhJbE=.072d0a59-8ea6-4d6a-ae53-526eb62b879b@github.com>

On Fri, 30 Jan 2026 23:00:52 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:
> 
>   Update newParser call sites

Marked as reviewed by jlahoda (Reviewer).

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

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

From cushon at openjdk.org  Tue Feb  3 10:23:35 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 3 Feb 2026 10:23:35 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v6]
In-Reply-To: <6zy9MUKvY9TI0qeScmP1blGj3Dx4Y_bYOOMrrHXa1bY=.215eb030-625b-44f5-b6f6-538ce0a04b2c@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>
 <o9J1XcaYWJxVlDXejv6y5k0hYwGA9NIKqkcQHyNm-C4=.fb3eb4cf-1ef1-4d09-9b50-483c32e21b97@github.com>
 <6zy9MUKvY9TI0qeScmP1blGj3Dx4Y_bYOOMrrHXa1bY=.215eb030-625b-44f5-b6f6-538ce0a04b2c@github.com>
Message-ID: <yTKhKEKfnva0IQz-wk0Hd90FJavz8O7k4Y18VbJ1xGs=.80adbd77-9ea7-4b3c-9e67-0a6e14dc7cea@github.com>

On Tue, 3 Feb 2026 10:07:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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()`.
>
> For me - I think there was a time where the idea was that some of the internal APIs (like to parser factories) would be evolved somewhat "compatibly". I don't think that's necessary anymore (and compatible evolution is not being done anyway), esp. for things like parser factories. So, for me: we can clear the factories and only keep one, that's OK and will improve maintainability.

That sounds good to me, I went ahead and updated this to just have the one overload.

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

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

From mcimadamore at openjdk.org  Tue Feb  3 11:05:47 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 11:05:47 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v11]
In-Reply-To: <ieyt1waLMEyn6-GrZ3zLdalW-AGl_7jI74bW7S6vc4w=.a450dab0-8d77-4762-b85b-84a5793e6209@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <ieyt1waLMEyn6-GrZ3zLdalW-AGl_7jI74bW7S6vc4w=.a450dab0-8d77-4762-b85b-84a5793e6209@github.com>
Message-ID: <rXL5j9CBLad43B1Ua9Z-yQBmUg0DvKfPvxaLtc3CVTM=.e5af804e-2eea-4162-afc3-091b0ec54403@github.com>

On Tue, 3 Feb 2026 10:23:32 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:
> 
>   Remove overload of ParserFactor#newParser

Looks good. Thanks for working on this!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.org  Tue Feb  3 11:11:18 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 11:11:18 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
Message-ID: <qYcv8fuY7DqI199axNAdeG0ekfxJkYw1OXvuaqYrY5k=.ec5f4b86-be9e-4671-acbf-63c1a9b0cfb8@github.com>

On Wed, 28 Jan 2026 16:27:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Updating copyright headers.
>  - Making the skipping of base checks more clear.
>  - Reflecting review feedback - cleanup.

The latest iteration looks solid. Ship it!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27256#pullrequestreview-3744633936

From mcimadamore at openjdk.org  Tue Feb  3 11:11:20 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 11:11:20 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <FKzlNQ7fr4qZHRf3YxRUC2UlWQ3Hl1snUsxN4IMAh_I=.3b8f129e-adea-4b11-ba49-60f8b630eb42@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
 <Q-FtMMpGoAXvjp3sFgK-NA7Vsu2IiROLxEK546SzaKE=.47d2f9a9-f77b-4ead-9f94-be305be1f800@github.com>
 <FKzlNQ7fr4qZHRf3YxRUC2UlWQ3Hl1snUsxN4IMAh_I=.3b8f129e-adea-4b11-ba49-60f8b630eb42@github.com>
Message-ID: <wGJwa45RPgg-XEURGSgLk7lOr4gzH7wkIyaXw66cVS4=.d7cf1c1a-56ee-41ec-aa28-2f8f3a9677b9@github.com>

On Wed, 28 Jan 2026 18:48:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 333:
>> 
>>> 331:                            case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R1 _)) -> 0;
>>> 332:                            case Root(R2 _, R2(R1 _, R2 _), R2(R1 _, R2 _)) -> 0;
>>> 333: //                           case Root(R2 _, R2(R1 _, R2 _), R2(R2 _, R1 _)) -> 0;
>> 
>> it could be confusing to have commented code in a test, I guess probably to just remove the commented code?
>
> These commented-out cases are the ones that are missing from the switch to be exhaustive. I kept them there intentionally, so see what the user might have missed, so that it can be compared with what javac reports. I can add comments to them if desired.

I'm ok with these comments -- I'm a bit less ok with the ones that say "this might be better in this form" -- either we file these case as follow up bugs, or we might as well remove the comments, as I don't think a comment in a test is the best way to track issues/further improvements

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

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

From cushon at openjdk.org  Tue Feb  3 11:55:05 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 3 Feb 2026 11:55:05 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v12]
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: <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@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 14 additional commits since the last revision:

 - Fix more references to newParser
 - Merge remote-tracking branch 'origin/master' into JDK-8372948
 - Remove overload of ParserFactor#newParser
 - Update newParser call sites
 - 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
 - ... and 4 more: https://git.openjdk.org/jdk/compare/72d5f2a0...f375f9a6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28610/files
  - new: https://git.openjdk.org/jdk/pull/28610/files/31284071..f375f9a6

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

  Stats: 46344 lines in 610 files changed: 21798 ins; 15694 del; 8852 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  Tue Feb  3 11:55:06 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 3 Feb 2026 11:55:06 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v11]
In-Reply-To: <ieyt1waLMEyn6-GrZ3zLdalW-AGl_7jI74bW7S6vc4w=.a450dab0-8d77-4762-b85b-84a5793e6209@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <ieyt1waLMEyn6-GrZ3zLdalW-AGl_7jI74bW7S6vc4w=.a450dab0-8d77-4762-b85b-84a5793e6209@github.com>
Message-ID: <AWEdfP0KnUfQtyQZMhw9nlScUuTFpWEVBbV6Kk5NqaI=.01a95090-fbc7-405e-9584-b4235d24439a@github.com>

On Tue, 3 Feb 2026 10:23:32 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:
> 
>   Remove overload of ParserFactor#newParser

Thanks for the reviews!

There were two references to `newParser` I missed updated earlier, which I have now fixed. I also merged in the latest changes from master, and double checked that tier1 is still passing.

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

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

From jlahoda at openjdk.org  Tue Feb  3 12:20:28 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Feb 2026 12:20:28 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v12]
In-Reply-To: <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com>
Message-ID: <w15ilg1vhB3AJ4ZHP6cu3nu1SclEUy6kkMCJQxO-iKs=.b370650d-f105-4b8e-8e54-e628fb4b6f87@github.com>

On Tue, 3 Feb 2026 11:55:05 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 14 additional commits since the last revision:
> 
>  - Fix more references to newParser
>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>  - Remove overload of ParserFactor#newParser
>  - Update newParser call sites
>  - 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
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9aee903f...f375f9a6

FWIW, I've submitted a test run, will comment here when it finishes.

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

Marked as reviewed by jlahoda (Reviewer).

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

From vromero at openjdk.org  Tue Feb  3 13:58:24 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 13:58:24 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
Message-ID: <ES3XuKAHZQkjGs0Wwo_TD44C-UAykUYFMFJOySAW70c=.cfb72c7e-7f09-43b3-a4ba-798ed9d1464f@github.com>

On Wed, 28 Jan 2026 16:27:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Updating copyright headers.
>  - Making the skipping of base checks more clear.
>  - Reflecting review feedback - cleanup.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 656:

> 654:             }
> 655:             if (covered) {
> 656:                 PatternDescription pd = new BindingPattern(rpOne.recordType, -1, Set.of(pattern));

shouldn't this `-1` be: `NO_BASE_CHECKS_COUNTING`?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 744:

> 742: 
> 743:         public BindingPattern(Type type) {
> 744:             this(type, -1, Set.of());

same here -1 -> NO_BASE_CHECKS_COUNTING

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

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

From jlahoda at openjdk.org  Tue Feb  3 14:39:13 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Feb 2026 14:39:13 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v17]
In-Reply-To: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
Message-ID: <Q3bFKBzQLbOSiz4ccfapcANhYiFWUz1LUHyEFJg5D7o=.f51c2a99-8bc8-4f5b-9370-ec55290f7ef8@github.com>

> Consider code like:
> 
> package test;
> public class Test {
>     private int test(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> ``` 
> 
> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> The goal of this PR is to improve the error, at least in some cases to something along these lines:
> 
> $ javac test/Test.java 
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
>   missing patterns:
>       Root(R2(R2 _), R2(R2 _))
> 1 error
> 
> 
> The (very simplified) way it works in a recursive (or induction) way:
> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
> - for a current missing pattern, try to enhance it:
>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
> 
> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
> 
> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
> 
> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
> 
> There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated.

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

  Cleanup: permittedSubtypes in BindingPattern is not needed anymore.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27256/files
  - new: https://git.openjdk.org/jdk/pull/27256/files/539760bc..17e65e43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27256&range=15-16

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

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

From jlahoda at openjdk.org  Tue Feb  3 14:39:16 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 3 Feb 2026 14:39:16 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <ES3XuKAHZQkjGs0Wwo_TD44C-UAykUYFMFJOySAW70c=.cfb72c7e-7f09-43b3-a4ba-798ed9d1464f@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
 <ES3XuKAHZQkjGs0Wwo_TD44C-UAykUYFMFJOySAW70c=.cfb72c7e-7f09-43b3-a4ba-798ed9d1464f@github.com>
Message-ID: <1xivIHAw1s0prGQT4Ie9Etr2fww-96ZXd1ZBiQDDruE=.15700758-4edd-4e2e-8bd5-03cee49a9703@github.com>

On Tue, 3 Feb 2026 13:55:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Updating copyright headers.
>>  - Making the skipping of base checks more clear.
>>  - Reflecting review feedback - cleanup.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 656:
> 
>> 654:             }
>> 655:             if (covered) {
>> 656:                 PatternDescription pd = new BindingPattern(rpOne.recordType, -1, Set.of(pattern));
> 
> shouldn't this `-1` be: `NO_BASE_CHECKS_COUNTING`?

The `-1` here was the number of permitted subtypes, so not quite `NO_BASE_CHECKS_COUNTING`. But, looking at it, the component is not needed anymore, so removed. Thanks!

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

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

From vromero at openjdk.org  Tue Feb  3 15:23:38 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 15:23:38 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v17]
In-Reply-To: <Q3bFKBzQLbOSiz4ccfapcANhYiFWUz1LUHyEFJg5D7o=.f51c2a99-8bc8-4f5b-9370-ec55290f7ef8@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <Q3bFKBzQLbOSiz4ccfapcANhYiFWUz1LUHyEFJg5D7o=.f51c2a99-8bc8-4f5b-9370-ec55290f7ef8@github.com>
Message-ID: <NqamdUwsXH7-4epYgU2eapbJRFf2VEiH9Uy-EXl5Lp0=.368ea31b-7e89-45b7-9d0a-4bb5838e8887@github.com>

On Tue, 3 Feb 2026 14:39:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package test;
>> public class Test {
>>     private int test(Root r) {
>>         return switch (r) {
>>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>>         };
>>     }
>>     sealed interface Base {}
>>     record R1() implements Base {}
>>     record R2(Base b1) implements Base {}
>>     record Root(R2 b2, R2 b3) {}
>> }
>> ``` 
>> 
>> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
>> 
>> $ javac test/Test.java
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>> 1 error
>> 
>> 
>> The goal of this PR is to improve the error, at least in some cases to something along these lines:
>> 
>> $ javac test/Test.java 
>> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>>         return switch (r) {
>>                ^
>>   missing patterns:
>>       Root(R2(R2 _), R2(R2 _))
>> 1 error
>> 
>> 
>> The (very simplified) way it works in a recursive (or induction) way:
>> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
>> - for a current missing pattern, try to enhance it:
>>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
>> 
>> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
>> 
>> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
>> 
>> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
>> 
>> There's also an open possibility for select tools to delay the more detailed computation to some late...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup: permittedSubtypes in BindingPattern is not needed anymore.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27256#pullrequestreview-3745904969

From vromero at openjdk.org  Tue Feb  3 15:23:41 2026
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Feb 2026 15:23:41 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <1xivIHAw1s0prGQT4Ie9Etr2fww-96ZXd1ZBiQDDruE=.15700758-4edd-4e2e-8bd5-03cee49a9703@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
 <ES3XuKAHZQkjGs0Wwo_TD44C-UAykUYFMFJOySAW70c=.cfb72c7e-7f09-43b3-a4ba-798ed9d1464f@github.com>
 <1xivIHAw1s0prGQT4Ie9Etr2fww-96ZXd1ZBiQDDruE=.15700758-4edd-4e2e-8bd5-03cee49a9703@github.com>
Message-ID: <mp_Oksks3FXo-Ktu9AUohK7ruZhpJK5If_ldZzt0amI=.313c6cf3-6afb-4be8-a042-5e2804d53558@github.com>

On Tue, 3 Feb 2026 14:35:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 656:
>> 
>>> 654:             }
>>> 655:             if (covered) {
>>> 656:                 PatternDescription pd = new BindingPattern(rpOne.recordType, -1, Set.of(pattern));
>> 
>> shouldn't this `-1` be: `NO_BASE_CHECKS_COUNTING`?
>
> The `-1` here was the number of permitted subtypes, so not quite `NO_BASE_CHECKS_COUNTING`. But, looking at it, the component is not needed anymore, so removed. Thanks!

oh I see, thanks!

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

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

From hannesw at openjdk.org  Tue Feb  3 15:59:07 2026
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 3 Feb 2026 15:59:07 GMT
Subject: RFR: 8284315: DocTrees.getElement is inconsistent with
 Elements.getTypeElement
Message-ID: <1_5SfOm0z3EagmWtn4tupsfmUmnnte7mOYqp2_LW4u0=.b3de6083-033b-4a0b-9457-c53b5b758b45@github.com>

Please review a change that brings the implementation of `DocTrees.getElement(DocTreePath)` in agreement with `javax.lang.model` behavior by returning `null` for `DocTree` instances referring to a primitive or array type. Additionally, this adds some missing functionality to the implementation of the related `DocTrees.getType(DocTreePath)` method and improves test coverage for both methods. 

Internally, the member lookup part in method `JavacTrees.attributeDocReference` is split into a separate `resolveMember` method that can also be used by `getType`. 

We also improve attribution of references with explicit module name by attempting to attribute the referenced type and checking whether the module matches the name in the reference afterwards. This allows us to support parameterized types in references with explicit module id. 

In `test/langtools/tools/javac/doctree/ReferenceTest.java` we add some missing test coverage such as for type parameter references, and add tests for `DocTrees.getType(DocTreePath)` to the existing tests for `DocTrees.getElement(DocTreePath)`. The former was previously ony covered in javadoc tests.

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

Commit messages:
 - 8284315: DocTrees.getElement is inconsistent with Elements.getTypeElement

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

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

From mcimadamore at openjdk.org  Tue Feb  3 16:56:59 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 16:56:59 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v12]
In-Reply-To: <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com>
Message-ID: <O5X77Yn3TTKeEqhHHAkFJllHBnRZOG9DnzOqr8RZB9k=.e88bca2c-0327-4f39-b2d8-a4b45fdae236@github.com>

On Tue, 3 Feb 2026 11:55:05 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 14 additional commits since the last revision:
> 
>  - Fix more references to newParser
>  - Merge remote-tracking branch 'origin/master' into JDK-8372948
>  - Remove overload of ParserFactor#newParser
>  - Update newParser call sites
>  - 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
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f694e34d...f375f9a6

Marked as reviewed by mcimadamore (Reviewer).

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

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

From mcimadamore at openjdk.org  Tue Feb  3 17:05:23 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Feb 2026 17:05:23 GMT
Subject: RFR: 8371162: Compiler warns about implicit cast from long to int
 in shift operation [v4]
In-Reply-To: <Bc30dnU3c9iVDE9YhMAZ0ri874RMuIiZtr2RvbDk_R4=.a21c755e-fbb8-4dbf-8e27-6cd7a0538275@github.com>
References: <k4m-HBFZ0NKc30wP-ALb2ZmrdyE53FHBP6BlSXHf3Cg=.cbc39f00-e458-4009-8061-7fdc835a6f67@github.com>
 <Bc30dnU3c9iVDE9YhMAZ0ri874RMuIiZtr2RvbDk_R4=.a21c755e-fbb8-4dbf-8e27-6cd7a0538275@github.com>
Message-ID: <3ZcjQ4YgG12VXHurgy_YJzNYdHiTBs7eYq0qwqDA9Kc=.67292804-57e4-4b3e-9ff2-ff0c423d10d5@github.com>

On Sun, 4 Jan 2026 18:40:25 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Consider code like this:
>> 
>> int x = 1;
>> x <<= 1L;
>> 
>> The compiler currently emits this warning:
>> 
>> warning: [lossy-conversions] implicit cast from long to int in compound assignment is possibly lossy
>>         x <<= 1L;
>>               ^
>> 
>> By definition, bit shift operations only use the bottom 5 or 6 bits of the specified shift amount (in this example, `1L`), and the JLS does not require the shift amount to be any specific integral type, only that that it be some integral type. So as long all but the bottom 5 or 6 bits are zero, there is no loss of information and the warning is inappropriate.
>> 
>> The case where the bottom 5 or 6 bits are _not_ all zero is addressed separately in [JDK-5038439](https://bugs.openjdk.org/browse/JDK-5038439).
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Update copyrights to 2026.
>  - Merge branch 'master' into JDK-8371162
>  - Merge branch 'master' into JDK-8371162 to fix conflict.
>  - Use cleaner switch statement syntax.
>  - Avoid lossy conversion warnings for 64 bit shift amounts.

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

> 4002:                               owntype);
> 4003:             switch (tree.getTag()) {
> 4004:             case SL_ASG, SR_ASG, USR_ASG -> { }     // we only use (at most) the lower 6 bits, so any integral type is OK

It's true that there's no loss of precision. One possible thing we might want to do (low priority) is to issue a lint warning if we see a constant value that exceeds the max shift amount.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28180#discussion_r2760084504

From acobbs at openjdk.org  Tue Feb  3 17:16:18 2026
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Feb 2026 17:16:18 GMT
Subject: RFR: 8371162: Compiler warns about implicit cast from long to int
 in shift operation [v4]
In-Reply-To: <3ZcjQ4YgG12VXHurgy_YJzNYdHiTBs7eYq0qwqDA9Kc=.67292804-57e4-4b3e-9ff2-ff0c423d10d5@github.com>
References: <k4m-HBFZ0NKc30wP-ALb2ZmrdyE53FHBP6BlSXHf3Cg=.cbc39f00-e458-4009-8061-7fdc835a6f67@github.com>
 <Bc30dnU3c9iVDE9YhMAZ0ri874RMuIiZtr2RvbDk_R4=.a21c755e-fbb8-4dbf-8e27-6cd7a0538275@github.com>
 <3ZcjQ4YgG12VXHurgy_YJzNYdHiTBs7eYq0qwqDA9Kc=.67292804-57e4-4b3e-9ff2-ff0c423d10d5@github.com>
Message-ID: <67jsMI2pUIqcutyFd55CQnZ_9hKwrUVniWXCXnhQtCU=.a1a665bd-c85a-4d29-9498-98c6f26fe71e@github.com>

On Tue, 3 Feb 2026 17:01:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> It's true that there's no loss of precision. One possible thing we might want to do (low priority) is to issue a lint warning if we see a constant value that exceeds the max shift amount.

Indeed... but I think that should already be taken care of (separately) by [JDK-5038439](https://bugs.openjdk.org/browse/JDK-5038439) (PR #27102), no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28180#discussion_r2760132472

From jlamperth at openjdk.org  Tue Feb  3 20:53:56 2026
From: jlamperth at openjdk.org (Jonathan =?UTF-8?B?TMOhc3psw7M=?= =?UTF-8?B?IA==?= =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Tue, 3 Feb 2026 20:53:56 GMT
Subject: RFR: 8376534: Source launcher instantiates wrong class on inherited
 instance main
Message-ID: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>

Fix a bug where, for inherited instance main methods, the source launcher attempts to invoke main on an instance of the superclass/superinterface that declares main, instead of on an instance of the inheriting class.

<details closed>
  <summary>Failure Example</summary>


// A.java
class A extends B {}
?
// B.java
class B {
    void main() {
        System.out.println(getClass().getName());
    }
}



$ java A.java
B // expected "A" here
?
$ java B.java
B
``` 
</details>

Note: There is still an issue with inheriting main from a different package in modular mode, which will be handled separately [JDK-8377010](https://bugs.openjdk.org/browse/JDK-8377010)

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

Commit messages:
 - Ensure source launcher instantiates correct class for inherited main

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

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

From liach at openjdk.org  Wed Feb  4 05:05:27 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 05:05:27 GMT
Subject: RFR: 8376534: Source launcher instantiates wrong class on
 inherited instance main
In-Reply-To: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>
References: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>
Message-ID: <xQ5pblw99HBbwAQM3RocffTEqTNnTG-_h3yb6NLFOHY=.d5965464-7266-4269-a563-edfd32dda60a@github.com>

On Tue, 3 Feb 2026 20:46:06 GMT, Jonathan L?szl? Lamp?rth <jlamperth at openjdk.org> wrote:

> Fix a bug where, for inherited instance main methods, the source launcher attempts to invoke main on an instance of the superclass/superinterface that declares main, instead of on an instance of the inheriting class.
> 
> <details closed>
>   <summary>Failure Example</summary>
> 
> 
> // A.java
> class A extends B {}
> ?
> // B.java
> class B {
>     void main() {
>         System.out.println(getClass().getName());
>     }
> }
> 
> 
> 
> $ java A.java
> B // expected "A" here
> ?
> $ java B.java
> B
> ``` 
> </details>
> 
> Note: There is still an issue with inheriting main from a different package in modular mode, which will be handled separately [JDK-8377010](https://bugs.openjdk.org/browse/JDK-8377010)

Good. For [JDK-8377010](https://bugs.openjdk.org/browse/JDK-8377010), I recommend using MethodHandles.lookup for resolution of members inherited across modules.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29550#pullrequestreview-3748985899

From jlahoda at openjdk.org  Wed Feb  4 07:15:47 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Feb 2026 07:15:47 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v12]
In-Reply-To: <w15ilg1vhB3AJ4ZHP6cu3nu1SclEUy6kkMCJQxO-iKs=.b370650d-f105-4b8e-8e54-e628fb4b6f87@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com>
 <w15ilg1vhB3AJ4ZHP6cu3nu1SclEUy6kkMCJQxO-iKs=.b370650d-f105-4b8e-8e54-e628fb4b6f87@github.com>
Message-ID: <Zg3Q8U2TftLErvcSxptX1M-5I7BW_aR_Nij47nvZV0Y=.aedb636c-f736-4aa4-9375-f1eca42bafac@github.com>

On Tue, 3 Feb 2026 12:18:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> FWIW, I've submitted a test run, will comment here when it finishes.

Tests finished OK, so this seems OK to integrate.

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

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

From cushon at openjdk.org  Wed Feb  4 08:28:12 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 4 Feb 2026 08:28:12 GMT
Subject: Integrated: 8372948: Store end positions directly in JCTree
In-Reply-To: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
Message-ID: <YNWYPuxDVqp_9I-NFgukXFnLI0EpxtyLmbj_vGz-pcg=.e8a4ab5f-cb01-4b2e-9cdd-9b0f94cb88dd@github.com>

On Tue, 2 Dec 2025 16:05:27 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.

This pull request has now been integrated.

Changeset: b0829a54
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0829a54cd787d5e378573f69ec0b82b40602454
Stats:     583 lines in 32 files changed: 18 ins; 451 del; 114 mod

8372948: Store end positions directly in JCTree

Reviewed-by: jlahoda, mcimadamore

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

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

From cushon at openjdk.org  Wed Feb  4 08:28:11 2026
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 4 Feb 2026 08:28:11 GMT
Subject: RFR: 8372948: Store end positions directly in JCTree [v12]
In-Reply-To: <Zg3Q8U2TftLErvcSxptX1M-5I7BW_aR_Nij47nvZV0Y=.aedb636c-f736-4aa4-9375-f1eca42bafac@github.com>
References: <I_CI2CdxpCnZqfcDWgbi_2aUXs6rNorCwvshI-gln4g=.4a0611fb-2b1d-4d06-be2e-b19efc11303e@github.com>
 <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com>
 <w15ilg1vhB3AJ4ZHP6cu3nu1SclEUy6kkMCJQxO-iKs=.b370650d-f105-4b8e-8e54-e628fb4b6f87@github.com>
 <Zg3Q8U2TftLErvcSxptX1M-5I7BW_aR_Nij47nvZV0Y=.aedb636c-f736-4aa4-9375-f1eca42bafac@github.com>
Message-ID: <9l9MgfPN9avG4828y4VoflQJtQwDRLnk2lSoA5WAWGI=.7969b138-7167-482e-9a0a-81ff5d775b9a@github.com>

On Wed, 4 Feb 2026 07:12:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > FWIW, I've submitted a test run, will comment here when it finishes.
> 
> Tests finished OK, so this seems OK to integrate.

Thanks for verifying that!

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

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

From jlahoda at openjdk.org  Wed Feb  4 08:41:07 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Feb 2026 08:41:07 GMT
Subject: RFR: 8367530: The exhaustiveness errors could be improved [v16]
In-Reply-To: <wGJwa45RPgg-XEURGSgLk7lOr4gzH7wkIyaXw66cVS4=.d7cf1c1a-56ee-41ec-aa28-2f8f3a9677b9@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
 <pGWr16nCDtNfIOphSVCs59iByUHdfAK_mxGOfBlXaOQ=.4a593b23-22a5-46b8-8360-f170839ea621@github.com>
 <Q-FtMMpGoAXvjp3sFgK-NA7Vsu2IiROLxEK546SzaKE=.47d2f9a9-f77b-4ead-9f94-be305be1f800@github.com>
 <FKzlNQ7fr4qZHRf3YxRUC2UlWQ3Hl1snUsxN4IMAh_I=.3b8f129e-adea-4b11-ba49-60f8b630eb42@github.com>
 <wGJwa45RPgg-XEURGSgLk7lOr4gzH7wkIyaXw66cVS4=.d7cf1c1a-56ee-41ec-aa28-2f8f3a9677b9@github.com>
Message-ID: <byrnKH41h8KS__AiWjeTrHdogt63z6Sls9pV3NL22uI=.aa1b1172-f37b-489c-aa70-e712a2cd6f5c@github.com>

On Tue, 3 Feb 2026 11:07:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> These commented-out cases are the ones that are missing from the switch to be exhaustive. I kept them there intentionally, so see what the user might have missed, so that it can be compared with what javac reports. I can add comments to them if desired.
>
> I'm ok with these comments -- I'm a bit less ok with the ones that say "this might be better in this form" -- either we file these case as follow up bugs, or we might as well remove the comments, as I don't think a comment in a test is the best way to track issues/further improvements

I've filled:
https://bugs.openjdk.org/browse/JDK-8377147

for me, the purpose of the comment here is to make the situation clearer for the reader of the test.

Thanks!

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

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

From jlahoda at openjdk.org  Wed Feb  4 11:07:16 2026
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Feb 2026 11:07:16 GMT
Subject: Integrated: 8367530: The exhaustiveness errors could be improved
In-Reply-To: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
References: <Wl8jSZg_Ao5uLZQTcwj3NvcOUD__x2eUSojhkxvkUZs=.11a724c0-3e04-4580-9540-1e56777a75a6@github.com>
Message-ID: <N8RPHpnrGTQr9ccLTszuLX_xUKgcaNlwa-l-z8g-u-o=.f221ae06-2d73-486b-be92-a58816d70074@github.com>

On Fri, 12 Sep 2025 11:45:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package test;
> public class Test {
>     private int test(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> ``` 
> 
> This is missing a case for `Root(R2(R2 _), R2(R2 _))`. javac will produce an error correctly, but the error is not very helpful:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> The goal of this PR is to improve the error, at least in some cases to something along these lines:
> 
> $ javac test/Test.java 
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
>   missing patterns:
>       Root(R2(R2 _), R2(R2 _))
> 1 error
> 
> 
> The (very simplified) way it works in a recursive (or induction) way:
> - start with defining the missing pattern as the binding pattern for the selector type. This would certainly exhaust the switch.
> - for a current missing pattern, try to enhance it:
>     - if the current type is a sealed type, try to expand to its (direct) permitted subtypes. Remove those that are not needed.
>     - if the current (binding pattern) type is a record type, expand it to a record type, generate all possible combinations of its component types based on sealed hierarchies. Remove those that are not needed.
> 
> This approach relies heavily on our ability to compute exhaustiveness, which is evaluated repeatedly in the process.
> 
> There are some cases where the algorithm does not produce ideal results (see the tests), but overall seems much better than what we have now.
> 
> Another significant limitation is the speed of the process. Evaluating exhaustiveness is not a fast process, and this algorithm evaluates exhaustiveness repeatedly, potentially for many combinations of patterns (esp. for record patterns). So part of the proposal here is to have a time deadline for the computation. The default is 5s, and can be changed by `-XDexhaustivityTimeout=<timeout-in-ms>`.
> 
> There's also an open possibility for select tools to delay the more detailed computation to some later time, although that would need to be tried and evaluated.

This pull request has now been integrated.

Changeset: 84e8787d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84e8787d1fdfe2d92f8b2c9b959651d8d63be91b
Stats:     1498 lines in 16 files changed: 1399 ins; 49 del; 50 mod

8367530: The exhaustiveness errors could be improved

Reviewed-by: vromero, mcimadamore

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

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

From mcimadamore at openjdk.org  Wed Feb  4 11:14:31 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Feb 2026 11:14:31 GMT
Subject: RFR: 8371162: Compiler warns about implicit cast from long to int
 in shift operation [v4]
In-Reply-To: <67jsMI2pUIqcutyFd55CQnZ_9hKwrUVniWXCXnhQtCU=.a1a665bd-c85a-4d29-9498-98c6f26fe71e@github.com>
References: <k4m-HBFZ0NKc30wP-ALb2ZmrdyE53FHBP6BlSXHf3Cg=.cbc39f00-e458-4009-8061-7fdc835a6f67@github.com>
 <Bc30dnU3c9iVDE9YhMAZ0ri874RMuIiZtr2RvbDk_R4=.a21c755e-fbb8-4dbf-8e27-6cd7a0538275@github.com>
 <3ZcjQ4YgG12VXHurgy_YJzNYdHiTBs7eYq0qwqDA9Kc=.67292804-57e4-4b3e-9ff2-ff0c423d10d5@github.com>
 <67jsMI2pUIqcutyFd55CQnZ_9hKwrUVniWXCXnhQtCU=.a1a665bd-c85a-4d29-9498-98c6f26fe71e@github.com>
Message-ID: <3ruLZv7mCuHhgdx-ZOWLILWlh4OS0qQgkRbt8FzLUTY=.ad79c032-a09f-4303-9458-3787f8d8b9e7@github.com>

On Tue, 3 Feb 2026 17:13:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4004:
>> 
>>> 4002:                               owntype);
>>> 4003:             switch (tree.getTag()) {
>>> 4004:             case SL_ASG, SR_ASG, USR_ASG -> { }     // we only use (at most) the lower 6 bits, so any integral type is OK
>> 
>> It's true that there's no loss of precision. One possible thing we might want to do (low priority) is to issue a lint warning if we see a constant value that exceeds the max shift amount.
>
>> It's true that there's no loss of precision. One possible thing we might want to do (low priority) is to issue a lint warning if we see a constant value that exceeds the max shift amount.
> 
> Indeed... but I think that should already be taken care of (separately) by [JDK-5038439](https://bugs.openjdk.org/browse/JDK-5038439) (PR #27102), no?

Ha! I missed that. Great!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28180#discussion_r2763463780

From jlamperth at openjdk.org  Wed Feb  4 21:45:49 2026
From: jlamperth at openjdk.org (Jonathan =?UTF-8?B?TMOhc3psw7M=?= =?UTF-8?B?IA==?= =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Wed, 4 Feb 2026 21:45:49 GMT
Subject: RFR: 8376534: Source launcher instantiates wrong class on
 inherited instance main [v2]
In-Reply-To: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>
References: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>
Message-ID: <jceeBnNgxG_ia0I4sfzH6iFiNaVM7zz-y09-GhlkpEc=.c9ccc11b-58be-4130-bd35-3506bba2ebca@github.com>

> Fix a bug where, for inherited instance main methods, the source launcher attempts to invoke main on an instance of the superclass/superinterface that declares main, instead of on an instance of the inheriting class.
> 
> <details closed>
>   <summary>Failure Example</summary>
> 
> 
> // A.java
> class A extends B {}
> ?
> // B.java
> class B {
>     void main() {
>         System.out.println(getClass().getName());
>     }
> }
> 
> 
> 
> $ java A.java
> B // expected "A" here
> ?
> $ java B.java
> B
> ``` 
> </details>
> 
> Note: There is still an issue with inheriting main from a different package in modular mode, which will be handled separately [JDK-8377010](https://bugs.openjdk.org/browse/JDK-8377010)

Jonathan L?szl? Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:

  Add JBS ID to @bug in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29550/files
  - new: https://git.openjdk.org/jdk/pull/29550/files/caa72b71..8adfad3e

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

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

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

From liach at openjdk.org  Wed Feb  4 22:29:24 2026
From: liach at openjdk.org (Chen Liang)
Date: Wed, 4 Feb 2026 22:29:24 GMT
Subject: RFR: 8376534: Source launcher instantiates wrong class on
 inherited instance main [v2]
In-Reply-To: <jceeBnNgxG_ia0I4sfzH6iFiNaVM7zz-y09-GhlkpEc=.c9ccc11b-58be-4130-bd35-3506bba2ebca@github.com>
References: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>
 <jceeBnNgxG_ia0I4sfzH6iFiNaVM7zz-y09-GhlkpEc=.c9ccc11b-58be-4130-bd35-3506bba2ebca@github.com>
Message-ID: <sJSrui3uhgH-HlEtVqTlOaskSGVLzg6D6959wDeLGno=.a7eb0a09-ac5e-43bc-9b39-b3a645a770ed@github.com>

On Wed, 4 Feb 2026 21:45:49 GMT, Jonathan L?szl? Lamp?rth <jlamperth at openjdk.org> wrote:

>> Fix a bug where, for inherited instance main methods, the source launcher attempts to invoke main on an instance of the superclass/superinterface that declares main, instead of on an instance of the inheriting class.
>> 
>> <details closed>
>>   <summary>Failure Example</summary>
>> 
>> 
>> // A.java
>> class A extends B {}
>> ?
>> // B.java
>> class B {
>>     void main() {
>>         System.out.println(getClass().getName());
>>     }
>> }
>> 
>> 
>> 
>> $ java A.java
>> B // expected "A" here
>> ?
>> $ java B.java
>> B
>> ``` 
>> </details>
>> 
>> Note: There is still an issue with inheriting main from a different package in modular mode, which will be handled separately [JDK-8377010](https://bugs.openjdk.org/browse/JDK-8377010)
>
> Jonathan L?szl? Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JBS ID to @bug in test

Bug number addition looks trivially good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29550#pullrequestreview-3753605576

From darcy at openjdk.org  Wed Feb  4 22:41:56 2026
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Feb 2026 22:41:56 GMT
Subject: RFR: 8376534: Source launcher instantiates wrong class on
 inherited instance main [v2]
In-Reply-To: <jceeBnNgxG_ia0I4sfzH6iFiNaVM7zz-y09-GhlkpEc=.c9ccc11b-58be-4130-bd35-3506bba2ebca@github.com>
References: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>
 <jceeBnNgxG_ia0I4sfzH6iFiNaVM7zz-y09-GhlkpEc=.c9ccc11b-58be-4130-bd35-3506bba2ebca@github.com>
Message-ID: <ysyeO5D_ESXyDv-XwZ3d0-uPBds8bBE3cpbqngPIBu4=.e2950cc3-4bc4-40d4-8347-7c4712dd33eb@github.com>

On Wed, 4 Feb 2026 21:45:49 GMT, Jonathan L?szl? Lamp?rth <jlamperth at openjdk.org> wrote:

>> Fix a bug where, for inherited instance main methods, the source launcher attempts to invoke main on an instance of the superclass/superinterface that declares main, instead of on an instance of the inheriting class.
>> 
>> <details closed>
>>   <summary>Failure Example</summary>
>> 
>> 
>> // A.java
>> class A extends B {}
>> ?
>> // B.java
>> class B {
>>     void main() {
>>         System.out.println(getClass().getName());
>>     }
>> }
>> 
>> 
>> 
>> $ java A.java
>> B // expected "A" here
>> ?
>> $ java B.java
>> B
>> ``` 
>> </details>
>> 
>> Note: There is still an issue with inheriting main from a different package in modular mode, which will be handled separately [JDK-8377010](https://bugs.openjdk.org/browse/JDK-8377010)
>
> Jonathan L?szl? Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JBS ID to @bug in test

@jonath4ndev, please file a CSR for the behavior change of the PR.

(From a quick skim, it isn't clear to me if any spec update is needed as well.)

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

PR Comment: https://git.openjdk.org/jdk/pull/29550#issuecomment-3850097731

From cstein at openjdk.org  Fri Feb  6 14:15:11 2026
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 6 Feb 2026 14:15:11 GMT
Subject: RFR: 8376534: Source launcher instantiates wrong class on
 inherited instance main [v2]
In-Reply-To: <jceeBnNgxG_ia0I4sfzH6iFiNaVM7zz-y09-GhlkpEc=.c9ccc11b-58be-4130-bd35-3506bba2ebca@github.com>
References: <FrGiBX-U7FYlmro9Utftw2speVsVHxO0V7l2J2beFj0=.6a4b66d2-5ed7-4de3-aa56-80822b53c2f6@github.com>
 <jceeBnNgxG_ia0I4sfzH6iFiNaVM7zz-y09-GhlkpEc=.c9ccc11b-58be-4130-bd35-3506bba2ebca@github.com>
Message-ID: <ZTS-3rBg-JhGuARd2w27vtU5pm5ZcvyCpFw5Pb_8wfo=.67c1403f-995d-4f3f-8883-f70ca090da81@github.com>

On Wed, 4 Feb 2026 21:45:49 GMT, Jonathan L?szl? Lamp?rth <jlamperth at openjdk.org> wrote:

>> Fix a bug where, for inherited instance main methods, the source launcher attempts to invoke main on an instance of the superclass/superinterface that declares main, instead of on an instance of the inheriting class.
>> 
>> <details closed>
>>   <summary>Failure Example</summary>
>> 
>> 
>> // A.java
>> class A extends B {}
>> ?
>> // B.java
>> class B {
>>     void main() {
>>         System.out.println(getClass().getName());
>>     }
>> }
>> 
>> 
>> 
>> $ java A.java
>> B // expected "A" here
>> ?
>> $ java B.java
>> B
>> ``` 
>> </details>
>> 
>> Note: There is still an issue with inheriting main from a different package in modular mode, which will be handled separately [JDK-8377010](https://bugs.openjdk.org/browse/JDK-8377010)
>
> Jonathan L?szl? Lamp?rth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JBS ID to @bug in test

Implementation and new tests look good.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29550#pullrequestreview-3763345546