As for the path to the compilation database I use the default one wich is ./compile_commands.json so I don't need to specify it explicitly.

Did you double check this statement? Looking at the sonarlint VSCode configuration spec, I see that they use an absolute path in the example:

Path to the active compilation database, e.g. `C:\\Repos\\MyProject\\compile_commands.json

Do you mind to provide a source definition of this conventions? I never heard of it and nvim-jdtls has no Lsp prefix in its commands.

@MKoseler, the config looks fine to me. Currently, the proxy might be an explanation why this is not working. Did you try if sonarlint for VScode works properly with setting up a connection? That would give us a good hint if it is related to a potential proxy issue or if it is due to some issue in sonarlint.nvim.

Also, you could try to debug sonarlint-language-server (if you are a Java dev) and see if you can find anything. Checkout this line in my dotfiles.

I guess, sonarlint-language-server fails because there is no analyzer present (checkout the -analyzers option). Also, for getting diagnostics for C, you need to specify the path to the compilation database (see here).

Java 17 should be fine.

schrieveslaach (ccf52586) at 06 Nov 12:17

Based on https://github.com/SonarSource/sonarlint-language-server/pull/551 this commit enhances the handler sonarlint/canShowMissingRequirementsNotification to check if the sonarlint-language-server supports the error_only return value to make sure that missing setup requirements will shown as LSP standard window message.

Fixes #29

schrieveslaach (0adb60a1) at 06 Nov 08:14

@jeremieburtin, are you certain that analyzers_path .."sonarjs.jar", points to correct path?

@mrt181, I see in your config that you enbaled sonarlint.nvim for CS only:

      filetypes = { "cs" },

Please, try with the additional file types.

I see rules = vim.empty_dict() in your LSP config. Can you remove it because look at the sonarlint.nvim README:

Rules can be configured, e.g. by turning them on or off, with the following configuration. Please note that rules = {} deactivates all rules.

Can you check following questions?

• Do you get a pop up in Neovim after changing the line locally?
• Can you tell me which sonarlint-language-server version you are using?
• Is there any error or suspicious message in :LspLog?

schrieveslaach (46a8007d) at 20 Oct 20:06

FYI: new attempt to fix it upstream, see https://github.com/SonarSource/sonarlint-language-server/pull/548

Can you try to adjust following code locally in your local sonarlint.nvim?

   config.handlers["sonarlint/canShowMissingRequirementsNotification"] = function()
      return true
   end

I think sonarlint.nvim swallows the notification. Meanwhile, I tried to improve upstream so that you get a proper message in Neovim.

4.3.1 should now be working without the custom init options. @coderkun, do you mind to try it without custom init options?

Cool, thanks for testing.

schrieveslaach (9ce2318b) at 04 Oct 10:09

When I use the new setup method via lspconfig then I get the error below.

https://github.com/mfussenegger/nvim-jdtls/?tab=readme-ov-file#via-lspconfig

Error executing vim.schedule lua callback: ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:171: attempt to index field 'handl
ers' (a nil value)                                                                                                                       
stack traceback:                                                                                                                         
        ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:171: in function 'init_config'                                       
        ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:166: in function ''                                                  
        vim/_editor.lua: in function ''                                                                                                  
        vim/_editor.lua: in function <vim/_editor.lua:0>                                                                                 

I couldn't figure out how to delay or postpone sonarlint configuration after the nvim-jdtls has done it's init setup.

schrieveslaach (1d49a469) at 04 Oct 10:09

Fixes #36

schrieveslaach (e6b8ac4d) at 03 Oct 10:19

After changing my dotfiles to use also the new jdtls initialization, I could reproduce your recent error. Now, it should be working fine. Can you give it another try?

schrieveslaach (9ce2318b) at 03 Oct 10:07

I found another approach that's get rid of the dependency on language/status. Do you mind to check if this is working with new jdtls setup. With the old setup it works.

schrieveslaach (0eda4467) at 02 Oct 10:06

@azdanov, can you try !27 (merged) to see it that fixes the issue?

Fixes #36

schrieveslaach (12a749c8) at 30 Sep 11:17

schrieveslaach (6a3f95e0) at 30 Sep 11:10

schrieveslaach (eb3d9c16) at 30 Sep 11:08

schrieveslaach (7feaa7ad) at 28 Sep 11:01

schrieveslaach (1281dbb4) at 28 Sep 10:57

Yes, that could be done to prevent the crashing. What bothers me though, that a client can crash the server and currently sonarlint-language-server relies on the client to not crash the server (see also my comment here).

Let's see how they respond.

Meanwhile, you should be able to prevent the crash in your local sonarlint.nvim conf:

         require("sonarlint").setup({
            server = {
               -- …
               init_options = {
                  connections = vim.empty_dict(),
                  rules = vim.empty_dict(),
                  automaticAnalysis = true,
               },
            },
         })

FYI: https://github.com/SonarSource/sonarlint-language-server/pull/532

diff --git a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
index bf0bdd38..b8a76ef6 100644
--- a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
+++ b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
@@ -19,6 +19,7 @@
  */
 package org.sonarsource.sonarlint.ls;
 
+import java.util.Collections;
 import java.util.Map;
 
 public record SonarLintLanguageServerInitializationOptions(
@@ -31,7 +32,7 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> additionalAttributes,
   String clientNodePath,
   boolean focusOnNewCode,
-  boolean automaticAnalysis,
+  Boolean automaticAnalysis,
   String omnisharpDirectory,
   String csharpOssPath,
   String csharpEnterprisePath,
@@ -41,4 +42,16 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> rules,
   Map<String, Object> connections) {
 
+  public SonarLintLanguageServerInitializationOptions {
+    if (rules == null) {
+      rules = Collections.emptyMap();
+    }
+    if (connections == null) {
+      connections = Collections.emptyMap();
+    }
+    if (automaticAnalysis == null) {
+      automaticAnalysis = Boolean.TRUE;
+    }
+  }
+
 }

This change did the trick. Digging into the diff of the release revealed to me that sonarlint-language-server relies on the client to initialize some maps. I'll create a PR and see if they'll merge it.

I can confirm that I'm running into the same issue. I created a fix for the NPE locally and tried to see if that is enough and if this local fix could be upstreamed. Here is the fix:

diff --git a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
index bf0bdd38..3a797b72 100644
--- a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
+++ b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
@@ -19,6 +19,7 @@
  */
 package org.sonarsource.sonarlint.ls;
 
+import java.util.Collections;
 import java.util.Map;
 
 public record SonarLintLanguageServerInitializationOptions(
@@ -41,4 +42,13 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> rules,
   Map<String, Object> connections) {
 
+   public SonarLintLanguageServerInitializationOptions {
+      if (rules == null) {
+         rules = Collections.emptyMap();
+      }
+      if (connections == null) {
+         connections = Collections.emptyMap();
+      }
+   }
+
 }

That fixes the error message and the LSP starts. However, there must be more adjustment because I don't get any diagnostics from Sonarlint LS.

schrieveslaach (29ae9ff6) at 18 Sep 06:28

schrieveslaach (067f041f) at 18 Sep 06:14

schrieveslaach (dc570255) at 18 Sep 06:14

With this commit the rule description is converted from HTML to markdown so that the display in the UI looks nicer.

schrieveslaach (067f041f) at 18 Sep 06:12

schrieveslaach (07813986) at 11 Sep 11:44

schrieveslaach (4af5879f) at 11 Sep 07:50

schrieveslaach (157182e4) at 05 Sep 11:20

... and 1 more commit

Oh, … Yes, I messed up the version numbers. I'll check it out.

This issue has been fixed upstream in sonarlint-language-server 4.13. Closing as duplicate of #24 (closed).

schrieveslaach (ec25369c) at 05 Sep 07:46

schrieveslaach (00ad9917) at 04 Sep 17:00

schrieveslaach (76624364) at 04 Sep 11:00

schrieveslaach (fbb02da0) at 04 Sep 10:49

schrieveslaach (e4804832) at 04 Sep 10:48

schrieveslaach (beba2668) at 04 Sep 10:45

... and 1 more commit

schrieveslaach (f22d199c) at 04 Sep 10:44

schrieveslaach (7e642899) at 04 Sep 08:47

schrieveslaach (e5c6181f) at 28 Aug 16:12