From duke at openjdk.org  Mon Nov  3 08:47:08 2025
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Mon, 3 Nov 2025 08:47:08 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme
In-Reply-To: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
Message-ID: <PbOO5CzFYqvDkxg7QGD-n5ePAFR3AVVGbOCzEmbcfMI=.36dd5d6a-6662-4b48-87c2-5ce6189d8643@github.com>

On Fri, 31 Oct 2025 13:30:06 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
> 
> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
> 
> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
> 
> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).

Changes look good, thanks!

With this it is now more feasible to share dark/light mode icons via themed variables like `--x-svg` (instead of `--x-svg-dark`). This would let us drop some scattered CSS blocks and keep light/dark logic centralized.

<details>
<summary>Such blocks could be removed</summary>


:root[data-theme="theme-dark"] input#reset-search,
:root[data-theme="theme-dark"] input.reset-filter,
:root[data-theme="theme-dark"] input#page-search-reset {
    background-image: var(--x-svg-dark);
}

</details>

<details>
<summary>I would envision something like this</summary>


:root {
    --x-svg: url('x.svg');
}

:root[data-theme="theme-dark"] {
    --x-svg: url('data:image/svg+xml; utf8, <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><path d="m8 8 84 84" style="stroke:%23e0e0e0;stroke-width:15;stroke-linecap:round"/><path d="M8 92 92 8" style="stroke:%23e0e0e0;stroke-width:15;stroke-linecap:round"/></svg>');
}

</details>

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/28085#issuecomment-3479454752

From hannesw at openjdk.org  Mon Nov  3 09:06:05 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 Nov 2025 09:06:05 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme
In-Reply-To: <4yZU1a4FFqS0EVPO8TLeisXaxv722Tb40LupDQ2tBuw=.56e52a93-17dc-4b4c-afe7-4c2a2a968576@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <4yZU1a4FFqS0EVPO8TLeisXaxv722Tb40LupDQ2tBuw=.56e52a93-17dc-4b4c-afe7-4c2a2a968576@github.com>
Message-ID: <PyVe_nGYDFWvd02EJarvmQ4Z880bpL0uTa9A-kJyrT0=.5b2b8b8a-3a87-4899-a9d8-2b7a22fbc08d@github.com>

On Fri, 31 Oct 2025 22:48:45 GMT, Chen Liang <liach at openjdk.org> wrote:

> What is the purpose of the padding change? I see the padding is now narrower, but the bar is still thicker than in 25.

The button was just a bit large, both compared to nearby elements such as the filter input, and to other buttons in the UI such as the theme picker or copy-to-clipboard button. Now it's the same size as the other buttons (32 x 32 px). (Image button size is content + 2 * padding, so padding has to be adjusted to the image.) Using `px` as unit is also a bit more consistent with other buttons.

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

PR Comment: https://git.openjdk.org/jdk/pull/28085#issuecomment-3479537630

From hannesw at openjdk.org  Mon Nov  3 10:45:43 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 Nov 2025 10:45:43 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v2]
In-Reply-To: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
Message-ID: <4n3NZogRiZPiJcU0KIrYlTur3OyQ4F1VbuNQWLVzr-I=.7872e63c-96ad-41ac-8ed4-f0180bc001f6@github.com>

> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
> 
> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
> 
> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
> 
> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Further improve theme styles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28085/files
  - new: https://git.openjdk.org/jdk/pull/28085/files/5af88406..919e3ae6

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

  Stats: 69 lines in 2 files changed: 33 ins; 31 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28085/head:pull/28085

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

From hannesw at openjdk.org  Mon Nov  3 11:18:42 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 Nov 2025 11:18:42 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v3]
In-Reply-To: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
Message-ID: <OmvLvPioDajFqwnQtUjEiUbnml8-f6s9BlIo0dKNccM=.be9f13b9-6948-418f-808b-59438ef7e722@github.com>

> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
> 
> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
> 
> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
> 
> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  More cleanup and better separation of TOC button styles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28085/files
  - new: https://git.openjdk.org/jdk/pull/28085/files/919e3ae6..35ee5df0

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

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

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

From hannesw at openjdk.org  Mon Nov  3 11:33:02 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 Nov 2025 11:33:02 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme
In-Reply-To: <PbOO5CzFYqvDkxg7QGD-n5ePAFR3AVVGbOCzEmbcfMI=.36dd5d6a-6662-4b48-87c2-5ce6189d8643@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <PbOO5CzFYqvDkxg7QGD-n5ePAFR3AVVGbOCzEmbcfMI=.36dd5d6a-6662-4b48-87c2-5ce6189d8643@github.com>
Message-ID: <KKlDzn9Hwpn6BElD82HOdMzkXkOs5whfjSJPFjm_U1k=.c5e3fc5e-c7d2-4589-b044-391acb9b7370@github.com>

On Mon, 3 Nov 2025 08:44:28 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> With this it is now more feasible to share dark/light mode icons via themed variables like --x-svg (instead of --x-svg-dark).

Thanks for the excellent suggestion, I updated the PR. 

I also made some further tweaks to TOC button styles:

 - Change hover border color to the one intended for the purpose (`--button-border-color`), which is more visible especially in dark theme
 - Move the positioning for the hide/show sidebar buttons into a separate ruleset that does not apply to the sort button
 - Tweak TOC size and position of hide/show buttons so that the hide button doesn't overlap the TOC (which moved down a bit because of the added sort button)

I uploaded the stylesheet of the [sample docs](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/java/lang/Thread.html#setUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)) in-place, you may have to shift-reload to fetch the new version of the stylesheet.

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

PR Comment: https://git.openjdk.org/jdk/pull/28085#issuecomment-3480050871

From duke at openjdk.org  Mon Nov  3 12:31:56 2025
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Mon, 3 Nov 2025 12:31:56 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v3]
In-Reply-To: <OmvLvPioDajFqwnQtUjEiUbnml8-f6s9BlIo0dKNccM=.be9f13b9-6948-418f-808b-59438ef7e722@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <OmvLvPioDajFqwnQtUjEiUbnml8-f6s9BlIo0dKNccM=.be9f13b9-6948-418f-808b-59438ef7e722@github.com>
Message-ID: <4ulSSwdIQrp1s3qerUozzxBGodq2tqc6sKgfFNUgPfU=.e9e401ce-19f7-441b-8aca-e03129be57cf@github.com>

On Mon, 3 Nov 2025 11:18:42 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
>> 
>> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
>> 
>> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
>> 
>> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup and better separation of TOC button styles

Changes look great!

I would probably define the following outside of the `:root` blocks, and leave that to be variable definitions only:

    button#theme-button img.light-theme-icon {
        display: inline;
    }
    button#theme-button img.dark-theme-icon {
        display: none;
    }


Probably the best solution would be to store `--current-theme-svg=url(moon.svg)`, `--current-theme-svg=url(sun.svg)`and use the `background` property for this button too?

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

PR Comment: https://git.openjdk.org/jdk/pull/28085#issuecomment-3480282575

From jlahoda at openjdk.org  Mon Nov  3 16:19:27 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 3 Nov 2025 16:19:27 GMT
Subject: RFR: 8370334: javadoc NPE with "import module" statement [v2]
In-Reply-To: <GRLKBDs8vNSlUUd8flL5bRBReojOpZVolH5DZwt7INM=.f750d5f7-8ba5-4938-8f00-5a09e4a152af@github.com>
References: <GRLKBDs8vNSlUUd8flL5bRBReojOpZVolH5DZwt7INM=.f750d5f7-8ba5-4938-8f00-5a09e4a152af@github.com>
Message-ID: <EM6uL9hjTvcVzncLUXhnPdSRIGfUR_7RHS6LkyDJgqc=.dfadb575-0077-44b8-bc1f-45915e9611bd@github.com>

> `Modules.enter` completes all root modules, but in case of additional modules being added to the module graph via `Modules.addExtraAddModules` (either from javadoc, or using the `CompilationTask.addModules`, these extra modules may not be completed at this time. Normally, they are completed eventually, but if their `module-info`s contain `import module`, an NPE will appear while checking the import, before the complete happens.
> 
> The proposal herein is to consistently complete all modules in the module graph when the module graphs is setup.

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

  Don't eagerly complete the unnamed module.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27974/files
  - new: https://git.openjdk.org/jdk/pull/27974/files/ff2162ee..14ac910e

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

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

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

From hannesw at openjdk.org  Mon Nov  3 16:45:20 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 Nov 2025 16:45:20 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v4]
In-Reply-To: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
Message-ID: <_3pWKgGiRVWvoM2vtNXS_w2dpkl0YaWZ3_Q0XisgVG4=.0f4edc16-e30e-4e4c-bafd-df6f676c2cda@github.com>

> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
> 
> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
> 
> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
> 
> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Simplify theme button

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28085/files
  - new: https://git.openjdk.org/jdk/pull/28085/files/35ee5df0..1e832573

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

  Stats: 95 lines in 6 files changed: 2 ins; 70 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/28085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28085/head:pull/28085

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

From hannesw at openjdk.org  Mon Nov  3 16:45:22 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 3 Nov 2025 16:45:22 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v3]
In-Reply-To: <4ulSSwdIQrp1s3qerUozzxBGodq2tqc6sKgfFNUgPfU=.e9e401ce-19f7-441b-8aca-e03129be57cf@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <OmvLvPioDajFqwnQtUjEiUbnml8-f6s9BlIo0dKNccM=.be9f13b9-6948-418f-808b-59438ef7e722@github.com>
 <4ulSSwdIQrp1s3qerUozzxBGodq2tqc6sKgfFNUgPfU=.e9e401ce-19f7-441b-8aca-e03129be57cf@github.com>
Message-ID: <fd_W3133hKO3aj-xz3IAId66qxBci9wkzlg-Ck5cK38=.6e346622-8be2-4794-afe5-df2309f74d6b@github.com>

On Mon, 3 Nov 2025 12:28:49 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> Probably the best solution would be to store --current-theme-svg=url(moon.svg), --current-theme-svg=url(sun.svg)and use the background property for this button too?

D'oh! Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28085#issuecomment-3481477221

From duke at openjdk.org  Mon Nov  3 16:49:05 2025
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Mon, 3 Nov 2025 16:49:05 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v4]
In-Reply-To: <_3pWKgGiRVWvoM2vtNXS_w2dpkl0YaWZ3_Q0XisgVG4=.0f4edc16-e30e-4e4c-bafd-df6f676c2cda@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <_3pWKgGiRVWvoM2vtNXS_w2dpkl0YaWZ3_Q0XisgVG4=.0f4edc16-e30e-4e4c-bafd-df6f676c2cda@github.com>
Message-ID: <Fj7Ma3uPmv2R3CMuRXOJWMHDuv-5hbXvEYXRcUx5QXE=.4679ef57-2266-4074-90ee-cb5c7585f1eb@github.com>

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

>> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
>> 
>> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
>> 
>> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
>> 
>> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify theme button

LGTM!

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

Marked as reviewed by jonath4ndev at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/28085#pullrequestreview-3411959028

From hannesw at openjdk.org  Tue Nov  4 08:23:59 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Nov 2025 08:23:59 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v5]
In-Reply-To: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
Message-ID: <-YRwgUItser3CBalGWDEAqwB-UzdwWbHgEJxly_Or7w=.70a5a8ee-1edc-444a-bdc0-28944ec0c524@github.com>

> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
> 
> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
> 
> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
> 
> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Move theme panel out of navigation list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28085/files
  - new: https://git.openjdk.org/jdk/pull/28085/files/1e832573..aafcf7db

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

  Stats: 158 lines in 4 files changed: 6 ins; 152 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28085/head:pull/28085

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

From hannesw at openjdk.org  Tue Nov  4 08:35:39 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Nov 2025 08:35:39 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v5]
In-Reply-To: <-YRwgUItser3CBalGWDEAqwB-UzdwWbHgEJxly_Or7w=.70a5a8ee-1edc-444a-bdc0-28944ec0c524@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <-YRwgUItser3CBalGWDEAqwB-UzdwWbHgEJxly_Or7w=.70a5a8ee-1edc-444a-bdc0-28944ec0c524@github.com>
Message-ID: <keF0lw0V7P2g9A-SGaNcXURp4TWW0RZwVz9MaGPa29U=.38e7fe5c-7096-4598-bd8c-435ddebc0f45@github.com>

On Tue, 4 Nov 2025 08:23:59 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
>> 
>> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
>> 
>> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
>> 
>> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move theme panel out of navigation list

Thanks, Jonathan. I've made another small change to move the theme panel out of the navigation list, where it doesn't belong, to immediately after the list. Tab order will still be correct as long as the theme button is the last item in the navigation list.

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

PR Comment: https://git.openjdk.org/jdk/pull/28085#issuecomment-3484569686

From hannesw at openjdk.org  Tue Nov  4 10:52:03 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Nov 2025 10:52:03 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v6]
In-Reply-To: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
Message-ID: <bk9SHDffUYtKl1VNh9rAgFJdpyXRXd-vU19CxNRhmN8=.afb5dc31-b982-4d11-954d-57b5f71ec71d@github.com>

> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
> 
> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
> 
> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
> 
> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Fix sizing bugs in mobile TOC introduced with dark theme

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28085/files
  - new: https://git.openjdk.org/jdk/pull/28085/files/aafcf7db..750e5f9a

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

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

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

From hannesw at openjdk.org  Tue Nov  4 15:35:32 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Nov 2025 15:35:32 GMT
Subject: RFR: 8366094: Sealed graph for nested types creates broken links
Message-ID: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>

Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that enclosing types are included in the path of the graph file and therefore must have a matching `../` in the generated link. 

Fixed graphs for some nested sealed types: 
 - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html)
 - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html)
 - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)

There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828).

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

Commit messages:
 - 8366094: Sealed graph for nested types creates broken links

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

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

From hannesw at openjdk.org  Tue Nov  4 16:17:54 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 4 Nov 2025 16:17:54 GMT
Subject: RFR: 8366094: Sealed graph for nested types creates broken links
 [v2]
In-Reply-To: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
References: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
Message-ID: <DpO57HYb_SOU1NdMp5r6bpNFDt82V7cl58aqLONp__8=.ce4fd54e-0444-428f-9c68-028d631bcb25@github.com>

> Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that enclosing types are included in the path of the graph file and therefore must have a matching `../` in the generated link. 
> 
> Fixed graphs for some nested sealed types: 
>  - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html)
>  - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html)
>  - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)
> 
> There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28134/files
  - new: https://git.openjdk.org/jdk/pull/28134/files/c5f60cc6..eb3c1ec3

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

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

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

