LinkageError: loader constraint violation

[InSyncWithFoo]

I'm getting the following error when targeting PyCharm Professional 2024.2, with a dependency on both the native client and LSP4IJ:

java.lang.LinkageError: loader constraint violation: loader com.intellij.ide.plugins.cl.PluginClassLoader @182fa87a wants to load class org.eclipse.lsp4j.Diagnostic. A different class with the same name was previously loaded by com.intellij.util.lang.PathClassLoader @65ab7765. (org.eclipse.lsp4j.Diagnostic is in unnamed module of loader com.intellij.util.lang.PathClassLoader @65ab7765)
	at insyncwithfoo.plugin.lsp.DiagnosticsSupportKt.getCodeAsString(DiagnosticsSupport.kt:10)
	at insyncwithfoo.plugin.lsp.DiagnosticsSupportKt.access$getCodeAsString(DiagnosticsSupport.kt:1)
	at insyncwithfoo.plugin.lsp.DiagnosticsSupport.getTooltip(DiagnosticsSupport.kt:19)
	at com.intellij.platform.lsp.api.customization.LspDiagnosticsSupport.createAnnotation(LspDiagnosticsSupport.kt:28)
	at com.intellij.platform.lsp.impl.highlighting.LspAnnotator.q(LspAnnotator.kt:71)
	at com.intellij.platform.lsp.impl.highlighting.LspAnnotator.annotate(LspAnnotator.kt:51)
	at com.intellij.codeInsight.daemon.impl.AnnotationHolderImpl.runAnnotatorWithContext(AnnotationHolderImpl.java:216)
	at com.intellij.codeInsight.daemon.impl.AnnotatorRunner.lambda$runAnnotator$3(AnnotatorRunner.java:139)
	at com.intellij.codeInsight.daemon.impl.AnnotationSessionImpl.computeWithSession(AnnotationSessionImpl.java:87)
	at com.intellij.codeInsight.daemon.impl.AnnotatorRunner.runAnnotator(AnnotatorRunner.java:129)
	at com.intellij.codeInsight.daemon.impl.AnnotatorRunner.lambda$runAnnotatorsAsync$0(AnnotatorRunner.java:66)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.tryRunReadAction(AnyThreadWriteThreadingSupport.kt:279)
	at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:965)
	at com.intellij.codeInsight.daemon.impl.AnnotatorRunner.lambda$runAnnotatorsAsync$1(AnnotatorRunner.java:66)
	at com.intellij.concurrency.JobLauncherImpl$2MyProcessQueueTask.lambda$call$0(JobLauncherImpl.java:494)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$13(CoreProgressManager.java:660)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:684)
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:659)
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:79)
	at com.intellij.concurrency.JobLauncherImpl$2MyProcessQueueTask.call(JobLauncherImpl.java:483)
	at com.intellij.concurrency.JobLauncherImpl$2MyProcessQueueTask.call(JobLauncherImpl.java:471)
	at com.intellij.concurrency.JobLauncherImpl$2.compute(JobLauncherImpl.java:456)
	at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:759)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:676)
	at com.intellij.concurrency.JobLauncherImpl.procInOrderAsync(JobLauncherImpl.java:554)
	at com.intellij.codeInsight.daemon.impl.AnnotatorRunner.runAnnotatorsAsync(AnnotatorRunner.java:67)
	at com.intellij.codeInsight.daemon.impl.GeneralHighlightingPass.collectHighlights(GeneralHighlightingPass.java:231)
	at com.intellij.codeInsight.daemon.impl.GeneralHighlightingPass.lambda$collectInformationWithProgress$10(GeneralHighlightingPass.java:176)
	at com.intellij.codeInsight.daemon.impl.HighlightVisitorRunner.createHighlightVisitorsFor(HighlightVisitorRunner.java:84)
	at com.intellij.codeInsight.daemon.impl.GeneralHighlightingPass.collectInformationWithProgress(GeneralHighlightingPass.java:109)
	at com.intellij.codeInsight.daemon.impl.ProgressableTextEditorHighlightingPass.doCollectInformation(ProgressableTextEditorHighlightingPass.java:84)
	at com.intellij.codeHighlighting.TextEditorHighlightingPass.collectInformation(TextEditorHighlightingPass.java:57)
	at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$doRun$2(PassExecutorService.java:418)
	at com.intellij.platform.diagnostic.telemetry.helpers.TraceKt.runWithSpanIgnoreThrows(trace.kt:118)
	at com.intellij.platform.diagnostic.telemetry.helpers.TraceUtil.runWithSpanThrows(TraceUtil.java:36)
	at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$doRun$3(PassExecutorService.java:413)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.tryRunReadAction(AnyThreadWriteThreadingSupport.kt:291)
	at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:965)
	at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$doRun$4(PassExecutorService.java:404)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$13(CoreProgressManager.java:660)
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:735)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:691)
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:659)
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:79)
	at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.doRun(PassExecutorService.java:403)
	at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$run$0(PassExecutorService.java:379)
	at com.intellij.openapi.fileTypes.impl.FileTypeManagerImpl.cacheFileTypesInside(FileTypeManagerImpl.java:802)
	at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.lambda$run$1(PassExecutorService.java:379)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.executeByImpatientReader(AnyThreadWriteThreadingSupport.kt:486)
	at com.intellij.openapi.application.impl.ApplicationImpl.executeByImpatientReader(ApplicationImpl.java:179)
	at com.intellij.codeInsight.daemon.impl.PassExecutorService$ScheduledPass.run(PassExecutorService.java:377)
	at com.intellij.concurrency.JobLauncherImpl$VoidForkJoinTask$1.exec(JobLauncherImpl.java:190)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1491)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2073)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2035)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)

