Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v31]

[Jonathan Gibbons]

> Please review a patch to add support for Markdown syntax in documentation 
> comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` 
> library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 40 commits:

 - Merge remote-tracking branch 'upstream/master' into 
8298405.doclet-markdown-v3
 - improve support for DocCommentParser.LineKind
 - Merge remote-tracking branch 'upstream/master' into 
8298405.doclet-markdown-v3 # Please enter a commit message to explain why this 
merge is necessary, # especially if it merges an updated upstream into a topic 
branch. # # Lines starting with '#' will be ignored, and an empty message 
aborts # the
   commit.
 - update copyright year on test
 - refactor recent new test case in TestMarkdown.java
 - address review feedback
 - address review feedback
 - added test case in TestMarkdown.java for handling of `@deprecated` tag
 - amend comment in test
 - improve comments on negative test case
 - ... and 30 more: https://git.openjdk.org/jdk/compare/2ed889b7...1c64a6e0

-

Changes: https://git.openjdk.org/jdk/pull/16388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=16388=30
  Stats: 22058 lines in 194 files changed: 21390 ins; 271 del; 397 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

[Joe Wang]

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in 
> JDK-8295729:  Properties files is essentially source code. It should have the 
> same whitespace checks as all other source code, so we don't get spurious 
> trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace 
> checks.
> 
> However, this turned out to be problematic, since trailing whitespace is 
> significant in properties files. That issue has mostly been sorted out in a 
> series of PRs, and this patch will finish the job with the few remaining 
> files, and actually enable the check in jcheck.

java.xml changes look fine to me.

-

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1876181019

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

[Joe Wang]

On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie  wrote:

>> This is an attempt to finally implement the idea brought forward in 
>> JDK-8295729:  Properties files is essentially source code. It should have 
>> the same whitespace checks as all other source code, so we don't get 
>> spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace 
>> checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is 
>> significant in properties files. That issue has mostly been sorted out in a 
>> series of PRs, and this patch will finish the job with the few remaining 
>> files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
>  line 24:
> 
>> 22: # Messages for message reporting
>> 23: BadMessageKey = The error message corresponding to the message key can 
>> not be found.
>> 24: FormatFailed = An internal error occurred while formatting the following 
>> message:\n
> 
> Same here with `:\n`...

It's done with the code (that is, a key is appended with the code). In fact, 
the whole Xerces stack was implemented this way. I'd leave it as is.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1486731927

Integrated: 8325570: Update to Graphviz 9.0.0

[Mikael Vidstedt]

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt  wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in 
> particular for creating various module graph images (.svg). This change 
> upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build 
> graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc 
> in the build
> * The version of of the graphviz dependency used when building at Oracle (in 
> jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of 
> Graphviz has an effect on the generated images, I have uploaded the docs 
> generated by graphviz 9.0.0 here: 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline 
> the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: 
> https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): 
> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old 
> (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new 
> graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be 
> identical.

This pull request has now been integrated.

Changeset: 7c697123
Author:Mikael Vidstedt 
URL:   
https://git.openjdk.org/jdk/commit/7c6971239dd9af2a62aefb1163328c66c4507ef1
Stats: 123 lines in 4 files changed: 86 ins; 1 del; 36 mod

8325570: Update to Graphviz 9.0.0

Reviewed-by: erikj, pminborg, ihse, mchung, iris

-

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

Re: RFR: 8325570: Update to Graphviz 9.0.0

[Mikael Vidstedt]

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt  wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in 
> particular for creating various module graph images (.svg). This change 
> upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build 
> graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc 
> in the build
> * The version of of the graphviz dependency used when building at Oracle (in 
> jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of 
> Graphviz has an effect on the generated images, I have uploaded the docs 
> generated by graphviz 9.0.0 here: 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline 
> the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: 
> https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): 
> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old 
> (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new 
> graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be 
> identical.

Thank you for all the reviews!

-

PR Comment: https://git.openjdk.org/jdk/pull/17794#issuecomment-1939516107

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]

[Jonathan Gibbons]

On Mon, 12 Feb 2024 17:27:42 GMT, Jonathan Gibbons  wrote:

>>> I guess it depends how much we want to import the code as-is, without 
>>> knowing any lint-warts.
>> 
>> I think it would be nice not to have to modify code beyond superficial 
>> edits: addition of headers, renaming of packages, and converting of 
>> non-ASCII symbols.
>
> I think adding `@SuppressWarnings` is a superficial edit, but I see the 
> writing on the wall.

Based on additional private conversations, and because the annotation is added 
automatically by the same utility used to address other issues in the imported 
code (package declarations, import statements, non-ASCII characters, etc), I 
will leave the annotation in at this time.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486674245

Re: RFR: 8325570: Update to Graphviz 9.0.0

[Iris Clark]

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt  wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in 
> particular for creating various module graph images (.svg). This change 
> upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build 
> graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc 
> in the build
> * The version of of the graphviz dependency used when building at Oracle (in 
> jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of 
> Graphviz has an effect on the generated images, I have uploaded the docs 
> generated by graphviz 9.0.0 here: 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline 
> the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: 
> https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): 
> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old 
> (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new 
> graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be 
> identical.

This is the java.se module graph generated by the previous version of Graphviz

[https://cr.openjdk.org/~iris/se/22/latestSpec/images/java.se-graph.svg](https://cr.openjdk.org/~iris/se/22/latestSpec/images/java.se-graph.svg)

and the new version:

[https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.se/module-graph.svg](https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.se/module-graph.svg).

They appear to be topologically identical.  The only differences I see is a 
slight increase in size, as noted by @vidmik in his original PR comment and a 
few crossed edges on the lower right side (e.g. java.net.http -> java.base, 
java.prefs -> java.base).

I think it's a minor price to pay for moving to the more recent version.

Thanks for moving to the newer version!

-

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1875970167

Re: RFR: 8325570: Update to Graphviz 9.0.0

[Mandy Chung]

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt  wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in 
> particular for creating various module graph images (.svg). This change 
> upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build 
> graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc 
> in the build
> * The version of of the graphviz dependency used when building at Oracle (in 
> jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of 
> Graphviz has an effect on the generated images, I have uploaded the docs 
> generated by graphviz 9.0.0 here: 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline 
> the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: 
> https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): 
> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old 
> (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new 
> graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be 
> identical.

Marked as reviewed by mchung (Reviewer).

I reviewed the module graph image output.  They look fine with this Graphviz 
update.

-

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1875936929
PR Comment: https://git.openjdk.org/jdk/pull/17794#issuecomment-1939320718

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v30]

[Jonathan Gibbons]

On Mon, 12 Feb 2024 17:44:29 GMT, Pavel Rappo  wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   refactor recent new test case in TestMarkdown.java
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
>  line 1465:
> 
>> 1463: markdownInput.append('\n');
>> 1464: }
>> 1465: markdownInput.append(PLACEHOLDER_BLOCK);
> 
> There's quite a lot of overlap with the recently simplified 
> https://github.com/openjdk/jdk/blob/7c6316886d1ae86a663d996dae373c42281622fd/src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java#L220-L238
> 
> If it's impractical to factor out the common bits, maybe we could at least 
> make the respective parts of HtmlDocletWriter as close as possible to those 
> of MarkdownTransformer.

I think it is impractical to factor out the common bits, but I will look at the 
possibility of making the code more similar -- but no promises.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486609585

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v30]

[Pavel Rappo]

On Fri, 9 Feb 2024 22:17:43 GMT, Jonathan Gibbons  wrote:

>> Please review a patch to add support for Markdown syntax in documentation 
>> comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` 
>> library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   refactor recent new test case in TestMarkdown.java

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

