Closed gayanper closed 7 months ago
Are there specific steps to reproduce? I tried with Lombok 1.18.30, and it seems to work (at least in my simple example) as I would expect:
(getTest
is not underlined, and is visible in the code completion; unknown
is underlined to show the error checking is running.)
Of course, the Lombok must support the javac used by the extension - informally speaking javac from JDK 21 for the current extension. That is a problem in Lombok, as it depends on javac internals, rather than only relying on the API.
Did the same work if your sample project is a gradle project?
Not really an expert on Gradle, but I let the extension generate a Java Application project in Gradle for me, added:
dependencies {
...
implementation 'org.projectlombok:lombok:1.18.30'
}
and copied the test files. Seems to work the same in this project. (And if I comment out the dependency, the errors for getTest
appear, if I re-add it, they won't be there.)
Note I am not saying there can't be a bug somewhere, that's why I am asking for specific steps to reproduce. OTOH, the general claim that annotation processors are not taken into consideration is too strong, I think.
I can test it out again, the reason I mentioned they are not taken into account because the same project works for redhat java language server and extension out of the box. But I will check again.
@lahodaj OK I see updating the lombok version to latest will resolve this issue, But on a sample project which has configured to use java 17 in Gradle build script, with lombok version 6.4.3
the code compilation is successful. But with netbeans LS this fails. Does that means netbeans LS compiler is not using the same JDK version as configured in Gradle build script ?
The internal parsing is currently based on javac from JDK 21. The JDK used by the project cannot change the javac used for the internal parsing (and even less so to an older javac than JDK 21's javac). This should not be a problem for annotation processors that use the proper APIs. For projects that decide, despite warnings, to use internal implementation (like Lombok), they need to update to support new javac versions.
There's a theoretical possibility to automatically internally use a new Lombok in place of the old one, but I am not a particular fan of such a solution.
This extension is focused towards Java development and directly Java related issues, Lombok doesn't follow Java so closing this issue. But if you have face any Java related or extension related issue please feel free to open an issue.
Hi, AFAIK, the main alternative extension for Java "Language Support for Java(TM) by Red Hat" supports Lombok etc. just fine?
Hi, AFAIK, the main alternative extension for Java "Language Support for Java(TM) by Red Hat" supports Lombok etc. just fine?
Yes
For example if i have a project which uses lombok, the parsed editor code doesn't take the annotation processor contributed symbols into consideration. The build project works fine since the gradle or maven already configured to use the annotation processor. This could be any annotation which libraries which generates code like mapstruct and lombok.