Please test 0.12.0 nighty build

[angelozerr]

Hi all,

I wanted to create the release of 0.12.0 which embeds amazing work from @SCWells72 .

Unfortunately it seems that there are some bugs (I don't blame you @SCWells72 please trust me!) that we are trying to fix it with @SCWells72 like:

• a freeze problem
• java.lang.NullPointerException: Cannot invoke "com.intellij.psi.PsiFile.getName()" because "targetFile" is null #898

We will fix those 2 issues but to prevent from another issues, please test nighty build to report us annoying issues before the release. Thanks so much for your help!

cc @CppCXY @InSyncWithFoo @seachicken @KUGDev @AlexWeinstein92 @aparnamichael @MituuZ @turkeylurkey @mrglavas @koxudaxi @FalsePattern @onriv @kristofvb @kdvolder @rcjsuen @jansorg @SCWells72 @ericdallo @nikunjarora12345

[SCWells72]

I've created PR #901 for #898. @angelozerr what's the latest on the freeze?

[vaisakhkannan]

Hi @angelozerr,

While testing our 24.0.12 Liberty Tools IntelliJ Plugin with your latest nightly build (version 0.12.0-20250317-135348), I encountered an exception on Windows OS with Intellij version 2024.3.4.1 Community Edition. Below is the exception log.

Error while consuming 'textDocument/codeLens' with language server 'MicroProfile'

org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Internal error.
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:209)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:193)
	at com.redhat.devtools.lsp4ij.LanguageServerWrapper.lambda$start$5(LanguageServerWrapper.java:332)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796)
	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)

I enabled traces for Jakarta EE, Liberty Config, Liberty LemMinX, and MicroProfile LS, then performed the following actions:

• Opened a Java file containing annotations and variables.
• Selected an annotation and right-clicked to bring up the context menu.
• Navigated to the Go To submenu and selected Implementation(s).
• Ensured the source file for that annotation opened in an editor.
• Selected a variable and right-clicked to bring up the context menu.
• Navigated to the Go To submenu and selected Type Declaration.
• Ensured the source file for that variable's type opened in an editor (e.g., Integer).

I encountered this error the first time I attempted to select the Type Declaration of a variable. However, when I retried the same steps, I couldn’t reproduce it. Then, I tested on new OpenLiberty projects and saw the exception occurring again when performing the same above list of actions.

[angelozerr]

Thanks @vaisakhkannan for your feedback. I think I have introduced a bug with codelens when I wanted to support resolve codelens. I did a fix, once https://github.com/redhat-developer/lsp4ij/actions/runs/13920089569 will be done please reinstall nighty build.

@CppCXY please install also this nighty, codelens should work better (I hope).

[vaisakhkannan]

Thanks @angelozerr, I checked with the latest nightly build, and I am no longer getting the exception.

[angelozerr]

That's great! Thanks for having tested and sorry to have lost your time with this problem.

[FalsePattern]

I'm getting this weird exception with the ZLS language server with LSP4IJ 0.12.0-20250318-135907:

java.lang.IllegalStateException: Missing header Content-Length in input "{"jsonrpc":"2.0","method":"window/logMessage","params":{"type":3,"message":"Loaded config:      /tmp/zigbrains-zls-autoconf1.json"}}C{"jsonrpc":"2.0","method":"window/logMessage","params":{"type":3,"message":"Set config option 'enable_build_on_save' to false"}}Content-Length: 160

"
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:91)
	at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

[FalsePattern]

Nevermind, restarting the language server seems to have fixed it

[angelozerr]

Mmmm I think this error is not linked to this version, but it seems we can have this bug -( I don't know why.

[FalsePattern]

Breadcrumbs are working correctly with Zig, but the sticky lines don't always appear for every file for some reason.
For extra context, both the std.zig and array_list.zig files come from a read-only "External Libraries" source set

[SCWells72]

To provide some context on sticky lines not being shown initially, that can occur when the following happens:

1. The IDE calls the breadcrumbsInfoProvider for sticky lines after the file is opened. There is not yet a textDocument/documentSymbol response for the file, so it's empty.
2. The textDocument/documentSymbol response is received, but there's no way (that I've found, at least) to tell the IDE to re-query sticky lines from the breadcrumbsInfoProvider. I've tried using DaemonCodeAnalyzer.restart(file), but that didn't make any difference.
3. If the file is closed and reopened or edited, sticky lines are displayed properly.

