Metals won't boot with a NoClassDefFoundError

[nrinaudo]

Describe the bug

When attempting to boot Metals, I get the following error in the logs:

2022.12.07 13:03:27 INFO  tracing is disabled for protocol LSP, to enable tracing of incoming and outgoing JSON messages create an empty file at c:\JPMC\DEV\TMP\mep-code-gen-unsealed\.metals\lsp.trace.json or C:\Users\D634183\AppData\Local\scalameta\metals\cache\lsp.trace.json
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/lsp4j/jsonrpc/CancelChecker
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
        at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
        at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        at scala.meta.metals.Main$.main(Main.scala:53)
        at scala.meta.metals.Main.main(Main.scala)
Caused by: java.lang.ClassNotFoundException: org.eclipse.lsp4j.jsonrpc.CancelChecker
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 11 more

Expected behavior

I would expect Metals to boot.

Operating system

Windows

Editor/Extension

VS Code

Version of Metals

v0.11.9

Extra context or search terms

Our setup is really rather hostile. On top of running Windows, all Maven requests have to go to an internal repository, which has to be populated manually.

This initially caused troubles far earlier in the installation process (when Metals failed to download its dependencies), but with the help of @tgodzik , I was able to identify which artifacts were missing and make them available.

I suspect the issue is that, somehow, metals is expecting some LSP4J JARs to be on the CLASSPATH but can't find them.

I have made sure that both org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc:0.19.0 and org.eclipse.lsp4j:org.eclipse.lsp4j:0.19.0 were available in our Maven repository.

[ckipp01]

I have made sure that both org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc:0.19.0 and org.eclipse.lsp4j:org.eclipse.lsp4j:0.19.0 were available in our Maven repository.

This might be a case of the wrong version being there. For example I just checked what should be on the classpath for Metals v.0.11.9 and it actually looks like it'll be looking for 0.15.0:

❯ cs resolve metals:0.11.9 | grep lsp4j
org.eclipse.lsp4j:org.eclipse.lsp4j:0.15.0:default
org.eclipse.lsp4j:org.eclipse.lsp4j.debug:0.15.0:default
org.eclipse.lsp4j:org.eclipse.lsp4j.generator:0.15.0:default
org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc:0.15.0:default
org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc.debug:0.15.0:default

[nrinaudo]

Good idea, but unfortunately, this doesn't change a thing :/

[ckipp01]

🤔 alright can you try one more thing. What's the output of the following for you:

cs launch org.scalameta:metals_2.13:0.11.9 -M scala.meta.metals.DownloadDependencies

[nrinaudo]

I like how optimistic you are about my chance to install cs locally.

I'll give it a shot and let you know :)

[ckipp01]

I like how optimistic you are about my chance to install cs locally.

Btw just incase the coursier jar is easier to get than cs you can also just use that instead of cs in my example.

[nrinaudo]

Sure, but even that is problematic. When I say my setup is hostile, I mean it.

I can set the COURSIER_REPOSITORIES env variable, which will work for the coursier CLI. It doesn't work for the coursier launcher though, so I can't even start that.

[tgodzik]

I started working on a PR that would detect cs/coursier locally so that you can just use a fully bootstrapped launcher:

scalameta/metals-languageclient#524 (review)

[nrinaudo]

@tgodzik there might be a misunderstanding here.

This issue is not about coursier not installing properly, but about Metals not installing properly, in a way that I believe is entirely unrelated to coursier. Metals successfully downloads all of its dependencies (or at least reports it does), it's "just" that it ends up not finding some classes it's expecting on the CLASSPATH.

Coursier, here, is a bit of a tangent: @ckipp01 asked me to run it for diagnostics, which I'm struggling to do because the coursier launcher has hard-coded URLs to maven central, which my environment basically blocks. Improving the way Metals downloads coursier is nice and desirable, but, I think, not related to what we're doing here.

Unless I'm missing something?

[tgodzik]

which I'm struggling to do because the coursier launcher has hard-coded URLs to maven central, which my environment basically blocks.

There are two ways to create bootstrapped launcher in coursier, one is minimal which will try to download all the needed jars from maven central (this is used in metals) and the other one will have everything already contained.

For example https://github.com/coursier/coursier/releases/download/v2.1.0-RC2/coursier.jar should not need to download anything.

[nrinaudo]

Ah. Sorry, I wasn't aware of that.

By running the command @ckipp01 suggested with that JAR, I'm seeing a bunch of download failures that I'll need to fix manually, such as metals. It's weird that when installing metals through the VSCode installer, this wasn't reported - nor did Metals even seem to think anything was wrong.

[tgodzik]

Yeah, might be because bootstrapped coursier is lacking a bunch of functionality. That's why I am thinking of allowing users to just use the one on the system and maybe later even makining it download the right one if possible (or printing instructions otherwise)

[nrinaudo]

The DownloadDependencies tool is proving super useful here. What would be even more useful, in my very specific scenario where I have to wait for all requests to maven central to timeout to identify which artifact is needed, would be a flag to list all dependencies it wants.

But that'd be for future me. Present me has everything he needs for the moment, thank you! Let's see if I can get this to work now.

[nrinaudo]

It's going to take a while - so many versions of mtags that require a few minutes to timeout, a few minutes to manually upload, and repeat... but, in the meantime: while this is definitely going to help, I'm not sure it's going to fix the issue. My problem is that Metals needs some LSP4J class that's not on the CLASSPATH, but none of the dependencies DownloadDependencies is downloading are LSP4J related.