From jjg at openjdk.org  Mon May  1 20:27:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 1 May 2023 20:27:14 GMT
Subject: RFR: 8301455: comments in TestTypeAnnotations still refer to
 resolved JDK-8068737
In-Reply-To: <opqxUZfNnPwFE553cgKRLC3l3qnehQ9VhavIX4Ho24o=.2f819732-d641-4bdd-b704-f92c7ab93597@github.com>
References: <opqxUZfNnPwFE553cgKRLC3l3qnehQ9VhavIX4Ho24o=.2f819732-d641-4bdd-b704-f92c7ab93597@github.com>
Message-ID: <p5Sh2RkD6JCXCose2Sw8HPw4RiuhU3vfAhNn5Ecs9CM=.2d3b323e-1b66-494e-8106-807b740865f6@github.com>

On Sat, 22 Apr 2023 21:15:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Simple patch removing comment references to an already fixed bug in test TestTypeAnnotations.java
> 
> TIA

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13600#pullrequestreview-1408074685

From vromero at openjdk.org  Mon May  1 20:32:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 May 2023 20:32:32 GMT
Subject: Integrated: 8301455: comments in TestTypeAnnotations still refer to
 resolved JDK-8068737
In-Reply-To: <opqxUZfNnPwFE553cgKRLC3l3qnehQ9VhavIX4Ho24o=.2f819732-d641-4bdd-b704-f92c7ab93597@github.com>
References: <opqxUZfNnPwFE553cgKRLC3l3qnehQ9VhavIX4Ho24o=.2f819732-d641-4bdd-b704-f92c7ab93597@github.com>
Message-ID: <8yJDmWRvpy2BzlFi-NIjOWsiO3x8iCCPbiKj9zZ4QQE=.fb874f90-9b54-4f1f-913d-e2dbff2ea4aa@github.com>

On Sat, 22 Apr 2023 21:15:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Simple patch removing comment references to an already fixed bug in test TestTypeAnnotations.java
> 
> TIA

This pull request has now been integrated.

Changeset: 35e75c13
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/35e75c131d7c1c2596022955c0f4c53dd3c7e448
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8301455: comments in TestTypeAnnotations still refer to resolved JDK-8068737

Reviewed-by: jjg

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

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

From jjg at openjdk.org  Thu May  4 18:08:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 4 May 2023 18:08:14 GMT
Subject: RFR: JDK-8307377: Remove use of `tagName` from
 TagletWriterImpl.linkSeeReferenceOutput
Message-ID: <owgI4-lZZgrXlTUQZ_pJB2Uq6lc5HlXhKQPK5fWR2jw=.51249bb0-3d34-439e-8f15-bdaec73ccdda@github.com>

Please review a simple fix to remove unnecessary detail from in-page and console messages about the name of the tag enclosing a bad reference.

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

Commit messages:
 - JDK-8307377: Remove use of `tagName` from TagletWriterImpl.linkSeeReferenceOutput

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

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

From hannesw at openjdk.org  Fri May  5 13:49:38 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 5 May 2023 13:49:38 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links
Message-ID: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>

Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:

https://cr.openjdk.org/~hannesw/8305958/api.00/index.html

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

Commit messages:
 - JDK-8305958: Use links instead of buttons for auto-generated header links

Changes: https://git.openjdk.org/jdk/pull/13831/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13831&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305958
  Stats: 96 lines in 9 files changed: 54 ins; 32 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13831.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13831/head:pull/13831

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

From liach at openjdk.org  Fri May  5 14:31:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 May 2023 14:31:17 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links
In-Reply-To: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
Message-ID: <hS_lZ_W8r_Y34OC9J-Vlz1pdFqNuCPV_UnAwtGuhsj4=.9b9b8cec-3007-4462-a5f1-b34cda5de83a@github.com>

On Fri, 5 May 2023 13:42:22 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
> 
> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html

This link icon does look much more informative compared to the existing copy icon.

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

PR Comment: https://git.openjdk.org/jdk/pull/13831#issuecomment-1536346863

From jjg at openjdk.org  Fri May  5 17:33:48 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 17:33:48 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents
In-Reply-To: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
Message-ID: <dMUiM_hIu7cQ4zQimX2j8y74Rl9Lp2m2_l2IPV8Z6xg=.0bbb6ed6-8832-40dc-9b50-687b80408a4b@github.com>

On Thu, 27 Apr 2023 08:02:50 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> I modified the location from which javadoc copies some legal files to the generated documentation.  If --legal-notices?option is set to default or nothing is specified,, GPLv2 Legal Documents are copied from legal/java.base/ directory, such as LICENSE, ADDITIONAL_LICENSE_INFO and ASSEMBLY_EXCEPTION.
> 
> Would you please review this fix?

The change to use a mixture of `Path` and `File` is bizarre and mostly gratuitous and unnecessary.
Please stay using `nio.Path` objects.

test/langtools/jdk/javadoc/doclet/testLegalNotices/TestLegalNotices.java line 35:

> 33: 
> 34: import java.io.IOException;
> 35: import java.io.File;

Use `java.nio.Path`, not `java.io.File`

test/langtools/jdk/javadoc/doclet/testLegalNotices/TestLegalNotices.java line 109:

> 107: 
> 108:         Set<File> expectFiles = getExpectFiles(optionKind, indexKind, legal);
> 109:         Set<File> foundFiles = listFiles(out.resolve("legal"));

Do not change return type from `Path` to `File`

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

Changes requested by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13686#pullrequestreview-1415181295
PR Review Comment: https://git.openjdk.org/jdk/pull/13686#discussion_r1186340653
PR Review Comment: https://git.openjdk.org/jdk/pull/13686#discussion_r1186341069

From jjg at openjdk.org  Fri May  5 17:35:52 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 17:35:52 GMT
Subject: RFR: JDK-8306285: Missing file in search test
In-Reply-To: <5eCr162CfLMe-IfKcrqwOIqJMYOqgnLFO1WVL_b5f7g=.421afa02-4766-462f-a926-260cab52ab2d@github.com>
References: <5eCr162CfLMe-IfKcrqwOIqJMYOqgnLFO1WVL_b5f7g=.421afa02-4766-462f-a926-260cab52ab2d@github.com>
Message-ID: <JCBqfK9j2KY8lQ1OY32EDmujtCfFAVeIQtu1ZadFiqs=.4ddd2a95-7c9a-4e11-81da-25e0f0fe85b5@github.com>

On Tue, 18 Apr 2023 12:42:05 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple fix for the javadoc `TestSearchScript` test which is skipped during normal test runs and only run manually. This adds a test file which was missing in a previous commit and a mock function for jQuery method `each()`.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13510#pullrequestreview-1415187248

From jjg at openjdk.org  Fri May  5 17:45:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 17:45:14 GMT
Subject: RFR: JDK-8306578: Report error if no label given in @see and
 {@link} when no default is available
In-Reply-To: <9Ng4WJbfI5yyy7wUgGAJH1Nc9qD5ZUnIh495LmAXkn4=.96b813c8-1fbc-412b-b044-9619177bb245@github.com>
References: <9Ng4WJbfI5yyy7wUgGAJH1Nc9qD5ZUnIh495LmAXkn4=.96b813c8-1fbc-412b-b044-9619177bb245@github.com>
Message-ID: <2n4CH5lspr0wlgCWSNugLsKgeOEzCBqECnNf38TT4jo=.9629d157-cecf-4fb1-9cfa-1b6346d3c694@github.com>

On Fri, 28 Apr 2023 14:01:18 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a trivial change to generate an error instead of a warning when no label is provided with a reference to a user-provided anchor.

Although not a conflict, see PR #13811 for a related change in this area.

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

PR Comment: https://git.openjdk.org/jdk/pull/13720#issuecomment-1536577125

From jjg at openjdk.org  Fri May  5 17:52:16 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 17:52:16 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links
In-Reply-To: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
Message-ID: <6jeJMgdoVaEVaZVEHC_eAVUgh-xRUYqyNU1x8g6jMbQ=.e8353a95-0b2f-42cb-9491-55f447c23d40@github.com>

On Fri, 5 May 2023 13:42:22 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
> 
> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html

* a typo
* suggest a CSS class, not `style` attribute for the link
* I like the new icon

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 411:

