oracle / javavscode

Java platform support for Visual Studio Code for full featured Java development (edit-compile-debug & test cycle)
Apache License 2.0
229 stars 30 forks source link

Annotation processors are not take into consideration when parsing #83

Closed gayanper closed 7 months ago

gayanper commented 11 months ago

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.

lahodaj commented 11 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: lombok-test

(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.

gayanper commented 11 months ago

Did the same work if your sample project is a gradle project?

lahodaj commented 11 months ago

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.

gayanper commented 11 months ago

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.

gayanper commented 11 months ago

@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 ?

lahodaj commented 11 months ago

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.

Achal1607 commented 7 months ago

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.

pbodnar commented 7 months ago

Hi, AFAIK, the main alternative extension for Java "Language Support for Java(TM) by Red Hat" supports Lombok etc. just fine?

gayanper commented 7 months ago

Hi, AFAIK, the main alternative extension for Java "Language Support for Java(TM) by Red Hat" supports Lombok etc. just fine?

Yes