On Thu, 11 Jul 2024 21:10:43 GMT, Chen Liang wrote:
> Please review this backport of #20129 to JDK 23, fixing the documentation
> Javadoc generates for the default object method implementations in user
> records about the comparison behavior for `float` and `double` values.
Marked as reviewed
On Wed, 10 Jul 2024 23:24:43 GMT, Chen Liang wrote:
> Fixes to Javadoc's default documentation on record classes, that all
> primitives are compared as if with their wrapper classes' `compare` method by
> default.
Looks good.
-
Marked as reviewed by prappo (Reviewer).
PR
On Thu, 11 Jul 2024 14:43:08 GMT, Chen Liang wrote:
>> Pavel Rappo has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request co
and "Method Details" sections. Otherwise, it will only appear in "Method
> Details". Appearances are numbered starting from 1 and increment by 1 from
> top ("Method Summary") to bottom ("Method Details").
Pavel Rappo has refreshed the contents of this
Please review this jdk24 bug, which we intend to backport to jdk23 before RDP2,
which is a week away. This is a simple fix, but it disturbs multiple tests.
Here's a tip for reviewing. Sometimes a snippet id in a test ends up with
`()1`, other times with `()2`. This is because the same snippet
On Mon, 1 Jul 2024 16:20:56 GMT, Hannes Wallnöfer wrote:
> I think Chen's point was that it should not be `null`, to which I agree,
> although it is probably a corner case.
If so, my bad for misreading it. For such corner cases authors should specify
`lang` attribute.
-
PR
On Mon, 1 Jul 2024 14:03:52 GMT, Chen Liang wrote:
>> Please review this bugfix to the way the language of a snippet is determined
>> and processed.
>>
>> The language of a snippet affects the form of snippet markup and enables
>> external syntax highlighting, such as that provided by
Please review this bugfix to the way the language of a snippet is determined
and processed.
The language of a snippet affects the form of snippet markup and enables
external syntax highlighting, such as that provided by prism.js. The language
of a snippet is
> The commit being backported was authored by SendaoYan on 18 Jun 2024 and was
> reviewed by Pavel Rappo.
>
> Only change test testcase, no risk.
>
> Thanks!
Marked as reviewed by prappo (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19765#pullrequestreview-2125224767
On Tue, 18 Jun 2024 07:43:23 GMT, SendaoYan wrote:
>> Hi all,
>> Test
>> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run
>> fails with root user privileged. I think it's necessary to skip this
>> testcase when user is root.
>> Why run the jtreg test by root
On Tue, 18 Jun 2024 07:43:23 GMT, SendaoYan wrote:
>> Hi all,
>> Test
>> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run
>> fails with root user privileged. I think it's necessary to skip this
>> testcase when user is root.
>> Why run the jtreg test by root
On Tue, 18 Jun 2024 01:26:33 GMT, SendaoYan wrote:
> Does the `throw new Error(f + ": " + message);` should be replaced to `throw
> new SkippedException(f + ": " + message);`, to avoid report failure if a
> directory cannot be made read-only.
Yes, it does! That's the whole point. Ironically,
On Sat, 15 Jun 2024 09:54:38 GMT, SendaoYan wrote:
>> Hi all,
>> Test
>> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run
>> fails with root user privileged. I think it's necessary to skip this
>> testcase when user is root.
>> Why run the jtreg test by root
On Sat, 15 Jun 2024 09:54:38 GMT, SendaoYan wrote:
>> Hi all,
>> Test
>> `test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java` run
>> fails with root user privileged. I think it's necessary to skip this
>> testcase when user is root.
>> Why run the jtreg test by root
On Fri, 14 Jun 2024 12:15:45 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 Wed, 12 Jun 2024 09:03:38 GMT, Hannes Wallnöfer wrote:
>> Wouldn't the easiest solution be to add a boolean `global`/`isGlobal` field
>> and getter to `Attr`?
>>
>> That would give use some more opportunities to simplify the code: We could
>> get rid of the `GLOBAL_ATTRS` map here *and*
On Tue, 11 Jun 2024 23:49:15 GMT, Jonathan Gibbons wrote:
>> 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 simpler?
>>
>> data-[a-z][-a-z0-9]*
>
> I admit to being "lazy" when
On Tue, 11 Jun 2024 14:42:48 GMT, Nizar Benalla wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line
>> 695:
>>
>>> 693: // custom "data-*" attributes are also accepted
>>> 694: var attrName=name.toString();
>>> 695: if
On Tue, 11 Jun 2024 13:35:31 GMT, Chen Liang wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line
>> 556:
>>
>>> 554: }
>>> 555:
>>> 556: private final EnumSet GLOBAL_ATTRS = EnumSet.of(
>>
>> I get it, you cannot make it static because it's used in
On Tue, 11 Jun 2024 13:24:48 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/javadocGlobalAttrs/pkg1/package-summary.html)
>> to the generated docs.
>> Thanks in
On Tue, 11 Jun 2024 11:37:27 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/javadocGlobalAttrs/pkg1/package-summary.html)
> to the generated docs.
> Thanks in
On Tue, 11 Jun 2024 11:51:05 GMT, Chen Liang 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/javadocGlobalAttrs/pkg1/package-summary.html)
>> to the generated docs.
>> Thanks in
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK. Primarily, the changes between JDK 22
>> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The
On Fri, 31 May 2024 10:01:17 GMT, Hannes Wallnöfer wrote:
>> Please review a simple patch to exclude preview visitor classes meant to
>> support future preview features from the Preview API page.
>>
>> The test adds an sample element annotated with the new
>>
On Fri, 31 May 2024 10:19:52 GMT, Pavel Rappo wrote:
> Consider adding a case of a primitive array, which while relates to
> primitives is also an object.
Oh, sorry, I see you did it in a separate test. I don't know why I didn't
notice it. Sigh.
-
PR Review Comment:
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 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:
>> 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 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 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 importing the latest
On Thu, 16 May 2024 14:53:17 GMT, Chen Liang 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 Wed, 15 May 2024 21:04:36 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
On Thu, 16 May 2024 13:05:39 GMT, Chen Liang wrote:
> A meta question about the JEP: Why don't Javadoc features (like snippets and
> markdown comments) don't go through preview, while Compiler features mostly
> do? Is there any bar for previews?
Jon could probably reply more substantially,
On Wed, 15 May 2024 21:04:36 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
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 Tue, 7 May 2024 17:31:29 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
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.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.o
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.
Withdrawing this, as a different approach is required.
-
PR Comment: https://git.openj
On Thu, 9 May 2024 08:18:41 GMT, David Holmes wrote:
>> Please review this mechanical change to man pages. This PR should be
>> integrated after https://github.com/openjdk/jdk/pull/18787.
>
> src/java.base/share/man/java.1 line 3856:
>
>> 3854: .SH REMOVED JAVA OPTIONS
>> 3855: .PP
>> 3856:
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.
Thanks for reviewing it Joe, I'm now delegating integration of this PR to
@JesperIRL, you, or anyo
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.
This PR is standalone as opposed to dependent because the
https://github.com/openjdk/jdk/pull
Please review this mechanical change to man pages. This PR should be integrated
after https://github.com/openjdk/jdk/pull/18787.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/19119/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19119=00
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
>
On Thu, 18 Apr 2024 18:43:13 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.
>
> Jonathan Gibbons has
On Fri, 12 Apr 2024 11:11:47 GMT, Hannes Wallnöfer wrote:
> Please review a change to update jQuery from version 3.6.1 to 3.7.1 in
> JavaDoc. The jQuery compressed and uncompressed files were obtained from
> https://jquery.com/download/. Changes were tested against javadoc tests as
> well as
On Fri, 12 Apr 2024 11:11:47 GMT, Hannes Wallnöfer wrote:
> Please review a change to update jQuery from version 3.6.1 to 3.7.1 in
> JavaDoc. The jQuery compressed and uncompressed files were obtained from
> https://jquery.com/download/. Changes were tested against javadoc tests as
> well as
On Tue, 16 Apr 2024 18:29:02 GMT, Jonathan Gibbons wrote:
>> src/jdk.javadoc/share/man/javadoc.1 line 1:
>>
>>> 1: .\" Copyright (c) 1994, 2024, Oracle and/or its affiliates. All rights
>>> reserved.
>>
>> This diff to the man page seems to contain some unrelated changes. If this
>> is
On Mon, 8 Apr 2024 21:12:42 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
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 looks like the right thing
ignatures in a class". Which means that for
> any two constructors or methods the erasure of their signatures must differ,
> or else it won't compile.
>
> The change is pretty straightforward, except for some test fallout that
> required attention.
>
> [JLS 8.4.2]:
&
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
On Fri, 5 Apr 2024 19:58:27 GMT, Jonathan Gibbons 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.
Yet another alternative notation, should we come up with one in the future.
On Fri, 5 Apr 2024 17:52:25 GMT, Jonathan Gibbons wrote:
> Approved, with two optional suggestions. Both could be considered style
> suggestions.
>
> ## 1
> (Minor) While I like the new multi-valued return for
> `forMember(ExecutableElement executable)` I'm slightly surprised at the use
> of
On Thu, 4 Apr 2024 21:21:58 GMT, Pavel Rappo wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriter.java
>> line 200:
>>
>>> 198: content.add(heading);
>>> 199: return HtmlTree.SECTIO
ignatures in a class". Which means that for
> any two constructors or methods the erasure of their signatures must differ,
> or else it won't compile.
>
> The change is pretty straightforward, except for some test fallout that
> required attention.
>
> [JLS 8.4.2]:
On Fri, 5 Apr 2024 12:01:52 GMT, Nizar Benalla wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java line 99:
>>
>>> 97: * @implSpec This implementation returns the inverse
>>> 98: * result to {@code isInlineTag}.
>>> 99: * @since 15
>>
>> Might as well insert a
On Fri, 5 Apr 2024 12:02:41 GMT, Nizar Benalla wrote:
>> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they
>> were added in later versions
>>
>> - SNIPPET_PATH was added in JDK 18
>>
On Fri, 5 Apr 2024 00:02:00 GMT, Nizar Benalla wrote:
> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they
> were added in later versions
>
> - SNIPPET_PATH was added in JDK 18
>
On Thu, 4 Apr 2024 21:31:03 GMT, Jonathan Gibbons wrote:
>> True, type parameters are not an issue for annotation interface methods,
>> which [are not allowed to have any parameters][], type or otherwise.
>> However, the code that prints annotations for method signatures does not
>> know that
On Thu, 4 Apr 2024 18:52:42 GMT, Jonathan Gibbons wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to feedback
>
> src/jdk.javadoc/share/classes/jdk/javadoc
On Thu, 4 Apr 2024 13:53:57 GMT, Chen Liang wrote:
>> The answer to your latter question is no. The id that will be assigned to
>> that public method do depend on whether the private overload positioned
>> before it is documented. You cannot do much about it with the current design
>> of
On Wed, 3 Apr 2024 23:29:44 GMT, Chen Liang wrote:
>> Pavel Rappo 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 11 addi
ignatures in a class". Which means that for
> any two constructors or methods the erasure of their signatures must differ,
> or else it won't compile.
>
> The change is pretty straightforward, except for some test fallout that
> required attention.
>
> [JLS 8.4.2]
On Wed, 3 Apr 2024 23:19:29 GMT, Chen Liang wrote:
>> Pavel Rappo 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 11 addi
On Wed, 3 Apr 2024 23:15:43 GMT, Chen Liang wrote:
>> Pavel Rappo 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 11 addi
On Wed, 3 Apr 2024 18:14:39 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 --
ignatures in a class". Which means that for
> any two constructors or methods the erasure of their signatures must differ,
> or else it won't compile.
>
> The change is pretty straightforward, except for some test fallout that
> required attention.
>
> [JLS 8.4.2]:
&
ignatures in a class". Which means that for
> any two constructors or methods the erasure of their signatures must differ,
> or else it won't compile.
>
> The change is pretty straightforward, except for some test fallout that
> required attention.
>
> [JLS 8.4.2]:
&
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
>>
On Thu, 28 Mar 2024 17:03:46 GMT, Jonathan Gibbons wrote:
> Some of us are in the privileged position of being at the bottom of the
> software stack, and so we rarely if ever need to create documentation to
> other libraries.
That paragraph of mine (that you are likely replying to) was about
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
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 it
> is possible
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 it
> is possible
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 it
> is possible
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
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 in JDK API, but present elsewhere -- that causes significant
On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote:
> Please review this simple bugfix to properly construct links to preview JEPs.
>
> The most straightforward fix I could think of was to pass `String` rather
> than `int` (`Integer`) to a method, which even
On Mon, 18 Mar 2024 14:53:44 GMT, Pavel Rappo wrote:
> Please review this simple bugfix to properly construct links to preview JEPs.
>
> The most straightforward fix I could think of was to pass `String` rather
> than `int` (`Integer`) to a method, which even
Please review this simple bugfix to properly construct links to preview JEPs.
The most straightforward fix I could think of was to pass `String` rather than
`int` (`Integer`) to a method, which eventually calls
`java.text.MessageFormat.format(String, Object...)`.
For the test, I decided to be
On Tue, 12 Mar 2024 22:06:35 GMT, Chen Liang wrote:
>> Please review this patch that fixes placement of type annotations on array
>> types in Javadoc output. This oversight seems to have existed since JDK 8
>> but was never noticed or reported.
>
> Chen Liang has updated the pull request with
On Wed, 13 Mar 2024 14:30:01 GMT, Hannes Wallnöfer wrote:
> > if you check "all" and then uncheck something else, then "all" will remain
> > selected. That is a confusing state.
>
> I agree, but I think the behavior of the checkbox is as it should be, and
> it's the label that is slightly
On Mon, 11 Mar 2024 13:37:54 GMT, Hannes Wallnöfer wrote:
> Please review a change to improve the user experience and implementation for
> the checkbox-based interface to selectively display content on API summary
> pages:
>
> - Add a checkbox to toggle (select/unselect) all checkboxes in
On Tue, 12 Mar 2024 03:33:38 GMT, Chen Liang wrote:
> Please review this patch that fixes placement of type annotations on array
> types in Javadoc output. This oversight seems to have existed since JDK 8 but
> was never noticed or reported.
I looked into it; that wasn't easy .
7 years ago
On Tue, 12 Mar 2024 03:33:38 GMT, Chen Liang wrote:
> Please review this patch that fixes placement of type annotations on array
> types in Javadoc output. This oversight seems to have existed since JDK 8 but
> was never noticed or reported.
I've read your discussion with @cushon in the
On Mon, 11 Mar 2024 13:57:23 GMT, Chen Liang wrote:
>> Please review this patch that fixes the issue where type annotations on
>> primitive types are not linked.
>>
>> Tested with file
>> https://cr.openjdk.org/~liach/8325433-arrayanno/ArrayAnno.java
>>
>> import java.lang.annotation.*;
>>
On Mon, 11 Mar 2024 13:37:54 GMT, Hannes Wallnöfer wrote:
> Please review a change to improve the user experience and implementation for
> the checkbox-based interface to selectively display content on API summary
> pages:
>
> - Add a checkbox to toggle (select/unselect) all checkboxes in
On Mon, 11 Mar 2024 13:57:23 GMT, Chen Liang wrote:
>> Please review this patch that fixes the issue where type annotations on
>> primitive types are not linked.
>>
>> Tested with file
>> https://cr.openjdk.org/~liach/8325433-arrayanno/ArrayAnno.java
>>
>> import java.lang.annotation.*;
>>
On Mon, 4 Mar 2024 14:40:06 GMT, Pavel Rappo wrote:
> I have a test case to report. The following results in no `@param`
> information being rendered, which I think is a bug:
>
> ```
> /// Hello, _Markdown_ world!
> ///
> ///
> /// @param hello
>
On Fri, 1 Mar 2024 21:49:29 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
equest contains 11 additional commits since
> the last revision:
>
> - Merge branch 'master' of https://github.com/openjdk/jdk into
> feature/jd-use-super-typearg
> - Improve documentation
> - Apply suggestions from code review
>
>Co-authored-by: Pavel Rappo <
On Thu, 22 Feb 2024 04:53:20 GMT, Chen Liang wrote:
>> Currently in the javadoc tool, the generated class use page does not track
>> the occurrences of a class in the type arguments of the extends or
>> implements list, where they can appear. (See more details on the JBS issue)
>> For
On Tue, 20 Feb 2024 21:04:34 GMT, Pavel Rappo wrote:
> It does not feel generic enough. (No pun intended.) What about using a class
> or interface as a bound as in this example?
>
> ```
> interface MyList> extends java.util.List
> ```
I checked, and your patch seems
On Tue, 30 Jan 2024 04:16:54 GMT, Chen Liang wrote:
>> Currently in the javadoc tool, the generated class use page does not track
>> the occurrences of a class in the type arguments of the extends or
>> implements list, where they can appear. (See more details on the JBS issue)
>> For
On Fri, 16 Feb 2024 07:42:47 GMT, Hannes Wallnöfer wrote:
>> Jonathan Gibbons has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Support for Table Of Contents in Markdown headings
>> - fix typo
>
>
On Thu, 15 Feb 2024 19:39:07 GMT, Pavel Rappo wrote:
>> whitespace is handled separately, on line 280 (`readIndent`) and285 (`:
>> (indent <= 3) ? peekLineKind()`)
>
> Correct, but I believe the ordered list marker should be like this:
>
> ORDERED_LIST_ITEM
On Thu, 15 Feb 2024 19:20:23 GMT, Jonathan Gibbons wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
>> line 1401:
>>
>>> 1399: */
>>> 1400: enum LineKind {
>>> 1401: BLANK(Pattern.compile("[ \t]*")),
>>
>> `BLANK` is a pseudo kind,
On Thu, 15 Feb 2024 00:30:25 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
On Mon, 12 Feb 2024 23:52:35 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
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
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
1 - 100 of 456 matches
Mail list logo
