[PATCH] Documented annotations for primitive types
Aaloan Miftah
al at poly-gamma.org
Mon Mar 27 17:04:07 UTC 2023
Hi,
I've signed the OCA already, it was submitted on 03-24-2023, it's awaiting
approval.
Cheers,
Al
On Mon, Mar 27, 2023 at 4:57 PM Pavel Rappo <pavel.rappo at oracle.com> wrote:
> To consider your patch we need you to sign OCA; have a look here:
> https://openjdk.org/guide/#contributing-to-an-openjdk-project
>
> > On 24 Mar 2023, at 18:59, Aaloan Miftah <al at poly-gamma.org> wrote:
> >
> > Hello,
> >
> > Currently when a primitive type is annotated with a `@Documented`
> annotation, the fqn of the annotation(s)
> > is always included in the resulting javadoc, and links aren't properly
> inserted. For example,
> >
> > ``
> > public abstract void
> foo(@org.checkerframework.checker.signedness.qual.Unsigned int bar);
> > ``
> >
> > The `bar` parameter, in the resulting javadoc, is documented with the fqn
> > `org.checkerframework.checker.signedness.qual.Unsigned` annotation,
> instead of just `Unsigned` with a link
> > to the annotation.
> >
> > This patch fixes
> jdk.javadoc.internal.doclets.formats.html.HtmlLinkFactory::getLink() by
> introducing special
> > handling for primitive types that takes their use annotation into
> account, and prints the simple type name.
> > Note that the type name is currently being derived using
> PrimitiveType::getKind() instead of
> > utils::getTypeName(), this is because the toString() for the default
> case in getTypeName() will always include
> > the annotations, which we want to avoid. I didn't modify
> utils::getTypeName() since I wasn't sure if a primitive
> > specific visit method would mess with any expected behavior.
> >
> > Cheers,
> > Al
> > <patch.diff>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/javadoc-dev/attachments/20230327/60494340/attachment-0001.htm>
More information about the javadoc-dev
mailing list