Breadcrumbs are displayed just fine because they're re-queried when the caret changes either by keyboard navigation or editing.

So this primarily occurs right after the IDE has been opened and the language server is starting/initializing. After that, sticky lines should show in a very consistent state. If you're not seeing that, please let me know.

[FalsePattern]

I'll poke around inside intellij sources and see if there's any way to refresh stickly lines

Worst case scenario it can just be done via reflecting into internal apis inside a try/catch block, the marketplace plugin verifier can't check reflective code for internal api usages. I use a similar approach in ZigBrains for opening the marketplace browser in idea ultimate when users click the prompt for installing the native debug jb plugin

[SCWells72]

I'll be interested to hear whether or not you find a solution. In my experience it's only editor tabs that are (re)opened before the associated language server has started that are affected, so very often just the focused editor tab when the project was opened. And as soon as an affected editor tab's contents are changed in any way, sticky lines show up properly. So it's a very niche issue that's resolved almost immediately upon actually using the IDE.

To fix that, when a language server has started completely, you need to "nudge" all open editors for files associated with that language server so that sticky lines are recomputed. Like I said, I was hoping that DaemonCodeAnalyzer.restart() would do that, but it didn't.

[SCWells72]

I may have actually just figured out how to do it. Let me see if it works and, if so, I'll get a PR going for it.

[SCWells72]

Opened #908 for the changes required to force-refresh sticky lines after the language server has started.

[angelozerr]

After investing the freeze problem with @SCWells72 it seems it can happen when language servers are used intensively and it can have a freeze when file/server mapping are evaluated (there are evaluated every time). We need to cache them and evict the if needed. I am trying to work on that.

[SCWells72]

I've opened PR #906 with a prospective fix for the reported issue. @angelozerr is investigating a generalization of that approach as separate work now.

[angelozerr]

I've opened PR #906 with a prospective fix for the reported issue. @angelozerr is investigating a generalization of that approach as separate work now.

Indeed but I think it is better to cache mapping instead of caching only editor behzviour state.

I am trying to do that in my draft PR.

[angelozerr]

Bad news for LSP4IJ 0.12.0 release, we have more and more bad feedback with performance (withIJ Quarkus) and it seems performance are degarated since 0.10.0 according the user feedback

I need to study why it is so slow and do some fixes.

[joswarmer]

I also still have freezes on the last build, if you think the thread dumps will be useful, I can send them.

[angelozerr]

Yes please, but I suspect it is the same problem than @kuglee

[SCWells72]

Yeah. I've just checked with the original test project for the other issue.

You just have to duplicate the first line a few times.

If you're on a Mac, you can use my config. Otherwise you need to have Swift and sourcekit-lsp installed. Here's my config: lsp4ij-export20250327.zip

Here's the test project: https://github.com/kuglee/Lsp-test

My development machines are all Windows. Is it possible to reproduce this on Windows? I do have a Mac Mini M1 that is used exclusively for platform testing, but it would take quite a bit to get it set up decently for dev/debug.

UPDATE: I'm installing and configuring Swift Developer Toolkit on Windows now. Hopefully I'll be able to reproduce this behavior shortly. I'll update here when I know more.

[SCWells72]

Not sure if I'm doing what you suggested to reproduce, but I'm not seeing any issues locally:

Please let me know other steps to reproduce if what I'm trying doesn't look correct.

UPDATE: I'm going to try it in a commercial JetBrains IDE with the Database plugin installed, but is there anything specific I need to do to have that logic executed via com.intellij.database.dialects.oracle.debugger.*?

[SCWells72]

I've managed to reproduce it after installing a local DB and connecting to it via the IDE's DB plugin. Trying to understand what I'm seeing now.

[joswarmer]

Here they are: threadDumps-freeze-20250327-190525-WS-243.26053.12 2.zip

[kuglee]

I've only had time to test it briefly and it didn't freeze when I tried the stuff I did before. So it's looking good. I'll keep testing it over the weekend and report back.

[joswarmer]

I did some testing today, no freezes so far :-) . I will continue using it through the weekend and next week.

[angelozerr]

