Packaged ltex-cli-plus breaks with LSP4J 1.0.0

[max0l]

Describe the bug

The ltex-cli-plus bundled by a current develop build is binary-incompatible with the LSP4J 1.0.0 jars in the same target/appassembler/lib directory. It receives diagnostics from the language server, then crashes while printing the first one:

java.lang.NoSuchMethodError: 'java.lang.String org.eclipse.lsp4j.Diagnostic.getMessage()'
    at org.bsplines.lspcli.client.Checker$Companion.printDiagnostic(Checker.kt:197)

This started after the LSP4J 1.0.0 update in #197. tools/addLtexCli.py currently bundles lsp-cli-plus 2.3.0, which was compiled against the older Diagnostic#getMessage(): String API. LSP4J 1.0.0 changed that method to return Either<String, MarkupContent>.

Without --verbose, this can look like an indefinite hang because the CLI main thread throws while its spawned language-server process remains alive.

Steps to reproduce

1. Check out current develop (d8894449 when reproduced).

2. Run mvn -DskipTests package.

3. Create /tmp/ltex-minimal.typ:

   Why is ltex not showing anithing?
   
   thisfh fhsdh gh.

4. Run:

   target/appassembler/bin/ltex-cli-plus --verbose /tmp/ltex-minimal.typ

5. The server checks the file and sends diagnostics, but the CLI throws NoSuchMethodError when it tries to print one.

For comparison, building commit 7721b75d (immediately before the LSP4J update) and running its packaged CLI against the same file prints five diagnostics and exits with status 3 as expected.

Expected behavior

The packaged CLI should print the diagnostics and exit with status 3.

Sample document

Details

Why is ltex not showing anithing?

thisfh fhsdh gh.

LTeX configuration

Details

{}

LTeX LS log

Details

INFO: Checking '/tmp/ltex-minimal.typ'...
INFO: Waiting for diagnostics for file '/tmp/ltex-minimal.typ'...
Exception in thread "main" java.lang.NoSuchMethodError: 'java.lang.String org.eclipse.lsp4j.Diagnostic.getMessage()'
    at org.bsplines.lspcli.client.Checker$Companion.printDiagnostic(Checker.kt:197)
    at org.bsplines.lspcli.client.Checker.checkFile(Checker.kt:136)
    at org.bsplines.lspcli.client.Checker.check(Checker.kt:67)
    at org.bsplines.lspcli.client.Checker.check(Checker.kt:40)
    at org.bsplines.lspcli.LspCliLauncher.call(LspCliLauncher.kt:184)

Version information

• Operating system: Fedora Linux 44, x86-64
• ltex-ls-plus: develop at d8894449
• bundled lsp-cli-plus: 2.3.0
• LSP4J: 1.0.0
• Java: OpenJDK 25.0.4

Additional context/information

The language server itself does publish valid textDocument/publishDiagnostics JSON. A direct protocol probe receives all five diagnostics, with Diagnostic.message serialized as a string. The failure is in the packaged Java CLI reading the LSP4J 1.0.0 model at runtime.

[alberti42]

Yes, I agree. This was something I had already realized in the past. I forgot to bring this up again this time.

@spitzerd: Do you have time to look into it and push a new release of the CLI? I am afraid that without it, the whole chain of tools with the nightly build is broken for everyone.

[spitzerd]

Thanks for reporting this issue. Even if we do not use the new features of LSP 3.18 (LSP4J 1.0.0), the API breaks. That's why we need to to do a major release of vscode-ltex-plus, ltex-ls-plus and lsp-cli-plus once we move to LSP 3.18. I will create a new release of lsp-cli-plus.

[spitzerd]

@alberti42 Off topic: The LanguageTool Premium tests are failing. Can you please have a look?

[alberti42]

@alberti42 Off topic: The LanguageTool Premium tests are failing. Can you please have a look?

It should now be fixed. I pushed yesterday a fix to the test unit. Now, the CI/CD comes out green.