RFR: 8164408: Add module support for @see, @link and @linkplain javadoc tags.
Jonathan Gibbons
jonathan.gibbons at oracle.com
Fri May 29 17:03:17 UTC 2020
On 5/28/20 7:49 AM, Hannes Wallnoefer wrote:
> Please review:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8164408
> Webrev: http://cr.openjdk.java.net/~hannesw/8164408/webrev.00/
>
> In the process of adding module support to DocCommentParser I switched the code to using ReferenceParser (both classes contained almost identical code to parse doc comment references, with the only difference being the type of the thrown exception).
>
> An reference like `foo.bar` that would normally resolve to a type or package will result in a link to a module if no type or package exists with that name. If a type or package with the same name exists, a link to the module can be obtained by appending a slash, e.g. `foo.bar/`.
>
> If that behaviour is acceptable I’ll update the CSR at https://bugs.openjdk.java.net/browse/JDK-8191355 accordingly.
>
> Thanks,
> Hannes
I think the proposed behavior, that 'foo.bar' resolves in favor of a
type or package, is OK, and favors backwards compatibility, which is
good, although it would not be my first choice if we were starting over
from scratch in an alternate reality.
In DocCommentParser, why do you go out of your way to store the
`trimmedSig` in the tree, and not the sig as found? Does this affect the
source-fidelity when printing out the tree?
-- Jon
More information about the javadoc-dev
mailing list