> 1463: markdownInput.append('\n');
> 1464: }
> 1465: markdownInput.append(PLACEHOLDER_BLOCK);

There's quite a lot of overlap with the recently simplified 
https://github.com/openjdk/jdk/blob/7c6316886d1ae86a663d996dae373c42281622fd/src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java#L220-L238

If it's impractical to factor out the common bits, maybe we could at least make 
the respective parts of HtmlDocletWriter as close as possible to those of 
MarkdownTransformer.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486548869

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

[Daniel Fuchs]

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in 
> JDK-8295729:  Properties files is essentially source code. It should have the 
> same whitespace checks as all other source code, so we don't get spurious 
> trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace 
> checks.
> 
> However, this turned out to be problematic, since trailing whitespace is 
> significant in properties files. That issue has mostly been sorted out in a 
> series of PRs, and this patch will finish the job with the few remaining 
> files, and actually enable the check in jcheck.

Approving the sun.net changes.

-

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875818676

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

[Naoto Sato]

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in 
> JDK-8295729:  Properties files is essentially source code. It should have the 
> same whitespace checks as all other source code, so we don't get spurious 
> trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace 
> checks.
> 
> However, this turned out to be problematic, since trailing whitespace is 
> significant in properties files. That issue has mostly been sorted out in a 
> series of PRs, and this patch will finish the job with the few remaining 
> files, and actually enable the check in jcheck.

