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