I did some testing today, no freezes so far :-) . I will continue using it through the weekend and next week.

Thanks so much @joswarmer @kuglee to take time to test lsp4ij !

@SCWells72 you are a god!

[SCWells72]

Yeah, this is one of those that if it doesn't freeze, that's not a guarantee that it's truly fixed, but if it does freeze, it's back to the drawing board. In this case, I have high hopes that it's a proper fix because, once the problem was discovered to be a classic off-by-one issue, it removed the uncertainty around fixing a thread concurrency/locking problem. Fingers crossed!

[angelozerr]

@kuglee @joswarmer I have started a new nighty build at https://github.com/redhat-developer/lsp4ij/actions/runs/14135123338 when it will finished please install it and give us feedback.

You should enjoy with Code Inspect (see #936) If your language server can support closed document, you should see all errors from your project.

[angelozerr]

cc @CppCXY @InSyncWithFoo @seachicken @KUGDev @AlexWeinstein92 @aparnamichael @MituuZ @turkeylurkey @mrglavas @koxudaxi @FalsePattern @onriv @kristofvb @kdvolder @rcjsuen @jansorg @SCWells72 @ericdallo @nikunjarora12345

I plan to create the release on Tuesday (1 april) since we did a lot of tests, but if it is too short for you, please tell me.

[rcjsuen]

I tested two different language servers (written in TypeScript and Go) and I don't see #644 anymore. 👍

[angelozerr]

I tested two different language servers (written in TypeScript and Go) and I don't see #644 anymore.

Again it is the amazing work from @SCWells72 ! It is working because ts and go language server supports semantic tokens. The main idea is when file have not a custom psifile, a fake psifile is build from the semantic tokens information if language server supports it.

[rcjsuen]

It is working because ts and go language server supports semantic tokens.

Very interesting. Thank you for clarifying. I was testing other language servers (rcjsuen/dockerfile-language-server and docker/docker-language-server, and not the TypeScript language server or gopls)...but yeah I do have semantic tokens there so... 🤔

[kuglee]

I've been testing it over the weekend and I'm happy to report that there were no freezes.

[angelozerr]

That's fanatstic! Please note that I have created a new nighty this morning to support Pull diagnostics which is supported by swift language server. Validation should work, but validation for referenced document (ex : you update a a.swift file and it should generate new validation for b.swift file) is not implemented. I will work on that this afternoon.

If you have time again to play with the nighty, don't hesitate to do that.

[angelozerr]

I have created a new nighty which supports now Pull diagnostics. @InSyncWithFoo please test it.

I have tested with swift and html language server and it seems it is working pretty well.

This afternoon I will improve it to support related document (since swift language server supports it).

@mrglavas don't be afraid with that, your language server doesn't support pull diagnostics, so there are no impact for you.

[InSyncWithFoo]

I get this error as soon as the language server is started:

com.intellij.openapi.diagnostic.RuntimeExceptionWithAttachments: Read access is allowed from inside read-action only (see Application.runReadAction()); If you access or modify model on EDT consider wrapping your code in WriteIntentReadAction  or ReadAction; see https://jb.gg/ij-platform-threading for details
Current thread: Thread[#110,JobScheduler FJ pool 2/3,6,main] 85132331 (EventQueue.isDispatchThread()=false)
SystemEventQueueThread: Thread[#49,AWT-EventQueue-0,6,main] 573583569
	at com.intellij.util.concurrency.ThreadingAssertions.createThreadAccessException(ThreadingAssertions.java:218)
	at com.intellij.util.concurrency.ThreadingAssertions.softAssertReadAccess(ThreadingAssertions.java:155)
	at com.intellij.openapi.fileEditor.impl.FileDocumentManagerBase.getDocument(FileDocumentManagerBase.java:50)
	at com.intellij.openapi.fileEditor.FileDocumentManager.getDocument(FileDocumentManager.java:61)
	at com.intellij.psi.AbstractFileViewProvider.getDocument(AbstractFileViewProvider.java:170)
	at com.intellij.codeInsight.daemon.impl.DaemonCodeAnalyzerImpl.restart(DaemonCodeAnalyzerImpl.java:827)
	at com.redhat.devtools.lsp4ij.DocumentContentSynchronizer.lambda$processPullDiagnosticIfNeeded$6(DocumentContentSynchronizer.java:317)
	at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:718)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
	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)

Other than that it seems to be working just fine. Thanks!

[angelozerr]

Thanks for your feedback!

Once https://github.com/redhat-developer/lsp4ij/actions/runs/14170276445 will be finished, please retry.

[gilbysunil14]

Hi @angelozerr,
While testing our 24.0.12 Liberty Tools IntelliJ Plugin with your latest nightly build (version 0.12.0-20250401-013318), I encountered an exception on Mac OS with Intellij version 2024.3.5 Ultimate Edition. Below is the exception log.

java.lang.IllegalArgumentException: Argument for @NotNull parameter 'file' of com/redhat/devtools/lsp4ij/LSPIJUtils.toUriAsString must not be null
	at com.redhat.devtools.lsp4ij.LSPIJUtils.$$$reportNull$$$0(LSPIJUtils.java)
	at com.redhat.devtools.lsp4ij.LSPIJUtils.toUriAsString(LSPIJUtils.java)
	at com.redhat.devtools.lsp4ij.LSPIJUtils.toTextDocumentIdentifier(LSPIJUtils.java:1158)
	at com.redhat.devtools.lsp4ij.features.semanticTokens.LSPSemanticTokensHighlightVisitor.highlightSemanticTokens(LSPSemanticTokensHighlightVisitor.java:106)
	at com.redhat.devtools.lsp4ij.features.semanticTokens.LSPSemanticTokensHighlightVisitor.analyze(LSPSemanticTokensHighlightVisitor.java:75)
	at com.intellij.codeInsight.daemon.impl.HighlightVisitorRunner.lambda$runVisitors$4(HighlightVisitorRunner.java:119)
	at com.intellij.concurrency.ApplierCompleter.processArrayItem(ApplierCompleter.java:126)
	at com.intellij.concurrency.ApplierCompleter.processArray(ApplierCompleter.java:207)
	at com.intellij.concurrency.ApplierCompleter.execAll(ApplierCompleter.java:176)
	at com.intellij.concurrency.JobLauncherImpl.lambda$invokeConcurrentlyUnderProgressAsync$3(JobLauncherImpl.java:108)
	at com.intellij.openapi.application.impl.AnyThreadWriteThreadingSupport.tryRunReadAction(AnyThreadWriteThreadingSupport.kt:333)
	at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:972)
	at com.intellij.concurrency.ApplierCompleter.lambda$wrapInReadActionAndIndicator$2(ApplierCompleter.java:158)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$14(CoreProgressManager.java:674)
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:749)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:705)
	