From jlamperth at openjdk.org  Wed Nov  5 16:20:01 2025
From: jlamperth at openjdk.org (Jonathan =?UTF-8?B?TMOhc3psw7M=?= =?UTF-8?B?IA==?= =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Wed, 5 Nov 2025 16:20:01 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v6]
In-Reply-To: <bk9SHDffUYtKl1VNh9rAgFJdpyXRXd-vU19CxNRhmN8=.afb5dc31-b982-4d11-954d-57b5f71ec71d@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <bk9SHDffUYtKl1VNh9rAgFJdpyXRXd-vU19CxNRhmN8=.afb5dc31-b982-4d11-954d-57b5f71ec71d@github.com>
Message-ID: <8JjjyaN0W7aSN2HAkpxC5fxKOlIAuZmQn78JXHMXTGE=.05f008ec-b1df-4498-a0ea-80d3a557e1f6@github.com>

On Tue, 4 Nov 2025 10:52:03 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
>> 
>> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
>> 
>> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
>> 
>> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix sizing bugs in mobile TOC introduced with dark theme

Marked as reviewed by jlamperth (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/28085#pullrequestreview-3423100353

From garret at globalmentor.com  Fri Nov  7 00:04:30 2025
From: garret at globalmentor.com (Garret Wilson)
Date: Thu, 6 Nov 2025 18:04:30 -0600
Subject: please allow Markdown URL links in JEP 467 `@see`
Message-ID: <61d76cfc-9bdd-40d8-863e-5e6a72b1800d@globalmentor.com>

I've been excitedly waiting for years to finally be able to use Markdown 
in Javadocs.

Using Java 25 with the new [JEP 467: Markdown Documentation 
Comments](https://openjdk.org/jeps/467), I tried to add the following:

```java
/// @see [Example Site](https://example.com/)
```

Javadoc (invoked by Maven) complained "error: unexpected content", with 
a `^` under the ending `)`.

If you look at the?[JEP 467](https://openjdk.org/jeps/467) proposal, it 
says:

 > You can use all other forms of Markdown links, including links to 
URLs ?.
 > ?
 > The inline and block tags are parsed in the same way as for 
traditional documentation comments, except that tag content is also 
parsed as Markdown.

I raised this issue on Stack Overflow: [Java 25 Javadoc not allowing 
Markdown URL link syntax in 
`@see`](https://stackoverflow.com/q/79794040). Someone pointed out that 
the JavaDoc specification is really at 
https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html 
. Unfortunately I see that the text about using Markdown links has been 
removed.

This is a significant oversight and impediment. Why would would we want 
to write Javadoc Markdown everywhere, except treat the `@see` tag specially?

My objective is not to find another way to link to classes or methods. I 
truly want to link to a URL. Many things we write are inspired, 
influenced, or guided by blog articles or even Stack Overflow. So to 
make things meta, if I were writing a Java implementation of Javadoc 
parsing I might just reference my own Stack Overflow question:


```java
/// Parses Javadoc Markdown comments and returns a Markdown node tree.
/// @implNote Supports Markdown for the `@see` tag.
/// @see [Java 25 Javadoc not allowing Markdown URL link syntax in 
`@see`](https://stackoverflow.com/q/79794040)
```

But that's not allowed. Even worse, it's not even a warning, it's an error!

This presents a huge problem with code generation with LLMs. If I ask an 
LLM to generate some documentation for a class, I have to find a way to 
explain to it to generate the API documentation using Markdown. Oh, but 
wait, LLM, if it's a `@see`, then you must use old-fashioned `<a 
href="blah">blah blah</a>`. Oh, but if it's not a URL, but a link to a 
class, then you can use Markdown. So the LLM tries to comply , and 
instead writes "See also ?", but then it uses an old style HTML link, so 
I have to tell it that if it uses `See` and not `@see` then it can use a 
Markdown URL link.

Do you think the LLM keeps all this straight? Of course not. I don't 
blame it. I can't keep it straight. It's one of those, "why, why, why" 
moments.

Sorry, went off a bit there. :) I spent a long time just now trying to 
convince an LLM of these arbitrary rules when I can't keep them straight 
myself.

I respectfully submit that this incongruence be fixed so we can all move 
forward toward a consistent, happy, Markdown Javadoc work. Please allow 
Markdown URL links in `@see` as soon as possible.

Garret


From hannes.wallnoefer at oracle.com  Fri Nov  7 13:45:56 2025
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 7 Nov 2025 13:45:56 +0000
Subject: please allow Markdown URL links in JEP 467 `@see`
In-Reply-To: <61d76cfc-9bdd-40d8-863e-5e6a72b1800d@globalmentor.com>
References: <61d76cfc-9bdd-40d8-863e-5e6a72b1800d@globalmentor.com>
Message-ID: <3ABD79B6-8514-41E1-8299-59C76AEFBE94@oracle.com>

Hi Garret,

I understand how one might expect that Markdown links should work in @see tags of Markdown comments.

The thing is that @see does not accept arbitrary rich content like some other tags do, so it is not processed as Markdown. Rather, it supports three specific forms that serve different purposes:: https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html#see

So basically we?d have to add a fourth form to support Markdown links. While this is not out of the question, it?s not a trivial task either. There?s a number of issues that have to be addressed, such as whether this should only work in Markdown comments or also traditional doc comments, whether it supports only URLs or also API references, and probably a few more.

A first step to evaluate these questions might be to file an enhancement issue at https://bugs.openjdk.org/.

Hannes


On 07.11.2025, at 01:04, Garret Wilson <garret at globalmentor.com> wrote:

I've been excitedly waiting for years to finally be able to use Markdown in Javadocs.

Using Java 25 with the new [JEP 467: Markdown Documentation Comments](https://openjdk.org/jeps/467), I tried to add the following:

```java
/// @see [Example Site](https://example.com/)
```

Javadoc (invoked by Maven) complained "error: unexpected content", with a `^` under the ending `)`.

If you look at the [JEP 467](https://openjdk.org/jeps/467) proposal, it says:

> You can use all other forms of Markdown links, including links to URLs ?.
> ?
> The inline and block tags are parsed in the same way as for traditional documentation comments, except that tag content is also parsed as Markdown.

I raised this issue on Stack Overflow: [Java 25 Javadoc not allowing Markdown URL link syntax in `@see`](https://stackoverflow.com/q/79794040). Someone pointed out that the JavaDoc specification is really at https://docs.oracle.com/en/java/javase/25/docs/specs/javadoc/doc-comment-spec.html . Unfortunately I see that the text about using Markdown links has been removed.

This is a significant oversight and impediment. Why would would we want to write Javadoc Markdown everywhere, except treat the `@see` tag specially?

My objective is not to find another way to link to classes or methods. I truly want to link to a URL. Many things we write are inspired, influenced, or guided by blog articles or even Stack Overflow. So to make things meta, if I were writing a Java implementation of Javadoc parsing I might just reference my own Stack Overflow question:


```java
/// Parses Javadoc Markdown comments and returns a Markdown node tree.
/// @implNote Supports Markdown for the `@see` tag.
/// @see [Java 25 Javadoc not allowing Markdown URL link syntax in `@see`](https://stackoverflow.com/q/79794040)
```

But that's not allowed. Even worse, it's not even a warning, it's an error!

This presents a huge problem with code generation with LLMs. If I ask an LLM to generate some documentation for a class, I have to find a way to explain to it to generate the API documentation using Markdown. Oh, but wait, LLM, if it's a `@see`, then you must use old-fashioned `<a href="blah">blah blah</a>`. Oh, but if it's not a URL, but a link to a class, then you can use Markdown. So the LLM tries to comply , and instead writes "See also ?", but then it uses an old style HTML link, so I have to tell it that if it uses `See` and not `@see` then it can use a Markdown URL link.

Do you think the LLM keeps all this straight? Of course not. I don't blame it. I can't keep it straight. It's one of those, "why, why, why" moments.

Sorry, went off a bit there. :) I spent a long time just now trying to convince an LLM of these arbitrary rules when I can't keep them straight myself.

I respectfully submit that this incongruence be fixed so we can all move forward toward a consistent, happy, Markdown Javadoc work. Please allow Markdown URL links in `@see` as soon as possible.

Garret


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251107/58002716/attachment-0001.htm>

From davidalayachew at gmail.com  Fri Nov  7 16:16:31 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 7 Nov 2025 11:16:31 -0500
Subject: Clicking class name when on that class page should not refresh page.
Message-ID: <CAA9v-_MSwkpQq0FNpr4qup3RDV7P21fBgYPTh1r7K8UqZQtXjg@mail.gmail.com>

Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,

When I am on the Javadoc for JFileChooser
<https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/javax/swing/JFileChooser.html>,
clicking on the topmost JFileChooser triggers a full page refresh, even
though we are already on the same page.

I propose that, upon clicking on the JFileChooser, that it is treated as if
it just jumps to the top of the page. This is the same functionality as
clicking on a method name -- those don't refresh the page, they just jump
you to a location on that page. Same deal -- just jump us to the top of the
page.

I have added a simple screenshot to the bottom of this email to clarify
which part I am talking about.

What do you all think? This should be a super low effort change to do,
while upping the usability in a nice way.

Thank you for your time and consideration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251107/7db096ce/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1000003339.png
Type: image/png
Size: 63501 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251107/7db096ce/1000003339-0001.png>

From dlsmith at openjdk.org  Sat Nov  8 01:35:35 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Sat, 8 Nov 2025 01:35:35 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs
 dir
Message-ID: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>

Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.

I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.

Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

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

Commit messages:
 - 8370154: Update @jls and @jvms taglets to point to local specs dir

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

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

From liach at openjdk.org  Sat Nov  8 03:29:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Nov 2025 03:29:00 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir
In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
Message-ID: <eYsLGIet78sQiey3i5UCSdjzOnvBb9ns_R0fDpU9ArM=.97084471-4097-4bd8-b053-deaa60522e8c@github.com>

On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
> 
> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
> 
> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

Looks goood. Meanwhile, do you think we should retain external link support via a system property? For the Java SE API specification only distribution for JCP, we might want to link to a static link instead of a local relative link. (I think as long as we can link, a relative link like here is better because it will be stable in the specdiff for JCP review, avoiding spams)

Since we removed the system property jspec.version, we should be able to remove this from the build files too: https://github.com/openjdk/jdk/blob/066810c877b206a66cc87537487b17f0481646c3/make/Docs.gmk#L295

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

PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3505717390

From dlsmith at openjdk.org  Sat Nov  8 04:32:59 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Sat, 8 Nov 2025 04:32:59 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir
In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
Message-ID: <yLu9nm_6ug_JC_-kRbSt4AqaQW6FQtwUULCv0i3STjo=.d3de7b05-8861-47a7-8de2-ee8a76747654@github.com>

On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
> 
> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
> 
> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

JCP reviews actually happen before GA, so I think the external links are always dead anyway?

If it's something the JCP folks care about, I think the right solution is to include JLS & JVMS in the SE-only docs. (They are, after all, specs for Java SE.) But for now, I think the business as usual process is fine.

I'll confirm there are no more uses of `jspec.version` and update Docs.gmk.

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

PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3505881120
PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3505884846

From liach at openjdk.org  Sat Nov  8 05:46:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Nov 2025 05:46:59 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir
In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
Message-ID: <ERXixRo0FX510dpA_nbf08eLdln-pfJ98SDNtoeJhog=.95eee0c6-4bca-4830-9387-e5a5d2e7da8e@github.com>

On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
> 
> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
> 
> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

I think we can go ahead with this once we verify Oracle's doc build passes. I will approve once the system property passing in Docs.gmk is updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3506017879

From hannes.wallnoefer at oracle.com  Sat Nov  8 08:45:37 2025
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Sat, 8 Nov 2025 08:45:37 +0000
Subject: [External] : Re: please allow Markdown URL links in JEP 467 `@see`
In-Reply-To: <fad79079-f814-4892-8ab4-275f0adaa28b@globalmentor.com>
References: <61d76cfc-9bdd-40d8-863e-5e6a72b1800d@globalmentor.com>
 <3ABD79B6-8514-41E1-8299-59C76AEFBE94@oracle.com>
 <fad79079-f814-4892-8ab4-275f0adaa28b@globalmentor.com>
Message-ID: <ECF301BE-06B4-415D-B59A-6438958F6C75@oracle.com>

Sorry, I forgot about that. I filed an issue here:

https://bugs.openjdk.org/browse/JDK-8371504

I can?t promise, but I think there are good chances that we will do it. Thanks for bringing this up!

Hannes


On 07.11.2025, at 15:44, Garret Wilson <garret at globalmentor.com> wrote:

?

A first step to evaluate these questions might be to file an enhancement issue at https://bugs.openjdk.org/ .

That was actually my very first stop, before I even filed the Stack Overflow issue if I remember correctly. But it looks like I have to have an OpenJDK login to even file a ticket. (It didn't used to be like that; I've filled Java bugs for eons.) How do I get an OpenJDK login?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251108/b2581537/attachment.htm>

From liach at openjdk.org  Sat Nov  8 15:56:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Nov 2025 15:56:02 GMT
Subject: RFR: 8370612: Simplify implementation of dark theme [v6]
In-Reply-To: <bk9SHDffUYtKl1VNh9rAgFJdpyXRXd-vU19CxNRhmN8=.afb5dc31-b982-4d11-954d-57b5f71ec71d@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
 <bk9SHDffUYtKl1VNh9rAgFJdpyXRXd-vU19CxNRhmN8=.afb5dc31-b982-4d11-954d-57b5f71ec71d@github.com>
Message-ID: <kLUHhnUeQBAsaYDcFVRaWlDKKlyAC2pijyrDZma2J_M=.16b6f06f-4541-4420-b61f-4686f399746b@github.com>

On Tue, 4 Nov 2025 10:52:03 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
>> 
>> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
>> 
>> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
>> 
>> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix sizing bugs in mobile TOC introduced with dark theme

Looks sensible to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28085#pullrequestreview-3438455052

From liach at openjdk.org  Sat Nov  8 22:05:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 8 Nov 2025 22:05:00 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir
In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
Message-ID: <Lhdh4YiblagFXuijNizF5XcEnY-PrIw6ng1nmC6rnP0=.74e9dbf2-e8c0-493f-9f2f-cd397920e7ee@github.com>

On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
> 
> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
> 
> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

Verified this passes on Oracle's CI.

I tested this patch on my local Linux-targeting OpenJDK WSL (because only Linux is building docs); the JVMS links become dead links in OpenJDK builds, which don't have access to JLS/JVMS, which are proprietary to Oracle. We should probably leave a comment that the dead links are intentional.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28207#pullrequestreview-3438821864
PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3506995226

From garret at globalmentor.com  Fri Nov  7 14:44:11 2025
From: garret at globalmentor.com (Garret Wilson)
Date: Fri, 7 Nov 2025 08:44:11 -0600
Subject: please allow Markdown URL links in JEP 467 `@see`
In-Reply-To: <3ABD79B6-8514-41E1-8299-59C76AEFBE94@oracle.com>
References: <61d76cfc-9bdd-40d8-863e-5e6a72b1800d@globalmentor.com>
 <3ABD79B6-8514-41E1-8299-59C76AEFBE94@oracle.com>
Message-ID: <fad79079-f814-4892-8ab4-275f0adaa28b@globalmentor.com>

On 11/7/2025 7:45 AM, Hannes Wallnoefer wrote:
> ??
> So basically we?d have to add a fourth form to support Markdown links.

Yes, please. Who wants things half-way done? Nobody wants to arbitrarily 
mix in different formats. And as I mentioned, it's just a nightmare to 
explain this to an LLM as it is to explain it to a junior developer. You 
think junior developers are going to remember all these gotcha exception 
rules?

> ?
>
> A first step to evaluate these questions might be to file an 
> enhancement issue at https://bugs.openjdk.org/.

That was actually my very first stop, before I even filed the Stack 
Overflow issue if I remember correctly. But it looks like I have to have 
an OpenJDK login to even file a ticket. (It didn't used to be like that; 
I've filled Java bugs for eons.) How do I get an OpenJDK login?

Garret


From hannesw at openjdk.org  Mon Nov 10 10:09:20 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 10 Nov 2025 10:09:20 GMT
Subject: Integrated: 8370612: Simplify implementation of dark theme
In-Reply-To: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
References: <Xri8vQdo9_wd-meUKVOhkxW8SrrfxtVPVeLX5Zs12Kg=.a0610e99-0e19-4354-84a3-2f6bc5fd430c@github.com>
Message-ID: <Pps6M1NeNYUXzcGUSB8wZlknEa_pXnt1oSkQyMijJMM=.37b1fded-f0b8-43b9-a5ff-ba64313bdef8@github.com>

On Fri, 31 Oct 2025 13:30:06 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to simplify the implementation of CSS themes by solely relying on an attribute set by script instead of the dual script plus media queries approach. This allows us to get rid of duplicate declaration of CSS theme variables. On the downside, JavaScript must be enabled to recognize the system theme, but this is an acceptable compromise as documentation remains fully usable with JavaScript disabled. This change also makes it much easier for users to override or extend JavaDoc stylesheets. 
> 
> Also included is a fix for the keyboard tab order of the theme switcher. When opening the theme switcher and hitting the tab key, focus now goes to the theme switcher and no longer goes to the first link in the breadcrumb navigation if there is one. This required moving the HTML for the theme switcher next to the theme button, which required a whole series of test changes. I considered removing the theme switcher markup from these tests, but decided against it, mostly to make sure there are no other unchecked links in the navigation bar. This fix also required reducing the `z-index` of the mobile table of contents.
> 
> Another improvement related to focus handling is to close the theme switcher when it loses focus, and when the `Enter` or `Escape` keys are pressed. Also included is a small change to slightly reduce the padding of the recently introduced TOC sort button. 
> 
> Sample documentation [can be viewed here](https://cr.openjdk.org/~hannesw/8370612/api.00/java.base/module-summary.html).

This pull request has now been integrated.

Changeset: 49f51f94
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49f51f9450ac3b923f83ba7d9089e5560e25ec7a
Stats:     468 lines in 9 files changed: 49 ins; 354 del; 65 mod

8370612: Simplify implementation of dark theme
8371021: Tab order in theme picker is broken

Reviewed-by: jlamperth, liach

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

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

From davidalayachew at gmail.com  Mon Nov 10 10:30:04 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Nov 2025 05:30:04 -0500
Subject: Please add a tab to navigate to the tools and specs pages
Message-ID: <CAA9v-_OcHq=go=c19dxnZiKBt_hZtFe+Ux96aEV=VsaF0YDhUg@mail.gmail.com>

Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org> team,

If I look up the documentation for the jar command in Java 25, I get this
page.

https://docs.oracle.com/en/java/javase/25/docs/specs/man/jar.html

On the top are 3 tabs, titled as follows.

* API
* Other Specifications
* Tool Guides

If I click API, it takes me to the main Javadoc page that we know. However,
I have no way to navigate back to that page, other than to use my back
button.

Could we add the "Other Specifications" and "Tool Guides" tabs to the main
Javadoc page? We could put a clean vertical divider between the group of
normal Javadoc tabs (OVERVIEW/TREE/PREVIEW/etc) and this new group.

Having that ability to navigate back and forth would help discoverability a
lot. For example, clicking on the "Tool Guides" tab shows me a whole bunch
of features I never knew about.

Ideally, this is a super low effort feature request to implement. They even
share the same url prefix, so very very little needs to be done here.

Even if we don't go about making the change, could we at least create a
ticket for it in JBS?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251110/f804ec8b/attachment-0001.htm>

From jaikiran.pai at oracle.com  Mon Nov 10 12:02:31 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Mon, 10 Nov 2025 17:32:31 +0530
Subject: please allow Markdown URL links in JEP 467 `@see`
In-Reply-To: <fad79079-f814-4892-8ab4-275f0adaa28b@globalmentor.com>
References: <61d76cfc-9bdd-40d8-863e-5e6a72b1800d@globalmentor.com>
 <3ABD79B6-8514-41E1-8299-59C76AEFBE94@oracle.com>
 <fad79079-f814-4892-8ab4-275f0adaa28b@globalmentor.com>
Message-ID: <6bb1842c-ac51-4f77-9d76-143af0b31d98@oracle.com>

Hello Garret,

On 07/11/25 8:14 pm, Garret Wilson wrote:
> ...
>
>> ?
>>
>> A first step to evaluate these questions might be to file an 
>> enhancement issue at https://bugs.openjdk.org/.
>
> That was actually my very first stop, before I even filed the Stack 
> Overflow issue if I remember correctly. But it looks like I have to 
> have an OpenJDK login to even file a ticket. (It didn't used to be 
> like that; I've filled Java bugs for eons.) How do I get an OpenJDK 
> login?
>
> Garret

You can file a bug here https://bugs.java.com/bugdatabase/ and you don't 
need a OpenJDK login for that. Those issues will get routed to the JDK 
bug tracker from there.

-Jaikiran


From nizar.benalla at oracle.com  Mon Nov 10 15:11:03 2025
From: nizar.benalla at oracle.com (Nizar Benalla)
Date: Mon, 10 Nov 2025 15:11:03 +0000
Subject: Please add a tab to navigate to the tools and specs pages
In-Reply-To: <CAA9v-_OcHq=go=c19dxnZiKBt_hZtFe+Ux96aEV=VsaF0YDhUg@mail.gmail.com>
References: <CAA9v-_OcHq=go=c19dxnZiKBt_hZtFe+Ux96aEV=VsaF0YDhUg@mail.gmail.com>
Message-ID: <BLAPR10MB50761739B3DE0047AB61C12B8ACEA@BLAPR10MB5076.namprd10.prod.outlook.com>

Hello David,

Thank you for the suggestion, this was fixed in JDK 26 https://bugs.openjdk.org/browse/JDK-8294074.

Cheers,
Nizar
________________________________
From: javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Monday, November 10, 2025 11:30 AM
To: javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
Subject: Please add a tab to navigate to the tools and specs pages

Hello @javadoc-dev at openjdk.org<mailto:javadoc-dev at openjdk.org> team,

If I look up the documentation for the jar command in Java 25, I get this page.

https://docs.oracle.com/en/java/javase/25/docs/specs/man/jar.html

On the top are 3 tabs, titled as follows.

* API
* Other Specifications
* Tool Guides

If I click API, it takes me to the main Javadoc page that we know. However, I have no way to navigate back to that page, other than to use my back button.

Could we add the "Other Specifications" and "Tool Guides" tabs to the main Javadoc page? We could put a clean vertical divider between the group of normal Javadoc tabs (OVERVIEW/TREE/PREVIEW/etc) and this new group.

Having that ability to navigate back and forth would help discoverability a lot. For example, clicking on the "Tool Guides" tab shows me a whole bunch of features I never knew about.

Ideally, this is a super low effort feature request to implement. They even share the same url prefix, so very very little needs to be done here.

Even if we don't go about making the change, could we at least create a ticket for it in JBS?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251110/be7e5574/attachment-0001.htm>

From davidalayachew at gmail.com  Mon Nov 10 17:26:25 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Nov 2025 12:26:25 -0500
Subject: Please add a tab to navigate to the tools and specs pages
In-Reply-To: <BLAPR10MB50761739B3DE0047AB61C12B8ACEA@BLAPR10MB5076.namprd10.prod.outlook.com>
References: <CAA9v-_OcHq=go=c19dxnZiKBt_hZtFe+Ux96aEV=VsaF0YDhUg@mail.gmail.com>
 <BLAPR10MB50761739B3DE0047AB61C12B8ACEA@BLAPR10MB5076.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_NrogmjQ4FxVqagjcLgmyfX+Xp+J4MX7_icS2wK8dUR9Q@mail.gmail.com>

Hello Nizar,

Ty vm. Is there any deployed Javadocs for me to see the end results? What
you have linked to me sounds like it only does half of what I asked for,
but the Javadocs should be able to show me for sure.

On Mon, Nov 10, 2025, 10:11?AM Nizar Benalla <nizar.benalla at oracle.com>
wrote:

> Hello David,
>
> Thank you for the suggestion, this was fixed in JDK 26
> https://bugs.openjdk.org/browse/JDK-8294074.
>
> Cheers,
> Nizar
> ------------------------------
> *From:* javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, November 10, 2025 11:30 AM
> *To:* javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
> *Subject:* Please add a tab to navigate to the tools and specs pages
>
> Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org> team,
>
> If I look up the documentation for the jar command in Java 25, I get this
> page.
>
> https://docs.oracle.com/en/java/javase/25/docs/specs/man/jar.html
>
> On the top are 3 tabs, titled as follows.
>
> * API
> * Other Specifications
> * Tool Guides
>
> If I click API, it takes me to the main Javadoc page that we know.
> However, I have no way to navigate back to that page, other than to use my
> back button.
>
> Could we add the "Other Specifications" and "Tool Guides" tabs to the main
> Javadoc page? We could put a clean vertical divider between the group of
> normal Javadoc tabs (OVERVIEW/TREE/PREVIEW/etc) and this new group.
>
> Having that ability to navigate back and forth would help discoverability
> a lot. For example, clicking on the "Tool Guides" tab shows me a whole
> bunch of features I never knew about.
>
> Ideally, this is a super low effort feature request to implement. They
> even share the same url prefix, so very very little needs to be done here.
>
> Even if we don't go about making the change, could we at least create a
> ticket for it in JBS?
>
> Thank you for your time and consideration.
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251110/751d175a/attachment.htm>

From davidalayachew at gmail.com  Mon Nov 10 17:29:50 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Nov 2025 12:29:50 -0500
Subject: Please add a tab to navigate to the tools and specs pages
In-Reply-To: <CAA9v-_NrogmjQ4FxVqagjcLgmyfX+Xp+J4MX7_icS2wK8dUR9Q@mail.gmail.com>
References: <CAA9v-_OcHq=go=c19dxnZiKBt_hZtFe+Ux96aEV=VsaF0YDhUg@mail.gmail.com>
 <BLAPR10MB50761739B3DE0047AB61C12B8ACEA@BLAPR10MB5076.namprd10.prod.outlook.com>
 <CAA9v-_NrogmjQ4FxVqagjcLgmyfX+Xp+J4MX7_icS2wK8dUR9Q@mail.gmail.com>
Message-ID: <CAA9v-_O7X1EB0rkga=PxsRtT_fLUZSKTP0kzYUk2CTTakMmYuA@mail.gmail.com>

Nevermind, I think I found it.

https://download.java.net/java/early_access/jdk26/docs/specs/index.html

It's not exactly what I wanted, but it is good enough for me.

On Mon, Nov 10, 2025, 12:26?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Nizar,
>
> Ty vm. Is there any deployed Javadocs for me to see the end results? What
> you have linked to me sounds like it only does half of what I asked for,
> but the Javadocs should be able to show me for sure.
>
> On Mon, Nov 10, 2025, 10:11?AM Nizar Benalla <nizar.benalla at oracle.com>
> wrote:
>
>> Hello David,
>>
>> Thank you for the suggestion, this was fixed in JDK 26
>> https://bugs.openjdk.org/browse/JDK-8294074.
>>
>> Cheers,
>> Nizar
>> ------------------------------
>> *From:* javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of David
>> Alayachew <davidalayachew at gmail.com>
>> *Sent:* Monday, November 10, 2025 11:30 AM
>> *To:* javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
>> *Subject:* Please add a tab to navigate to the tools and specs pages
>>
>> Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org> team,
>>
>> If I look up the documentation for the jar command in Java 25, I get this
>> page.
>>
>> https://docs.oracle.com/en/java/javase/25/docs/specs/man/jar.html
>>
>> On the top are 3 tabs, titled as follows.
>>
>> * API
>> * Other Specifications
>> * Tool Guides
>>
>> If I click API, it takes me to the main Javadoc page that we know.
>> However, I have no way to navigate back to that page, other than to use my
>> back button.
>>
>> Could we add the "Other Specifications" and "Tool Guides" tabs to the
>> main Javadoc page? We could put a clean vertical divider between the group
>> of normal Javadoc tabs (OVERVIEW/TREE/PREVIEW/etc) and this new group.
>>
>> Having that ability to navigate back and forth would help discoverability
>> a lot. For example, clicking on the "Tool Guides" tab shows me a whole
>> bunch of features I never knew about.
>>
>> Ideally, this is a super low effort feature request to implement. They
>> even share the same url prefix, so very very little needs to be done here.
>>
>> Even if we don't go about making the change, could we at least create a
>> ticket for it in JBS?
>>
>> Thank you for your time and consideration.
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251110/f3ece4c4/attachment-0001.htm>

From dlsmith at openjdk.org  Mon Nov 10 23:46:33 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Mon, 10 Nov 2025 23:46:33 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir [v2]
In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
Message-ID: <rjrYGeaUl9gMDNUdC2X-16KKRBlKHwvXCaVpdadiJB4=.6ebf368b-db7d-44c9-9586-713f1ca34ee2@github.com>

> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
> 
> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
> 
> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  Remove setting of 'jspec.version' property

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28207/files
  - new: https://git.openjdk.org/jdk/pull/28207/files/ec6d88dd..a47c3c5a

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

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

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

From dlsmith at openjdk.org  Mon Nov 10 23:52:01 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Mon, 10 Nov 2025 23:52:01 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir
In-Reply-To: <Lhdh4YiblagFXuijNizF5XcEnY-PrIw6ng1nmC6rnP0=.74e9dbf2-e8c0-493f-9f2f-cd397920e7ee@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
 <Lhdh4YiblagFXuijNizF5XcEnY-PrIw6ng1nmC6rnP0=.74e9dbf2-e8c0-493f-9f2f-cd397920e7ee@github.com>
Message-ID: <VQChi6DGdSSLWPjZg_PzwMokc3D6bdiuZplmGD1K0jk=.2809defa-f04e-434f-a755-9bc46e8093e1@github.com>

On Sat, 8 Nov 2025 22:01:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> I tested this patch on my local Linux-targeting OpenJDK WSL (because only Linux is building docs); the JVMS links become dead links in OpenJDK builds, which don't have access to JLS/JVMS, which are proprietary to Oracle. We should probably leave a comment that the dead links are intentional.

Where is a good place for that comment?

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

PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3514379165

From dlsmith at openjdk.org  Tue Nov 11 00:36:30 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Tue, 11 Nov 2025 00:36:30 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir [v3]
In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
Message-ID: <gYR9DKrX8FmC1bqIyxf-bj5JZd3UtC3SBOK05Y8TBdU=.63bb8b21-f516-4f26-b8a9-5b4b53733f57@github.com>

> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
> 
> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
> 
> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  Comment about open-source builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28207/files
  - new: https://git.openjdk.org/jdk/pull/28207/files/a47c3c5a..cb8de969

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

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

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

From liach at openjdk.org  Tue Nov 11 06:43:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Nov 2025 06:43:05 GMT
Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local
 specs dir [v3]
In-Reply-To: <gYR9DKrX8FmC1bqIyxf-bj5JZd3UtC3SBOK05Y8TBdU=.63bb8b21-f516-4f26-b8a9-5b4b53733f57@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
 <gYR9DKrX8FmC1bqIyxf-bj5JZd3UtC3SBOK05Y8TBdU=.63bb8b21-f516-4f26-b8a9-5b4b53733f57@github.com>
Message-ID: <_8-tL-LF9aW4oQhg-nlEYAw6QYrXWABnKjVQnZNbFCw=.5253e893-aa69-4085-80c7-8901c9f04e00@github.com>

On Tue, 11 Nov 2025 00:36:30 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
>> 
>> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
>> 
>> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment about open-source builds

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28207#pullrequestreview-3446476869

From dlsmith at openjdk.org  Tue Nov 11 17:15:13 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Tue, 11 Nov 2025 17:15:13 GMT
Subject: Integrated: 8370154: Update @jls and @jvms taglets to point to local
 specs dir
In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com>
Message-ID: <t4fUYnh6I-PNV1HELAUC2tjpSAF2P1-ynZXzUTyxB98=.a2388eb2-bfe0-4403-82ed-f7174ac9937e@github.com>

On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153.
> 
> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw.
> 
> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place.

This pull request has now been integrated.

Changeset: c6a8027b
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f
Stats:     62 lines in 3 files changed: 39 ins; 13 del; 10 mod

8370154: Update @jls and @jvms taglets to point to local specs dir

Reviewed-by: liach

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

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

From jlahoda at openjdk.org  Wed Nov 12 17:33:15 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 12 Nov 2025 17:33:15 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link
Message-ID: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>

The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.

This PR mostly just adds checks that will stop the attribution, and return `null`.

Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).

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

Commit messages:
 - Cleanup.
 - Whitespace tweak.
 - More tests
 - More conservative fix.
 - 8371248: Crash in -Xdoclint with invalid @link

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

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

From cushon at openjdk.org  Wed Nov 12 17:56:07 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 12 Nov 2025 17:56:07 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link
In-Reply-To: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
Message-ID: <gVb6MXXgBJvXp1qMxNqIiP3NszVBJxzIxvdD0x_SwOg=.16a85629-adba-4554-a8b1-d4d5e3e88766@github.com>

On Wed, 12 Nov 2025 17:26:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
> 
> This PR mostly just adds checks that will stop the attribution, and return `null`.
> 
> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).

test/langtools/tools/javac/doctree/ReferenceTest.java line 90:

> 88:  * {@link double#NAN Bad}
> 89:  * {@link double#double Bad}
> 90:  * {@link java.base/double Bad}

I also some crashes in non-primitive examples like


 * {@link List<String>.of}
 * {@link Optional<String>.empty}
 * {@link Map<String, Integer>.Entry}


This PR also fixes them, but maybe consider adding more tests like that, unless it's already covered?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2519258043

From jlahoda at openjdk.org  Thu Nov 13 07:52:19 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Nov 2025 07:52:19 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v2]
In-Reply-To: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
Message-ID: <Ktr1DNWpG8-AyQszGMQ9iLAeW9wElWdj70LDjQCYQhA=.4bcffa92-595a-4418-aba4-62e2d6119af0@github.com>

> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
> 
> This PR mostly just adds checks that will stop the attribution, and return `null`.
> 
> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).

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

  More appropriate handling of parameterized types in Attr.attribIdent.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28272/files
  - new: https://git.openjdk.org/jdk/pull/28272/files/ea99a0f1..3a6f37e2

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

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

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

From jlahoda at openjdk.org  Thu Nov 13 10:47:12 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Nov 2025 10:47:12 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v3]
In-Reply-To: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
Message-ID: <bKiWArQGxuMzJmWND2OqCr_C1acSytMzHeVGjTksj_c=.d28d27b5-15ca-4879-b05a-756e81fef4a9@github.com>

> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
> 
> This PR mostly just adds checks that will stop the attribution, and return `null`.
> 
> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).

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

  Fixing test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28272/files
  - new: https://git.openjdk.org/jdk/pull/28272/files/3a6f37e2..8fb68a3d

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

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

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

From hannesw at openjdk.org  Thu Nov 13 13:58:16 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 13 Nov 2025 13:58:16 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v3]
In-Reply-To: <bKiWArQGxuMzJmWND2OqCr_C1acSytMzHeVGjTksj_c=.d28d27b5-15ca-4879-b05a-756e81fef4a9@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <bKiWArQGxuMzJmWND2OqCr_C1acSytMzHeVGjTksj_c=.d28d27b5-15ca-4879-b05a-756e81fef4a9@github.com>
Message-ID: <s7FexkTFnrjGOtV8BNVExCUIy5xO0RKZprUt_r4OciY=.d027ce41-1525-4f8c-934a-d75ea8731f33@github.com>

On Thu, 13 Nov 2025 10:47:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
>> 
>> This PR mostly just adds checks that will stop the attribution, and return `null`.
>> 
>> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

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

> 39: import com.sun.source.tree.MemberSelectTree;
> 40: import com.sun.source.tree.ParameterizedTypeTree;
> 41: import com.sun.source.tree.PrimitiveTypeTree;

These imports are no longer needed since you removed the respective visitor methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2523563668

From jlahoda at openjdk.org  Thu Nov 13 14:25:04 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Nov 2025 14:25:04 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v4]
In-Reply-To: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
Message-ID: <vWD-xR36nYDZvJpDw6yqDDkQn4a-RWBnNuNQCCYcv1Y=.63a0e7f3-3924-4e9c-841e-831f70688161@github.com>

> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
> 
> This PR mostly just adds checks that will stop the attribution, and return `null`.
> 
> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).

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

  Removing unnecessary imports as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28272/files
  - new: https://git.openjdk.org/jdk/pull/28272/files/8fb68a3d..669251e7

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

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

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

From jlahoda at openjdk.org  Thu Nov 13 14:25:06 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Nov 2025 14:25:06 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v3]
In-Reply-To: <s7FexkTFnrjGOtV8BNVExCUIy5xO0RKZprUt_r4OciY=.d027ce41-1525-4f8c-934a-d75ea8731f33@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <bKiWArQGxuMzJmWND2OqCr_C1acSytMzHeVGjTksj_c=.d28d27b5-15ca-4879-b05a-756e81fef4a9@github.com>
 <s7FexkTFnrjGOtV8BNVExCUIy5xO0RKZprUt_r4OciY=.d027ce41-1525-4f8c-934a-d75ea8731f33@github.com>
Message-ID: <SrsVqoMpQHsJ9xTowHC58d-OeJzLPc54TLPt5nLZ9BU=.a1692459-6e9a-4b03-869d-c9fbdb6d121a@github.com>

On Thu, 13 Nov 2025 13:54:53 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing test.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 41:
> 
>> 39: import com.sun.source.tree.MemberSelectTree;
>> 40: import com.sun.source.tree.ParameterizedTypeTree;
>> 41: import com.sun.source.tree.PrimitiveTypeTree;
> 
> These imports are no longer needed since you removed the respective visitor methods.

Thanks, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2523652858

From jlahoda at openjdk.org  Thu Nov 13 14:25:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Nov 2025 14:25:09 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v4]
In-Reply-To: <gVb6MXXgBJvXp1qMxNqIiP3NszVBJxzIxvdD0x_SwOg=.16a85629-adba-4554-a8b1-d4d5e3e88766@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <gVb6MXXgBJvXp1qMxNqIiP3NszVBJxzIxvdD0x_SwOg=.16a85629-adba-4554-a8b1-d4d5e3e88766@github.com>
Message-ID: <2V4J_m1DQ6K5yeG4u_fMWs8LRcRELL-rD6jFbEb0xZU=.fc73b64f-1511-4407-907b-6099a04d1540@github.com>

On Wed, 12 Nov 2025 17:53:09 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary imports as suggested.
>
> test/langtools/tools/javac/doctree/ReferenceTest.java line 90:
> 
>> 88:  * {@link double#NAN Bad}
>> 89:  * {@link double#double Bad}
>> 90:  * {@link java.base/double Bad}
> 
> I also saw some crashes in non-primitive examples like
> 
> 
>  * {@link List<String>.of}
>  * {@link Optional<String>.empty}
>  * {@link Map<String, Integer>.Entry}
> 
> 
> This PR also fixes them, but maybe consider adding more tests like that, unless it's already covered?

I've added some tests along these lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2523654046

From cushon at openjdk.org  Thu Nov 13 14:25:10 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 13 Nov 2025 14:25:10 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v4]
In-Reply-To: <2V4J_m1DQ6K5yeG4u_fMWs8LRcRELL-rD6jFbEb0xZU=.fc73b64f-1511-4407-907b-6099a04d1540@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <gVb6MXXgBJvXp1qMxNqIiP3NszVBJxzIxvdD0x_SwOg=.16a85629-adba-4554-a8b1-d4d5e3e88766@github.com>
 <2V4J_m1DQ6K5yeG4u_fMWs8LRcRELL-rD6jFbEb0xZU=.fc73b64f-1511-4407-907b-6099a04d1540@github.com>
Message-ID: <ulJnGB1oM_3qY7l6IJbI721k3HXqgTJ2kKbugsM_VVI=.22a3f541-681a-4d38-9012-b7a35e41dca3@github.com>

On Thu, 13 Nov 2025 14:20:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> test/langtools/tools/javac/doctree/ReferenceTest.java line 90:
>> 
>>> 88:  * {@link double#NAN Bad}
>>> 89:  * {@link double#double Bad}
>>> 90:  * {@link java.base/double Bad}
>> 
>> I also saw some crashes in non-primitive examples like
>> 
>> 
>>  * {@link List<String>.of}
>>  * {@link Optional<String>.empty}
>>  * {@link Map<String, Integer>.Entry}
>> 
>> 
>> This PR also fixes them, but maybe consider adding more tests like that, unless it's already covered?
>
> I've added some tests along these lines.

Thanks! Looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2523668727

From hannesw at openjdk.org  Thu Nov 13 15:16:21 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 13 Nov 2025 15:16:21 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v4]
In-Reply-To: <vWD-xR36nYDZvJpDw6yqDDkQn4a-RWBnNuNQCCYcv1Y=.63a0e7f3-3924-4e9c-841e-831f70688161@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <vWD-xR36nYDZvJpDw6yqDDkQn4a-RWBnNuNQCCYcv1Y=.63a0e7f3-3924-4e9c-841e-831f70688161@github.com>
Message-ID: <PXJ9D149blmpiAO4TgAqrxdZgilBFRRvuKtoUhD9rbk=.6bec743d-a243-4620-9de8-9dbcecdeed3c@github.com>

On Thu, 13 Nov 2025 14:25:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
>> 
>> This PR mostly just adds checks that will stop the attribution, and return `null`.
>> 
>> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary imports as suggested.

Looks good to me.

test/langtools/tools/javac/doctree/ReferenceTest.java line 111:

> 109:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>.getKey Bad}
> 110:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>#getKey Bad}
> 111:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>#setValue(Object) Bad}

Is there a reason parameterized types don't work with modules, or is it just an implementation quirk? Not that it matters much as it is a rather unlikely corner case.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28272#pullrequestreview-3460274938
PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2523845287

From hannesw at openjdk.org  Fri Nov 14 10:07:07 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 14 Nov 2025 10:07:07 GMT
Subject: RFR: 8366094: Sealed graph for nested types creates broken links
 [v3]
In-Reply-To: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
References: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
Message-ID: <-k6Pl4zkJCrLubFltPYXsWTUVMql0gszWG-5JRgQwe4=.045b6320-07c3-4c50-8580-8a158bb00af5@github.com>

> Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs  must have a matching `../` for each enclosing type. 
> 
> Fixed graphs for some nested sealed types: 
>  - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html)
>  - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html)
>  - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)
> 
> There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828).

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to explain SVG naming scheme

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28134/files
  - new: https://git.openjdk.org/jdk/pull/28134/files/eb3c1ec3..ef36422e

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

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

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

From hannesw at openjdk.org  Fri Nov 14 10:08:45 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 14 Nov 2025 10:08:45 GMT
Subject: RFR: 8366094: Sealed graph for nested types creates broken links
 [v2]
In-Reply-To: <DpO57HYb_SOU1NdMp5r6bpNFDt82V7cl58aqLONp__8=.ce4fd54e-0444-428f-9c68-028d631bcb25@github.com>
References: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
 <DpO57HYb_SOU1NdMp5r6bpNFDt82V7cl58aqLONp__8=.ce4fd54e-0444-428f-9c68-028d631bcb25@github.com>
Message-ID: <c2fU_v0gaNXc78BCXUJGhzyyPvHqojhZwNqTCif5xQU=.d3f2a7ed-f627-411d-b12e-fed1c7fa572f@github.com>

On Tue, 4 Nov 2025 16:17:54 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs  must have a matching `../` for each enclosing type. 
>> 
>> Fixed graphs for some nested sealed types: 
>>  - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html)
>>  - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html)
>>  - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)
>> 
>> There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I added a comment and updated the description to better explain the problem and fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/28134#issuecomment-3531955266

From stefano.cordio at gmail.com  Tue Nov 11 16:10:12 2025
From: stefano.cordio at gmail.com (Stefano Cordio)
Date: Tue, 11 Nov 2025 17:10:12 +0100
Subject: Possible `javadoc` regression when upgrading from 21 to 25
Message-ID: <CAGsEpmMxAm9rZ=u3wHK6MNzeWgg8rjiybYH6K+=aDuP4wzyWKg@mail.gmail.com>

Hello everyone,

I am upgrading a project's build from Java 21 to Java 25, and Javadoc
generation fails with the following error:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.11.3:jar
(attach-javadoc) on project spring-batch-notion: MavenReportException:
Error while generating Javadoc:
[ERROR] Exit code: 1
[ERROR] /home/runner/work/spring-batch-extensions/spring-batch-extensions/spring-batch-notion/src/main/java/org/springframework/batch/extensions/notion/Sort.java:29:
error: reference not found
[ERROR]  * The direction defaults to {@link Direction#DEFAULT_DIRECTION}.
[ERROR]                                     ^
[ERROR] The generated documentation contains diagnostic markers for
invalid input.
[ERROR] 1 error
[ERROR] Command line was:
/usr/lib/jvm/temurin-25-jdk-amd64/bin/javadoc -J-Duser.language=
-J-Duser.country= @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/home/runner/work/spring-batch-extensions/spring-batch-extensions/spring-batch-notion/target/reports/apidocs'
dir.


Given that it was working fine on 21, I imagine it could be a regression.

Reference:
https://github.com/spring-projects/spring-batch-extensions/pull/192

Thanks in advance for any feedback!

Best regards,
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251111/a0441d0f/attachment.htm>

From garret at globalmentor.com  Mon Nov 10 20:38:12 2025
From: garret at globalmentor.com (Garret Wilson)
Date: Mon, 10 Nov 2025 12:38:12 -0800
Subject: [External] : Re: please allow Markdown URL links in JEP 467 `@see`
In-Reply-To: <ECF301BE-06B4-415D-B59A-6438958F6C75@oracle.com>
References: <61d76cfc-9bdd-40d8-863e-5e6a72b1800d@globalmentor.com>
 <3ABD79B6-8514-41E1-8299-59C76AEFBE94@oracle.com>
 <fad79079-f814-4892-8ab4-275f0adaa28b@globalmentor.com>
 <ECF301BE-06B4-415D-B59A-6438958F6C75@oracle.com>
Message-ID: <8e4a80a1-2b8f-4c45-9fb3-d1a6fc6b0634@globalmentor.com>

That's welcome news. Thank you for going forward with that, Hannes!

Garret

On 11/8/2025 12:45 AM, Hannes Wallnoefer wrote:
> Sorry, I forgot about that. I filed an issue here:
>
> https://bugs.openjdk.org/browse/JDK-8371504
>
> I can?t promise, but I think there are good chances that we will do 
> it. Thanks for bringing this up!
>
> Hannes
>
>
>> On 07.11.2025, at 15:44, Garret Wilson <garret at globalmentor.com> wrote:
>>
>>> ?
>>>
>>> A first step to evaluate these questions might be to file an 
>>> enhancement issue at https://bugs.openjdk.org/ .
>>
>> That was actually my very first stop, before I even filed the Stack 
>> Overflow issue if I remember correctly. But it looks like I have to 
>> have an OpenJDK login to even file a ticket. (It didn't used to be 
>> like that; I've filled Java bugs for eons.) How do I get an OpenJDK 
>> login?
>>
>

From hannes.wallnoefer at oracle.com  Fri Nov 14 18:08:22 2025
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 14 Nov 2025 18:08:22 +0000
Subject: Possible `javadoc` regression when upgrading from 21 to 25
In-Reply-To: <CAGsEpmMxAm9rZ=u3wHK6MNzeWgg8rjiybYH6K+=aDuP4wzyWKg@mail.gmail.com>
References: <CAGsEpmMxAm9rZ=u3wHK6MNzeWgg8rjiybYH6K+=aDuP4wzyWKg@mail.gmail.com>
Message-ID: <73298225-D154-47EB-8BE8-C8D48E9BBBD3@oracle.com>

Hi Stefano,

DEFAULT_DIRECTION is not a constant in enum Direction[1], it's a field in the enclosing Sort class[2]. So the new bahaviour of JavaDoc is actually correct.

[1]: https://github.com/spring-projects/spring-batch-extensions/blob/deb1c6d7890d8a25312f765724ec5078aaf8a691/spring-batch-notion/src/main/java/org/springframework/batch/extensions/notion/Sort.java#L111-L133

[2]: https://github.com/spring-projects/spring-batch-extensions/blob/deb1c6d7890d8a25312f765724ec5078aaf8a691/spring-batch-notion/src/main/java/org/springframework/batch/extensions/notion/Sort.java#L38

Unfortunately JavaDoc used to accept this kind of invalid link. It was fixed in 23:

https://bugs.openjdk.org/browse/JDK-8164094

It?s quite an easy mistake to make if you don?t get an error for it. We also had several instances of this in JDK source code.

Hannes


On 11.11.2025, at 17:10, Stefano Cordio <stefano.cordio at gmail.com> wrote:

Hello everyone,

I am upgrading a project's build from Java 21 to Java 25, and Javadoc generation fails with the following error:


[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.11.3:jar (attach-javadoc) on project spring-batch-notion: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1
[ERROR] /home/runner/work/spring-batch-extensions/spring-batch-extensions/spring-batch-notion/src/main/java/org/springframework/batch/extensions/notion/Sort.java:29: error: reference not found
[ERROR]  * The direction defaults to {@link Direction#DEFAULT_DIRECTION}.
[ERROR]                                     ^
[ERROR] The generated documentation contains diagnostic markers for invalid input.
[ERROR] 1 error
[ERROR] Command line was: /usr/lib/jvm/temurin-25-jdk-amd64/bin/javadoc -J-Duser.language= -J-Duser.country= @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in '/home/runner/work/spring-batch-extensions/spring-batch-extensions/spring-batch-notion/target/reports/apidocs' dir.

Given that it was working fine on 21, I imagine it could be a regression.

Reference: https://github.com/spring-projects/spring-batch-extensions/pull/192

Thanks in advance for any feedback!

Best regards,
Stefano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251114/8a4eb597/attachment-0001.htm>

From stefano.cordio at gmail.com  Fri Nov 14 18:28:17 2025
From: stefano.cordio at gmail.com (Stefano Cordio)
Date: Fri, 14 Nov 2025 19:28:17 +0100
Subject: Possible `javadoc` regression when upgrading from 21 to 25
In-Reply-To: <73298225-D154-47EB-8BE8-C8D48E9BBBD3@oracle.com>
References: <CAGsEpmMxAm9rZ=u3wHK6MNzeWgg8rjiybYH6K+=aDuP4wzyWKg@mail.gmail.com>
 <73298225-D154-47EB-8BE8-C8D48E9BBBD3@oracle.com>
Message-ID: <CAGsEpmPsCLgyN4AN-perD8o9eatZht6=0OTBMZA3cRTEjb+04A@mail.gmail.com>

Oh, many thanks, Hannes!

That error was hiding in plain sight right before my eyes? also because the
IDE (IntelliJ) links it incorrectly too.

Best regards,
Stefano

On Fri, Nov 14, 2025 at 7:08?PM Hannes Wallnoefer <
hannes.wallnoefer at oracle.com> wrote:

> Hi Stefano,
>
> DEFAULT_DIRECTION is not a constant in enum Direction[1], it's a field in
> the enclosing Sort class[2]. So the new bahaviour of JavaDoc is actually
> correct.
>
> [1]:
> https://github.com/spring-projects/spring-batch-extensions/blob/deb1c6d7890d8a25312f765724ec5078aaf8a691/spring-batch-notion/src/main/java/org/springframework/batch/extensions/notion/Sort.java#L111-L133
>
> [2]:
> https://github.com/spring-projects/spring-batch-extensions/blob/deb1c6d7890d8a25312f765724ec5078aaf8a691/spring-batch-notion/src/main/java/org/springframework/batch/extensions/notion/Sort.java#L38
>
> Unfortunately JavaDoc used to accept this kind of invalid link. It was
> fixed in 23:
>
> https://bugs.openjdk.org/browse/JDK-8164094
>
> It?s quite an easy mistake to make if you don?t get an error for it. We
> also had several instances of this in JDK source code.
>
> Hannes
>
>
> On 11.11.2025, at 17:10, Stefano Cordio <stefano.cordio at gmail.com> wrote:
>
> Hello everyone,
>
> I am upgrading a project's build from Java 21 to Java 25, and Javadoc
> generation fails with the following error:
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.11.3:jar (attach-javadoc) on project spring-batch-notion: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1
> [ERROR] /home/runner/work/spring-batch-extensions/spring-batch-extensions/spring-batch-notion/src/main/java/org/springframework/batch/extensions/notion/Sort.java:29: error: reference not found
> [ERROR]  * The direction defaults to {@link Direction#DEFAULT_DIRECTION}.
> [ERROR]                                     ^
> [ERROR] The generated documentation contains diagnostic markers for invalid input.
> [ERROR] 1 error
> [ERROR] Command line was: /usr/lib/jvm/temurin-25-jdk-amd64/bin/javadoc -J-Duser.language= -J-Duser.country= @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in '/home/runner/work/spring-batch-extensions/spring-batch-extensions/spring-batch-notion/target/reports/apidocs' dir.
>
>
> Given that it was working fine on 21, I imagine it could be a regression.
>
> Reference:
> https://github.com/spring-projects/spring-batch-extensions/pull/192
>
> Thanks in advance for any feedback!
>
> Best regards,
> Stefano
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251114/34c4f240/attachment.htm>

From vromero at openjdk.org  Fri Nov 14 22:04:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Nov 2025 22:04:04 GMT
Subject: RFR: 8370334: javadoc NPE with "import module" statement [v2]
In-Reply-To: <EM6uL9hjTvcVzncLUXhnPdSRIGfUR_7RHS6LkyDJgqc=.dfadb575-0077-44b8-bc1f-45915e9611bd@github.com>
References: <GRLKBDs8vNSlUUd8flL5bRBReojOpZVolH5DZwt7INM=.f750d5f7-8ba5-4938-8f00-5a09e4a152af@github.com>
 <EM6uL9hjTvcVzncLUXhnPdSRIGfUR_7RHS6LkyDJgqc=.dfadb575-0077-44b8-bc1f-45915e9611bd@github.com>
Message-ID: <0jeDgji--ZZUO6tQ21WZr0MctZw0OFfAJXZiClMvy_0=.5e0e4f87-dac3-40ae-a4fc-6864b6f16811@github.com>

On Mon, 3 Nov 2025 16:19:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> `Modules.enter` completes all root modules, but in case of additional modules being added to the module graph via `Modules.addExtraAddModules` (either from javadoc, or using the `CompilationTask.addModules`, these extra modules may not be completed at this time. Normally, they are completed eventually, but if their `module-info`s contain `import module`, an NPE will appear while checking the import, before the complete happens.
>> 
>> The proposal herein is to consistently complete all modules in the module graph when the module graphs is setup.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't eagerly complete the unnamed module.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27974#pullrequestreview-3466997830

From vromero at openjdk.org  Fri Nov 14 22:17:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Nov 2025 22:17:07 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v4]
In-Reply-To: <vWD-xR36nYDZvJpDw6yqDDkQn4a-RWBnNuNQCCYcv1Y=.63a0e7f3-3924-4e9c-841e-831f70688161@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <vWD-xR36nYDZvJpDw6yqDDkQn4a-RWBnNuNQCCYcv1Y=.63a0e7f3-3924-4e9c-841e-831f70688161@github.com>
Message-ID: <B02XJIQDn5R_P2DHgKgeBdIUazUV4oQJ9gN8dUhcQ9s=.6fee85ae-0718-4956-b136-ad979ca6be35@github.com>

On Thu, 13 Nov 2025 14:25:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
>> 
>> This PR mostly just adds checks that will stop the attribution, and return `null`.
>> 
>> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary imports as suggested.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28272#pullrequestreview-3467035920

From davidalayachew at gmail.com  Sat Nov 15 06:38:05 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 15 Nov 2025 01:38:05 -0500
Subject: Add a url param to specify dark mode?
Message-ID: <CAA9v-_OOcuk9F0BQyn8eUQnzEYujXiEUdX1P1koRz5vyOc-EnA@mail.gmail.com>

Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,

I am forced to use a browser that wipes history, cookies, sessions, etc. on
close, leaving behind only bookmarks and settings. That means that I have
to reapply Dark Mode multiple times a day (on the ea Java 26 docs). It's
not that big a deal, but I would appreciate a url (better yet, the %s
search engine!) that has dark mode activated as part of the url. Either
that, or have the default be system setting (or give me a url that does
that).

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251115/263a82c9/attachment.htm>

From hannes.wallnoefer at oracle.com  Mon Nov 17 11:52:47 2025
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 17 Nov 2025 11:52:47 +0000
Subject: Add a url param to specify dark mode?
In-Reply-To: <CAA9v-_OOcuk9F0BQyn8eUQnzEYujXiEUdX1P1koRz5vyOc-EnA@mail.gmail.com>
References: <CAA9v-_OOcuk9F0BQyn8eUQnzEYujXiEUdX1P1koRz5vyOc-EnA@mail.gmail.com>
Message-ID: <9DCBF491-52FD-441A-BA87-725CD1EC7862@oracle.com>

Hi David,

Thanks for your feedback. Among the options you mention, I think following the system setting by default is the one I like best. The reason we kept the light theme as default was to introduce the feature with as little disruption as possible, but I?m open to reconsider that decision.

Hannes

On 15.11.2025, at 07:38, David Alayachew <davidalayachew at gmail.com> wrote:

Hello @javadoc-dev at openjdk.org<mailto:javadoc-dev at openjdk.org>,

I am forced to use a browser that wipes history, cookies, sessions, etc. on close, leaving behind only bookmarks and settings. That means that I have to reapply Dark Mode multiple times a day (on the ea Java 26 docs). It's not that big a deal, but I would appreciate a url (better yet, the %s search engine!) that has dark mode activated as part of the url. Either that, or have the default be system setting (or give me a url that does that).

Thank you for your time and consideration.
David Alayachew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251117/ad6e95d9/attachment.htm>

From davidalayachew at gmail.com  Mon Nov 17 12:36:19 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 17 Nov 2025 07:36:19 -0500
Subject: Add a url param to specify dark mode?
In-Reply-To: <9DCBF491-52FD-441A-BA87-725CD1EC7862@oracle.com>
References: <CAA9v-_OOcuk9F0BQyn8eUQnzEYujXiEUdX1P1koRz5vyOc-EnA@mail.gmail.com>
 <9DCBF491-52FD-441A-BA87-725CD1EC7862@oracle.com>
Message-ID: <CAA9v-_P1BRODKbDH7dZKzAFHMv7j4FLAdKBqavqOtQNFViVx2Q@mail.gmail.com>

Thanks for the response Hannes.

Then I vote that we default to system settings. That is what their system
is requesting, after all. The fact that we ignored it historically seems to
be a weak justification to ignore what is actively being requested
now. Having the default be system settings makes more sense imo.

And it's not like browsers or OS' are defaulting to Dark Mode -- that's
something you have to opt-in to. So, the javadoc website is merely marching
to the beat set by the user's choice on the OS/Browser.

But if you still disagree, then that's fine. Turns out there are different
extensions that can do this for me anyways. Even on my fully locked down
browser, it looks like I can download Dark Reader for Firefox, allowing me
to fix my problem.

On Mon, Nov 17, 2025 at 6:52?AM Hannes Wallnoefer <
hannes.wallnoefer at oracle.com> wrote:

> Hi David,
>
> Thanks for your feedback. Among the options you mention, I think following
> the system setting by default is the one I like best. The reason we kept
> the light theme as default was to introduce the feature with as little
> disruption as possible, but I?m open to reconsider that decision.
>
> Hannes
>
> On 15.11.2025, at 07:38, David Alayachew <davidalayachew at gmail.com> wrote:
>
> Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,
>
> I am forced to use a browser that wipes history, cookies, sessions, etc.
> on close, leaving behind only bookmarks and settings. That means that I
> have to reapply Dark Mode multiple times a day (on the ea Java 26 docs).
> It's not that big a deal, but I would appreciate a url (better yet, the %s
> search engine!) that has dark mode activated as part of the url. Either
> that, or have the default be system setting (or give me a url that does
> that).
>
> Thank you for your time and consideration.
> David Alayachew
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251117/1e360ef6/attachment-0001.htm>

From hannesw at openjdk.org  Mon Nov 17 15:28:47 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 17 Nov 2025 15:28:47 GMT
Subject: RFR: 8371896: Links in snippets can not be highlighted
Message-ID: <LDDOKS54iw1UeLWn5eSnXBIm6f0oMjwP-gy_WZRcuSs=.429d9231-4713-4782-a25d-7b3ec0db11d0@github.com>

Please review a simple change to allow fragments of snippet content to act both as link and highlighted text. Previously, only the link was generated while the highlight was ignored. 

We also change snippet links to use the aequivalent of `{@linkplain}` instead of `{@link}` because the `<code>` element in `{@link}` markup is redundant in snippet content which is already inside a `<code>` element. `{@link}` also creates `PREVIEW` superscript flags which are likely to be disruptive in example code.

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

Commit messages:
 - 8371896: Links in snippets can not be highlighted

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

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

From hannesw at openjdk.org  Mon Nov 17 17:19:18 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 17 Nov 2025 17:19:18 GMT
Subject: RFR: 8304408: Javadoc unexpectedly reports that hybrid snippet
 contents mismatch
Message-ID: <Rb4HUt_ygJ0F1Fa0NqXHekg6IHdi3aaGQCJeE3kXAYM=.0908c221-1a02-493e-b1bb-96261b7ad6f4@github.com>

Please review a change to ignore leading and trailing line breaks when comparing inline and external snippet contents in a hybrid snippets. It is often hard to get leading/trailing linebreaks identical between the two, and it is generally not a significant aspect in terms of consistency. 

There is an open CSR for this issue to update the section about hybrid snippets in the doc comment spec.

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

Commit messages:
 - 8304408: Javadoc unexpectedly reports that hybrid snippet contents mismatch

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

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

From davidalayachew at gmail.com  Tue Nov 18 01:53:43 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 17 Nov 2025 20:53:43 -0500
Subject: Bug -- Page jumps around randomly when moving the mouse over search
 results
Message-ID: <CAA9v-_NuBW-OCMFxC3hR-jt4cuCN0yiX=22kBwvwn7LVhxxm-w@mail.gmail.com>

Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,

Here are steps to reproduce.

   1. In your browser (I am using Firefox), go to this url --
   https://docs.oracle.com/en/java/javase/25/docs/api/search.html?q=list
   2. Starting from the top of the screen going down, slowly move your
   mouse over the class names on the results (without scrolling). Don't click
   or press anything, just move your mouse, hovering over the results.
   3. Once you get to the bottom of the browser window, the page will
   randomly jump.

If it doesn't show up the first time, zoom out to 90% and reattempt the
above steps, and again for 80%.

Thank you for your time and consideration!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251117/a23ff940/attachment.htm>

From davidalayachew at gmail.com  Tue Nov 18 03:25:45 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 17 Nov 2025 22:25:45 -0500
Subject: Bug -- Nested Class box doesn't look like it belongs
Message-ID: <CAA9v-_PRjggS0rdKU+dduoUxHgsMQWmE4im=pFb3fKL6L7pQcA@mail.gmail.com>

Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,

Please look at the following Javadoc. Compare the "Nested Class Summary"
sections between them.

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.html

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.Greedy.html

There should not be a box for nested class summary for the Greedy one,
right? That looks wrong, especially when compared to Integrator.

And I think it is Javadoc's fault because there is nothing I can see in the
source code that would trigger this behaviour.

Am I mistaken?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251117/87698a6e/attachment-0001.htm>

From chen.l.liang at oracle.com  Tue Nov 18 03:34:19 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Tue, 18 Nov 2025 03:34:19 +0000
Subject: Bug -- Nested Class box doesn't look like it belongs
In-Reply-To: <CAA9v-_PRjggS0rdKU+dduoUxHgsMQWmE4im=pFb3fKL6L7pQcA@mail.gmail.com>
References: <CAA9v-_PRjggS0rdKU+dduoUxHgsMQWmE4im=pFb3fKL6L7pQcA@mail.gmail.com>
Message-ID: <CH3PR10MB767717146BF0A9E627960DACA2D6A@CH3PR10MB7677.namprd10.prod.outlook.com>

Hi David, I believe this is intentional - Greedy has itself inherited as an accessible nested class, because Greedy inherits itself from Integrator.

Try using this class literal in JShell:

Gatherer.Integrator.Greedy.Greedy.class

You will find this resolves to the Gatherer.Integrator.Greedy class. So I believe javadoc is correct as it reflects actual language behavior.

The behavior is similar for other nested interfaces which extend their enclosing interface, such as PrimitiveIterator.OfInt.

Regards,
Chen
________________________________
From: javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Monday, November 17, 2025 9:25 PM
To: javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
Subject: Bug -- Nested Class box doesn't look like it belongs

Hello @javadoc-dev at openjdk.org<mailto:javadoc-dev at openjdk.org>,

Please look at the following Javadoc. Compare the "Nested Class Summary" sections between them.

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.html

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.Greedy.html

There should not be a box for nested class summary for the Greedy one, right? That looks wrong, especially when compared to Integrator.

And I think it is Javadoc's fault because there is nothing I can see in the source code that would trigger this behaviour.

Am I mistaken?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251118/f21875df/attachment.htm>

From davidalayachew at gmail.com  Tue Nov 18 03:47:13 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 17 Nov 2025 22:47:13 -0500
Subject: Bug -- Nested Class box doesn't look like it belongs
In-Reply-To: <CH3PR10MB767717146BF0A9E627960DACA2D6A@CH3PR10MB7677.namprd10.prod.outlook.com>
References: <CAA9v-_PRjggS0rdKU+dduoUxHgsMQWmE4im=pFb3fKL6L7pQcA@mail.gmail.com>
 <CH3PR10MB767717146BF0A9E627960DACA2D6A@CH3PR10MB7677.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_P5jm+ovOucPqcsVnPu=CuVF_5Z8QRW7WqmAYxGMio=aw@mail.gmail.com>

Hah!

And JShell confirms you are right! The following is valid code!

jshell> Gatherer.Integrator.Greedy.Greedy.Greedy.Greedy.Greedy.class
$2 ==> interface java.util.stream.Gatherer$Integrator$Greedy

On Mon, Nov 17, 2025 at 10:34?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi David, I believe this is intentional - Greedy has itself inherited as
> an accessible nested class, because Greedy inherits itself from Integrator.
>
> Try using this class literal in JShell:
>
> Gatherer.Integrator.Greedy.Greedy.class
>
> You will find this resolves to the Gatherer.Integrator.Greedy class. So I
> believe javadoc is correct as it reflects actual language behavior.
>
> The behavior is similar for other nested interfaces which extend their
> enclosing interface, such as PrimitiveIterator.OfInt.
>
> Regards,
> Chen
> ------------------------------
> *From:* javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, November 17, 2025 9:25 PM
> *To:* javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
> *Subject:* Bug -- Nested Class box doesn't look like it belongs
>
> Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,
>
> Please look at the following Javadoc. Compare the "Nested Class Summary"
> sections between them.
>
>
> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.html
>
>
> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.Greedy.html
>
> There should not be a box for nested class summary for the Greedy one,
> right? That looks wrong, especially when compared to Integrator.
>
> And I think it is Javadoc's fault because there is nothing I can see in
> the source code that would trigger this behaviour.
>
> Am I mistaken?
>
> Thank you for your time and consideration.
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251117/c8a54289/attachment-0001.htm>

From davidalayachew at gmail.com  Tue Nov 18 04:02:39 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 17 Nov 2025 23:02:39 -0500
Subject: Bug -- Nested Class box doesn't look like it belongs
In-Reply-To: <CAA9v-_P5jm+ovOucPqcsVnPu=CuVF_5Z8QRW7WqmAYxGMio=aw@mail.gmail.com>
References: <CAA9v-_PRjggS0rdKU+dduoUxHgsMQWmE4im=pFb3fKL6L7pQcA@mail.gmail.com>
 <CH3PR10MB767717146BF0A9E627960DACA2D6A@CH3PR10MB7677.namprd10.prod.outlook.com>
 <CAA9v-_P5jm+ovOucPqcsVnPu=CuVF_5Z8QRW7WqmAYxGMio=aw@mail.gmail.com>
Message-ID: <CAA9v-_PcUq4YXP4VT9=7HroxrTsxwN0htXfsV4Et+HZx6T_7Yg@mail.gmail.com>

Ok, not a bug. Thanks for the laughs though Chen lol.

On Mon, Nov 17, 2025 at 10:47?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hah!
>
> And JShell confirms you are right! The following is valid code!
>
> jshell> Gatherer.Integrator.Greedy.Greedy.Greedy.Greedy.Greedy.class
> $2 ==> interface java.util.stream.Gatherer$Integrator$Greedy
>
> On Mon, Nov 17, 2025 at 10:34?PM Chen Liang <chen.l.liang at oracle.com>
> wrote:
>
>> Hi David, I believe this is intentional - Greedy has itself inherited as
>> an accessible nested class, because Greedy inherits itself from Integrator.
>>
>> Try using this class literal in JShell:
>>
>> Gatherer.Integrator.Greedy.Greedy.class
>>
>> You will find this resolves to the Gatherer.Integrator.Greedy class. So I
>> believe javadoc is correct as it reflects actual language behavior.
>>
>> The behavior is similar for other nested interfaces which extend their
>> enclosing interface, such as PrimitiveIterator.OfInt.
>>
>> Regards,
>> Chen
>> ------------------------------
>> *From:* javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of David
>> Alayachew <davidalayachew at gmail.com>
>> *Sent:* Monday, November 17, 2025 9:25 PM
>> *To:* javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
>> *Subject:* Bug -- Nested Class box doesn't look like it belongs
>>
>> Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,
>>
>> Please look at the following Javadoc. Compare the "Nested Class Summary"
>> sections between them.
>>
>>
>> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.html
>>
>>
>> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Gatherer.Integrator.Greedy.html
>>
>> There should not be a box for nested class summary for the Greedy one,
>> right? That looks wrong, especially when compared to Integrator.
>>
>> And I think it is Javadoc's fault because there is nothing I can see in
>> the source code that would trigger this behaviour.
>>
>> Am I mistaken?
>>
>> Thank you for your time and consideration.
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251117/37860a35/attachment.htm>

From jlahoda at openjdk.org  Tue Nov 18 08:17:51 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Nov 2025 08:17:51 GMT
Subject: Integrated: 8370334: javadoc NPE with "import module" statement
In-Reply-To: <GRLKBDs8vNSlUUd8flL5bRBReojOpZVolH5DZwt7INM=.f750d5f7-8ba5-4938-8f00-5a09e4a152af@github.com>
References: <GRLKBDs8vNSlUUd8flL5bRBReojOpZVolH5DZwt7INM=.f750d5f7-8ba5-4938-8f00-5a09e4a152af@github.com>
Message-ID: <83SiDS3yjQrIBf5VJTy4_v0g9t4ea9EwLbrQF5Qjb3g=.b3e69d50-fe75-4355-b749-89c19f27a0b1@github.com>

On Fri, 24 Oct 2025 12:18:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `Modules.enter` completes all root modules, but in case of additional modules being added to the module graph via `Modules.addExtraAddModules` (either from javadoc, or using the `CompilationTask.addModules`, these extra modules may not be completed at this time. Normally, they are completed eventually, but if their `module-info`s contain `import module`, an NPE will appear while checking the import, before the complete happens.
> 
> The proposal herein is to consistently complete all modules in the module graph when the module graphs is setup.

This pull request has now been integrated.

Changeset: 8af59437
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8af594371979b2b76ec04e0a2753413dc35b8d44
Stats:     77 lines in 3 files changed: 71 ins; 0 del; 6 mod

8370334: javadoc NPE with "import module" statement

Reviewed-by: vromero

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

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

From liach at openjdk.org  Tue Nov 18 16:41:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 16:41:32 GMT
Subject: RFR: 8366094: Sealed graph for nested types creates broken links
 [v3]
In-Reply-To: <-k6Pl4zkJCrLubFltPYXsWTUVMql0gszWG-5JRgQwe4=.045b6320-07c3-4c50-8580-8a158bb00af5@github.com>
References: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
 <-k6Pl4zkJCrLubFltPYXsWTUVMql0gszWG-5JRgQwe4=.045b6320-07c3-4c50-8580-8a158bb00af5@github.com>
Message-ID: <Gm13N7ns1_sJXXJS9quuRZlM3UIzA2GlsBc3JaTyVKg=.321bc0b6-4dc5-45cd-b4c6-1477cb61eb0f@github.com>

On Fri, 14 Nov 2025 10:07:07 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs  must have a matching `../` for each enclosing type. 
>> 
>> Fixed graphs for some nested sealed types: 
>>  - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html)
>>  - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html)
>>  - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)
>> 
>> There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828).
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to explain SVG naming scheme

These links are weird right now. This fix is good, we can fix the svg file locations later.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28134#pullrequestreview-3478734910

From hannesw at openjdk.org  Tue Nov 18 16:55:51 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 18 Nov 2025 16:55:51 GMT
Subject: Integrated: 8366094: Sealed graph for nested types creates broken
 links
In-Reply-To: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
References: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
Message-ID: <_ix8Qq2G8v6Dh2FNxTPND7wx-ZEaEFX71SklDJ2IVWk=.295f4376-f494-49e5-b5eb-6fa01220e955@github.com>

On Tue, 4 Nov 2025 15:28:27 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs  must have a matching `../` for each enclosing type. 
> 
> Fixed graphs for some nested sealed types: 
>  - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html)
>  - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html)
>  - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)
> 
> There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828).

This pull request has now been integrated.

Changeset: ac6f5e96
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac6f5e96512a7f003ac536611c53f2564ea912a6
Stats:     7 lines in 1 file changed: 2 ins; 2 del; 3 mod

8366094: Sealed graph for nested types creates broken links

Reviewed-by: liach

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

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

From liach at openjdk.org  Tue Nov 18 17:41:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 17:41:25 GMT
Subject: RFR: 8304408: Javadoc unexpectedly reports that hybrid snippet
 contents mismatch
In-Reply-To: <Rb4HUt_ygJ0F1Fa0NqXHekg6IHdi3aaGQCJeE3kXAYM=.0908c221-1a02-493e-b1bb-96261b7ad6f4@github.com>
References: <Rb4HUt_ygJ0F1Fa0NqXHekg6IHdi3aaGQCJeE3kXAYM=.0908c221-1a02-493e-b1bb-96261b7ad6f4@github.com>
Message-ID: <x5yRppUhe6zKFLoDPgjwBkxQgsgMPzj5VnPIT4oEF-g=.da379b22-2e62-4bbd-bdfc-d23202f3012c@github.com>

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

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

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28357#pullrequestreview-3479003846

From liach at openjdk.org  Tue Nov 18 17:41:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 17:41:25 GMT
Subject: RFR: 8371896: Links in snippets can not be highlighted
In-Reply-To: <LDDOKS54iw1UeLWn5eSnXBIm6f0oMjwP-gy_WZRcuSs=.429d9231-4713-4782-a25d-7b3ec0db11d0@github.com>
References: <LDDOKS54iw1UeLWn5eSnXBIm6f0oMjwP-gy_WZRcuSs=.429d9231-4713-4782-a25d-7b3ec0db11d0@github.com>
Message-ID: <5CTP8aexp73BjzN0LlQSAEPLagigO-Oa0t3tI3_hc2s=.73feda02-9bc3-4df7-988c-fae6820ac61f@github.com>

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

> Please review a simple change to allow fragments of snippet content to act both as link and highlighted text. Previously, only the link was generated while the highlight was ignored. 
> 
> We also change snippet links to use the aequivalent of `{@linkplain}` instead of `{@link}` because the `<code>` element in `{@link}` markup is redundant in snippet content which is already inside a `<code>` element. `{@link}` also creates `PREVIEW` superscript flags which are likely to be disruptive in example code.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28354#pullrequestreview-3479004497

From hannesw at openjdk.org  Tue Nov 18 17:59:16 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 18 Nov 2025 17:59:16 GMT
Subject: Integrated: 8371896: Links in snippets can not be highlighted
In-Reply-To: <LDDOKS54iw1UeLWn5eSnXBIm6f0oMjwP-gy_WZRcuSs=.429d9231-4713-4782-a25d-7b3ec0db11d0@github.com>
References: <LDDOKS54iw1UeLWn5eSnXBIm6f0oMjwP-gy_WZRcuSs=.429d9231-4713-4782-a25d-7b3ec0db11d0@github.com>
Message-ID: <yVL5l-l3mXivVb8QYFw44nbiQWN7_do3hw7VPOERZ2M=.989edc1a-d548-4bc1-a422-66aee0e6729d@github.com>

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

> Please review a simple change to allow fragments of snippet content to act both as link and highlighted text. Previously, only the link was generated while the highlight was ignored. 
> 
> We also change snippet links to use the aequivalent of `{@linkplain}` instead of `{@link}` because the `<code>` element in `{@link}` markup is redundant in snippet content which is already inside a `<code>` element. `{@link}` also creates `PREVIEW` superscript flags which are likely to be disruptive in example code.

This pull request has now been integrated.

Changeset: 0e6c7e86
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e6c7e8664fdddd8b789851263613852fc2c55f7
Stats:     80 lines in 2 files changed: 64 ins; 2 del; 14 mod

8371896: Links in snippets can not be highlighted

Reviewed-by: liach

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

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

From jlahoda at openjdk.org  Wed Nov 19 08:58:30 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 19 Nov 2025 08:58:30 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v4]
In-Reply-To: <PXJ9D149blmpiAO4TgAqrxdZgilBFRRvuKtoUhD9rbk=.6bec743d-a243-4620-9de8-9dbcecdeed3c@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <vWD-xR36nYDZvJpDw6yqDDkQn4a-RWBnNuNQCCYcv1Y=.63a0e7f3-3924-4e9c-841e-831f70688161@github.com>
 <PXJ9D149blmpiAO4TgAqrxdZgilBFRRvuKtoUhD9rbk=.6bec743d-a243-4620-9de8-9dbcecdeed3c@github.com>
Message-ID: <xH5Blfx9_od9clb3A_Jc71p5KribIFyJyuFsGB9ZdV8=.39245e2e-f100-4063-b2a2-0384d8d2dfaa@github.com>

On Thu, 13 Nov 2025 15:11:57 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary imports as suggested.
>
> test/langtools/tools/javac/doctree/ReferenceTest.java line 111:
> 
>> 109:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>.getKey Bad}
>> 110:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>#getKey Bad}
>> 111:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>#setValue(Object) Bad}
> 
> Is there a reason parameterized types don't work with modules, or is it just an implementation quirk? Not that it matters much as it is a rather unlikely corner case.

To some degree, in theory, it is only an implementation quirk. In practice, it is a bit tricky to make that work compatibly enough. I tried here:
https://github.com/lahodaj/jdk/compare/JDK-8371248...lahodaj:jdk:JDK-8371248-full-attribution?expand=1
but it is not perfect.

Unless there are objections, I would like to proceed with the change as it is here, and then we can see if we can improve the reference attribution.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2541108232

From hannesw at openjdk.org  Wed Nov 19 11:37:41 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 19 Nov 2025 11:37:41 GMT
Subject: RFR: 8371248: Crash in -Xdoclint with invalid @link [v4]
In-Reply-To: <xH5Blfx9_od9clb3A_Jc71p5KribIFyJyuFsGB9ZdV8=.39245e2e-f100-4063-b2a2-0384d8d2dfaa@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
 <vWD-xR36nYDZvJpDw6yqDDkQn4a-RWBnNuNQCCYcv1Y=.63a0e7f3-3924-4e9c-841e-831f70688161@github.com>
 <PXJ9D149blmpiAO4TgAqrxdZgilBFRRvuKtoUhD9rbk=.6bec743d-a243-4620-9de8-9dbcecdeed3c@github.com>
 <xH5Blfx9_od9clb3A_Jc71p5KribIFyJyuFsGB9ZdV8=.39245e2e-f100-4063-b2a2-0384d8d2dfaa@github.com>
Message-ID: <UJoM2Ge5-QMVwwda3v1twMH0puqZyu9cO6ReXs5rhJA=.d283bfd2-4348-46c6-af7e-751b4782a802@github.com>

On Wed, 19 Nov 2025 08:56:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> test/langtools/tools/javac/doctree/ReferenceTest.java line 111:
>> 
>>> 109:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>.getKey Bad}
>>> 110:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>#getKey Bad}
>>> 111:  * {@link java.base/java.util.Map<String, String>.Entry<String, String>#setValue(Object) Bad}
>> 
>> Is there a reason parameterized types don't work with modules, or is it just an implementation quirk? Not that it matters much as it is a rather unlikely corner case.
>
> To some degree, in theory, it is only an implementation quirk. In practice, it is a bit tricky to make that work compatibly enough. I tried here:
> https://github.com/lahodaj/jdk/compare/JDK-8371248...lahodaj:jdk:JDK-8371248-full-attribution?expand=1
> but it is not perfect.
> 
> Unless there are objections, I would like to proceed with the change as it is here, and then we can see if we can improve the reference attribution.
> 
> Thanks!

Thanks for the explanation, Jan. I'm fine with integrating this PR in its current form. Both module-qualified and parameterized links are so rare in real usage that this combination is not worth spending too much effort on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28272#discussion_r2541630387

From jlahoda at openjdk.org  Thu Nov 20 06:18:14 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Nov 2025 06:18:14 GMT
Subject: Integrated: 8371248: Crash in -Xdoclint with invalid @link
In-Reply-To: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
References: <lzUfXyln6hkR5R4zHjLb7x-B34jIeApPW3dHtuaXh1o=.8d6ae367-5098-457a-9979-ae2133289d2e@github.com>
Message-ID: <iw0jgkMwEdVqV_4lxF2ASXgswyDEMBrEJmyMKrjhXMM=.a190c6fb-c68f-4884-8264-75df7dabe5f1@github.com>

On Wed, 12 Nov 2025 17:26:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The attribution of javadoc links fails with an NPE if the link is like `{@link double.NAN Bad}` - it tries to dereference the `double`, which obviously cannot work.
> 
> This PR mostly just adds checks that will stop the attribution, and return `null`.
> 
> Note that for `{@link double Class}` the existing code does not crash and returns the internal a `TypeElement` corresponding to the `double`. This is a weird quirk of this API, and is preserved with this PR (although a test is added for it into `test/langtools/tools/javac/doctree/ReferenceTest.java`).

This pull request has now been integrated.

Changeset: 5d3e73b9
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d3e73b9e512b55cdf554158b19a4ec642dc1f1a
Stats:     33 lines in 3 files changed: 30 ins; 0 del; 3 mod

8371248: Crash in -Xdoclint with invalid @link

Reviewed-by: hannesw, vromero

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

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

From dfuchs at openjdk.org  Thu Nov 20 12:26:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:21 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v2]
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <fbZzaZTDoy8CE5Q-391sOVBezopxpDa7ggDCKJ2R3po=.cac468b3-953b-491f-8bb5-05b3222db78b@github.com>

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Daniel Fuchs 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 two additional commits since the last revision:

 - Merge branch 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28421/files
  - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737

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

  Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/28421.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421

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

From dfuchs at openjdk.org  Thu Nov 20 12:26:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:22 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <BEkaPOGOa8LRlqic4jsZvlx97AR8RVfNhjk5_1Kvips=.741bab98-7b90-4f2c-aadc-c93d62650091@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Something went wrong when I tried to merge the main PR branch in the dependent PR branch. I'm going to withdraw this PR and start again.

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

PR Comment: https://git.openjdk.org/jdk/pull/28421#issuecomment-3557752299

From dfuchs at openjdk.org  Thu Nov 20 12:26:23 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:23 GMT
Subject: Withdrawn: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <S8TUGJh8rmGEbyRwrMCP7SaPKA6HJG8O_HHX17gFyDw=.2eb7031f-a01d-42d1-8efc-1b49466b48dc@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

This pull request has been closed without being integrated.

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

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

From hannesw at openjdk.org  Fri Nov 21 13:35:39 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 21 Nov 2025 13:35:39 GMT
Subject: RFR: 8372055: Fragment link tag does not work in package info
Message-ID: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>

Please review a change to make unqualified anchor references such as `{@link ##anchor link}` work everywhere. Previously, such links only worked in class pages. The fix consists in attributing the correct Element in `JavacTrees::attributeDocReference` for references declared in API elements, and setting it to `null` for references defined in `doc-files` to make them work as local links.

Because of unattributed `doc-files` references, we also have to exclude such links from the reference check in DocLint. This is fine because local references always have a target element, and we do not check the anchor anyway.

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

Commit messages:
 - Make unqualified reference in legacy package.html work as package link everywhere.
 - Add tests and tweak details
 - 8372055: Fragment link tag does not work in package info

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

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

From davidalayachew at gmail.com  Sat Nov 22 21:02:50 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 22 Nov 2025 16:02:50 -0500
Subject: Feature Request -- Add tooltip on hover for the textboxes and their
 labels
Message-ID: <CAA9v-_MwwCjwL5S34EXZxFn94q_gM8bjANEktPLCqvUCOg6csw@mail.gmail.com>

Hello @javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>,

I have poor vision, which means I constantly have the scale set to a high
percentage on my screen. Furthermore, I use Windows Magnifier (press
WindowsKey simultaneously with "+" or "-" to try it out yourself!) to zoom
in further, if the OS and browser zoom is not enough. Browser zoom tends to
break most websites, so that's usually my last resort.

Most of the Javadoc page either has word wrap or scroll bars to accomodate
me, which are acceptable compromises.

However, the 2 textboxes on the top right (Search documentation) and top
left (Filter contents) tend to be cut off, such that their directions
("type /"and "type .", respectively) are not visible or cut off for me.

In order to read them, I have to zoom my browser all the way out, then zoom
my Windows Magnifier all the way in, causing me to mess up my presets,
making things very inconvenient.

Could we add tooltips to both text boxes, such that, on hover, they show,
via tooltip, the directions? I'm fine if the tooltip is only active if the
directions are cut off, like they are for me.

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20251122/ddb323de/attachment-0001.htm>

From hannesw at openjdk.org  Tue Nov 25 14:22:49 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 25 Nov 2025 14:22:49 GMT
Subject: RFR: 8369531: Wrong generic tooltip used in external class links
Message-ID: <_VXqc_dgk_zswAVIdeg1O_jFhtiWLpP_ssL9bX6Y7A0=.f1e900e5-51b9-4d67-8088-613f196cf71f@github.com>

Please review a change to use the same title attribute (tooltip) in external class links as in internal ones. 

Currently, links to external types and their members always use `class or interface in x.y.z` as tooltip. This is unecessarily generic for type links, because we actually know whether it is a class or an interface, and already have the correct tooltip message. For member links, it is misleading because the link target is not the class or interface.

With this change, external links use the same tooltip as internal ones. Links to top-level types specify whether it is a class or interface. Links to methods use the method signature as tooltip if the link label only contains the method name. For other members, the no tooltip is set. 

I'm also removing the `doclet.Href_Class_Or_Interface_Title` message because it is not used anymore.

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

Commit messages:
 - 8369531: Wrong generic tooltip used in external class links

Changes: https://git.openjdk.org/jdk/pull/28491/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369531
  Stats: 186 lines in 23 files changed: 5 ins; 20 del; 161 mod
  Patch: https://git.openjdk.org/jdk/pull/28491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28491/head:pull/28491

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

From hannesw at openjdk.org  Tue Nov 25 14:26:23 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 25 Nov 2025 14:26:23 GMT
Subject: RFR: 8369531: Wrong generic tooltip used in external class links
 [v2]
In-Reply-To: <_VXqc_dgk_zswAVIdeg1O_jFhtiWLpP_ssL9bX6Y7A0=.f1e900e5-51b9-4d67-8088-613f196cf71f@github.com>
References: <_VXqc_dgk_zswAVIdeg1O_jFhtiWLpP_ssL9bX6Y7A0=.f1e900e5-51b9-4d67-8088-613f196cf71f@github.com>
Message-ID: <r_lRD1q1XWKZwR0z88KK1fwyMdPzUuz5MUBNuXGTrJ8=.9895fd95-98a3-4c3d-b305-1d7b5b275763@github.com>

> Please review a change to use the same title attribute (tooltip) in external class links as in internal ones. 
> 
> Currently, links to external types and their members always use `class or interface in x.y.z` as tooltip. This is unecessarily generic for type links, because we actually know whether it is a class or an interface, and already have the correct tooltip message. For member links, it is misleading because the link target is not the class or interface.
> 
> With this change, external links use the same tooltip as internal ones. Links to top-level types specify whether it is a class or interface. Links to methods use the method signature as tooltip if the link label only contains the method name. For other members, the no tooltip is set. 
> 
> I'm also removing the `doclet.Href_Class_Or_Interface_Title` message because it is not used anymore.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Add @bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28491/files
  - new: https://git.openjdk.org/jdk/pull/28491/files/8e4138c5..dbf2c4d7

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

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

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

From liach at openjdk.org  Tue Nov 25 17:34:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 17:34:40 GMT
Subject: RFR: 8372055: Fragment link tag does not work in package info
In-Reply-To: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
References: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
Message-ID: <rgGQI28Ok8oiuAez7FTSHGuHnMnqdJk0Y9X3rUEzsbA=.369911b8-eed4-4b96-a4d3-24b0e6e6c237@github.com>

On Tue, 18 Nov 2025 13:28:37 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to make unqualified anchor references such as `{@link ##anchor link}` work everywhere. Previously, such links only worked in class pages. The fix consists in attributing the correct Element in `JavacTrees::attributeDocReference` for references declared in API elements, and setting it to `null` for references defined in `doc-files` to make them work as local links.
> 
> Because of unattributed `doc-files` references, we also have to exclude such links from the reference check in DocLint. This is fine because local references always have a target element, and we do not check the anchor anyway.

The tests look very good.

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java line 422:

> 420:                     case COMPILATION_UNIT ->
> 421:                         // Treat unqualified reference in legacy package.html as package reference.
> 422:                         // Unqualified references in doc-fiiles only need to work locally, so null is fine.

Suggestion:

                        // Unqualified references in doc-files only need to work locally, so null is fine.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java line 166:

> 164:                 // Unqualified local anchor link
> 165:                 return htmlWriter.links.createLink(HtmlId.of(refFragment), labelContent);
> 166:             }

Why do we need a new if here? Does this not fall into the `else if (refFragment == null) {` block somehow?

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

PR Review: https://git.openjdk.org/jdk/pull/28372#pullrequestreview-3506058261
PR Review Comment: https://git.openjdk.org/jdk/pull/28372#discussion_r2560783266
PR Review Comment: https://git.openjdk.org/jdk/pull/28372#discussion_r2560805106

From nbenalla at openjdk.org  Tue Nov 25 17:34:41 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 25 Nov 2025 17:34:41 GMT
Subject: RFR: 8369531: Wrong tooltip used in external class links [v2]
In-Reply-To: <r_lRD1q1XWKZwR0z88KK1fwyMdPzUuz5MUBNuXGTrJ8=.9895fd95-98a3-4c3d-b305-1d7b5b275763@github.com>
References: <_VXqc_dgk_zswAVIdeg1O_jFhtiWLpP_ssL9bX6Y7A0=.f1e900e5-51b9-4d67-8088-613f196cf71f@github.com>
 <r_lRD1q1XWKZwR0z88KK1fwyMdPzUuz5MUBNuXGTrJ8=.9895fd95-98a3-4c3d-b305-1d7b5b275763@github.com>
Message-ID: <fXx1ugeTpwFcN2V8p4QUUVjNuECFRs6Z199KK6IXjhA=.b2e5d660-7e50-4c02-ae03-42946ef0e439@github.com>

On Tue, 25 Nov 2025 14:26:23 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to use the same title attribute (tooltip) in external class links as in internal ones. 
>> 
>> Currently, links to external types and their members always use `class or interface in x.y.z` as tooltip. This is unecessarily generic for type links, because we actually know whether it is a class or an interface, and already have the correct tooltip message. For member links, it is misleading because the link target is not the class or interface.
>> 
>> With this change, external links use the same tooltip as internal ones. Links to top-level types specify whether it is a class or interface. Links to methods use the method signature as tooltip if the link label only contains the method name. For other members, the no tooltip is set. 
>> 
>> I'm also removing the `doclet.Href_Class_Or_Interface_Title` message because it is not used anymore.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @bug id

It seems that skara is having issues retrieving the bug information

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

PR Comment: https://git.openjdk.org/jdk/pull/28491#issuecomment-3576653871

From hannesw at openjdk.org  Wed Nov 26 09:08:43 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 26 Nov 2025 09:08:43 GMT
Subject: RFR: 8372055: Fragment link tag does not work in package info [v2]
In-Reply-To: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
References: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
Message-ID: <DHuHr4EUReDe-EanRzL-7_ll2xFhOpfdMsBv9FB2Mwc=.1b5f9f07-aa8f-4359-b06c-b7c717b240d6@github.com>

> Please review a change to make unqualified anchor references such as `{@link ##anchor link}` work everywhere. Previously, such links only worked in class pages. The fix consists in attributing the correct Element in `JavacTrees::attributeDocReference` for references declared in API elements, and setting it to `null` for references defined in `doc-files` to make them work as local links.
> 
> Because of unattributed `doc-files` references, we also have to exclude such links from the reference check in DocLint. This is fine because local references always have a target element, and we do not check the anchor anyway.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28372/files
  - new: https://git.openjdk.org/jdk/pull/28372/files/a9f5d0a2..8cf42e3e

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

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

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

From hannesw at openjdk.org  Wed Nov 26 09:08:45 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 26 Nov 2025 09:08:45 GMT
Subject: RFR: 8372055: Fragment link tag does not work in package info [v2]
In-Reply-To: <rgGQI28Ok8oiuAez7FTSHGuHnMnqdJk0Y9X3rUEzsbA=.369911b8-eed4-4b96-a4d3-24b0e6e6c237@github.com>
References: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
 <rgGQI28Ok8oiuAez7FTSHGuHnMnqdJk0Y9X3rUEzsbA=.369911b8-eed4-4b96-a4d3-24b0e6e6c237@github.com>
Message-ID: <KA0pne7FgZCKsIQTTf5C4SZNTjLafWUYBWlPSdmgRl8=.dc98e298-df08-49a2-a12f-822e154eb1ed@github.com>

On Tue, 25 Nov 2025 17:13:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java line 166:
> 
>> 164:                 // Unqualified local anchor link
>> 165:                 return htmlWriter.links.createLink(HtmlId.of(refFragment), labelContent);
>> 166:             }
> 
> Why do we need a new if here? Does this not fall into the `else if (refFragment == null) {` block somehow?

`refFragment` is not null here, `ref` is, which is the referenced element. This is necessary for unqualified hash fragment links in doc-files, where the referenced element is set to `null` in `JavacTrees`. We know that local links in doc-files will never be used outside of the doc-file itself (for example in summary or index pages), so we can always create a simple local hash fragment link. 

I've updated the comment to say that this is for doc-files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28372#discussion_r2564096439

From liach at openjdk.org  Wed Nov 26 13:17:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 13:17:18 GMT
Subject: RFR: 8372055: Fragment link tag does not work in package info [v2]
In-Reply-To: <DHuHr4EUReDe-EanRzL-7_ll2xFhOpfdMsBv9FB2Mwc=.1b5f9f07-aa8f-4359-b06c-b7c717b240d6@github.com>
References: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
 <DHuHr4EUReDe-EanRzL-7_ll2xFhOpfdMsBv9FB2Mwc=.1b5f9f07-aa8f-4359-b06c-b7c717b240d6@github.com>
Message-ID: <1CVj16x651cmV7L5kElmp-V5QZLIBvnX9Anz12dApyg=.45aeb97b-fdfa-41c6-b3b3-091e8ff31a0c@github.com>

On Wed, 26 Nov 2025 09:08:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to make unqualified anchor references such as `{@link ##anchor link}` work everywhere. Previously, such links only worked in class pages. The fix consists in attributing the correct Element in `JavacTrees::attributeDocReference` for references declared in API elements, and setting it to `null` for references defined in `doc-files` to make them work as local links.
>> 
>> Because of unattributed `doc-files` references, we also have to exclude such links from the reference check in DocLint. This is fine because local references always have a target element, and we do not check the anchor anyway.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28372#pullrequestreview-3510915110

From hannesw at openjdk.org  Wed Nov 26 13:39:56 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 26 Nov 2025 13:39:56 GMT
Subject: Integrated: 8372055: Fragment link tag does not work in package info
In-Reply-To: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
References: <sRmnsCytsaCN2GMcGkK7u0m0IYTHqJQ53S4KHD_Az0U=.2543641e-5851-4a56-ab3f-583d6b357cf2@github.com>
Message-ID: <G4TLr5ZR2WpRuDrPMYuTcOulcN7Kp8r5WdB6HjKuQtM=.ab921f8a-6fe6-464e-801a-adfefb991d9d@github.com>

On Tue, 18 Nov 2025 13:28:37 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to make unqualified anchor references such as `{@link ##anchor link}` work everywhere. Previously, such links only worked in class pages. The fix consists in attributing the correct Element in `JavacTrees::attributeDocReference` for references declared in API elements, and setting it to `null` for references defined in `doc-files` to make them work as local links.
> 
> Because of unattributed `doc-files` references, we also have to exclude such links from the reference check in DocLint. This is fine because local references always have a target element, and we do not check the anchor anyway.

This pull request has now been integrated.

Changeset: 85d4f551
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85d4f551b1f82f1b43155a4ac3c5026ac580410e
Stats:     156 lines in 4 files changed: 135 ins; 0 del; 21 mod

8372055: Fragment link tag does not work in package info

Reviewed-by: liach

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

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

From liach at openjdk.org  Wed Nov 26 13:48:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 13:48:51 GMT
Subject: RFR: 8369531: Wrong tooltip used in external class links [v2]
In-Reply-To: <r_lRD1q1XWKZwR0z88KK1fwyMdPzUuz5MUBNuXGTrJ8=.9895fd95-98a3-4c3d-b305-1d7b5b275763@github.com>
References: <_VXqc_dgk_zswAVIdeg1O_jFhtiWLpP_ssL9bX6Y7A0=.f1e900e5-51b9-4d67-8088-613f196cf71f@github.com>
 <r_lRD1q1XWKZwR0z88KK1fwyMdPzUuz5MUBNuXGTrJ8=.9895fd95-98a3-4c3d-b305-1d7b5b275763@github.com>
Message-ID: <RcyBn8JyVa7dqgm0ybtgt_cKq2UGlie9mz8aidm8GXU=.16651de6-4f39-4a43-942a-354c569b6319@github.com>

On Tue, 25 Nov 2025 14:26:23 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to use the same title attribute (tooltip) in external class links as in internal ones. 
>> 
>> Currently, links to external types and their members always use `class or interface in x.y.z` as tooltip. This is unecessarily generic for type links, because we actually know whether it is a class or an interface, and already have the correct tooltip message. For member links, it is misleading because the link target is not the class or interface.
>> 
>> With this change, external links use the same tooltip as internal ones. Links to top-level types specify whether it is a class or interface. Links to methods use the method signature as tooltip if the link label only contains the method name. For other members, the no tooltip is set. 
>> 
>> I'm also removing the `doclet.Href_Class_Or_Interface_Title` message because it is not used anymore.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @bug id

Looks simple and clean.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28491#pullrequestreview-3511052187

From hannesw at openjdk.org  Wed Nov 26 14:10:05 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 26 Nov 2025 14:10:05 GMT
Subject: Integrated: 8369531: Wrong tooltip used in external class links
In-Reply-To: <_VXqc_dgk_zswAVIdeg1O_jFhtiWLpP_ssL9bX6Y7A0=.f1e900e5-51b9-4d67-8088-613f196cf71f@github.com>
References: <_VXqc_dgk_zswAVIdeg1O_jFhtiWLpP_ssL9bX6Y7A0=.f1e900e5-51b9-4d67-8088-613f196cf71f@github.com>
Message-ID: <3SXxLzzxktDR7HnO01QJ0g414enIVJXuf9kpt3UvQMY=.b320ab84-3254-41aa-a82f-3fbba54b8046@github.com>

On Tue, 25 Nov 2025 14:15:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to use the same title attribute (tooltip) in external class links as in internal ones. 
> 
> Currently, links to external types and their members always use `class or interface in x.y.z` as tooltip. This is unecessarily generic for type links, because we actually know whether it is a class or an interface, and already have the correct tooltip message. For member links, it is misleading because the link target is not the class or interface.
> 
> With this change, external links use the same tooltip as internal ones. Links to top-level types specify whether it is a class or interface. Links to methods use the method signature as tooltip if the link label only contains the method name. For other members, the no tooltip is set. 
> 
> I'm also removing the `doclet.Href_Class_Or_Interface_Title` message because it is not used anymore.

This pull request has now been integrated.

Changeset: 0a3809f0
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a3809f0be94c92c2c46f00fe5ff981afdd55cf0
Stats:     191 lines in 23 files changed: 6 ins; 20 del; 165 mod

8369531: Wrong tooltip used in external class links

Reviewed-by: liach

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

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