> @naotoj Thanks! Would you care to also submit a review?

My bad. I thought I approved this PR.

-

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875811619

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]

[Jonathan Gibbons]

On Mon, 12 Feb 2024 17:23:56 GMT, Pavel Rappo  wrote:

>> It's possible, but that would be a more global setting, whereas this is a 
>> very targeted modification.
>> 
>> I guess it depends how much we want to import the code as-is, without 
>> knowing any lint-warts.
>> 
>> FWIW, any module can be compiled with module-specific lint settings, if we 
>> choose to do so.
>
>> I guess it depends how much we want to import the code as-is, without 
>> knowing any lint-warts.
> 
> I think it would be nice not to have to modify code beyond superficial edits: 
> addition of headers, renaming of packages, and converting of non-ASCII 
> symbols.

I think adding `@SuppressWarnings` is a superficial edit, but I see the writing 
on the wall.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486531142

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]

[Pavel Rappo]

On Mon, 12 Feb 2024 16:29:19 GMT, Jonathan Gibbons  wrote:

> I guess it depends how much we want to import the code as-is, without knowing 
> any lint-warts.

I think it would be nice not to have to modify code beyond superficial edits: 
addition of headers, renaming of packages, and converting of non-ASCII symbols.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486526603

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v22]

[Jonathan Gibbons]

On Thu, 8 Feb 2024 17:20:23 GMT, Pavel Rappo  wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to 
>> a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 
>> 8298405.doclet-markdown-v3 # Please enter a commit message to explain why 
>> this merge is necessary, # especially if it
>>merges an updated upstream into a topic branch. # # Lines starting with 
>> '#' will be ignored, and an empty message aborts # the commit.
>>  - add test case contributed by @lahodaj
>>  - initial fix for source offset problem
>>  - remove unused imports
>>  - First pass at remove DocCommentTransformer from the public API.
>>
>>It is still declared internally, and installed by default, using the 
>> service-provider mechanism.
>>If the standard impl is not available, an identity transformer is used.
>>  - updates for "first sentence" issues and tests
>>  - add info about provenance of `jdk.internal.md` module
>>  - MarkdownTransformer: tweak doc comments
>>  - MarkdownTransformer: change `Lower.replaceIter` to be `private final`
>>  - MarkdownTransformer: use suggested text for using streams
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/18e24d06...63dd8bf4
>
> src/jdk.internal.md/share/classes/module-info.java line 41:
> 
>> 39: // * package and import statements are updated
>> 40: // * characters outside the ASCII range are converted to Unicode escapes
>> 41: // * @SuppressWarnings("fallthrough") is added to getSetextHeadingLevel
> 
> I wonder if it would be better to compile this module without (some) lint 
> checks. Is it possible?

It's possible, but that would be a more global setting, whereas this is a very 
targeted modification.