It might have something to do with this one in the docs, but I'm not sure.

If codebase access is necessary, give me a ping.

[angelozerr]

It might have something to do with this one in the docs, but I'm not sure.

I don't think so. You need to do that when your plugin import a library which have a dependency to LSP4IJ (case of IJ Quarkus).

If it works before PyCharm 2024.2, my understand of this problem is that:

• before 2024.2, LSP4IJ and Jetbreains LSP use the same version of LSPJ which expose Diagnostic class code
• in 2024.2, LSP4IJ and Jetbreains LSP don't use the same version of LSPJ and you have this problem.

The fix is that LSP4IJ should uses the same version of LS4J than Jetbrains LSP, but it will work with 2024.2, but not with <2024.2.

Perhaps I'm wrong, but Ifear that there is no solution because your plugin requires Diagnostic class from 2 version of LSP4J.

[InSyncWithFoo]

I checked the About section, and it says LSP4J is at 0.21.1. Let's say I don't care about compatibility with 2024.1 and lower; what can I do so that I no longer get this error?

[angelozerr]

I checked the About section, and it says LSP4J is at 0.21.1.

Thats strange LSP4IJ used too 0.21.1?

Let's say I don't care about compatibility with 2024.1 and lower; what can I do so that I no longer get this error?

I dont master this problem but I think to avoid having LSP4IJ should have the same version of LSP4J than LSP Jetbrains.

The thing I dont understand is that it seems good according your comment?

[angelozerr]

@InSyncWithFoo if you remove LSP4J as dependency in your plugin, is it working better?

[InSyncWithFoo]

That's the thing: I don't depend on LSP4J directly, but LSP4IJ and the native client both depend on it, which is why I assumed there was some conflict between them.

I also tried adding this to my build.gradle.kts, but nothing changed.

implementation("org.jetbrains.plugins:com.redhat.devtools.lsp4ij:0.3.0") {
    exclude("org.eclipse.lsp4j")
}

[angelozerr]

If there is the linkage problem it means that several plugins like LSP4IJ, LSP Jetbrains provide an LSP4J library which have different version

We need to check really which version of LSP4J is used in 2024 2

[InSyncWithFoo]

The version numbers are actually inconsistent, but it was the same in 2024.1:

[angelozerr]

The version numbers are actually inconsistent, but it was the same in 2024.1:

@InSyncWithFoo I'm little lost. You mean that there are the same version of LSP4J in 2024.1 and it is working?

[InSyncWithFoo]

I mean it was just as inconsistent. Not sure if JetBrains updated their LSP4J version or not.

[angelozerr]

Not sure if JetBrains updated their LSP4J version or not.

We need to know the exact version of LSP4J that Jetbrains provide. If you can find that please tell me.

[InSyncWithFoo]

According to this SO answer, the version, or even the JAR file the class is from, doesn't matter.

I asked about this on Slack and here's the reply from a JetBrains employee:

Sorry, hard to say what to do 🤷 no one expects such configuration
[...]
You could have a plugin-like architecture and build different versions for community and commercial IDEs

...I suppose that means it is currently impossible to not get such an error. Ideas for workarounds and corresponding obvious drawbacks include:

• Try to load all LSP4J classes at the same time the plugin is loaded: This might consume memory unnecessarily.
• Doing some monkeypatch on our own to prevent loading the classes twice: I have no idea if this is even possible.
• File an issue on YouTrack and wait for JetBrains to fix it: This should only be the last resort.

[angelozerr]

According to this SO answer, the version, or even the JAR file the class is from, doesn't matter.

I asked about this on Slack and here's the reply from a JetBrains employee:

Sorry, hard to say what to do 🤷 no one expects such configuration
[...]
You could have a plugin-like architecture and build different versions for community and commercial IDEs

...I suppose that means it is currently impossible to not get such an error. Ideas for workarounds and corresponding obvious drawbacks include:

• Try to load all LSP4J classes at the same time the plugin is loaded: This might consume memory unnecessarily.
• Doing some monkeypatch on our own to prevent loading the classes twice: I have no idea if this is even possible.
• File an issue on YouTrack and wait for JetBrains to fix it: This should only be the last resort.

It was my fear. But I wonder why you provide the both LSP support in the same plugin.

For me using LSP4IJ is for providing an IJ plugin for community, no?

If your plugin use LSP Support of Jetbrains your plugin can be used with IJ community.

[InSyncWithFoo]

But I wonder why you provide the both LSP support in the same plugin.

A plugin of mine has already been using the native LSP ever since it was created, so I don't want to break user experience. Guess I'll have to document this as a limitation.

[InSyncWithFoo]

I found this documentation page regarding class loaders. Might worth looking into.