Implemented changes to LSP versions 3.6 and 3.7

[spoenemann]

Fixes #167, #178, and #118.

Unfortunately, this change massively breaks API. I don't know how else we could realize the change in LSP from

• method: ‘textDocument/completion’
• params: TextDocumentPositionParams

to

• method: ‘textDocument/completion’
• params: CompletionParams

In TypeScript this change is API compatible, in Java it's not :-(

[akosyakov]

In the spec it is not marked as optional. Is it bug there?

[spoenemann]

The LSP documentation says "The name of the workspace folder. Defaults to the uri's basename." I think it's a bug in the specification: either the property should be optional, or the second part of the property documentation should be removed.

[akosyakov]

It is named as kind in the spec

[spoenemann]

That's why I corrected it here :-)

[akosyakov]

@spoenemann please see my comments, i was not able to spot anything else, although it is hard to check whether everything is covered

Do you think it will make sense to have a change log with breaking changes or developers will notice it anyway it? cc @svenefftinge

[jvalkeal]

Just out of curiosity if you could start over, what comes for a textDocument/completion and other objects, would you simply go with TextDocumentCompletion and then postfixing request/response classes with Request or Response? Then all changes would be internal to those classes.

[spoenemann]

@akosyakov I'll prepare a change log for the release.

@jvalkeal I don't understand what you mean. Could you explain further?

[jvalkeal]

@spoenemann I just asked that if you'd have originally used custom TextDocumentCompletionRequest extending TextDocumentPositionParams then now changing it to extends CompletionParams would not have broken any api's.

[jonahgraham]

While you are updating LS versions, it may be worth updating the Readme, it currently says:

Supported LSP Versions

• LSP4J 0.2.x → LSP 3.x
• LSP4J 0.1.x → LSP 2.x

[spoenemann]

Up to now we have only implemented the data types from the specification, and have not added any additional types.

Even then we wouldn't get around breaking the API. The root of the problem is that the LSP is designed for TypeScript, which has a completely different type system than Java. Some kinds of API changes that are 100% compatible in TypeScript break the corresponding Java representations.

[spoenemann]

https://github.com/eclipse/lsp4j/blob/master/CHANGELOG.md

I'll document where the API has been broken now.