I guess it depends how much we want to import the code as-is, without knowing 
any lint-warts.

FWIW, any module can be compiled with module-specific lint settings, if we 
choose to do so.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486450189

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]

[Pavel Rappo]

On Thu, 8 Feb 2024 18:52:54 GMT, Jonathan Gibbons  wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java
>>  line 145:
>> 
>>> 143: }
>>> 144: 
>>> 145: Pattern tag = Pattern.compile("<(?[A-Za-z0-9]+)(\\s|>)");
>> 
>> I'm not sure I grok this pattern; what's up with `\\s`?
>
> The code is looking for HTML tag names, The match for a tag name is one of
> * `<` _tag-name_ `>`
> * `<` _tag-name_ _whitespace_

I see, thanks.
Suggestion:

private final Pattern tag = Pattern.compile("<(?[A-Za-z0-9]+)(\\s|>)");

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486384478

Re: RFR: 8325626: Allow selection of non-matching configurations using CONF=!string

[Julian Waters]

On Mon, 12 Feb 2024 11:44:46 GMT, Magnus Ihse Bursie  wrote:

> A common scenario is for a developer to have two configurations, a product 
> and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the 
> latter using `CONF` is just a matter of using `CONF=debug`, but to select the 
> former, the complete name needs to be supplied: `CONF=linux-x64`.
> 
> Instead, this patch introduces the use of `!` as a negation character, so 
> `CONF=!debug` would select all configurations that do not match `debug`. 
> 
> I also took the time to clarify and correct the documentation on how to use 
> `CONF`.

Marked as reviewed by jwaters (Committer).

-

PR Review: https://git.openjdk.org/jdk/pull/17804#pullrequestreview-1875552891

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]

[Pavel Rappo]

On Tue, 30 Jan 2024 23:47:00 GMT, Jonathan Gibbons  wrote:

>> src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java
>>  line 771:
>> 
>>> 769: copyTo(getStartPos(link));
>>> 770: // push temporary value for {@code trees} while 
>>> handling the content of the node
>>> 771: var saveTrees = trees;
>> 
>> "saveTrees": I see what you did there :-)
>
> ?? Not sure I understand this comment.

It's just a funny word play evoking the famous eco slogan, is all.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486368352

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]

[Pavel Rappo]

On Thu, 1 Feb 2024 00:19:42 GMT, Jonathan Gibbons  wrote:

>> I'll add a test case.
>
> Done

Thank you. I double-checked: if that `replace` is removed, 
jdk/javadoc/doclet/testMarkdown/TestMarkdown.java fails.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486361794

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]

[Pavel Rappo]

On Wed, 31 Jan 2024 22:15:23 GMT, Jonathan Gibbons  wrote:

>> I guess I don't see this as being as big a deal as you seem to think it is. 
>> What is it that you are so concerned about?
>> 
>> I also think it is a potential feature to document and use reference links 
>> with `code:` URLs, using the reference link syntax to avoid having long 
>> method signatures in narrative text.
>> 
>> For example, 
>> 
>>One of the methods on [List] has [lots of args][List.of10].
>>
>>[List.of10]code:List.of(E,E,E,E,E,E,E,E,E,E)
>
> I've changed the prefix to be dynamically generated. It's now called 
> `autorefScheme` and is passed around as needed. It contains a hex hashcode, 
> so is reasonably unguessable.
> 
> I'm still sort-of sad to lose the ability to use `code:` URLs directly, so 
> I've left a comment in the code hinting that that is a possibility.

Thanks for accepting this; we could revert it later if the fixed, known scheme 
is deemed more useful.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486364459

Re: RFR: JDK-8298405: Support Markdown in Documentation Comments [v7]

[Pavel Rappo]

