Wrong list elements generated in Javadoc, in some cases where a line contains an @

[fbricon]

I noticed an issue with the javadoc of java.lang.annotation.ElementType. It can be narrowed down to an @thing behind followed by another @thingy on the same line, this generates wrong list elements.

    /**
     * Some javadoc and then ...
     * @jls 9.6.4.1 @Target
     */
    public void foo(){}

The @Target in ElementType should be rendered as a link to the jls spec, in this case : https://docs.oracle.com/javase/specs/jls/se25/html/jls-9.html#jls-9.6.4.1

Not sure what should happen if @jls 9.6.4.1 @Target is present on a non JDK class.

[fbricon]

In Eclipse, the generated javadoc doesn't contain a link to the remote spec, but at least it doesn't break:

[subyssurendran666]

The @Target in ElementType should be rendered as a link to the jls spec, in this case : https://docs.oracle.com/javase/specs/jls/se25/html/jls-9.html#jls-9.6.4.1

I have a few questions regarding this requirement and would appreciate some clarification.

• Given a Javadoc tag like @jls 9.6.4.1 @Target, how is the language server expected to determine the corresponding Java version?
• Is there any mechanism in OpenJDK or elsewhere through which the language server can obtain the correct URL for linking to the JLS documentation?

Currently, JDT treats @jls 9.6.4.1 @Target as a single TagElement with the tag name @jls, and all remaining content is handled as child TextElements, similar to how custom Javadoc tags are processed. I have also verified the behavior in a few other popular IDEs, and it appears that linking JLS references is not implemented there either. Based on this, could you please confirm whether adding such link support is expected?

NB: Please note that the incorrect Javadoc rendering observed in hover displays has been addressed in #3649

[fbricon]

For now generating the link is not necessary. We'll probably need to infer the version from the project's JRE, eventually.