Update to newer LSP4J

[mickaelistria]

Working on integrating JDT-LS in Eclipse IDE with an in-process deployment is made harder because JDT-LS uses an outdated version of LSP4J and this cause clashes in the workspace (not only JDT-LS's fault, also PDE's one probably, anyway it's almost blocking).
I've investigated migrating JDT-LS to newer version and found that the main cause of trouble would the the custom type hierarchy commands. Now that those commands are standardized as LSP operations; are they still useful? Do some clients require them? If not, a happy end would be to just remove them.

[mickaelistria]

I noticed https://github.com/redhat-developer/vscode-java/blob/master/src/commands.ts still references them; but isn't it as well something that VSCode now provides by default and thus could be removed?

[rgrunber]

I think we want to use the type hierarchy request methods that are part of the protocol now. When it was implemented, I think it wasn't yet known if they would become part of the spec.

[CsCherrYY]

there is a PR about moving type hierarchy to LSP using new version of LSP4J: redhat-developer/vscode-java#2376, but the change is now blocked by the language client version update, see: redhat-developer/vscode-java#2377.

[jdneo]

+1 for this.

Another benefit is that newer LSP contains some new features that we can leverage. For example, it allows LS to provide descriptions for completion items, which will be displayed at the right of the completion list.

[rgrunber]

You're right. I forgot the migration was blocked for the VS Code client due to that. The best timeline for this is probably start of 2023 then. Only way to do it sooner is if we can allow both (delegate calls for type hierarchy, and LSP 3.17) to coexist.

Are there any clients other than VS Code that are known to have implemented type hierarchy on the current (delegate handler) API ?

Update: I also realized, that updating to LSP4J > 0.12.0 (LSP 3.17) could be risky since there's no guarantee it would work with a client (eg. vscode-java) that continues to stay on an older spec. May as well make the changes early on in a release cycle.

[mickaelistria]

Current workaround is mickaelistria@e4f50f3

[mickaelistria]

Just a note (hopefully to increase priority here): because of this -and other issues in Eclipse PDE- I'm finding it tricky to continue working on the JDT-LS and JDT-LS client simultaneously because I need to align the LSP4J versions for the workspace to show no error.
I always need to re-cherry-pick my workaround patch every time I make a change and this is easily forgotten or pushed to wrong branch and so on. Too messy for me to feel productive.
So I'm going to pause my experiments with JDT-LS client for some weeks, until JDT-LS adopts newer LSP4J APIs that are not conflcting with latest release of LSP4J.

[mickaelistria]

See #2417