On Tue, 30 Jan 2024 23:15:32 GMT, Jonathan Gibbons  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java 
>> line 790:
>> 
>>> 788: 
>>> 789: // end of paragraph is newline, followed by a blank line or 
>>> the beginning of the next block
>>> 790: private static final Pattern endPara = Pattern.compile("\n(([ 
>>> \t]*\n)|( {0,3}[-+*#=]))");
>> 
>> So DocTreeMaker now also knows about Markdown. I wonder if we can avoid 
>> that. Also, I assume you mean this (`+` is not a part of "thematic break"):
>> Suggestion:
>> 
>> private static final Pattern endPara = Pattern.compile("\n(([ 
>> \t]*\n)|( {0,3}[-_*#=]))");
>
> The code is doing its best to model the non-Markdown behavior, which is to 
> detect paragraph breaks, which terminate the first sentence in the absence of 
> any period.
> 
> `+` is in the pattern as a list marker; I added `_` for thematic break, and 
> added more comments.

I can see that you have fixed it to recognise lists `+` and thematic breaks 
`_`; good.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486343596

Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]

[Magnus Ihse Bursie]

On Mon, 12 Feb 2024 14:09:49 GMT, Julian Waters  wrote:

> That said, should I test autoconf on all platforms too?

No, that seems over the top. For this purpose, we must assume that all autoconf 
on all platforms behave the same.

-

PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938783176

Re: RFR: 8325626: Allow selection of non-matching configurations using CONF=!string

[Erik Joelsson]

On Mon, 12 Feb 2024 11:44:46 GMT, Magnus Ihse Bursie  wrote:

> A common scenario is for a developer to have two configurations, a product 
> and a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the 
> latter using `CONF` is just a matter of using `CONF=debug`, but to select the 
> former, the complete name needs to be supplied: `CONF=linux-x64`.
> 
> Instead, this patch introduces the use of `!` as a negation character, so 
> `CONF=!debug` would select all configurations that do not match `debug`. 
> 
> I also took the time to clarify and correct the documentation on how to use 
> `CONF`.

Marked as reviewed by erikj (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/17804#pullrequestreview-1875350996

Re: [External] : Re: Which JDK in the build directory is the one that is shipped?

[erik . joelsson]

On 2/11/24 03:14, Julian Waters wrote:

Hi Erik,

Thanks for the clarification! How then does Oracle compile the JDK, 
such that the versioning numbers appear in the following manner?


C:\Users\vertig0>java --version
java 21 2023-09-19 LTS
Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
Java HotSpot(TM) 64-Bit Server VM (build 21+35-LTS-2513, mixed mode, 
sharing)


(My system doesn't have OpenJDK as its main JDK, and uses the Oracle 
JDK instead. The "Java" strings should rightfully be "OpenJDK", so pay 
no mind to that. Last I remember, the printed OpenJDK version is the 
same as above except for "Java(TM)" being "OpenJDK" instead)


The MSYS2 Project would prefer to have its MinGW JDKs versioned as 
such (Eg build 21+35-LTS-2513 or whatever), rather than something like 
"23-internal-adhoc.mingwci.jdk", and we'd prefer to mimic how Oracle 
compiles both OpenJDK and Oracle JDK as closely as possible.


I believe Oracle probably does it by specifying different parts of the 
version string on configure, something like


bash configure 
make product-bundles

but I'd like to know the exact flags used, especially for Windows 
binaries, if possible



These are the relevant arguments we used for that particular build:

 --with-version-build=35 --with-version-pre= --with-version-opt=LTS-2513

/Erik


best regards,
Julian

On Thu, Feb 1, 2024 at 9:52 PM  wrote:

On 2/1/24 04:47, Julian Waters wrote:
> Hi all,
>
> Quick question: Which JDK in the build directory is the one that is
> officially shipped by Oracle? Is it the one in "jdk" that is
directly
> in the build directory, or the one in "images/jdk"?

The one in images/jdk is the one we base the distribution on, but
it's
not actually exactly that. For historic reasons the image
generated in
images/jdk contains external debug symbols, which we do not ship.
To get
exactly what is shipped, run `make product-bundles` and check the
zip/tar.gz in "bundles/".

The one directly in jdk, the "exploded image", just exists because
it's
faster to build, especially incrementally, so in some developer
workflows it's preferred. Since the class files are all laid out
on disk
and not jlinked together, it has quite different performance
characteristics.

/Erik

Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]

[Julian Waters]

On Mon, 12 Feb 2024 13:57:55 GMT, Magnus Ihse Bursie  wrote:

> I have verified that this works fine in the Oracle internal CI.
> 
> Erik's point still stands:
> 
> > I still think it would be prudent to verify this patch with all the 
> > currently accepted versions of autoconf (2.69, 2.70, 2.71, 2.72).
> 
> I think the easiest way to achieve this is to checkout the autoconf at these 
> versions, and build it yourself. Iirc it was quite easy to build autoconf 
> (anything else would be a shame and very bad PR for the project! :-o).
> 
> I'm hoping you are willing to do this, since I believe this is a superior 
> solution and I'd like to see it in mainline. (Otherwise, let me know and I'll 
> try to squeeze in doing it.)

It's actually even easier to do on Windows than it might appear, since MinGW's 
pacman system has caches that contain past package versions. I wouldn't have to 
build it at all in fact, all I'd have to do is downgrade my autoconf to past 
versions (I think I'm currently on 2.71). I know you're probably very busy 
right now, so I'll spare you the chore of having to do that by testing it on my 
end. That said, should I test autoconf on all platforms too? That aside, I'm 
still a little unhappy that there is no formal way to unregister an AC_DEFUN 
macro though :(

By the way, I've left you something in the mail. Hope you have some time to 
check it out!

-

PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938751180

Re: RFR: 8323672: Suppress unwanted autoconf added flags in CC and CXX [v7]

[Magnus Ihse Bursie]

On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters  wrote:

>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted 
>> autoconf flags being added to the command line, and solves the issue by 
>> filtering out the added flags by force. This is not optimal however, as 
>> doing so leaves the autoconf message that the flags were added still 
>> displaying during the configure process, which is confusing. Instead, 
>> setting a couple of fields to disable the autoconf internals responsible for 
>> the unwanted flag is a cleaner solution
>
> Julian Waters has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Implement custom AC_PROG_CC and AC_PROG_CXX in util.m4

I have verified that this works fine in the Oracle internal CI.

Erik's point still stands:
> I still think it would be prudent to verify this patch with all the currently 
> accepted versions of autoconf (2.69, 2.70, 2.71, 2.72).

I think the easiest way to achieve this is to checkout the autoconf at these 
versions, and build it yourself. Iirc it was quite easy to build autoconf 
(anything else would be a shame and very bad PR for the project! :-o).

I'm hoping you are willing to do this, since I believe this is a superior 
solution and I'd like to see it in mainline. (Otherwise, let me know and I'll 
try to squeeze in doing it.)

-

PR Comment: https://git.openjdk.org/jdk/pull/17401#issuecomment-1938730535

Re: RFR: 8325570: Update to Graphviz 9.0.0

[Magnus Ihse Bursie]

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt  wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in 
> particular for creating various module graph images (.svg). This change 
> upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build 
> graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc 
> in the build
> * The version of of the graphviz dependency used when building at Oracle (in 
> jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of 
> Graphviz has an effect on the generated images, I have uploaded the docs 
> generated by graphviz 9.0.0 here: 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline 
> the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: 
> https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): 
> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old 
> (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new 
> graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be 
> identical.

LGTM. Thanks for updating the build documentation!

-

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1875177939

RFR: 8325626: Allow selection of non-matching configurations using CONF=!string

[Magnus Ihse Bursie]

A common scenario is for a developer to have two configurations, a product and 
a debug version, e.g. `linux-x64`and `linux-x64-debug`. To select the latter 
using `CONF` is just a matter of using `CONF=debug`, but to select the former, 
the complete name needs to be supplied: `CONF=linux-x64`.

Instead, this patch introduces the use of `!` as a negation character, so 
`CONF=!debug` would select all configurations that do not match `debug`. 

I also took the time to clarify and correct the documentation on how to use 
`CONF`.

-

Commit messages:
 - 8325626: Allow selection of non-matching configurations using CONF=!string

Changes: https://git.openjdk.org/jdk/pull/17804/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=17804=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325626
  Stats: 51 lines in 4 files changed: 30 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17804/head:pull/17804

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

Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]

[Joachim Kern]

On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern  wrote:

>> And also `#define statvfs statvfs64` is not necessary with the same 
>> explanation as  for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the 
>> filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it 
>> has a width of 16 Bytes.
>
>> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? 
>> If so, I could not be bothered to make another change. Otherwise, we can get 
>> rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.
> 
> Same as `statvfs`. Only the file system ID field is smaller.

> @JoKern65 @MBaesken I did not receive any reply about what to do with 
> `fstatvfs`, so I decided to keep the last verified change for AIX. If you 
> want to clean this up, then please do so, but at that time it will be an 
> AIX-only patch.

@magicus I have to reach out to IBM asking if the different size of the 
'filesystem ID' field in statvfs makes an important difference. If not, I will 
remove the defines in an AIX-only patch.
Thanks a lot for your effort.

-

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938300228

Re: RFR: 8325570: Update to Graphviz 9.0.0

[Per Minborg]

On Fri, 9 Feb 2024 19:02:13 GMT, Mikael Vidstedt  wrote:

> Graphviz (aka. dotty/dot) is used when building "full" docs, and in 
> particular for creating various module graph images (.svg). This change 
> upgrades the Graphviz version used to 9.0.0 (latest).
> 
> In particular, the change:
> 
> * Updates the createGraphvizBundle.sh script (currently broken) to build 
> graphviz from source
> * Updates doc/building.{md,html} to reflect the role of Graphviz and Pandoc 
> in the build
> * The version of of the graphviz dependency used when building at Oracle (in 
> jib-profiles.js)
> 
> Since, in addition to the changes in this PR itself, the exact version of 
> Graphviz has an effect on the generated images, I have uploaded the docs 
> generated by graphviz 9.0.0 here: 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/. For baseline 
> the latest jdk23 docs, which uses graphviz 2.38.0, should do the trick: 
> https://download.java.net/java/early_access/jdk23/docs/api/.
> 
> For example, picking a random .svg file:
> 
> baseline (graphviz 2.38.0): 
> https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> new (graphviz 9.0.0): 
> https://cr.openjdk.org/~mikael/graphviz-9.0.0/cmp-v1/docs/api/java.base/java/lang/classfile/Signature/RefTypeSig-sealed-graph.svg
> 
> 
> Testing: tier1, manual inspection of a few of the generated .svg files
> 
> As far as I can tell there are only very minor differences between the old 
> (2.38.0) and new (9.0.0) .svg files. In particular, it seems like the new 
> graphs are ever so slightly (5-10% or so) larger, but otherwise appear to be 
> identical.

I have reviewed the image output for some classes (e.g. MemoryLayout) and there 
is a small scale difference and some minor changes in the appearance of 
rendered objects. As the rendering is not strictly defined, the effect of the 
proposed changes looks good to me.

-

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17794#pullrequestreview-1874769735

Re: Which JDK in the build directory is the one that is shipped?

[Andrew Haley]

On 2/11/24 11:14, Julian Waters wrote:

Hi Erik,

Thanks for the clarification! How then does Oracle compile the JDK, such that 
the versioning numbers appear in the following manner?

C:\Users\vertig0>java --version
java 21 2023-09-19 LTS
Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
Java HotSpot(TM) 64-Bit Server VM (build 21+35-LTS-2513, mixed mode, sharing)

(My system doesn't have OpenJDK as its main JDK, and uses the Oracle JDK instead. The "Java" strings should 
rightfully be "OpenJDK", so pay no mind to that. Last I remember, the printed OpenJDK version is the same as 
above except for "Java(TM)" being "OpenJDK" instead)

The MSYS2 Project would prefer to have its MinGW JDKs versioned as such (Eg build 
21+35-LTS-2513 or whatever), rather than something like 
"23-internal-adhoc.mingwci.jdk", and we'd prefer to mimic how Oracle compiles 
both OpenJDK and Oracle JDK as closely as possible.

I sh ./configure --helpbelieve Oracle probably does it by specifying different 
parts of the version string on configure, something like

bash configure 


"sh ./configure --help" and look for the --with-version options.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]

[Magnus Ihse Bursie]

On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern  wrote:

>> And also `#define statvfs statvfs64` is not necessary with the same 
>> explanation as  for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the 
>> filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it 
>> has a width of 16 Bytes.
>
>> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? 
>> If so, I could not be bothered to make another change. Otherwise, we can get 
>> rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.
> 
> Same as `statvfs`. Only the file system ID field is smaller.

@JoKern65 @MBaesken I did not receive any reply about what to do with 
`fstatvfs`, so I decided to keep the last verified change for AIX. If you want 
to clean this up, then please do so, but at that time it will be an AIX-only 
patch.

-

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938201250

Re: RFR: 8325558: Add jcheck whitespace checking for properties files

[Magnus Ihse Bursie]

On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato  wrote:

>> This is an attempt to finally implement the idea brought forward in 
>> JDK-8295729:  Properties files is essentially source code. It should have 
>> the same whitespace checks as all other source code, so we don't get 
>> spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace 
>> checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is 
>> significant in properties files. That issue has mostly been sorted out in a 
>> series of PRs, and this patch will finish the job with the few remaining 
>> files, and actually enable the check in jcheck.
>
> Skimmed through the changes and all look good to me. Good to have `jcheck` 
> detect those unneeded trailing spaces.

@naotoj Thanks! Would you care to also submit a review?

-

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1938204446

Integrated: 8324539: Do not use LFS64 symbols in JDK libs

[Magnus Ihse Bursie]

On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie  wrote:

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we 
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK 
> native libraries.

This pull request has now been integrated.

Changeset: e5cb78cc
Author:Magnus Ihse Bursie 
URL:   
https://git.openjdk.org/jdk/commit/e5cb78cc88761cd27964e9fe77fc9c6f9073e888
Stats: 310 lines in 29 files changed: 23 ins; 144 del; 143 mod

8324539: Do not use LFS64 symbols in JDK libs

Reviewed-by: jwaters, erikj, mbaesken, alanb

-

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

Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11]

