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: References:

Message-ID: <6zy9MUKvY9TI0qeScmP1blGj3Dx4Y_bYOOMrrHXa1bY=.215eb030-625b-44f5-b6f6-538ce0a04b2c@github.com> On Fri, 30 Jan 2026 22:55:00 GMT, Liam Miller-Cushon 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: References: Message-ID: > 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: References:

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

<6zy9MUKvY9TI0qeScmP1blGj3Dx4Y_bYOOMrrHXa1bY=.215eb030-625b-44f5-b6f6-538ce0a04b2c@github.com> Message-ID: On Tue, 3 Feb 2026 10:07:59 GMT, Jan Lahoda 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: References:

Message-ID: On Tue, 3 Feb 2026 10:23:32 GMT, Liam Miller-Cushon wrote: >> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this 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: <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com> Message-ID: On Tue, 3 Feb 2026 11:55:05 GMT, Liam Miller-Cushon wrote: >> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this 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 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: <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com> Message-ID: On Tue, 3 Feb 2026 11:55:05 GMT, Liam Miller-Cushon wrote: >> This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this 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 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: References: <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com> Message-ID: On Tue, 3 Feb 2026 12:18:08 GMT, Jan Lahoda 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: References: Message-ID: On Tue, 2 Dec 2025 16:05:27 GMT, Liam Miller-Cushon wrote: > This change adds a field to `JCTree` to store end positions, instead of using a separate `EndPosTable` map. See also [this 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 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: References: <8bPWtAubiO0ufcXGHhnr8zDhF7h_5idlZBkWQydlmGM=.0e5fe26a-e300-427d-a62f-c0c8cdb9f004@github.com>

Message-ID: <9l9MgfPN9avG4828y4VoflQJtQwDRLnk2lSoA5WAWGI=.7969b138-7167-482e-9a0a-81ff5d775b9a@github.com> On Wed, 4 Feb 2026 07:12:34 GMT, Jan Lahoda 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 duke at openjdk.org Thu Feb 12 03:08:06 2026 From: duke at openjdk.org (duke) Date: Thu, 12 Feb 2026 03:08:06 GMT Subject: Withdrawn: 8309748: Improve host selection in `External Specifications` page In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 08:45:01 GMT, Hannes Walln?fer wrote: > Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. > > - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html) > - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion > > I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28863