Add mfussenegger/nvim-jdtls to languages/java

[venkyr77]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find a similar feature request

🏷️ Feature Type

New Addon

🔖 Feature description

https://github.com/mfussenegger/nvim-jdtls offers several extensions over the default jdtls configured over lspconfig. Almost all of the tutorials / guidances suggest using nvim-jdtls and so consumers of nvf are probably writing their own config for nvim-jdtls (at least me - https://github.com/venkyr77/nvfnvim/blob/main/modules/lsp/jdtls.nix). nixvim supports nvim-jdtls here.

Both nvim-lspconfig and nvim-jdtls use the client built into neovim
Some differences between the two:
* The setup of lspconfig creates a java filetype hook itself and provides some defaults for the cmd of the config.
* nvim-jdtls delegates the choice when to call start_or_attach to the user.
* nvim-jdtls adds some logic to handle jdt:// URIs. These are necessary to load source code from third party libraries or the JDK.
* nvim-jdtls adds some additional handlers and sets same extra capabilities to enable all the extensions

Read more here

Also, nvim-jdtls provides the easiest way to run and debug tests with nvim-dap - https://github.com/mfussenegger/nvim-dap/wiki/Extensions#language-specific-extensions, https://github.com/mfussenegger/nvim-jdtls?tab=readme-ov-file#debugger-via-nvim-dap

with dap enabled like

    debugger.nvim-dap = {
      enable = true;
      ui = {
        autoStart = false;
        enable = true;
      };
    };

one could simply run tests using require('jdtls').test_class() or require('jdtls').test_nearest_method().

We already use jdtls, we can add an option config.vim.languages.java.lsp.enableNvimJdtlsIntegration to enable nvim-jdtls support

✔️ Solution

Implement nvim-jdtls integration for java when config.vim.languages.java.lsp.enableNvimJdtlsIntegration is true

❓ Alternatives

No response

📝 Additional Context

No response

[NotAShelf]

For some languages, I've added a uniform extensions option that can be used to define, well, extensions. Typescript, Typst and Markdown make use of this "API" (if you can call it that) already. I think a similar option can be added to Java as well, but since I don't write Java anymore I am not not confident that I can implement it in a way that I can confirm to be working.

[venkyr77]

I can take a stab at it if that is okay, I use java quite a lot, I can provide sample testing workspaces along with my PR

[NotAShelf]

I'm happy to review a PR that adds nvim-jdtls as an extension. #727 is also relevant.

An option under extensions is the best approach imo, other modules I've listed above can be used as reference.

[venkyr77]

For some languages, I've added a uniform extensions option

I am aware of that. So, my thoughts would be to add config.vim.languages.java.extensions.nvim-jdtls.*.

For draft - https://github.com/venkyr77/nvfnvim/blob/main/modules/lsp/jdtls.nix. I would be using

1. pkgs.vimPlugins.nvim-jdtls
2. pkgs.vscode-extensions.vscjava.vscode-java-debug
3. pkgs.vscode-extensions.vscjava.vscode-java-test
4. pkgs.lombok
5. pkgs.jdk8
6. pkgs.jdk11
7. pkgs.jdk17
8. pkgs.jdk21

I am thinking

config.vim.languages.java.extensions.nvim-jdtls.enable
config.vim.languages.java.extensions.nvim-jdtls.test.enable

if the second one is true,

1. pkgs.vscode-extensions.vscjava.vscode-java-debug
2. pkgs.vscode-extensions.vscjava.vscode-java-test

would be needed and we will set config.vim.debugger.nvim-dap.enable = true.

I recently also saw that we are wanting to move to the mental model of default keymaps having a toggle. so,

if config.vim.languages.java.extensions.nvim-jdtls.test.keymaps.enable is true,

vim.keymap.set("n", "<leader>ltc", function()
  jdtls.test_class({
    config_overrides = overrides,
  })
end, { buffer = bufnr, desc = "[t]est [c]lass" })

vim.keymap.set("n", "<leader>ltm", function()
  jdtls.test_nearest_method({
    config_overrides = overrides,
  })
end, { buffer = bufnr, desc = "[t]est nearest [m]ethod" })

let me know your thoughts

[NotAShelf]

That all sounds good to me. I also like that you're thinking about keyboards early, so I say go ahead with the module, and we'll see how it goes in the context of nvf. I'll be away this weekend, but I can provide you a review on Monday or maybe late Sunday if there is anything concrete by then.