Jakarta Validation Annotations and Lombok Fake Issue
Hi,
in case you have a class with nested annotation within generic < > like below
An error will be raised up to Problems panel
But when you open the file the error will disappear because the extension check the file.
This is very annoying issue because it seems there is an error but is not true.
Hi @rgrunber, have you some idea for this issue?
What version of vscode-java (1.44.0 is latest, there's also pre-releases) ? Would you be able to give more information about that block of code ? Also, you mentioned the error goes a way if you open the file. If you close all files, so none are opened and then run Java: Force Java Compilation, and select Full (should be second option) from the list, does the error return, until you open the file once again ?
Based on the image I tried :
package org.example;
import java.util.Set;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;
import javax.validation.constraints.Pattern;
import lombok.Builder;
@Builder
public class MyClass {
@NotNull
@Size(min = 1, message = "MEMBER_CODE_VALIDATION_MESSAGE")
@Builder.Default
private Set<@Size(max = 10) @Pattern(regexp = "NO_SPECIAL_CHARACTERS_REGEX") String> mySet = Set.of();
}
and added the following jars to a lib/ folder : lombok-1.18.39-4050.jar, validation-api-2.0.1.Final.jar. Everything resolved without any errors. I also tried it as part of some Maven project with the additional dependencies :
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.38</version>
</dependency>
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>2.0.1.Final</version>
</dependency>
Hi @rgrunber i'm using
- jakarta.validation:jakarta.validation-api:jar:3.0.2:compile
- org.projectlombok:lombok-mapstruct-binding:jar:0.2.0:provided (i don't know if could be useful)
- org.projectlombok:lombok:jar:1.18.38:compile
- vscode-java 1.44.0
Steps to reproduce it
- Java: Force Java Compilation with Full
- Wait the end
- Errors will report error
When i open the class the issue disappear Maybe it depends from vscode java configuration?!
"java.contentProvider.preferred": "fernflower",
"java.jdt.ls.java.home": "/app/exchange/java/jdk-21",
"java.jdt.ls.vmargs": "-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx2G -Xms1G -Xlog:disable",
"java.codeGeneration.generateComments": true,
"java.codeGeneration.hashCodeEquals.useJava7Objects": true,
"java.compile.nullAnalysis.mode": "disabled",
"java.compile.nullAnalysis.nonnull": [],
"java.compile.nullAnalysis.nullable": [],
"java.configuration.updateBuildConfiguration": "automatic",
"java.debug.settings.onBuildFailureProceed": true,
"java.debug.settings.showQualifiedNames": true,
"java.debug.settings.showStaticVariables": true,
"java.dependency.packagePresentation": "hierarchical",
"java.dependency.showMembers": true,
"java.eclipse.downloadSources": true,
"java.format.settings.profile": "GoogleStyle",
"java.format.settings.url": "https://raw.githubusercontent.com/google/styleguide/gh-pages/eclipse-java-google-style.xml",
"java.maven.downloadSources": true,
PS. the field is initialized with LinkedHashSet
Let me know if you need more information
Does the project build from command-line with no compilation errors ? Does it run either from command-line or in VS Code ? Here's the simple project I created : issue-4040.zip
Would you be able to test that it occurs with that ? I think the only change you'd need to make is set java.jdt.ls.java.home to your JDK 21. Also, on most platforms, vscode-java ships with an embedded JDK 21 for startup, so even if that's not set, it would be the default. I've also tried both the embedded Lombok provided by vscode-java, and the one you defined and it doesn't seem to be that.
With that said, the behaviour that you're seeing, where opening the file makes the error go away is something I've seen before in https://github.com/redhat-developer/vscode-java/issues/1111#issuecomment-1900674260 . In that case, the error was valid. It's a case where a full build reports the error, that is then silenced by just opening the singular file. It's odd that it shows "column 1" for the error. As an example :
correctly emits a diagnostic for a column that makes sense based on where the error is.
Hi @rgrunber In order to answer you, yes I runned the compilation with mvn clean compile from terminal and with vacode java full compilation, both completed successfully without issues. The jvm used is jdk21 requested by extension to works. About your code within image is little bit different because there is ? Between <>, instead on my case I used the inference. In addition the issue don't appear if I remove the annotation @Size within field declaration.
Thanks a lot for your analysis.
Hi @rgrunber i made others tests
- mvn clean compile with 17/21 no errors reported
-
java.jdt.ls.java.home17/21 andForce Java CompilationFull the issues will be appear - i removed
lombokas maven dependency, then runForce Java Compilationthe issues will be appear
About vscode internal jdk, i'm not sure is included in this version, but i'm using this OpenJDK 17/21
@robertonav20 I tested @rgrunber's test project and don't see the issue either, using full build. Do you have the same issue with his sample project? If not could you provide a test project that reproduces this issue?
Hi @fbricon ,
indeed i tested with issue-4040.zip example and the issue didn't appear, maybe it depends on vscode/extensions configuration, i will investigate more.
Thanks for the support
Hi @rgrunber and @fbricon,
i made other tests and it seems the issue is present when @SuperBuilder annotation is used on top of class instead of @Builder indeed i changed with second and the issue disappear.
Have you some idea about this?
@robertonav20 from issue-404.zip, I have no problem with this:
package org.example;
import java.util.LinkedHashSet;
import java.util.Set;
import jakarta.validation.constraints.NotNull;
import jakarta.validation.constraints.Size;
import jakarta.validation.constraints.Pattern;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.experimental.SuperBuilder;
@Data
@SuperBuilder
@AllArgsConstructor
@NoArgsConstructor
public class MyClass {
private int id;
private int name;
@NotNull
@Size(min = 1, message = "MEMBER_CODE_VALIDATION_MESSAGE")
@Builder.Default
private Set<@Size(max = 10) @Pattern(regexp = "NO_SPECIAL_CHARACTERS_REGEX") String> mySet = new LinkedHashSet<>();
}
Can you please add a test case reproducing your issue with SuperBuilder?
Hi @fbricon
yes you are right, on my pc i got the same behaviour, at this time i think is something related to VM configuration in that case i fixed issue with @Builder annotation instead of @SuperBuilder