[External] : Re: Snippet specification feedback

[Pavel Rappo]

> On 31 Mar 2023, at 13:50, Tagir Valeev <amaembo at gmail.com> 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