feature: add java.action.applyRefactoringCommand

[mawkler]

Did you check the docs?

• I have read all the docs

Is your feature request related to a problem? Please describe.

First of all, thank you for this awesome plugin! It made it super simple for me to get a Java config up and running.

Second, Is there any reason why it doesn't wrap nvim-jdtls? According to this comment by its author it would be pretty simple. nvim-jdtls supports code-actions like extracting methods and variables for instance. What would be your response to this? 🙂

Describe the solution you'd like

nvim-java sets up nvim-jdtls

Describe alternatives you've considered

Not using nvim-java and instead manually settings up nvim-jdtls (which seems is really tedious)

Additional context

Here's the post that I made in nvim-jdtls:

LSP client configuration

No response

Eclipse.jdt.ls version

v1.30.1

Steps to Reproduce

Hi! Thanks for making this awesome plugin! I just installed it, and when I try and perform the code action "Extract to method" I get the message

Language server `jdtls` does not support command `java.action.applyRefactoringCommand`. This command may require a client extension.

Is this expected behaviour? The README says that extract_method is supported.

This is the config that I'm using:

Click to expand

return {
  'nvim-java/nvim-java',
  dependencies = {
    'nvim-java/lua-async-await',
    'nvim-java/nvim-java-core',
    'nvim-java/nvim-java-test',
    'nvim-java/nvim-java-dap',
    'MunifTanjim/nui.nvim',
    'neovim/nvim-lspconfig',
    'mfussenegger/nvim-dap',
    {
      'williamboman/mason.nvim',
      opts = {
        registries = {
          'github:nvim-java/mason-registry',
          'github:mason-org/mason-registry',
        },
      },
    },
  },
  config = function()
    require('java').setup()
    require('lspconfig').jdtls.setup({})
  end
}

To reproduce:

1. Open a .java file
2. Select text in visual mode
3. Do :=vim.lsp.buf.code_action()
4. Select Extract to method
5. Message pops up

Expected Result

Code action lets me extract code to a new method

Actual Result

I get the message

Language server `jdtls` does not support command `java.action.applyRefactoringCommand`. This command may require a client extension.

[s1n7ax]

Regarding the issue, these will be implemented eventually. If you get a feature in either vscode or eclipse, I would like to have them implemented within this plugin as well. But right now, I'm pretty busy don't expect this to be implemented anytime soon.

I don't have any reason to justify why I shouldn't have used nvim-jdtls. It's a damn good plugin. But,

I created this issue in AstroNvim while trying to get nvim-jdtls working with Neoconf AstroNvim/AstroNvim#2352. This is a feature I really need because I work in various machines/VMs and devcontainers. This is the moment I thought I should create a more friendlier plugin that just works & works with Neoconf. There might be a way to change Neoconf to somehow manage nvim-jdtls settings but I'm a programmer who genuinely like writing code, understanding how things work & trying to solve things creative ways. These things I do for fun in free time, so wrapping nvim-jdtls I don't save me money. I only lose the fun I would have had trying to figure out how to do this and that.

[s1n7ax]

@mawkler Could you please update the description with the information you have in nvim-jdtls issue.

[mfussenegger]

There might be a way to change Neoconf to somehow manage nvim-jdtls

Pretty much all the extra functionality of nvim-jdtls is based on having a lsp client named jdtls that can be retrieved via vim.lsp.get_active_clients (or vim.lsp.get_clients in neovim 0.10+)

How that client gets started is not that important. jdtls.start_or_attach sets some extra capabilities and then calls vim.lsp.start but one could start the client also with lspconfig - which should get neoconf to work(?).
The extra capabilities are even separately exposed so that one doesn't have to go through jdtls.start_or_attach: https://github.com/mfussenegger/nvim-jdtls/blob/66b5ace68a5d1c45fdfb1afa8d847e87af2aa1f8/lua/jdtls/setup.lua#L95

An exception could be the jdt:// handing, but I wouldn't mind moving the attach mechanism so that it doesn't rely on a filetype event that does it.

So you could keep the mason/lspconfig handling, add nvim-jdtls as dependency, require it somewhere to ensure it's client commands get registered and if you want re-export it's public API under your module.