Please don't use Deprecated annotations for language server protocol deprecations

[DavidGregory084]

I have noticed that it is common in LSP4J to use Deprecated annotations to communicate deprecations in the language server protocol itself.

Would it be possible to avoid this?

Most of the LSP deprecations have been in place for years at this point, and as the author of a language server I still have to handle e.g. rootUri in InitializeParams (deprecated since 2020) because a client may still send it.

It needlessly litters good code with deprecation warnings and it doesn't appear that the LSP protocol is actually going to follow through with removing any of these deprecated constructs, at least until there is a version 4.x of the protocol.

If you'd prefer to keep using deprecations, could they perhaps be used only for "response" type data, rather than properties of requests that a language server must handle in order to follow the protocol?

[pisv]

From my point of view, that would probably make sense. I think that this issue is somewhat alike to the project's earlier decision to avoid using @since tag for tracking evolution of the language server protocol itself.

Having said that, I would be against any asymmetry in a potential solution, like

If you'd prefer to keep using deprecations, could they perhaps be used only for "response" type data, rather than properties of requests that a language server must handle in order to follow the protocol?

Please note that LSP4J is used for implementing both language servers and language clients.

@DavidGregory084 Do you have a specific idea of how your proposal could be implemented?