Migration lsp4j 0.24.0 → lsp4j 1.0.0

[alberti42]

@spitzerd

I reverted to 2.2.1 baseline which assures we can run lsp4j 0.24.0

There was a routine dependabot bump that upgraded

lsp4j 0.24.0 → 1.0.0 (PR #50, shipped in 2.2.2).

lsp4j 1.0.0 requires a corresponding API migration on ltex-ls-plus
that has not been done; until both halves of the shipping pair are
on the same lsp4j, releasing this develop as 2.2.2+ would break the
bundled ltex-cli-plus when end users run it against the still-0.24.0
ltex-ls-plus (lsp4j JARs of two different versions end up on the
shared appassembler classpath and the LSP message handshake hangs).

I allowed myself to push a commit rolling develop's tree back to
80f50b8 (2.2.1). The dependabot bumps and version markers
are preserved in 2c4827b and should later be split into:

• feat/lsp4j-1.0.0: a coordinated lsp4j upgrade branch validated
  end-to-end against a parallel ltex-ls-plus migration
• individual cherry-picks of safe non-lsp4j dep bumps (Kotlin,
  JUnit, Maven plugin versions, gson, jansi, GitHub Actions) onto
  develop, each evaluated on its own.

[spitzerd]

You are right. The update to 1.0.0 of lsp4j was not intended as lsp4j 1.0.0 uses LSP 3.18, which is not finalized yet and I am not sure about the compatibility with the various editors. Hence, I hesitate to upgrade it now. For ltex-ls-plus, I skipped the upgrade, see , see ltex-plus/ltex-ls-plus#139 (comment).

What do you propose? Creating a release 2.2.3. release with lsp4j 0.24.0? Or upgrading ltex-ls-plus to lsp4j 1.0.0?

[alberti42]

I'd go with releasing lsp-cli-plus 2.2.3 on lsp4j 0.24.0 — upgrading to 1.0.0 is too risky for the upcoming release and I would like to test it separately.

I ran into several hard-to-debug hangs caused by the version mismatch between lsp-cli-plus and ltex-ls-plus — the two lsp4j JARs on the shared classpath cause the LSP handshake to stall indefinitely. I was in the middle of fixing a crash bug in the language server at the time, and the mixed lsp4j versions made it very difficult to isolate what was going wrong. Rolling back to 0.24.0 was the only safe way for me to get a stable baseline for debugging.

For the plan going forward: let's get 18.7.0 out on lsp4j 0.24.0 first. Once that's sshipped,we can look into the lsp4j 1.0.0 upgrade as a coordinated effort across both repos — possibly for a 18.7.1 if we're confident it's safe, or defer to 18.8.0. I'm not even sure yet what concrete benefits lsp4j 1.0.0 / LSP 3.18 would bring our users, so it'll take some time to understand the full implications before committing to it.

[spitzerd]

In my opinion, going to LSP 3.18 resp. lsp4j 1.0.0 causes new major version of ltex-ls-plus resp. lsp-cli-plus, because it's a change to the API (see https://semver.org/). We have to go to 19.0.0 for ltex-ls-plus and 3.0.0 for lsp-cli-plus

[alberti42]

lsp-cli-plus, because it's a change to the API

Do you expect to break how the lsp-client communicates with the lsp-server?

If we provide an updated version for the VS Code plugin and the Emacs package and submit a PR for the Sublime Text plugin, hopefully the users would not even notice the API break. But in reality, this discontinuity is never so smooth because the user has to figure out that the client has to be updated or vice versa, that the language server has to be updated. So there is to expect some friction in the transition.

The next release will have many new features. Is it not better that we ship it at 18.7.0? This will make it easier for us to address any possible issue after the new release.

We could ship the current lsp4j 0.24.0 version, and then if everything runs stably, in a couple of months target the upgrade to the new lsp4j. Does this sound reasonable to you?

PS: Do you already know how LSP4J 1.0 improves over the current one?

[spitzerd]

Do you expect to break how the lsp-client communicates with the lsp-server?

After you reported, that the mismatch of the versions of lsp4j between ltex-ls-plus and lsp-cli-plus caused handshake hangs, there seems to be a change in the API.

I suggest to postpone the upgrade of lsp4j for the next release keeping in mind, that LSP 3.18 is not fully released yet. I am not aware of any improvements of LSP 3.18

[alberti42]

After you reported, that the mismatch of the versions of lsp4j between ltex-ls-plus and lsp-cli-plus caused handshake hangs, there seems to be a change in the API.

If your data point comes from me, then it is not reliable. I was trying to fix a bug that was causing me trouble. And on top of that, there was the mismatch of versions between the CLI and the ltex-ls, which was causing the whole thing to hang.

So, even without an API break, just because the two JAR libraries were incompatible (same name but providing different internal functions; I don't remember exactly the details from a few weeks ago), there was an unavoidable hanging. Whether the system would hang if we used the same version, I don't know. My guess (and hope) is that everything will work just fine. But it was not tried. If we want to try, we can start an experimental branch where we upgrade both, because if you upgrade just one, then it breaks.

I suggest to postpone the upgrade of lsp4j for the next release keeping in mind, that LSP 3.18 is not fully released yet.

Very good. Then this is decided.