[Sam James]

On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie  wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we 
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK 
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to 
> a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into jdk-FOB64
>  - Fix indentation
>  - Once more, remove AIX dirent64 et al defines
>  - Also fix fstatvfs on AIX
>  - Redefine statvfs as statvfs64 on AIX
>  - Add kludge to BufferedRenderPipe.c for AIX
>  - Merge branch 'master' into jdk-FOB64
>  - Remove all system includes from debug_util.h
>  - Merge branch 'master' into jdk-FOB64
>  - Move #include  out of debug_util.h
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b

Thank you again for this!

-

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938202537

Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v12]

[Magnus Ihse Bursie]

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we 
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK 
> native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one 
additional commit since the last revision:

  Update copyright year

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/caccbf9b..7f673ef6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=17538=11
 - incr: https://webrevs.openjdk.org/?repo=jdk=17538=10-11

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

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

Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11]

[Magnus Ihse Bursie]

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we 
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK 
> native libraries.

Magnus Ihse Bursie has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into jdk-FOB64
 - Fix indentation
 - Once more, remove AIX dirent64 et al defines
 - Also fix fstatvfs on AIX
 - Redefine statvfs as statvfs64 on AIX
 - Add kludge to BufferedRenderPipe.c for AIX
 - Merge branch 'master' into jdk-FOB64
 - Remove all system includes from debug_util.h
 - Merge branch 'master' into jdk-FOB64
 - Move #include  out of debug_util.h
 - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b

-

Changes: https://git.openjdk.org/jdk/pull/17538/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk=17538=10
  Stats: 284 lines in 29 files changed: 23 ins; 144 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/17538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538

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