Compatibility with null-ls ?

[clement-buchart]

Hello,

For the project I'm working on, we're using prettier-java as a formatter.
I've set-up null-ls as an additional lsp server to handle the formatting.

Unfortunately nvim-jdtls uses vim.lsp.buf_request to execute it's requests to jdtls server, but this method, as per the docs, Sends an async request for all active clients attached to the buffer., including null-ls.

Obviously null-ls can't handle things like 'vscode.java.resolveMainClass', 'vscode.java.test.junit.argument' and simply returns nothing, and as such using features like test_nearest_method throws a lot of errors, and can even crash neovim on my install.

I'm wondering if, instead of vim.lsp.buf_request, nvim-jdtls could use something like vim.lsp.get_active_clients(), find jdtls, and than use request(method, params, [handler], bufnr) on said client.

If you think that's something reasonable, I would glagly offer a PR with the change.

Cheers.

[clement-buchart]

For reference here is the fix I'm using locally : clement-buchart@26d87ce

It would need to handle the client name not being the default value of 'jdt.ls' as it is configurable.
But otherwise it solves my use-case

[mfussenegger]

Could you try with #140 ?

Went with a bit of a different approach to not depend on the name. And it might also lead to better error messages if the java-debug bundle isn't setup correctly.

[clement-buchart]

Hello,

Ah yes that looks like a better fix.
The errors are gone on the command-capabilities branch.

Thank you.