Performed the following actions:

1. Open a Java file containing annotations and variables
2. Select an annotation and right click to bring up the context menu
3. Navigate with the mouse to the Go To submenu and select Implementation(s)

I encountered this error the first time I attempted to goto the implementation of an annotation. However, when I retried the same steps, I couldn’t reproduce it.

[angelozerr]

@vaisakhkannan @gilbysunil14 sorry youhave right, I have interoduced a bug when I did a lot of performance, please retry reinstall nighty when https://github.com/redhat-developer/lsp4ij/actions/runs/14191904843 will be finished.

[vaisakhkannan]

@angelozerr The build has failed.

[angelozerr]

@angelozerr The build has failed.

I dont know why. I have restarted , please retry.

[vaisakhkannan]

@angelozerr , We have tested with the latest nightly version 0.12.0-20250401-104929, and we are not encountering the issue that was reported. Thanks for fixing that. As per your previous suggestion, we also checked with the older LSP4IJ version 0.11.0, and we did not encounter the issue there either.

[angelozerr]

@angelozerr , We have tested with the latest nightly version 0.12.0-20250401-104929, and we are not encountering the issue that was reported.

That's great!

Thanks for fixing that.

You are welcome! And thanks so much to have reported the issue.

As per your previous suggestion, we also checked with the older LSP4IJ version 0.11.0, and we did not encounter the issue there either.

Indeed you ar eright, this issue was not present in the older LSP4IJ, I am really sorry for wasting your time -(

[angelozerr]

LSP4IJ 0.12.0 has been released and is now available on Jetbrains Marketplace!

Thanks so much for having helped me to improve performance, fixing bugs and having tested this release!