> On 31 Mar 2023, at 13:50, Tagir Valeev <[email protected]> wrote:
>
> <snip>
>
>> It's good that you are looking into this, because it pushes us to improve
>> the spec. That said, even javadoc is qui We might want an API, such as the
>> one described in this comment
>> https://bugs.openjdk.org/browse/JDK-8304408?focusedCommentId=14570485&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14570485
>>
>> It would be good if IDEs, REPLs or editors didn't have to maintain their own
>> implementations of the spec and instead focused on a much easier task:
>> having an up-to-date version of a library that provides jdk.javadoc
>> services, such as (i) "render documentation for this symbol" or (ii)
>> "lint/parse this doc comment". Think Language Server Protocol, but simpler
>> and specifically for javadoc. I know that such a library will not eliminate
>> the need for good spec (if nothing else, authors need spec to build their
>> mental model of what's going on), but at least it will provide a great deal
>> of uniformity and reduce maintenance effort.
>>
> That would be great, though probably not completely useful for us. E.g., we
> have our own incremental parser and own parse tree model which includes both
> javadoc and the surrounding java code in a single tree. It might be
> non-trivial to incorporate a foreign parser for some subtrees there. Also,
> there will be a transition period, as IDE boot JDK may be older than project
> JDK. E.g., now IntelliJ IDEA works on JDK 17 but it supports all the syntax
> features up to JDK 20. Nevertheless, parts of the API might be perfectly
> reusable. Feel free to ping me to review such an API if you come up with it.
While I understand JDK mismatch you describe, jdk.javadoc changes slowly. The
absolute majority of bugs I've filed against other implementations were related
to functionality preceding JEP 413 (Snippets).
-Pavel
