Lombok rename field support

[tobias-z]

Problem Statement

Currently when trying to refactor a field when the lombok jar is enabled as such:

config.cmd = {
-- ...
"-javaagent:" .. home .. "/.local/share/nvim/lsp_servers/jdtls/lombok.jar",
-- ...
}

The jdtls server kind of just ignores the request since it does not seem to support such a refactor.

If this is just my mistake in some configuration, i would love to know what i can do.

Ideas or possible solutions

I currently have a working solution bypassing this problem in my local config, which involves performing an lsp references request, and then using that to rename both the fields and getters and setters to match the field name.

Would you be interested in a pull request allowing rename functionality? (This could easily be removed if at some point the lsp starts supporting lombok refactoring)

The rename function would do something like this:

1. Check if we are in a java file and currently hovering a field. If not then, we will just call vim.lsp.buf.rename
2. Find the references to the field we are hovering, and since the lsp server provides getter and setter references when lombok is on, we can rename everything using built in vim.api to the chosen new name.

If at some point the lsp server starts to suppot renaming lombok fields/setters/getters, this implementation could just be removed.

[mfussenegger]

If this is just my mistake in some configuration, i would love to know what i can do.

If lombok is otherwise working I don't think it is a configuration issue. I've noticed that there are cases where eclipse.jdt.ls isn't able to create the rename refactoring, even without lombok.

Your approach sounds interesting but I don't think it fits the scope of nvim-jdtls. And I think anything that could be improved or fixed on the server side should be fixed there.
Did you consider raising an issue in the eclipse.jdt.ls repository, or contributing the functionality there?

[tobias-z]

Good to know it's not an issue with my config 😆

Your approach sounds interesting but I don't think it fits the scope of nvim-jdtls.

Okay fair enough, in that case I think i will put it into a neovim plugin for people to install if they want to.

And I think anything that could be improved or fixed on the server side should be fixed there. Did you consider raising an issue in the eclipse.jdt.ls repository, or contributing the functionality there?

I totally agree, and it would probably be faster refactoring aswell. I did consider submitting an issue there, which seamed like the logical place for it to be implemented, however i wanted a quick solution which would 'just work' for now 😆
I'm also not sure what their philosophies are around adding specific solutions for lombok in the lsp codebase?

When i release the plugin would it be okay for me to provide a link to it from this issue?

[mfussenegger]

I'm also not sure what their philosophies are around adding specific solutions for lombok in the lsp codebase?

There's at least lombok support in the vscode extension, so chances might be good.
Probably best to create an issue, ideally with some minimal reproduction steps to see where it goes

When i release the plugin would it be okay for me to provide a link to it from this issue?

Sure

[tobias-z]

I've now started the plugin which for now only contains the functionality i was talking about.

java-util.nvim

I will be working on other features which I find would be helpful to a java workflow.

[mfussenegger]

Not sure if it's the same thing, but maybe eclipse-jdtls/eclipse.jdt.ls#2339 is addressing this

[tobias-z]

I think you're right, it looks like exactly the fix needed 🥳