On Fri, 14 Jun 2024 02:32:16 GMT, Nizar Benalla wrote:
>> Nizar Benalla has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> whitespace
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line
> 695:
>
>> 693:
On Fri, 14 Jun 2024 19:16:26 GMT, Nizar Benalla wrote:
>> Can I please get a review for this change, that aims to add support for
>> Global HTML tags.
>> Here is the
>> [link](https://cr.openjdk.org/~nbenalla/javadocGlobalPR/pkg1/package-summary.html)
>> to the generated docs.
>> Thanks in
On Tue, 11 Jun 2024 13:03:47 GMT, Pavel Rappo wrote:
>> Nizar Benalla 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 ten additional
>> commits
On Tue, 11 Jun 2024 22:12:42 GMT, Jonathan Gibbons wrote:
>> Nizar Benalla 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 conta
On Fri, 14 Jun 2024 12:12:51 GMT, Nizar Benalla wrote:
>> Can I please get a review for this change, that aims to add support for
>> Global HTML tags.
>> Here is the
>> [link](https://cr.openjdk.org/~nbenalla/javadocGlobalPR/pkg1/package-summary.html)
>> to the generated docs.
>> Thanks in
On Tue, 11 Jun 2024 13:41:58 GMT, Pavel Rappo wrote:
>> If we are ordering the entries, we can use comparable to check that an attr
>> is greater than the start of the global attr, something like
>>
>> private static boolean isGlobalAttr(Attr value) {
>> return
On Tue, 11 Jun 2024 12:40:23 GMT, Nizar Benalla wrote:
>> Either what Chen has suggested or re-sort the complete list alphabetically
>> as it was prior to this change, well, almost.
>
>> Either what Chen has suggested or re-sort the complete list alphabetically
>> as it was prior to this
On Tue, 11 Jun 2024 15:09:03 GMT, Pavel Rappo wrote:
>> I think like being slightly restrictive and safe.
>
> As @jonathan-gibbons likes to point out, javadoc is not an HTML validation
> tool. So I think, it's okay to leave the code simple. Maybe this would be
> even simp
On Mon, 3 Jun 2024 06:37:22 GMT, psoujany wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
>> line 349:
>>
>>> 347: * For more information on the `widget_tabbable_single`
>>> rule, please refer to the following documentation:
>>> 348:
the language or tools, (e.g.
>> `the name of this class`, ``, ``.
>>
>> This change seems to be going backwards.
>>
>> Whatever the policy we use for translating (or not translating) parts of a
>> message, we should be consistent across all tools and documents.
>
y, the diffs are viewable here and was generated using Jonathan
> Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
line 409:
> 407: compiler.err.unconditional.pattern.and.default=Switch umfas
On Sun, 9 Jun 2024 22:07:44 GMT, Damon Nguyen wrote:
>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
>> line 183:
>>
>>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach
>>> Umschalt+Tab.\nVerwenden Sie "I" für automatischen Import, "V" zur
>>>
On 6/5/24 2:51 AM, Osipov, Michael wrote:
On 2024-05-31 21:38, Jonathan Gibbons wrote:
Michael,
There is no `element-list` file for any version of JDK before JDK 9.
Before JDK 9, the appropriate information was in the `package-list`
file. In JDK 9, with the introduction of modules, the format
On Fri, 31 May 2024 09:20:27 GMT, Pavel Rappo wrote:
>> I understand the solution and see how it logically parallels the existing
>> link between `getDocTreePath` and inheritable taglets. That said, I dislike
>> the solution, but also cannot propose a better one at this time. The logic
>> is
On Fri, 31 May 2024 06:28:28 GMT, Jan Lahoda wrote:
>> This is an attempt to add Markdown support in documentation comments to
>> JShell.
>>
>> It works by converting the Markdown text to HTML during the process of
>> resolving `{@inheritDoc}` tags.
>
> Jan Lahoda has updated the pull request
Michael,
There is no `element-list` file for any version of JDK before JDK 9.
Before JDK 9, the appropriate information was in the `package-list`
file. In JDK 9, with the introduction of modules, the format of the file
was updated to include modules, and because this was an incompatible
On Wed, 29 May 2024 19:39:14 GMT, Hannes Wallnöfer wrote:
> Please review a patch to change the breadcrumb sub-navigation in API docs to
> display nested classes as separate links.
>
> The change itself is simple, I replaced the `getBreadCrumbLink` method in
> `HtmlDocletWriter` which
On Tue, 28 May 2024 12:28:53 GMT, Hannes Wallnöfer wrote:
> Please review a simple fix to make DocLint report an error when linking to
> non-declared types in `{@link}` or `@see` tags. This has been implemented
> when the Standard Doclet is running without DocLint in
>
On Thu, 30 May 2024 18:43:28 GMT, Pavel Rappo wrote:
> I understand the solution and see how it logically parallels the existing
> link between `getDocTreePath` and inheritable taglets. That said, I dislike
> the solution, but also cannot propose a better one at this time. The logic is
>
On Thu, 23 May 2024 10:39:52 GMT, Hannes Wallnöfer wrote:
> Please review a patch to fix a NPE thrown when a `@since` tag inherited by a
> nested class contains a nested inline tag. The solution is to make
> `CommentHelper.getDocTreePath(DocTree)` able to handle block tags inherited
> by
On Thu, 30 May 2024 18:33:25 GMT, Jonathan Gibbons wrote:
>> Please review a patch to fix a NPE thrown when a `@since` tag inherited by a
>> nested class contains a nested inline tag. The solution is to make
>> `CommentHelper.getDocTreePath(DocTree)` able to handle bl
On Wed, 29 May 2024 11:50:14 GMT, Jan Lahoda wrote:
>> If the javadoc comment contains a (Markdown) link like:
>>
>> [java.util.Arrays#asList(Object[])]
>>
>>
>> The transformer that converts this link into the Javadoc link will not find
>> the reference, as it is looking for
On Tue, 28 May 2024 19:07:06 GMT, Vicente Romero wrote:
>> Sorry for the belated answer. Yes, regexps are usually not very performant,
>> but it is only happening when the exact match fails. And, hopefully, the
>> regexp should not be too difficult to handle. I was considering writing the
>>
On Fri, 24 May 2024 09:05:20 GMT, Jan Lahoda wrote:
> If the javadoc comment contains a (Markdown) link like:
>
> [java.util.Arrays#asList(Object[])]
>
>
> The transformer that converts this link into the Javadoc link will not find
> the reference, as it is looking for
On Fri, 24 May 2024 15:47:02 GMT, Hannes Wallnöfer wrote:
>> Please review a relatively simple update to the generated Help page, as part
>> of the ongoing campaign to improve the documentation around the overall use
>> of `@since` tags.
>
>
On Mon, 20 May 2024 20:17:10 GMT, Jonathan Gibbons wrote:
> Please review a small fix to address a crash when handling HTML5 entities in
> a Markdown doc comment.
>
> The path for the `entities.txt` (originally `entities.properties`) was not
> correctly imported when impor
On Mon, 20 May 2024 23:21:31 GMT, Erik Joelsson wrote:
> Build change looks good.
Thank you
-
PR Comment: https://git.openjdk.org/jdk/pull/19317#issuecomment-2121488205
On Mon, 20 May 2024 21:20:29 GMT, Pavel Rappo wrote:
> Assuming the test fails without the fix, but passes with it, looks good.
Confirmed the test fails without the fix (crash, as reported) and passes with
the fix.
-
PR Comment:
Please review a small fix to address a crash when handling HTML5 entities in a
Markdown doc comment.
The path for the `entities.txt` (originally `entities.properties`) was not
correctly imported when importing the latest version of `commonmark-java`. And,
the makefiles need to be updated to
On Thu, 26 Oct 2023 23:29:00 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 `JavaTokeniz
On Thu, 16 May 2024 16:44:51 GMT, Hannes Wallnöfer wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update tests for dangling doc comments, per review feedback
>
> src/jdk.jav
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 revisi
On Thu, 16 May 2024 15:05:32 GMT, Jonathan Gibbons wrote:
> There were some community comments objecting the use of `///` for markdown
> documentation, and called for alternative syntaxes like `/*markdown */`.
This was
[addressed](https://openjdk.org/jeps/467#Using-///-for-Ma
On Thu, 16 May 2024 15:03:26 GMT, Pavel Rappo wrote:
> If you are concerned with it being a lint warning rather than a **doc**lint
> warning, then it's a technicality: doclint sees less than lint sees, and
> sadly not enough for that check. Thus, that check was put in `lint.
To clarify that a
On Thu, 16 May 2024 15:03:26 GMT, Pavel Rappo wrote:
> My rationale for a potential preview is that we changed
> `-Xlint:dangling-doc-comments` as `///` is now dangling doc comment. Is this
> considered a Java programming language change? There were some community
> comments objecting the use
On Thu, 16 May 2024 10:56:26 GMT, Hannes Wallnöfer wrote:
> Please review a change to improve the layout of definition lists used to
> display block tags:
>
> - Add indentation to the `` elements used for block tag details
> - Set the margin of lists within block tag details so they do not
On Wed, 15 May 2024 13:08:39 GMT, Hannes Wallnöfer wrote:
>> Please review an enhancement to detect [JavaScript
>> modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules)
>> when added to `javadoc` with the `--add-script` option, which require a
>> different `type`
On Tue, 9 Apr 2024 13:06:28 GMT, Hannes Wallnöfer wrote:
> Please review an update to the `jdk-default.css` stylesheet used for
> specifications and tool guides. The original purpose was to make use of the
> Dejavu web fonts provided by the API docs and to update the navigation bar to
> match
On Wed, 15 May 2024 10:08:19 GMT, Pavel Rappo wrote:
> I think we should add a test to verify that if `--disable-line-doc-comments`
> is specified, no `///` dangling comments are reported.
Added more tests for dangling doc comments.
Note we cannot currently use `-Xlint:dangling-doc-comments`
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:
update t
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
On Fri, 10 May 2024 13:42:43 GMT, Hannes Wallnöfer wrote:
>> Please review a change to move a long-running shellsupport test from
>> langtools tier1 to tier2, while modifying the tier1 test to only retrieve
>> doc comments for members of `java.lang.StringBuilder`, which is where [the
>>
On Tue, 9 Apr 2024 13:06:28 GMT, Hannes Wallnöfer wrote:
> Please review an update to the `jdk-default.css` stylesheet used for
> specifications and tool guides. The original purpose was to make use of the
> Dejavu web fonts provided by the API docs and to update the navigation bar to
> match
On Fri, 29 Mar 2024 09:39:18 GMT, Hannes Wallnöfer wrote:
> Please review an enhancement to detect [JavaScript
> modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules)
> when added to `javadoc` with the `--add-script` option, which require a
> different `type`
On Sun, 12 May 2024 08:36:44 GMT, Chen Liang wrote:
> Some tests are not migrated to the ClassFile API in previous migrations.
>
> - Some are simple oversights that didn't remove usages of
> com.sun.tools.classfile;
> - The CallerSensitive ones used an old utility, replaced by CF API-based
Please review a relatively simple update to the generated Help page, as part of
the ongoing campaign to improve the documentation around the overall use of
`@since` tags.
-
Commit messages:
- 8331873: Improve/expand info in `New API In` on Help page.
Changes:
On Fri, 10 May 2024 16:15:36 GMT, Hannes Wallnöfer wrote:
> Please review a patch to update to the javadoc man page to add the
> `--no-fonts` option and fix a typo.
Marked as reviewed by jjg (Reviewer).
-
PR Review:
On Fri, 26 Apr 2024 11:05:03 GMT, Nizar Benalla wrote:
> This PR aims to add `@since` tags in elements in both `jdk.compiler` and
> `java.compiler`.
> A lot of these changes have to do with handling of preview features.
>
> The existing rules for handling of `@since` for preview elements:
> -
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
Marked as reviewed by jjg (Reviewer).
-
PR Review:
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
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 revisio
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:
U
On Fri, 12 Apr 2024 17:39:11 GMT, Joe Darcy wrote:
> There should be some quick testing of the new default method on Elements
> using the VacuousElements implementation; see
> `test/langtools/tools/javac/processing/model/util/elements` for some examples.
@jddarcy I've reorganized the tests in
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
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:
addre
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 revis
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
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:
upda
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:
Remove
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:
Su
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
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that
On Fri, 26 Apr 2024 16:40:33 GMT, Pavel Rappo wrote:
> The feature is good, but I'm surprised to see it being tested in
> DocLintTest.java.
Yeah, good point. The message should be generated independently of any doclint
settings.
-
PR Comment:
On Fri, 26 Apr 2024 15:14:04 GMT, Hannes Wallnöfer wrote:
> Please review a change to print a terminal message if the documentation
> generated by `HtmlDoclet` contains any diagnostic marker elements for invalid
> input. The message is printed after the documentation has been generated and
>
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` t
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/*
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/*
On Mon, 22 Apr 2024 18:02:39 GMT, Jonathan Gibbons wrote:
> Please review a simple change to clean up inappropriate use of `/**` comments
> in test code -- most notably to enclose the `jtreg` test description.
>
> There is no change to the functionality of any test, and (ob
Please review a simple change to clean up inappropriate use of `/**` comments
in test code -- most notably to enclose the `jtreg` test description.
There is no change to the functionality of any test, and (obviously) all tests
continue to pass.
-
Commit messages:
- JDK-8330704:
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/*
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` t
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**`
On Wed, 20 Mar 2024 19:04:04 GMT, Jonathan Gibbons wrote:
> Please review changes to the support for `since`, `author`, and `version`
> tags, such that if there are no such tags on a nested class, the doclet will
> look for any such tags in enclosing classes.
This pull request has
> Please review changes to the support for `since`, `author`, and `version`
> tags, such that if there are no such tags on a nested class, the doclet will
> look for any such tags in enclosing classes.
Jonathan Gibbons has updated the pull request incrementally with one additional
com
On Mon, 8 Apr 2024 12:07:25 GMT, Pavel Rappo wrote:
> This looks like the right thing to do; thanks for doing this.
>
> A general comment regarding the test cases. It would be better if:
>
> * the nesting was at least two levels deep (`public class Foo { static class
> Bar { static class Baz
On Mon, 8 Apr 2024 11:53:25 GMT, Pavel Rappo wrote:
>> Please review changes to the support for `since`, `author`, and `version`
>> tags, such that if there are no such tags on a nested class, the doclet will
>> look for any such tags in enclosing classes.
>
>
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**`
On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust call for `saveDanglingDocComments` for enum members
>
> The build change
for the dangling
> * comments, subject to the {@code -Xlint} and
> * {@code @SuppressWarnings}.
>
>
> 3. Updates to the make files to disable the warnings in modules for which
> the
> warning is generated. This is often because of the confusing use of `/**` t
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:
addre
On Tue, 9 Apr 2024 08:53:10 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add support for JDK-8329296: Update Elements for '///' documentation
>> comments
>
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:
add s
On Fri, 5 Apr 2024 19:47:40 GMT, Pavel Rappo wrote:
> Does this make sense?
While I am dubious about 3-tuples, your explanation makes enough sense that I
accept your reply. Thanks for the explanation.
-
PR Comment: https://git.openjdk.org/jdk/pull/18519#issuecomment-2040539618
On Fri, 5 Apr 2024 15:53:40 GMT, Nizar Benalla wrote:
>> Nizar Benalla has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add blank line
>
> This PR is ready, I plan on integrating it at a later point.
> I won't make anymore changes, I
On Fri, 5 Apr 2024 15:03:36 GMT, Pavel Rappo wrote:
>> Creating a link to a constructor or a method or comparing constructors or
>> methods __does not__ factor in type parameters. When constructors or methods
>> are overloaded and differ only in type parameters -- a situation which is
>>
On Thu, 4 Apr 2024 21:52:20 GMT, Pavel Rappo wrote:
>> If you use `forMember` on an `ExecutableElement` whose enclosing element is
>> an annotation type interface, you know there cannot be any type parameters.
>
> Right, but some accommodation/special-casing for annotations will be there
>
On Thu, 4 Apr 2024 21:20:19 GMT, Pavel Rappo wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java
>> line 567:
>>
>>> 565: var methods =
>>> vmt.getVisibleMembers(VisibleMemberTable.Kind.METHODS);
>>> 566: // for whatever reason
On Thu, 4 Apr 2024 12:28:23 GMT, Pavel Rappo wrote:
>> Creating a link to a constructor or a method or comparing constructors or
>> methods __does not__ factor in type parameters. When constructors or methods
>> are overloaded and differ only in type parameters -- a situation which is
>>
On Thu, 29 Feb 2024 11:39:41 GMT, Hannes Wallnöfer wrote:
>> Setext headings only come in "level 1" and "level 2" flavors.
>> And, at the time the renderer sees the AST, the difference between ATX and
>> setext headings is erased. They're just "headings".
>>
>> I also think it is better to
On Thu, 28 Mar 2024 12:54:10 GMT, Pavel Rappo wrote:
> While I've been working with javadoc for the last five years, somehow I've
> never had to deal with composability functionality provided by `link` and
> `linkoffline`. These options have been there since at least 1998: the
> earliest bug
On Wed, 27 Mar 2024 22:41:33 GMT, Pavel Rappo wrote:
> Would this be the first lint -- not doclint -- warning related to comments,
> let alone doc comments?
No. `-Xlint:dep-ann` correlates `@Deprecated` annotations with `@deprecated`
tags in doc comments.
>
On Wed, 27 Mar 2024 21:56:48 GMT, Chen Liang wrote:
>> Creating a link to a constructor or a method or comparing constructors or
>> methods __does not__ factor in type parameters. When constructors or methods
>> are overloaded and differ only in type parameters -- a situation which is
>>
Please review the updates to support a proposed new
`-Xlint:dangling-doc-comments` option.
The work can be thought of as in 3 parts:
1. An update to the `javac` internal class `DeferredLintHandler` so that it is
possible to specify the appropriately configured `Lint` object when it is time
to
On Wed, 27 Mar 2024 17:19:35 GMT, Pavel Rappo wrote:
> Creating a link to a constructor or a method or comparing constructors or
> methods __does not__ factor in type parameters. When constructors or methods
> are overloaded and differ only in type parameters -- a situation which is
> absent
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:
add s
On Wed, 20 Mar 2024 15:54:12 GMT, Hannes Wallnöfer wrote:
>> This change adds the DejaVu web fonts that were previously maintained
>> externally to the open repository so they are available both in JDK API
>> documentation and any API documentation generated with the `javadoc` tool.
>> All
On Fri, 2 Feb 2024 14:02:28 GMT, Jan Lahoda wrote:
> This is an attempt to add Markdown support in documentation comments to
> JShell.
>
> It works by converting the Markdown text to HTML during the process of
> resolving `{@inheritDoc}` tags.
Changes requested by jjg (Reviewer).
Compared
Martin,
Thank you for the report. I have filed JDK-8328848 to fix the documentation.
There is currently no way to also group packages in a multi-modules project.
-- Jon
https://bugs.openjdk.org/browse/JDK-8328848
On 3/23/24 3:59 AM, Martin Desruisseaux wrote:
Hello
The documentation for
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
1 - 100 of 847 matches
Mail list logo