> 409:     $("main").click(collapse);
> 410:     $("section[id] > :header, :header[id], :header:has(a[id])").each(function(idx, el) {
> 411:         // Create anchor liniks for headers with an associated id attribute

typo: `linik`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 417:

> 415:             hdr.append(" <a href='#" + id + "' class='anchor-link' aria-label='" + messages.linkToSection
> 416:                 + "'><img src='" + pathtoroot + "link.svg' alt='" + messages.linkIcon +"' tabindex='0'"
> 417:                 + " style='width: 0.9em; height: 0.9em; vertical-align: baseline;'></a>");

Should this be in a CSS class, not an inline `style` ?

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

PR Review: https://git.openjdk.org/jdk/pull/13831#pullrequestreview-1415207608
PR Review Comment: https://git.openjdk.org/jdk/pull/13831#discussion_r1186355923
PR Review Comment: https://git.openjdk.org/jdk/pull/13831#discussion_r1186357616

From jjg at openjdk.org  Fri May  5 17:59:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 17:59:13 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links
In-Reply-To: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
Message-ID: <XnKPbGR2G-hOWMSu2LEOD541ELml_wxX8geJzqnlwzc=.cdce4f1f-a2ee-441f-87f6-7d9781168ce6@github.com>

On Fri, 5 May 2023 13:42:22 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
> 
> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html

Playing with the posted demo docs, I have the following comments, not necessarily criticism

* I'm mildly surprised the links show up on some of the "standard" "internal" headings, like "Constructor Details". I guess there may be cases where this is wanted, and maybe if you didn't do it, we would get a RFE to do it.

* the change accentuates the difference between "real" headings and "heading-like labels" (like **See Also:**) which is just a bold label.   But given my surprise about the use of links in my previous bullet, I'm not necessarily suggesting we should change this.

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

PR Comment: https://git.openjdk.org/jdk/pull/13831#issuecomment-1536590174

From jjg at openjdk.org  Fri May  5 20:25:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 May 2023 20:25:14 GMT
Subject: RFR: JDK-8307377: Remove use of `tagName` from
 TagletWriterImpl.linkSeeReferenceOutput
In-Reply-To: <owgI4-lZZgrXlTUQZ_pJB2Uq6lc5HlXhKQPK5fWR2jw=.51249bb0-3d34-439e-8f15-bdaec73ccdda@github.com>
References: <owgI4-lZZgrXlTUQZ_pJB2Uq6lc5HlXhKQPK5fWR2jw=.51249bb0-3d34-439e-8f15-bdaec73ccdda@github.com>
Message-ID: <6p7DL0sW8hx2X1SVamCBwTbKzl7Qh0Ezc28fr9kNvy4=.48c64d32-e5be-4843-9d4f-bd6c56a35b5c@github.com>

On Thu, 4 May 2023 18:01:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to remove unnecessary detail from in-page and console messages about the name of the tag enclosing a bad reference.

See also PR #13720 for another fix in this area

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 476:

> 474:                                            DocTree refTree,
> 475:                                            String refSignature,
> 476:                                            Element ref,

A related but different improvement would be to change this from `Element ref` to `TypeMirror refType`.
That would save a separate lookup on (new) line 542.

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

PR Comment: https://git.openjdk.org/jdk/pull/13811#issuecomment-1536736857
PR Review Comment: https://git.openjdk.org/jdk/pull/13811#discussion_r1186470360

From hannesw at openjdk.org  Mon May  8 08:07:28 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 8 May 2023 08:07:28 GMT
Subject: Integrated: JDK-8306285: Missing file in search test
In-Reply-To: <5eCr162CfLMe-IfKcrqwOIqJMYOqgnLFO1WVL_b5f7g=.421afa02-4766-462f-a926-260cab52ab2d@github.com>
References: <5eCr162CfLMe-IfKcrqwOIqJMYOqgnLFO1WVL_b5f7g=.421afa02-4766-462f-a926-260cab52ab2d@github.com>
Message-ID: <uTSEraFDYAROk_mKxYWcGo-dOl6uWjSAB_Adyddo1yE=.c6572b32-dca6-4605-8be9-dfe0fc9cdf16@github.com>

On Tue, 18 Apr 2023 12:42:05 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a simple fix for the javadoc `TestSearchScript` test which is skipped during normal test runs and only run manually. This adds a test file which was missing in a previous commit and a mock function for jQuery method `each()`.

This pull request has now been integrated.

Changeset: f6ea8979
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6ea89795b1c5c5adffb1964154762830afaed42
Stats:     47 lines in 2 files changed: 46 ins; 0 del; 1 mod

8306285: Missing file in search test

Reviewed-by: jjg

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

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

From hannesw at openjdk.org  Mon May  8 11:09:15 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 8 May 2023 11:09:15 GMT
Subject: RFR: JDK-8307377: Remove use of `tagName` from
 TagletWriterImpl.linkSeeReferenceOutput
In-Reply-To: <owgI4-lZZgrXlTUQZ_pJB2Uq6lc5HlXhKQPK5fWR2jw=.51249bb0-3d34-439e-8f15-bdaec73ccdda@github.com>
References: <owgI4-lZZgrXlTUQZ_pJB2Uq6lc5HlXhKQPK5fWR2jw=.51249bb0-3d34-439e-8f15-bdaec73ccdda@github.com>
Message-ID: <-mMswBD7yX5HmgGno-zLGKpxnPCIDKPEQaDOvvQ7aY8=.5f741ccd-3e81-46d7-a8ab-d71685fb43b8@github.com>

On Thu, 4 May 2023 18:01:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to remove unnecessary detail from in-page and console messages about the name of the tag enclosing a bad reference.

Looks good to me.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13811#pullrequestreview-1416594403

From hannesw at openjdk.org  Mon May  8 12:52:11 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 8 May 2023 12:52:11 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links
In-Reply-To: <XnKPbGR2G-hOWMSu2LEOD541ELml_wxX8geJzqnlwzc=.cdce4f1f-a2ee-441f-87f6-7d9781168ce6@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
 <XnKPbGR2G-hOWMSu2LEOD541ELml_wxX8geJzqnlwzc=.cdce4f1f-a2ee-441f-87f6-7d9781168ce6@github.com>
Message-ID: <x3kKNNZ7pOjXUqjKs7hnzwUhtQYi6_zcBBSBbi5xEj4=.053c2d47-e60b-45f1-af4e-be02361c0297@github.com>

On Fri, 5 May 2023 17:56:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> 
>     * I'm mildly surprised the links show up on some of the "standard" "internal" headings, like "Constructor Details". I guess there may be cases where this is wanted, and maybe if you didn't do it, we would get a RFE to do it.
> 

This was already the case with the previous copy-to-clipboard button. All HTML headings with an `id` attribute as well as sections with an `id` attribute and a heading as first child element are given a link. This not only includes standard page sections, but also individual member details. I think this is quite useful when looking at a member detail without having gone through the link in the member summary section.

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

PR Comment: https://git.openjdk.org/jdk/pull/13831#issuecomment-1538304745

From hannesw at openjdk.org  Mon May  8 13:53:28 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 8 May 2023 13:53:28 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links
In-Reply-To: <6jeJMgdoVaEVaZVEHC_eAVUgh-xRUYqyNU1x8g6jMbQ=.e8353a95-0b2f-42cb-9491-55f447c23d40@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
 <6jeJMgdoVaEVaZVEHC_eAVUgh-xRUYqyNU1x8g6jMbQ=.e8353a95-0b2f-42cb-9491-55f447c23d40@github.com>
Message-ID: <QX7iHBtU4pj4FdgRcixS80yZZ-heM-eD1VF9cdPufhY=.fd7ca4f7-30b1-45c3-bc85-084a64948066@github.com>

On Fri, 5 May 2023 17:47:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
>> 
>> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 417:
> 
>> 415:             hdr.append(" <a href='#" + id + "' class='anchor-link' aria-label='" + messages.linkToSection
>> 416:                 + "'><img src='" + pathtoroot + "link.svg' alt='" + messages.linkIcon +"' tabindex='0'"
>> 417:                 + " style='width: 0.9em; height: 0.9em; vertical-align: baseline;'></a>");
> 
> Should this be in a CSS class, not an inline `style` ?

I used inline style to make sure the styles are always available, as the default size of the SVG image is so large that it blows up the layout of the page. My initial choice was to use the `height` and `width` attributes in the HTML `img` element, but after some research came to the conclusion that that was not the proper use of these attributes. (I'm not 100% sure this is the correct conclusion but that's another problem.)

This is how I ended up with the inline styles. It could probably be moved to the stylesheet, at the risk of blowing up the layout when the page is loaded without stylesheet for some reason (such as network problems).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13831#discussion_r1187472516

From hannesw at openjdk.org  Mon May  8 14:00:30 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 8 May 2023 14:00:30 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links [v2]
In-Reply-To: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
Message-ID: <VNj616Rp5h-2bxTdZA3aLIzCudRV9fGuWuCz7Vw1E-M=.3e244adf-18a5-46cc-a8f1-2e0e31cd31ef@github.com>

> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
> 
> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13831/files
  - new: https://git.openjdk.org/jdk/pull/13831/files/2253cc5a..0be60c3c

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

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

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

From hannesw at openjdk.org  Mon May  8 14:35:39 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 8 May 2023 14:35:39 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links [v3]
In-Reply-To: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
Message-ID: <usMgF0VR4mXiEVT04NYzwVn0DphfGEDu_1ioFtp3tbs=.072a5e2b-200b-4025-9068-8d18f3a66b60@github.com>

> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
> 
> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html

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

  Move anchor-link sizing to stylesheet.css

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13831/files
  - new: https://git.openjdk.org/jdk/pull/13831/files/0be60c3c..efe0a741

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

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

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

From hannesw at openjdk.org  Mon May  8 14:40:28 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 8 May 2023 14:40:28 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links [v3]
In-Reply-To: <QX7iHBtU4pj4FdgRcixS80yZZ-heM-eD1VF9cdPufhY=.fd7ca4f7-30b1-45c3-bc85-084a64948066@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
 <6jeJMgdoVaEVaZVEHC_eAVUgh-xRUYqyNU1x8g6jMbQ=.e8353a95-0b2f-42cb-9491-55f447c23d40@github.com>
 <QX7iHBtU4pj4FdgRcixS80yZZ-heM-eD1VF9cdPufhY=.fd7ca4f7-30b1-45c3-bc85-084a64948066@github.com>
Message-ID: <K6BbJT4X0NX7Dqp58nSeluyeWqwC-9xH8ZbWpgvxddk=.1d04b5d3-8c1d-4c5f-aaf3-ca400ca2d0f3@github.com>

On Mon, 8 May 2023 13:50:30 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 417:
>> 
>>> 415:             hdr.append(" <a href='#" + id + "' class='anchor-link' aria-label='" + messages.linkToSection
>>> 416:                 + "'><img src='" + pathtoroot + "link.svg' alt='" + messages.linkIcon +"' tabindex='0'"
>>> 417:                 + " style='width: 0.9em; height: 0.9em; vertical-align: baseline;'></a>");
>> 
>> Should this be in a CSS class, not an inline `style` ?
>
> I used inline style to make sure the styles are always available, as the default size of the SVG image is so large that it blows up the layout of the page. My initial choice was to use the `height` and `width` attributes in the HTML `img` element, but after some research came to the conclusion that that was not the proper use of these attributes. (I'm not 100% sure this is the correct conclusion but that's another problem.)
> 
> This is how I ended up with the inline styles. It could probably be moved to the stylesheet, at the risk of blowing up the layout when the page is loaded without stylesheet for some reason (such as network problems).

I think I found a good solution for this. I moved the CSS rules from inline to the stylesheet and added `width` and `height` attributes to the `img` element as fallback / safety net. Both HTML attributes and CSS rules result in the same computed values, but the CSS rules override the HTML attributes. The `vertical-align: baseline` was not needed as that is the default value for that property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13831#discussion_r1187526576

From liach at openjdk.org  Tue May  9 03:17:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 03:17:13 GMT
Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes
Message-ID: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>

Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet.

Current JDK 21:
https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html
https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html
![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png)

This patch:
https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html
https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html
![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png)

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

Commit messages:
 - 8300204: Sealed-class hierarchy graph missing nodes

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

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

From liach at openjdk.org  Tue May  9 04:18:38 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 04:18:38 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes
Message-ID: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>

`@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.

An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
JDK 20:
![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)

This patch:
![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png)

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

Commit messages:
 - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes

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

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

From pminborg at openjdk.org  Tue May  9 06:38:23 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 9 May 2023 06:38:23 GMT
Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes
In-Reply-To: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>
References: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>
Message-ID: <PrN6XzwwrlRwKL2dgdfxrMUGw4y0ZrWQOBAUuW3TWe4=.1385fbf8-e216-427f-9c99-4e1c30b2b786@github.com>

On Tue, 9 May 2023 03:11:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet.
> 
> Current JDK 21:
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html
> ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png)
> 
> This patch:
> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html
> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html
> ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png)

Looks good to me! Thanks for providing this patch. Unfortunately, I am not a reviewer so we have to get someone else to review it.

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

PR Comment: https://git.openjdk.org/jdk/pull/13875#issuecomment-1539537777

From gli at openjdk.org  Tue May  9 14:11:18 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 9 May 2023 14:11:18 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
Message-ID: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>

Hi all,

When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
to solve this issue. And a corresponding test case is added.

Thanks for the review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8288619

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

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

From jjg at openjdk.org  Tue May  9 14:21:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 9 May 2023 14:21:27 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags.   That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.

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

PR Review: https://git.openjdk.org/jdk/pull/13888#pullrequestreview-1418759322

From gli at openjdk.org  Tue May  9 14:36:24 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 9 May 2023 14:36:24 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
Message-ID: <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>

On Tue, 9 May 2023 14:17:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.

If there is something between the tag name and the quoted string, 
the method `quotedString` is never invoked by method `TagParser::parse`.
So such case seems not related to this bug. Do I miss anything?

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1540248594

From jjg at openjdk.org  Tue May  9 14:47:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 9 May 2023 14:47:27 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
 <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>
Message-ID: <bnJ0o_Eltm4nPwHNVrWtQ6rchNNEX2werF6Y5m5H6bg=.aed42d6b-9585-40a5-8583-ba8a8ffd0d84@github.com>

On Tue, 9 May 2023 14:33:50 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> > Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.
> 
> If there is something between the tag name and the quoted string, the method `quotedString` is never invoked by method `TagParser::parse`. So such case seems not related to this bug. Do I miss anything?

I was just trying to imagine a case where `newline` might be true after the tag name has been read.

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1540267331

From jjg at openjdk.org  Tue May  9 17:43:47 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 9 May 2023 17:43:47 GMT
Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes
In-Reply-To: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>
References: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>
Message-ID: <DcfjFqP9l5HM7xsdWPyuzpCR_a8MU3baPbwXWnMda2o=.c360a14f-3f51-40b6-8c1d-708f2356c36e@github.com>

On Tue, 9 May 2023 03:11:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet.
> 
> Current JDK 21:
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html
> ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png)
> 
> This patch:
> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html
> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html
> ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png)

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13875#pullrequestreview-1419153267

From jjg at openjdk.org  Wed May 10 22:09:48 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 10 May 2023 22:09:48 GMT
Subject: Integrated: JDK-8307377: Remove use of `tagName` from
 TagletWriterImpl.linkSeeReferenceOutput
In-Reply-To: <owgI4-lZZgrXlTUQZ_pJB2Uq6lc5HlXhKQPK5fWR2jw=.51249bb0-3d34-439e-8f15-bdaec73ccdda@github.com>
References: <owgI4-lZZgrXlTUQZ_pJB2Uq6lc5HlXhKQPK5fWR2jw=.51249bb0-3d34-439e-8f15-bdaec73ccdda@github.com>
Message-ID: <rO6tFLOmtKKV4y4vmNSqHhJon3BtUJhLyf1pVsZ2QWc=.9cc667fa-f3d9-437e-b9bc-d3b4d5d85439@github.com>

On Thu, 4 May 2023 18:01:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple fix to remove unnecessary detail from in-page and console messages about the name of the tag enclosing a bad reference.

This pull request has now been integrated.

Changeset: f250ab2c
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f250ab2c2ae120c9b25da1486e919f2acf08f7d1
Stats:     48 lines in 8 files changed: 1 ins; 7 del; 40 mod

8307377: Remove use of `tagName` from TagletWriterImpl.linkSeeReferenceOutput

Reviewed-by: hannesw

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

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

From duke at openjdk.org  Thu May 11 08:50:55 2023
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Thu, 11 May 2023 08:50:55 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents [v2]
In-Reply-To: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
Message-ID: <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>

> I modified the location from which javadoc copies some legal files to the generated documentation.  If --legal-notices?option is set to default or nothing is specified,, GPLv2 Legal Documents are copied from legal/java.base/ directory, such as LICENSE, ADDITIONAL_LICENSE_INFO and ASSEMBLY_EXCEPTION.
> 
> Would you please review this fix?

KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:

  8306980: Generated docs should contain correct GPLv2 Legal Documents

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13686/files
  - new: https://git.openjdk.org/jdk/pull/13686/files/74222156..acf1694c

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

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

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

From duke at openjdk.org  Thu May 11 08:53:43 2023
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Thu, 11 May 2023 08:53:43 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents [v2]
In-Reply-To: <dMUiM_hIu7cQ4zQimX2j8y74Rl9Lp2m2_l2IPV8Z6xg=.0bbb6ed6-8832-40dc-9b50-687b80408a4b@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
 <dMUiM_hIu7cQ4zQimX2j8y74Rl9Lp2m2_l2IPV8Z6xg=.0bbb6ed6-8832-40dc-9b50-687b80408a4b@github.com>
Message-ID: <6fxokGwSMT217uXL8awVrPNSvpIZpbQtuGnNO7O4QP8=.07eed60f-304d-488f-ac4c-b51af762d64c@github.com>

On Fri, 5 May 2023 17:30:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8306980: Generated docs should contain correct GPLv2 Legal Documents
>
> The change to use a mixture of `Path` and `File` is bizarre and mostly gratuitous and unnecessary.
> Please stay using `nio.Path` objects.

@jonathan-gibbons 
Thank you for your review.
As your advice, I fixed the test to not use java.io.File.

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

PR Comment: https://git.openjdk.org/jdk/pull/13686#issuecomment-1543598219

From jjg at openjdk.org  Thu May 11 20:05:39 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 May 2023 20:05:39 GMT
Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and
 inlineContent [v6]
In-Reply-To: <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com>
References: <UE7CaXR_PLguWd3vHzG5kUeeo1L5_hpQUSY8AVsj0k4=.d67291fa-a1af-4d87-86a7-e2473abdcc49@github.com>
 <7Ez2OhUYEJyGmYoh31ZiCrjMg4t1qpXCCX2VojLSl6A=.3d578c38-0ff8-4e12-b5e6-7403ff018832@github.com>
Message-ID: <XOb58-cLiw0ulATQykA0C6EY7t-GDIMPtq3GrcFKyFk=.4cb7559e-1e03-4fb9-bf28-404f9fac1916@github.com>

On Wed, 19 Apr 2023 14:17:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment.
>> 
>> **Note:** This is dependent on PR #13362, to convert `DocCommentParser` to use enhanced switch.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback

(keep alive comment).  Still need to respond to feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/13431#issuecomment-1544601330

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

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

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

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

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <w-aBr-h4WVCyWPDEHHatqoQcdQJp6dN4eld2Y-85Ak4=.558819ae-881a-42fb-8b67-7a6b5618e323@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From jjg at openjdk.org  Fri May 12 21:03:56 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 21:03:56 GMT
Subject: RFR: 8300204: Sealed-class hierarchy graph missing nodes
In-Reply-To: <PrN6XzwwrlRwKL2dgdfxrMUGw4y0ZrWQOBAUuW3TWe4=.1385fbf8-e216-427f-9c99-4e1c30b2b786@github.com>
References: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>
 <PrN6XzwwrlRwKL2dgdfxrMUGw4y0ZrWQOBAUuW3TWe4=.1385fbf8-e216-427f-9c99-4e1c30b2b786@github.com>
Message-ID: <BC8AHnhSOcTRfHS3lH7SwDa-AWlGGuC4IjrtiMbdksQ=.c9b7a8d3-c7ba-4cd9-800c-1cb063ef3030@github.com>

On Tue, 9 May 2023 06:35:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet.
>> 
>> Current JDK 21:
>> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html
>> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html
>> ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png)
>> 
>> This patch:
>> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html
>> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html
>> ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png)
>
> Looks good to me! Thanks for providing this patch. Unfortunately, I am not a reviewer so we have to get someone else to review it.

I'll sponsor this, given the comment by @minborg 
https://github.com/openjdk/jdk/pull/13875#issuecomment-1539537777

> Looks good to me! Thanks for providing this patch. Unfortunately, I am not a reviewer so we have to get someone else to review it.

@minborg You may not be an OpenJDK "R"eviewer yet, but you can still "review" changes and report whether you approve the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13875#issuecomment-1546291445
PR Comment: https://git.openjdk.org/jdk/pull/13875#issuecomment-1546296142

From liach at openjdk.org  Fri May 12 21:03:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 May 2023 21:03:58 GMT
Subject: Integrated: 8300204: Sealed-class hierarchy graph missing nodes
In-Reply-To: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>
References: <dEnWc5m2vsfI5_RJRgPbCaVkaZroyrL7axikfyyL7QM=.251f79f1-d205-43a8-a3b5-c470182868b9@github.com>
Message-ID: <XmffcbB11wSNM3sdctsjJwmenVw-mF11vqtV7c7RrhU=.0ad405c7-3118-42c8-8ddb-df8b0c7e733c@github.com>

On Tue, 9 May 2023 03:11:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this simple patch that fixes the package determination for nested classes in the `@sealedGraph` taglet.
> 
> Current JDK 21:
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout.html
> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/ValueLayout.html
> ![image](https://user-images.githubusercontent.com/7806504/236984282-f4361510-6208-4469-92d6-b9ce143204c3.png)
> 
> This patch:
> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/MemoryLayout.html
> https://cr.openjdk.org/~liach/8300204/java.base/java/lang/foreign/ValueLayout.html
> ![image](https://user-images.githubusercontent.com/7806504/236984331-a877a493-487a-444a-984c-9175393cbb92.png)

This pull request has now been integrated.

Changeset: d8afc7be
Author:    Chen Liang <liach at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8afc7beeb4c41c2dae4ec1dd6671464eaec4720
Stats:     9 lines in 1 file changed: 1 ins; 0 del; 8 mod

8300204: Sealed-class hierarchy graph missing nodes

Reviewed-by: jjg

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

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

From jjg at openjdk.org  Fri May 12 21:18:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 21:18:43 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <LvlsyRpk7L9insGV7ZkkiXv-Q7DrE4o0NFNRaZ_Ju94=.a6e00cb5-ddcd-4185-a039-2bd91d4ad7c5@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

I see the problem reported in the JBS issue, but the proposed fix is not the best one.

It would be better to set the `newline` flag to false earlier, perhaps at the beginning of `blockTag`

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

Changes requested by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13888#pullrequestreview-1425165029

From jjg at openjdk.org  Fri May 12 21:35:46 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 21:35:46 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>
Message-ID: <vpT5YCHszDyI9qmnUufXVYSgepyDm2TMJjOVBX7qu1Y=.676ece6e-5c7a-4f67-a1ef-c5245fb96675@github.com>

On Fri, 12 May 2023 21:31:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hi all,
>> 
>> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
>> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
>> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
>> to solve this issue. And a corresponding test case is added.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> test/langtools/tools/javac/doctree/SeeTest.java line 59:
> 
>> 57:      * @see "{@code}"
>> 58:      */
>> 59:     void at_sign_in_quote_string() { }
> 
> (minor) add `d` after `quote` in method name

Also, add a test case for this, with a newline after the tag:

    /**
     * abc.
     * @see
     *    "{@code ...}"
     */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13888#discussion_r1192811508

From jjg at openjdk.org  Fri May 12 21:35:45 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 21:35:45 GMT
Subject: RFR: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

test/langtools/tools/javac/doctree/SeeTest.java line 59:

> 57:      * @see "{@code}"
> 58:      */
> 59:     void at_sign_in_quote_string() { }

(minor) add `d` after `quote` in method name

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13888#discussion_r1192810666

From jjg at openjdk.org  Fri May 12 22:09:47 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 22:09:47 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes
In-Reply-To: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
Message-ID: <7tWiHfGzhyY86-itKV0poJnO80RrNdIvU8bxgoNnbwI=.e52d5164-9f17-4e37-a75c-75bb21a2d565@github.com>

On Tue, 9 May 2023 04:11:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
> 
> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
> JDK 20:
> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
> 
> This patch:
> ![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png)

@minborg You should comment on this one.   

I'm not sure that italics by itself is a good idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1546361261

From jjg at openjdk.org  Fri May 12 22:38:42 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 May 2023 22:38:42 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents [v2]
In-Reply-To: <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
 <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
Message-ID: <iQupKQFoKeQJuRWwF7THEVZ-fxV7BFFNl7NOdgjtjSo=.844faa16-3743-42a6-a4ca-2859ef6ba1b8@github.com>

On Thu, 11 May 2023 08:50:55 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I modified the location from which javadoc copies some legal files to the generated documentation.  If --legal-notices?option is set to default or nothing is specified,, GPLv2 Legal Documents are copied from legal/java.base/ directory, such as LICENSE, ADDITIONAL_LICENSE_INFO and ASSEMBLY_EXCEPTION.
>> 
>> Would you please review this fix?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306980: Generated docs should contain correct GPLv2 Legal Documents

This seems like the wrong solution.

It does not seem right for javadoc to rummage around finding legal files that may or may not be the right ones to use.   By deign, it is supposed to just copy the files from a directory that has been provided. If the files in that directory are wrong or missing, we should fix that, not fix javadoc to go looking elsewhere.

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

Changes requested by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13686#pullrequestreview-1425223519

From gli at openjdk.org  Mon May 15 05:05:46 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 15 May 2023 05:05:46 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v2]
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <HXd2WFYguc4iyB0RPGhQ8C0PGa7bxq7jzmcT7jWv61o=.cd658190-4829-42eb-a9ad-ad6e7f2993cf@github.com>

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:

 - Add test case.
 - Set newline as false at blockTag. Fix typo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13888/files
  - new: https://git.openjdk.org/jdk/pull/13888/files/89f4323a..904c800f

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

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

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

From gli at openjdk.org  Mon May 15 05:05:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 15 May 2023 05:05:48 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v2]
In-Reply-To: <vpT5YCHszDyI9qmnUufXVYSgepyDm2TMJjOVBX7qu1Y=.676ece6e-5c7a-4f67-a1ef-c5245fb96675@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <B8O6eH7ti0FN4icAcx0lCAKjWppG3Sg_CizRzB0KuJI=.4fc2c7ee-87c7-42f7-8a34-7d8f36515716@github.com>
 <vpT5YCHszDyI9qmnUufXVYSgepyDm2TMJjOVBX7qu1Y=.676ece6e-5c7a-4f67-a1ef-c5245fb96675@github.com>
Message-ID: <9DnYgyTK0HGKmfNui5qjYu7lsRJS7aJ0d8OaWOIqOy4=.69ad7b8f-af1a-4199-b72a-4bb3a3e1e88b@github.com>

On Fri, 12 May 2023 21:32:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/tools/javac/doctree/SeeTest.java line 59:
>> 
>>> 57:      * @see "{@code}"
>>> 58:      */
>>> 59:     void at_sign_in_quote_string() { }
>> 
>> (minor) add `d` after `quote` in method name
>
> Also, add a test case for this, with a newline after the tag:
> 
>     /**
>      * abc.
>      * @see
>      *    "{@code ...}"
>      */

> (minor) add `d` after `quote` in method name

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13888#discussion_r1193327514

From gli at openjdk.org  Mon May 15 05:11:47 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 15 May 2023 05:11:47 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v2]
In-Reply-To: <LvlsyRpk7L9insGV7ZkkiXv-Q7DrE4o0NFNRaZ_Ju94=.a6e00cb5-ddcd-4185-a039-2bd91d4ad7c5@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <LvlsyRpk7L9insGV7ZkkiXv-Q7DrE4o0NFNRaZ_Ju94=.a6e00cb5-ddcd-4185-a039-2bd91d4ad7c5@github.com>
Message-ID: <bGuehDVpqgMmFg7mmxpq6gHz33sd2IAcjVTVjqBqODc=.bad5c4b7-e62f-43ba-be30-9578057e3b62@github.com>

On Fri, 12 May 2023 21:15:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> It would be better to set the `newline` flag to false earlier, perhaps at the beginning of `blockTag`

Fixed.

> Here is another test case:
> 
> ```
>     /**
>      * case 2.
>      * @see
>      *    "{@code ...}"
>      */
>     public void m2() { }
> ```

I add this test case. But it fails with the following error message. The `DocCommentTester#PrettyChecker` doesn't seem to work as expected?


METHOD new_line_before_quoted_string PrettyChecker
Error: mismatch
*** expected:
Test_new_line_before_quoted_string.
@see
____"{@code}"
*** found:
Test_new_line_before_quoted_string.
@see_"{@code}"

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1547198907

From pminborg at openjdk.org  Mon May 15 06:49:44 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 May 2023 06:49:44 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes
In-Reply-To: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
Message-ID: <XD7X2jc1b8p91KfG8-BEX60Zp7ocwNi91UnmEUquAcs=.6ac10f70-e8a0-4edf-8603-a1999b41bb8d@github.com>

On Tue, 9 May 2023 04:11:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
> 
> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
> JDK 20:
> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
> 
> This patch:
> ![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png)

Thanks for this improvement suggestion. Indicating "openness" is certainly important. I was playing around with various ways of expressing it and came up with this:

![image](https://github.com/openjdk/jdk/assets/7457876/3f5204b5-7dd7-47ee-9df4-397c5b69f0d4)

What is your opinion on it? It might be slightly more intuitive? We could even do this:

![image](https://github.com/openjdk/jdk/assets/7457876/32e2542f-ef81-4523-a658-d0a39da13ea8)



Here is the code:



digraph G {

 shape="none"
 rankdir = "BT"
 
 ClassDesc -> ConstantDesc
 MethodHandleDesc -> ConstantDesc
 DirectMethodHandleDesc -> MethodHandleDesc
 DynamicConstantDesc -> ConstantDesc
 Float -> ConstantDesc
 Hidden1 -> DynamicConstantDesc [style="dashed"]
 
 Hidden1 [label="<any>"]
 
  ClassDesc [shape=none];
  ConstantDesc [shape=none];
  MethodHandleDesc [shape=none];
  DynamicConstantDesc [shape=none];
  DirectMethodHandleDesc [shape=none];
  Float [shape=none];
  Hidden1 [shape=none];
}

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

PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1547278887

From hannesw at openjdk.org  Mon May 15 14:49:55 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 15 May 2023 14:49:55 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
Message-ID: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>

Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 

With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.

The error message for the warning was enhanced to refer to the default style for the `<a>` element.

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

Commit messages:
 - JDK-8292157: Improve warning messages
 - Merge branch 'master' into JDK-8292157
 - JDK-8292157: Incorrect error: "block element not allowed within inline element <a>"

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

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

From hannesw at openjdk.org  Tue May 16 15:11:46 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 16 May 2023 15:11:46 GMT
Subject: RFR: JDK-8305710: Line breaks in search tags cause invalid JSON in
 index file
Message-ID: <OZEGrOuIQuiQZn5Me4fnPL5lSNTf9MEQJ85RZ3yBjnM=.4025076b-bb41-44d5-a25d-a48b30fd2e61@github.com>

This fixes a number of issues that can or could result in invalid JavaScript search index files, and a single invalid index file breaking the whole JavaDoc search feature.

 - The `IndexItem` now throws `IllegalArgumentException` if the label argument contains a line break. This was the original cause for this bug and was already fixed in [JDK-8305407](https://bugs.openjdk.org/browse/JDK-8305407), but it is a good idea to add the explicit check to fail in a visible way should it occur again.
 - The `IndexItem.escapeQuotes(String)` method now escapes backslashes in addition to quote. Failure to escape a trailing backslash would result in an escaped quote, leading to an invalid index file.
 - The search script gets a check for null/undefined to avoid a missing tag index file to break the search feature as a whole. 

Note that the added test covers only the second item in the list above. The other two changes are trivial and would require undue effort to test.

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

Commit messages:
 - JDK-8305710: Line breaks in search tags cause invalid JSON in index file

Changes: https://git.openjdk.org/jdk/pull/14016/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305710
  Stats: 75 lines in 4 files changed: 45 ins; 6 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14016/head:pull/14016

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

From liach at openjdk.org  Tue May 16 17:16:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 May 2023 17:16:57 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes [v2]
In-Reply-To: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
Message-ID: <CqJKVdta8TzieXphIRZhGhNSTOOOxM6HzlD1tvKtuSk=.9b48dbf4-1a6c-43ad-8dea-1368a9ef351a@github.com>

> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
> 
> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
> JDK 20:
> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
> 
> This patch:
> ![image](https://user-images.githubusercontent.com/7806504/236991592-affcb128-9721-45cf-860c-6292ee6a8bb6.png)

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

 - Use an edge and node to indicate non-sealed hierarchy
 - Merge branch 'master' into fix/sealedgraph-nonsealed
 - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13877/files
  - new: https://git.openjdk.org/jdk/pull/13877/files/cab36e65..bb2d215c

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

  Stats: 99505 lines in 1624 files changed: 79242 ins; 8145 del; 12118 mod
  Patch: https://git.openjdk.org/jdk/pull/13877.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13877/head:pull/13877

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

From liach at openjdk.org  Tue May 16 17:23:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 May 2023 17:23:45 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes
In-Reply-To: <XD7X2jc1b8p91KfG8-BEX60Zp7ocwNi91UnmEUquAcs=.6ac10f70-e8a0-4edf-8603-a1999b41bb8d@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
 <XD7X2jc1b8p91KfG8-BEX60Zp7ocwNi91UnmEUquAcs=.6ac10f70-e8a0-4edf-8603-a1999b41bb8d@github.com>
Message-ID: <Ma1abGQ_HVEAZW9a-sF7cRxRiIcfbqgTnDh2H3PmSfg=.72917519-ccfd-48ce-9083-445bf9bbd102@github.com>

On Mon, 15 May 2023 06:46:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
>> 
>> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
>> JDK 20:
>> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
>> 
>> This patch:
>> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf)
>
> Thanks for this improvement suggestion. Indicating "openness" is certainly important. I was playing around with various ways of expressing it and came up with this:
> 
> ![image](https://github.com/openjdk/jdk/assets/7457876/3f5204b5-7dd7-47ee-9df4-397c5b69f0d4)
> 
> What is your opinion on it? It might be slightly more intuitive? We could even do this:
> 
> ![image](https://github.com/openjdk/jdk/assets/7457876/32e2542f-ef81-4523-a658-d0a39da13ea8)
> 
> 
> 
> Here is the code:
> 
> 
> 
> digraph G {
> 
>  shape="none"
>  rankdir = "BT"
>  
>  ClassDesc -> ConstantDesc
>  MethodHandleDesc -> ConstantDesc
>  DirectMethodHandleDesc -> MethodHandleDesc
>  DynamicConstantDesc -> ConstantDesc
>  Float -> ConstantDesc
>  Hidden1 -> DynamicConstantDesc [style="dashed"]
>  
>  Hidden1 [label="<any>"]
>  
>   ClassDesc [shape=none];
>   ConstantDesc [shape=none];
>   MethodHandleDesc [shape=none];
>   DynamicConstantDesc [shape=none];
>   DirectMethodHandleDesc [shape=none];
>   Float [shape=none];
>   Hidden1 [shape=none];
> }

@minborg Done. I've made the `<any>` in italics and its hover label is "Non-sealed Hierarchy". Example images of ConstantDesc and CallSite:
![image](https://github.com/openjdk/jdk/assets/7806504/f8e83eee-68b4-4a1e-9353-9c5ba5f453ee)
![image](https://github.com/openjdk/jdk/assets/7806504/f98dca5d-0fa9-4fa6-a680-df6c7b690524)

In addition, the copyright year is updated to reflect the correct creation date of this taglet (2022 instead of 2017)

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

PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1550071543

From pminborg at openjdk.org  Wed May 17 06:37:46 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 17 May 2023 06:37:46 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes [v2]
In-Reply-To: <CqJKVdta8TzieXphIRZhGhNSTOOOxM6HzlD1tvKtuSk=.9b48dbf4-1a6c-43ad-8dea-1368a9ef351a@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
 <CqJKVdta8TzieXphIRZhGhNSTOOOxM6HzlD1tvKtuSk=.9b48dbf4-1a6c-43ad-8dea-1368a9ef351a@github.com>
Message-ID: <znMDjneRRwQEuRh5es2LA_ik0uvOxqrn-ZTmRd1aTe8=.4f2b2216-5b90-4c1e-b5c9-c26e539e7468@github.com>

On Tue, 16 May 2023 17:16:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
>> 
>> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
>> JDK 20:
>> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
>> 
>> This patch:
>> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf)
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Use an edge and node to indicate non-sealed hierarchy
>  - Merge branch 'master' into fix/sealedgraph-nonsealed
>  - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes

These changes look very good. A significant improvement to the graph rendering.

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

Marked as reviewed by pminborg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1429913989

From hannesw at openjdk.org  Wed May 17 10:14:07 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 17 May 2023 10:14:07 GMT
Subject: RFR: JDK-8305710: Line breaks in search tags cause invalid JSON in
 index file [v2]
In-Reply-To: <OZEGrOuIQuiQZn5Me4fnPL5lSNTf9MEQJ85RZ3yBjnM=.4025076b-bb41-44d5-a25d-a48b30fd2e61@github.com>
References: <OZEGrOuIQuiQZn5Me4fnPL5lSNTf9MEQJ85RZ3yBjnM=.4025076b-bb41-44d5-a25d-a48b30fd2e61@github.com>
Message-ID: <Xe8wFzQkgB3pIPVn1B-PhY9QEJyODZQZGxEvPPFe2dQ=.ccb28528-e0a4-4563-a2e2-c986d57b3633@github.com>

> This fixes a number of issues that can or could result in invalid JavaScript search index files, and a single invalid index file breaking the whole JavaDoc search feature.
> 
>  - The `IndexItem` now throws `IllegalArgumentException` if the label argument contains a line break. This was the original cause for this bug and was already fixed in [JDK-8305407](https://bugs.openjdk.org/browse/JDK-8305407), but it is a good idea to add the explicit check to fail in a visible way should it occur again.
>  - The `IndexItem.escapeQuotes(String)` method now escapes backslashes in addition to quote. Failure to escape a trailing backslash would result in an escaped quote, leading to an invalid index file.
>  - The search script gets a check for null/undefined to avoid a missing tag index file to break the search feature as a whole. 
> 
> Note that the added test covers only the second item in the list above. The other two changes are trivial and would require undue effort to test.
> 
> I also removed a few `boolean` parameters from test methods in `TestSearch.java` that are always called with `true` as value.

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

  Fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14016/files
  - new: https://git.openjdk.org/jdk/pull/14016/files/7a10b754..db501a82

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

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

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

From gli at openjdk.org  Thu May 18 05:22:49 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 18 May 2023 05:22:49 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v3]
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <id4Ezp_T_WIbRnmaXAWdTmC6NbxpETi9QYvmUruBawA=.999b88f3-9292-4bf6-a649-3fe8d7502d10@github.com>

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Exclude the PrettyChecker.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13888/files
  - new: https://git.openjdk.org/jdk/pull/13888/files/904c800f..7bd28103

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

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

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

From duke at openjdk.org  Thu May 18 11:46:49 2023
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Thu, 18 May 2023 11:46:49 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents [v2]
In-Reply-To: <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
 <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
Message-ID: <ZMEQmaw-goeBIS1LyhhuUbTMmuA7aFdAvoXBJiyAXw8=.7050a1d7-b9e4-4445-850e-32df506ebda1@github.com>

On Thu, 11 May 2023 08:50:55 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I modified the location from which javadoc copies some legal files to the generated documentation.  If --legal-notices?option is set to default or nothing is specified,, GPLv2 Legal Documents are copied from legal/java.base/ directory, such as LICENSE, ADDITIONAL_LICENSE_INFO and ASSEMBLY_EXCEPTION.
>> 
>> Would you please review this fix?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306980: Generated docs should contain correct GPLv2 Legal Documents

Bundling duplicate files is inefficient.
Since the existing design references files under java.base, isn't it reasonable to use those files?

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

PR Comment: https://git.openjdk.org/jdk/pull/13686#issuecomment-1552935328

From liach at openjdk.org  Fri May 19 21:27:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 May 2023 21:27:48 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes
In-Reply-To: <7tWiHfGzhyY86-itKV0poJnO80RrNdIvU8bxgoNnbwI=.e52d5164-9f17-4e37-a75c-75bb21a2d565@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
 <7tWiHfGzhyY86-itKV0poJnO80RrNdIvU8bxgoNnbwI=.e52d5164-9f17-4e37-a75c-75bb21a2d565@github.com>
Message-ID: <VDviVKCiHZw4Bvbaq_-AFSHaRmBGACjGnvMCDSly4aA=.0a178609-ab5c-4250-b708-d4e0aab1a64c@github.com>

On Fri, 12 May 2023 22:07:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
>> 
>> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
>> JDK 20:
>> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
>> 
>> This patch:
>> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf)
>
> @minborg You should comment on this one.   
> 
> I'm not sure that italics by itself is a good idea.

@jonathan-gibbons Can you take a look again at the revised version?

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

PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1555269626

From pminborg at openjdk.org  Mon May 22 07:24:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 07:24:54 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes [v2]
In-Reply-To: <CqJKVdta8TzieXphIRZhGhNSTOOOxM6HzlD1tvKtuSk=.9b48dbf4-1a6c-43ad-8dea-1368a9ef351a@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
 <CqJKVdta8TzieXphIRZhGhNSTOOOxM6HzlD1tvKtuSk=.9b48dbf4-1a6c-43ad-8dea-1368a9ef351a@github.com>
Message-ID: <MAPFU9M8xKFwuATCnJhssP_If8M6EtDLuvbpCktGm9w=.c223e19a-e939-4782-954a-d2e7d83edd2e@github.com>

On Tue, 16 May 2023 17:16:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
>> 
>> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
>> JDK 20:
>> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
>> 
>> This patch:
>> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf)
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Use an edge and node to indicate non-sealed hierarchy
>  - Merge branch 'master' into fix/sealedgraph-nonsealed
>  - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes

Marked as reviewed by pminborg (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1435944754

From jjg at openjdk.org  Tue May 23 21:30:56 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 May 2023 21:30:56 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents [v2]
In-Reply-To: <ZMEQmaw-goeBIS1LyhhuUbTMmuA7aFdAvoXBJiyAXw8=.7050a1d7-b9e4-4445-850e-32df506ebda1@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
 <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
 <ZMEQmaw-goeBIS1LyhhuUbTMmuA7aFdAvoXBJiyAXw8=.7050a1d7-b9e4-4445-850e-32df506ebda1@github.com>
Message-ID: <8P_Vqic4UXnVqUHw7oQ5VmoD7AzGs4-l-ltkbm_gIKE=.1a423dda-f0da-49f4-9509-9dcffea22bf7@github.com>

On Thu, 18 May 2023 11:44:04 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Bundling duplicate files is inefficient.
> Since the existing design references files under java.base, isn't it reasonable to use those files?

While the files being copied are represented in the JDK image with symbolic links, these links are (or should be) implicitly followed when the files are copied into the generated documentation.

For example, here are the files being copied:

lrwxr-xr-x  1 jjg  staff    36 May 23 13:49 ADDITIONAL_LICENSE_INFO -> ../java.base/ADDITIONAL_LICENSE_INFO
lrwxr-xr-x  1 jjg  staff    31 May 23 13:49 ASSEMBLY_EXCEPTION -> ../java.base/ASSEMBLY_EXCEPTION
lrwxr-xr-x  1 jjg  staff    20 May 23 13:49 LICENSE -> ../java.base/LICENSE
-r--r--r--  1 jjg  staff  2936 May 23 13:49 jquery.md
-r--r--r--  1 jjg  staff  1870 May 23 13:49 jqueryUI.md


Here are the files as they are found in generated documentation:

-rw-r--r--  1 jjg  staff   2114 May 23 13:52 ADDITIONAL_LICENSE_INFO
-rw-r--r--  1 jjg  staff   1514 May 23 13:52 ASSEMBLY_EXCEPTION
-rw-r--r--  1 jjg  staff  19274 May 23 13:52 LICENSE
-rw-r--r--  1 jjg  staff   2936 May 23 13:52 jquery.md
-rw-r--r--  1 jjg  staff   1870 May 23 13:52 jqueryUI.md


Note there are no symbolic links in the generated documentation.

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

PR Comment: https://git.openjdk.org/jdk/pull/13686#issuecomment-1560140997

From jjg at openjdk.org  Tue May 23 21:30:59 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 May 2023 21:30:59 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents [v2]
In-Reply-To: <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
 <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
Message-ID: <HlLb3R3kJohHn3RtWoWFVTS4dNQqHjSmoDJgSD8I8QQ=.fec06da5-2459-4c01-91dd-e6d65bc94125@github.com>

On Thu, 11 May 2023 08:50:55 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I modified the location from which javadoc copies some legal files to the generated documentation.  If --legal-notices?option is set to default or nothing is specified,, GPLv2 Legal Documents are copied from legal/java.base/ directory, such as LICENSE, ADDITIONAL_LICENSE_INFO and ASSEMBLY_EXCEPTION.
>> 
>> Would you please review this fix?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306980: Generated docs should contain correct GPLv2 Legal Documents

If you have evidence that symbolic links are being copied to the generated documentation, then the correct fix would be to ensure that any symbolic links **are** followed, and not to simulate following the links as suggested in this PR.

However, I would want to see evidence that symbolic links are ending up in generated documentation before pursuing this any further.

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

PR Comment: https://git.openjdk.org/jdk/pull/13686#issuecomment-1560144942

From jjg at openjdk.org  Wed May 24 20:09:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:09:00 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v3]
In-Reply-To: <id4Ezp_T_WIbRnmaXAWdTmC6NbxpETi9QYvmUruBawA=.999b88f3-9292-4bf6-a649-3fe8d7502d10@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <id4Ezp_T_WIbRnmaXAWdTmC6NbxpETi9QYvmUruBawA=.999b88f3-9292-4bf6-a649-3fe8d7502d10@github.com>
Message-ID: <5khCaXNZ5w1naNAF1mAOKR0Xez3YTrBSG9L6b1STy9g=.92dc074d-562e-41d1-8758-08100b2bd092@github.com>

On Thu, 18 May 2023 05:22:49 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
>> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
>> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
>> to solve this issue. And a corresponding test case is added.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude the PrettyChecker.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13888#pullrequestreview-1442670406

From jjg at openjdk.org  Wed May 24 20:19:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:19:54 GMT
Subject: RFR: JDK-8292157: Incorrect error:
 "block element not allowed within inline element <a>"
In-Reply-To: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
References: <NJ55o_xV_kx7Kaky9EgqC6bYxNoP4jdXT8iCec_7pCA=.ed5b4190-cbf0-4894-a67f-7a0ab8089094@github.com>
Message-ID: <agyvNcy18QQHLDyfJTYoVCLSWXr_MRtofuL86Veu384=.204db998-6642-4cd0-9262-7d82465fc06d@github.com>

On Mon, 15 May 2023 14:43:15 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to downgrade from error to warning if the label of a `<a>` element or reference tag contains an HTML block element. Before HTML 5, elements were clearly divided into block and inline elements, and the latter were not allowed to contain the former. 
> 
> With HTML5, the division between block and inline elements is delegated to CSS, and although elements have default styles, styles can be freely customized by the author. This applies especially true for the `<a>` element which is commonly used both with inline and block layout. That was the rationale for downgrading from error to warning for the `<a>` element only. See the JBS issue comments for details and references.
> 
> The error message for the warning was enhanced to refer to the default style for the `<a>` element.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 80:

> 78: dc.tag.not.allowed = element not allowed in documentation comments: <{0}>
> 79: dc.tag.not.allowed.inline.element = block element not allowed within inline element <{1}>: {0}
> 80: dc.tag.not.allowed.element.default.style = block element not allowed within element <{1}> with default style: {0}

Is it possible to improve the wording?

As written, it is ambiguous/confusing: it seems like `{0}` is the default style, which I don't think is what you intend.
Also, inconsistent pointy brackets `<{1}>` but just `{0}`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13990#discussion_r1204716808

From jjg at openjdk.org  Wed May 24 20:35:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:35:55 GMT
Subject: RFR: JDK-8305958: Use links instead of buttons for auto-generated
 header links [v3]
In-Reply-To: <usMgF0VR4mXiEVT04NYzwVn0DphfGEDu_1ioFtp3tbs=.072a5e2b-200b-4025-9068-8d18f3a66b60@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
 <usMgF0VR4mXiEVT04NYzwVn0DphfGEDu_1ioFtp3tbs=.072a5e2b-200b-4025-9068-8d18f3a66b60@github.com>
Message-ID: <-ywigQ_83d8rICiCs4ssJopaDxrRm1bj7dNnUe6sq9E=.8ff69a04-c72f-4201-980f-e2739b28f9fd@github.com>

On Mon, 8 May 2023 14:35:39 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
>> 
>> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move anchor-link sizing to stylesheet.css

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13831#pullrequestreview-1442706339

From jjg at openjdk.org  Wed May 24 20:45:58 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:45:58 GMT
Subject: RFR: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes [v2]
In-Reply-To: <CqJKVdta8TzieXphIRZhGhNSTOOOxM6HzlD1tvKtuSk=.9b48dbf4-1a6c-43ad-8dea-1368a9ef351a@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
 <CqJKVdta8TzieXphIRZhGhNSTOOOxM6HzlD1tvKtuSk=.9b48dbf4-1a6c-43ad-8dea-1368a9ef351a@github.com>
Message-ID: <c2ktIFzF6cDmV8pyx6_7RW9cBI8IIFBnaDCr2Rc7sW4=.414567c5-6a4c-4a8a-8080-8bdd25136d93@github.com>

On Tue, 16 May 2023 17:16:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
>> 
>> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
>> JDK 20:
>> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
>> 
>> This patch:
>> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf)
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Use an edge and node to indicate non-sealed hierarchy
>  - Merge branch 'master' into fix/sealedgraph-nonsealed
>  - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes

Generally, a good feature and a nice solution.

I endorse @minborg's approval.

Given this is in a build-time taglet for JDK documentation, the use of `<any>` is acceptable and a reasonably good solution.

If this were to ever become a standard javadoc feature, we would maybe have to figure out how to localize the string, but that is not necessary here.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1442720465
PR Comment: https://git.openjdk.org/jdk/pull/13877#issuecomment-1561898654

From jjg at openjdk.org  Wed May 24 20:54:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 20:54:55 GMT
Subject: RFR: JDK-8305710: Line breaks in search tags cause invalid JSON in
 index file [v2]
In-Reply-To: <Xe8wFzQkgB3pIPVn1B-PhY9QEJyODZQZGxEvPPFe2dQ=.ccb28528-e0a4-4563-a2e2-c986d57b3633@github.com>
References: <OZEGrOuIQuiQZn5Me4fnPL5lSNTf9MEQJ85RZ3yBjnM=.4025076b-bb41-44d5-a25d-a48b30fd2e61@github.com>
 <Xe8wFzQkgB3pIPVn1B-PhY9QEJyODZQZGxEvPPFe2dQ=.ccb28528-e0a4-4563-a2e2-c986d57b3633@github.com>
Message-ID: <i-jfXsiDCwDyQb4E0pHOAW3PM_cv74ekO81yU97HlLs=.7b1a71d7-8652-4ed3-bb21-a84d54cc2a5d@github.com>

On Wed, 17 May 2023 10:14:07 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This fixes a number of issues that can or could result in invalid JavaScript search index files, and a single invalid index file breaking the whole JavaDoc search feature.
>> 
>>  - The `IndexItem` now throws `IllegalArgumentException` if the label argument contains a line break. This was the original cause for this bug and was already fixed in [JDK-8305407](https://bugs.openjdk.org/browse/JDK-8305407), but it is a good idea to add the explicit check to fail in a visible way should it occur again.
>>  - The `IndexItem.escapeQuotes(String)` method now escapes backslashes in addition to quote. Failure to escape a trailing backslash would result in an escaped quote, leading to an invalid index file.
>>  - The search script gets a check for null/undefined to avoid a missing tag index file to break the search feature as a whole. 
>> 
>> Note that the added test covers only the second item in the list above. The other two changes are trivial and would require undue effort to test.
>> 
>> I also removed a few `boolean` parameters from test methods in `TestSearch.java` that are always called with `true` as value.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14016#pullrequestreview-1442732298

From jjg at openjdk.org  Wed May 24 21:03:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 21:03:55 GMT
Subject: RFR: JDK-8303056: Improve support for Unicode characters and
 digits in JavaDoc search
In-Reply-To: <0EwKjkX-neABaN07Npm6QN936wh6LeAR6uTbgE6oUcM=.90c3f0e1-a5c3-4cf9-a6ee-f3143f14773b@github.com>
References: <0EwKjkX-neABaN07Npm6QN936wh6LeAR6uTbgE6oUcM=.90c3f0e1-a5c3-4cf9-a6ee-f3143f14773b@github.com>
Message-ID: <F8Akf2DjEofWAhPo2-dz723XDZtRAJb-eCTmcg8Po2c=.2c740263-9ad2-496b-ab59-859a0a514811@github.com>

On Thu, 27 Apr 2023 12:50:07 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to make JavaDoc search Unicode-aware and better handle elements and index items with digits in their names. The most significant change is to use Unicode property escapes in regular expressions in the search script, but a few other changes were needed. In addition to running the updated test I did extensive manual testing on multiple desktop and mobile browsers to make sure search behavior did not change for other cases.

Nice

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13690#pullrequestreview-1442743976

From liach at openjdk.org  Wed May 24 21:07:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 May 2023 21:07:06 GMT
Subject: Integrated: 8307652: sealed class hierarchy graph doesn't distinguish
 non-sealed classes
In-Reply-To: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
References: <gLC1VZp4vv8RIfX-z9hwANO1OgcwI9sIEs6cVgz4QSQ=.0f526a62-2b1d-4633-8856-0ddf5348fa08@github.com>
Message-ID: <uuYkWOAO0rk319wxAHZ1C7maHjRmWpuRNIVI8MzxPgw=.c64311c1-a4b6-4762-be3d-3cb3814f2122@github.com>

On Tue, 9 May 2023 04:11:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> `@sealedGraph` had a mechanism to render non-sealed classes differently, but it's useless because the graph nodes are not bordered. This patch converts the non-sealed classes to be rendered in italics instead.
> 
> An example of `ConstantDesc`, which has a sealed hierarchy except `DynamicConstantDesc`:
> JDK 20:
> ![image](https://user-images.githubusercontent.com/7806504/236991678-e30c181a-cb1f-407a-b3e0-f648fe2df788.png)
> 
> This patch:
> ![image](https://github.com/openjdk/jdk/assets/7806504/4fb8ec10-4f10-4902-8b9d-107b3644b2cf)

This pull request has now been integrated.

Changeset: 1451ac17
Author:    Chen Liang <liach at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1451ac1770aa1fde0a96e475dfe9a92bc76b4eb9
Stats:     59 lines in 1 file changed: 44 ins; 6 del; 9 mod

8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes

Reviewed-by: pminborg, jjg

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

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

From jjg at openjdk.org  Wed May 24 21:14:58 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 May 2023 21:14:58 GMT
Subject: RFR: JDK-8306578: Report error if no label given in @see and
 {@link} when no default is available
In-Reply-To: <9Ng4WJbfI5yyy7wUgGAJH1Nc9qD5ZUnIh495LmAXkn4=.96b813c8-1fbc-412b-b044-9619177bb245@github.com>
References: <9Ng4WJbfI5yyy7wUgGAJH1Nc9qD5ZUnIh495LmAXkn4=.96b813c8-1fbc-412b-b044-9619177bb245@github.com>
Message-ID: <97jsLAGke914wZirnRXWXmOhHHkYD6nAhVXOZckrCSg=.44b420df-acc1-4815-91ef-dbce477ed8e3@github.com>

On Fri, 28 Apr 2023 14:01:18 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a trivial change to generate an error instead of a warning when no label is provided with a reference to a user-provided anchor.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 503:

> 501:                 // A non-empty label is required for fragment links as the
> 502:                 // reference target does not provide a useful default label.
> 503:                 htmlWriter.messages.error(ch.getDocTreePath(refTree), "doclet.link.see.no_label");

This is ... interesting.
This method is called from various places, which is why we pass in a function to report diagnostics in the appropriate way for the caller (meaning, at the appropriate position.). It seems less than ideal to avoid using the function, but that being said, this codepath likely cannot occur in the most problematic situation, in snippets.

I'm not (yet) sure what the right approach is here.  Maybe we can move away from needing the `reportWarning` function. See PR #13811 for a separate PR in this area.

Maybe/probably the better (future?) solution is to pass in the tree path for `refTree` instead of (just) `refTree` by itself.  This could/should be used in all diagnostics and world obviate the need for the `reportWarning` function.  It would still require a TODO in the snippet code, to replace the existing TODO to provide the function for `reportWarning`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13720#discussion_r1186350404

From gli at openjdk.org  Thu May 25 03:29:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 25 May 2023 03:29:08 GMT
Subject: RFR: 8288619: Unexpected parsing for @see [v3]
In-Reply-To: <bnJ0o_Eltm4nPwHNVrWtQ6rchNNEX2werF6Y5m5H6bg=.aed42d6b-9585-40a5-8583-ba8a8ffd0d84@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
 <0ayK4_eUErLWK-fC6QnJzgMSf0El0G07pavGjjoqmpg=.5d760782-d26c-4997-9e8a-a01ccd18eb3e@github.com>
 <MDwWjeV2zMIO5FUspmqGkUvYXJC9mpWeTi10TRdxjRk=.2198cb0b-fe01-4f37-bce1-7500bdb5cfaf@github.com>
 <bnJ0o_Eltm4nPwHNVrWtQ6rchNNEX2werF6Y5m5H6bg=.aed42d6b-9585-40a5-8583-ba8a8ffd0d84@github.com>
Message-ID: <VfNSjAwG1Wkn0VydTUERZeu9fb_D-s8HwyLuXTYyetk=.b798dd84-3be7-4512-b556-25035abd548d@github.com>

On Tue, 9 May 2023 14:44:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.
>> 
>> If there is something between the tag name and the quoted string, 
>> the method `quotedString` is never invoked by method `TagParser::parse`.
>> So such case seems not related to this bug. Do I miss anything?
>
>> > Overall, I would expect `newline` to be set `false`earlier, maybe in `blockTag`, so that the setting applies to all block tags. That might still leave the possibility of a newline happening after the tag name and before the quoted string, but your test case does not cover that.
>> 
>> If there is something between the tag name and the quoted string, the method `quotedString` is never invoked by method `TagParser::parse`. So such case seems not related to this bug. Do I miss anything?
> 
> I was just trying to imagine a case where `newline` might be true after the tag name has been read.

@jonathan-gibbons Thanks for the review. Integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/13888#issuecomment-1562203426

From gli at openjdk.org  Thu May 25 03:29:08 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 25 May 2023 03:29:08 GMT
Subject: Integrated: 8288619: Unexpected parsing for @see
In-Reply-To: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
References: <Fck9YcG9bxqBz7XmMWCfLOkQotfTwhOX8M6KWtl-RMg=.2162b3c8-15e4-45f9-a531-2172cc3a6dbf@github.com>
Message-ID: <29RnUtDlreM20sLXxbVoVShDtKgnQbGha0E8mZ_qyQk=.92ffe700-31df-489e-bf08-b71ef5fc7008@github.com>

On Tue, 9 May 2023 14:01:43 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When invoking the method `DocCommentParser::quotedString` with field `newline` as `true` 
> and the quoted string has the character `@`, `quotedString` will break the loop and return `null`.
> This patch changes the field `newline` to `false` at the beginning of the method `quotedString`
> to solve this issue. And a corresponding test case is added.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: a291f002
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a291f002cdd3daffeccab36ec713d9e59fe50f16
Stats:     46 lines in 3 files changed: 43 ins; 0 del; 3 mod

8288619: Unexpected parsing for @see

Reviewed-by: jjg

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

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

From hannesw at openjdk.org  Thu May 25 07:33:10 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 25 May 2023 07:33:10 GMT
Subject: Integrated: JDK-8305958: Use links instead of buttons for
 auto-generated header links
In-Reply-To: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
References: <OvZ6jqZR62SvBnzL2MvvdEG-LNn2CtdD6BJ8Jjq8Hb0=.fb30292d-694c-4bca-8750-10229a89159f@github.com>
Message-ID: <zgfxM7jyeCaTEMuktAuu4doNN27U_t3LoznsLjemVMg=.f9178411-ec7f-4e52-8ac6-db995197ed19@github.com>

On Fri, 5 May 2023 13:42:22 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to use plain HTML links instead of buttons to provide the URL to page section/heading anchors. Special care was taken to retain the accessibility features added in JDK-8299718, so section links can be reached and activated by keyboard and have an `aria-label` attribute. The generated documentation was tested on a range of desktop and mobile browsers (Firefox, Chrome on Mac OS and Linux, Safari on Mac OS and iOS, Chrome on Android) and can be viewed here:
> 
> https://cr.openjdk.org/~hannesw/8305958/api.00/index.html

This pull request has now been integrated.

Changeset: 3f4abff5
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f4abff59cfe3c5055f086cba969371a9812170f
Stats:     100 lines in 9 files changed: 58 ins; 32 del; 10 mod

8305958: Use links instead of buttons for auto-generated header links

Reviewed-by: jjg

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

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

From hannesw at openjdk.org  Thu May 25 07:44:03 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 25 May 2023 07:44:03 GMT
Subject: Integrated: JDK-8305710: Line breaks in search tags cause invalid JSON
 in index file
In-Reply-To: <OZEGrOuIQuiQZn5Me4fnPL5lSNTf9MEQJ85RZ3yBjnM=.4025076b-bb41-44d5-a25d-a48b30fd2e61@github.com>
References: <OZEGrOuIQuiQZn5Me4fnPL5lSNTf9MEQJ85RZ3yBjnM=.4025076b-bb41-44d5-a25d-a48b30fd2e61@github.com>
Message-ID: <dQzsEt6OFJ0B3wEvX2Z35w1A5kdTkD5GoVjtWM-jOHA=.a14d6d18-ff08-4a7a-a644-3db7d84ed061@github.com>

On Tue, 16 May 2023 15:04:27 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This fixes a number of issues that can or could result in invalid JavaScript search index files, and a single invalid index file breaking the whole JavaDoc search feature.
> 
>  - The `IndexItem` now throws `IllegalArgumentException` if the label argument contains a line break. This was the original cause for this bug and was already fixed in [JDK-8305407](https://bugs.openjdk.org/browse/JDK-8305407), but it is a good idea to add the explicit check to fail in a visible way should it occur again.
>  - The `IndexItem.escapeQuotes(String)` method now escapes backslashes in addition to quote. Failure to escape a trailing backslash would result in an escaped quote, leading to an invalid index file.
>  - The search script gets a check for null/undefined to avoid a missing tag index file to break the search feature as a whole. 
> 
> Note that the added test covers only the second item in the list above. The other two changes are trivial and would require undue effort to test.
> 
> I also removed a few `boolean` parameters from test methods in `TestSearch.java` that are always called with `true` as value.

This pull request has now been integrated.

Changeset: 3272e259
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3272e2597ac1176353bea33fb59e2938395bdb3f
Stats:     74 lines in 4 files changed: 45 ins; 6 del; 23 mod

8305710: Line breaks in search tags cause invalid JSON in index file

Reviewed-by: jjg

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

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

From hannesw at openjdk.org  Fri May 26 14:43:25 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 26 May 2023 14:43:25 GMT
Subject: RFR: JDK-8286470: Support searching for sections in class/package
 javadoc
Message-ID: <ObkB-GnZYr35TBraPq-2gbxiqy9y7OqNOENvZdNWzH4=.744d8c73-2f34-4c8d-8da5-f4748b878b28@github.com>

Please review a change to generate search index entries for all HTML headings in the documentation comments and auxiliary files. The change is relatively straightforward, new new code replaces and complements the code to generate `id` attributes for all headings.

JDK API docs generated with this change are available here: https://cr.openjdk.org/~hannesw/8286470/api.00/

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

Commit messages:
 - JDK-8286470: Support searching for sections in class/package javadoc

Changes: https://git.openjdk.org/jdk/pull/14179/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14179&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286470
  Stats: 135 lines in 5 files changed: 70 ins; 14 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/14179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14179/head:pull/14179

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

From jjg at openjdk.org  Fri May 26 14:52:57 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 May 2023 14:52:57 GMT
Subject: RFR: JDK-8286470: Support searching for sections in class/package
 javadoc
In-Reply-To: <ObkB-GnZYr35TBraPq-2gbxiqy9y7OqNOENvZdNWzH4=.744d8c73-2f34-4c8d-8da5-f4748b878b28@github.com>
References: <ObkB-GnZYr35TBraPq-2gbxiqy9y7OqNOENvZdNWzH4=.744d8c73-2f34-4c8d-8da5-f4748b878b28@github.com>
Message-ID: <4ejXLrtg3fDd0iHn8IcZGh53wIuuUfY6nvBMrO92Cfs=.f8f93da5-e807-443b-b8cc-c55023d30e48@github.com>

On Fri, 26 May 2023 14:36:30 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to generate search index entries for all HTML headings in the documentation comments and auxiliary files. The change is relatively straightforward, new code replaces and complements the code to generate `id` attributes for all headings.
> 
> JDK API docs generated with this change are available here: https://cr.openjdk.org/~hannesw/8286470/api.00/

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1516:

> 1514:             HtmlId htmlId = htmlIds.forHeading(headingContent, headingIds);
> 1515:             id = htmlId.name();
> 1516:             attrs.add("id=\"").add(htmlId.name()).add("\"");

I'm not saying this is wrong, but it does look like a weird way to achieve the goal.  It seems like either the wrong type is being passed in (`Content` instead of `HtmlTree`) or we're missing some abstraction here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14179#discussion_r1206903911

From jjg at openjdk.org  Fri May 26 15:03:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 May 2023 15:03:02 GMT
Subject: RFR: JDK-8286470: Support searching for sections in class/package
 javadoc
In-Reply-To: <ObkB-GnZYr35TBraPq-2gbxiqy9y7OqNOENvZdNWzH4=.744d8c73-2f34-4c8d-8da5-f4748b878b28@github.com>
References: <ObkB-GnZYr35TBraPq-2gbxiqy9y7OqNOENvZdNWzH4=.744d8c73-2f34-4c8d-8da5-f4748b878b28@github.com>
Message-ID: <jCf6M2q2ZqxIjRi6cf722FJ7ePPHXzLHB6haGq1K3Uw=.ce2f26f1-0347-43dc-8f12-bb2be737e0c2@github.com>

On Fri, 26 May 2023 14:36:30 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to generate search index entries for all HTML headings in the documentation comments and auxiliary files. The change is relatively straightforward, new code replaces and complements the code to generate `id` attributes for all headings.
> 
> JDK API docs generated with this change are available here: https://cr.openjdk.org/~hannesw/8286470/api.00/

Nice to see more uses of the index.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14179#pullrequestreview-1446424091

From hannesw at openjdk.org  Fri May 26 18:40:12 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 26 May 2023 18:40:12 GMT
Subject: Integrated: JDK-8286470: Support searching for sections in
 class/package javadoc
In-Reply-To: <ObkB-GnZYr35TBraPq-2gbxiqy9y7OqNOENvZdNWzH4=.744d8c73-2f34-4c8d-8da5-f4748b878b28@github.com>
References: <ObkB-GnZYr35TBraPq-2gbxiqy9y7OqNOENvZdNWzH4=.744d8c73-2f34-4c8d-8da5-f4748b878b28@github.com>
Message-ID: <xZwyxMVAO8NBMrfvQCidhoV3pqqvGec3WsOWwJy6jZU=.8d9b7d91-ba0a-47d9-a1a4-1b59ff9e8cfd@github.com>

On Fri, 26 May 2023 14:36:30 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a change to generate search index entries for all HTML headings in the documentation comments and auxiliary files. The change is relatively straightforward, new code replaces and complements the code to generate `id` attributes for all headings.
> 
> JDK API docs generated with this change are available here: https://cr.openjdk.org/~hannesw/8286470/api.00/

This pull request has now been integrated.

Changeset: a9236346
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a92363461dbe67d8736a6b0c3cbe1c3ad7aa28ae
Stats:     135 lines in 5 files changed: 70 ins; 14 del; 51 mod

8286470: Support searching for sections in class/package javadoc

Reviewed-by: jjg

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

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

From duke at openjdk.org  Tue May 30 09:11:57 2023
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 30 May 2023 09:11:57 GMT
Subject: RFR: 8306980: Generated docs should contain correct GPLv2 Legal
 Documents [v2]
In-Reply-To: <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
References: <GCSfz89ugW2Ate_Y7Nv4GEPdCQlyWkS863TaTHtBJoI=.8109147c-b3f8-46f1-bce2-2035a6791c0e@github.com>
 <ApadsuiHkW-ZYlFyvD5JP6C8El_vMikMSo8FF3Kffq8=.036bce08-4171-4380-946f-1edf89056642@github.com>
Message-ID: <RYy_EXiIRtGCoMPi-YUatiIFIGtCt4W8SkPYMYo0Dzc=.f1da4320-168d-4fad-8ca0-fdbf41e700ec@github.com>

On Thu, 11 May 2023 08:50:55 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> I modified the location from which javadoc copies some legal files to the generated documentation.  If --legal-notices?option is set to default or nothing is specified,, GPLv2 Legal Documents are copied from legal/java.base/ directory, such as LICENSE, ADDITIONAL_LICENSE_INFO and ASSEMBLY_EXCEPTION.
>> 
>> Would you please review this fix?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8306980: Generated docs should contain correct GPLv2 Legal Documents

As you said, there were no problems with platforms other than Windows.
However, as mentioned in the bug issue, on Windows, symbolic links are not supported and the contents of some files like "ADDITIONAL_LICENSE_INFO" are not included in the generated documentation. This fix will ensure that the contents of the files are reliably included  in the generated documentation.

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

PR Comment: https://git.openjdk.org/jdk/pull/13686#issuecomment-1568066692

From prappo at openjdk.org  Tue May 30 15:32:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 30 May 2023 15:32:02 GMT
Subject: RFR: 8304135: Introduce unified overridden methods query
Message-ID: <HpgLjnoF4hgPlfXBvKCDfQ7w_YJsCqBcpzcVVGgwgVw=.cab5522e-bb25-40a8-8419-873f6a4839e4@github.com>

Please review this change.

It turns out that JavaDoc's model for overriding and inheritance for methods is simplistic. As a result, it fails to accommodate upcoming changes in the "method comments algorithm" and the new feature called "directed documentation inheritance".

This change aligns JavaDoc's model for overriding and inheritance for methods with that of the Java Language Specification. The most important part of the change pertains to overridden methods. The model now recognizes that "overrides" is not a transitive relation: from the fact that A overrides B and B overrides C, it does not necessarily follow that A overrides C. The model also recognizes that "overrides" depends on three parameters, not two: the method that overrides, the method that is being overridden, and the class where the override takes place. For details, see the test that this change adds: `TestMethodMembers.java`.

Additionally, the change provides a unified query for method overrides: be it defined in a class or interface, be it abstract or concrete, an overridden method can be queried through a single new API method in `VisibleMemberTable`: 

    public OverrideSequence overrideAt(ExecutableElement method)

That query accepts a method and returns a sequence of methods that the accepted method overrides from the class or interface described by the instance of `VisibleMemberTable` that the query has been called on. That sequence is totally ordered and can be traversed in either direction.

It's quite remarkable that there are only 2 existing tests that required some adjustment after the change. However, there are approximately 250 changed files in the generated JDK API Documentation (i.e. the result of `make docs`). Most of them are benign or beneficial (e.g. they fix a bug). However, there is at least one that will need to be fixed after the upcoming but separate "directed documentation inheritance" update: `java.util.concurrent.LinkedBlockingDeque`.

With this change, it takes the same time (as measured with `TIME(1)`) to run the tests and produce JDK API documentation. Proper benchmarks will be done later on.

---

_Meanwhile, I'll try to figure out a convenient way to attach diffs for JDK API Documentation to this PR._

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

Commit messages:
 - Fix errors reported by jcheck
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14221/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304135
  Stats: 1736 lines in 20 files changed: 1146 ins; 417 del; 173 mod
  Patch: https://git.openjdk.org/jdk/pull/14221.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14221/head:pull/14221

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

From hannesw at openjdk.org  Tue May 30 16:10:39 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 30 May 2023 16:10:39 GMT
Subject: RFR: JDK-8306578: Report error if no label given in @see and
 {@link} when no default is available [v2]
In-Reply-To: <9Ng4WJbfI5yyy7wUgGAJH1Nc9qD5ZUnIh495LmAXkn4=.96b813c8-1fbc-412b-b044-9619177bb245@github.com>
References: <9Ng4WJbfI5yyy7wUgGAJH1Nc9qD5ZUnIh495LmAXkn4=.96b813c8-1fbc-412b-b044-9619177bb245@github.com>
Message-ID: <WIjeOgfhSPysLWJNEi2GozR7aHtxiPNW0UaQZv0f3vk=.5f80d4d3-691c-49cb-9e83-9e5e3d471432@github.com>

> Please review a trivial change to generate an error instead of a warning when no label is provided with a reference to a user-provided anchor.

Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8306578
 - JDK-8306578: Report error if no label given in @see and {@link} when no default is available

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

Changes: https://git.openjdk.org/jdk/pull/13720/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13720&range=01
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13720/head:pull/13720

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

From jjg at openjdk.org  Tue May 30 23:30:18 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 May 2023 23:30:18 GMT
Subject: RFR: JDK-8309150: Need to escape " inside attribute values
Message-ID: <pnbbVIXINUydhbUwtP3R9-fvz7DsnCF7r3_hK8jndko=.052a9019-e85c-4d86-a387-08f3ec8af31d@github.com>

Please review a trivial PR to escape `"` as `&quot;` when writing HTML attribute values enclosed in `"`.

A simple test is added, using a `@spec` tag to introduce a user-defined `id`.

The inverse transformation (from `&quot;` to `"`) needs to be done in the `HtmlParser` for the `JavadocTester` framework.

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

Commit messages:
 - JDK-8309150: Need to escape " inside attribute values

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

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

From jjg at openjdk.org  Tue May 30 23:59:59 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 May 2023 23:59:59 GMT
Subject: RFR: JDK-8306578: Report error if no label given in @see and
 {@link} when no default is available [v2]
In-Reply-To: <97jsLAGke914wZirnRXWXmOhHHkYD6nAhVXOZckrCSg=.44b420df-acc1-4815-91ef-dbce477ed8e3@github.com>
References: <9Ng4WJbfI5yyy7wUgGAJH1Nc9qD5ZUnIh495LmAXkn4=.96b813c8-1fbc-412b-b044-9619177bb245@github.com>
 <97jsLAGke914wZirnRXWXmOhHHkYD6nAhVXOZckrCSg=.44b420df-acc1-4815-91ef-dbce477ed8e3@github.com>
Message-ID: <u96i5Q7hSYWFV7A1MQ0t2yKhdPEc9KGGS7AXIcyJ7VY=.bb1de463-1856-4f84-b0a8-d0c4d91ba573@github.com>

On Fri, 5 May 2023 17:40:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into JDK-8306578
>>  - JDK-8306578: Report error if no label given in @see and {@link} when no default is available
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 503:
> 
>> 501:                 // A non-empty label is required for fragment links as the
>> 502:                 // reference target does not provide a useful default label.
>> 503:                 htmlWriter.messages.error(ch.getDocTreePath(refTree), "doclet.link.see.no_label");
> 
> This is ... interesting.
> This method is called from various places, which is why we pass in a function to report diagnostics in the appropriate way for the caller (meaning, at the appropriate position.). It seems less than ideal to avoid using the function, but that being said, this codepath likely cannot occur in the most problematic situation, in snippets.
> 
> I'm not (yet) sure what the right approach is here.  Maybe we can move away from needing the `reportWarning` function. See PR #13811 for a separate PR in this area.
> 
> Maybe/probably the better (future?) solution is to pass in the tree path for `refTree` instead of (just) `refTree` by itself.  This could/should be used in all diagnostics and world obviate the need for the `reportWarning` function.  It would still require a TODO in the snippet code, to replace the existing TODO to provide the function for `reportWarning`.

Filed https://bugs.openjdk.org/browse/JDK-8309158

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13720#discussion_r1210948173

From prappo at openjdk.org  Wed May 31 07:59:56 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 31 May 2023 07:59:56 GMT
Subject: RFR: JDK-8309150: Need to escape " inside attribute values
In-Reply-To: <pnbbVIXINUydhbUwtP3R9-fvz7DsnCF7r3_hK8jndko=.052a9019-e85c-4d86-a387-08f3ec8af31d@github.com>
References: <pnbbVIXINUydhbUwtP3R9-fvz7DsnCF7r3_hK8jndko=.052a9019-e85c-4d86-a387-08f3ec8af31d@github.com>
Message-ID: <gc_XtW0tgBBIJwBTsNH8y9OV-hF6Dvpx6SnKBTIqKrE=.96339dbc-5e1f-48de-b470-951b999015ea@github.com>

On Tue, 30 May 2023 23:22:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial PR to escape `"` as `&quot;` when writing HTML attribute values enclosed in `"`.
> 
> A simple test is added, using a `@spec` tag to introduce a user-defined `id`.
> 
> The inverse transformation (from `&quot;` to `"`) needs to be done in the `HtmlParser` for the `JavadocTester` framework.

Aside from the stale copyright years, looks good.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14234#pullrequestreview-1452444657

From jjg at openjdk.org  Wed May 31 21:26:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 May 2023 21:26:00 GMT
Subject: RFR: JDK-8309150: Need to escape " inside attribute values [v2]
In-Reply-To: <pnbbVIXINUydhbUwtP3R9-fvz7DsnCF7r3_hK8jndko=.052a9019-e85c-4d86-a387-08f3ec8af31d@github.com>
References: <pnbbVIXINUydhbUwtP3R9-fvz7DsnCF7r3_hK8jndko=.052a9019-e85c-4d86-a387-08f3ec8af31d@github.com>
Message-ID: <a1N7yGBIZgiv7XKLlSV9nyWVBy6Wuk6hwQAXKr4NU9A=.f623b7a4-a958-4aca-8929-79207a3594be@github.com>

> Please review a trivial PR to escape `"` as `&quot;` when writing HTML attribute values enclosed in `"`.
> 
> A simple test is added, using a `@spec` tag to introduce a user-defined `id`.
> 
> The inverse transformation (from `&quot;` to `"`) needs to be done in the `HtmlParser` for the `JavadocTester` framework.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14234/files
  - new: https://git.openjdk.org/jdk/pull/14234/files/aa0cb83a..2e06c0f2

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

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

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

From jjg at openjdk.org  Wed May 31 21:26:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 31 May 2023 21:26:02 GMT
Subject: Integrated: JDK-8309150: Need to escape " inside attribute values
In-Reply-To: <pnbbVIXINUydhbUwtP3R9-fvz7DsnCF7r3_hK8jndko=.052a9019-e85c-4d86-a387-08f3ec8af31d@github.com>
References: <pnbbVIXINUydhbUwtP3R9-fvz7DsnCF7r3_hK8jndko=.052a9019-e85c-4d86-a387-08f3ec8af31d@github.com>
Message-ID: <0Y3Y_rG7nkMEhAkAJ-y9J7_u-tf6woQXrlvyTYvKWek=.4d4d47f6-f953-4de0-8bda-aee021787e02@github.com>

On Tue, 30 May 2023 23:22:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial PR to escape `"` as `&quot;` when writing HTML attribute values enclosed in `"`.
> 
> A simple test is added, using a `@spec` tag to introduce a user-defined `id`.
> 
> The inverse transformation (from `&quot;` to `"`) needs to be done in the `HtmlParser` for the `JavadocTester` framework.

This pull request has now been integrated.

Changeset: 09514745
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09514745fc87d5a212bdf09399aa2045f02b4612
Stats:     80 lines in 3 files changed: 76 ins; 0 del; 4 mod

8309150: Need to escape " inside attribute values

Reviewed-by: prappo

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

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