You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Marko suggested implementing one of the following to get around the issue:
Create a custom optional value extractor
Create a custom "null or not blank" annotation + validator
While either option works, I suppose the main question is: Why does @NotBlank consider null to be invalid? The behavior seems inconsistent to me because @Email and @Pattern are also constraints against CharSequence, but these two consider null to be valid. If a developer wanted an element to be not-nullable, wouldn't it be more appropriate to use @NotNull in conjunction with whatever other constraints needed? (e.g. @NotNull @NotEmpty String)
There's probably some historical reason for this behavior, but I'm not sure if it's documented anywhere. Some insight regarding this issue would be very much appreciated, if this behavior can be changed in future specs or if the solution is to simply roll our own solutions.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi folks, it was suggested that I should create an issue here to start a discussion about the behavior of
@NotBlank
. Relevant issue here:quarkusio/quarkus#41262
tldr is that an empty
Optional<@NotBlank String>
will fail validation, and the reason is because:Optional
value extractor returns null if empty: https://jakarta.ee/specifications/bean-validation/3.0/jakarta-bean-validation-spec-3.0.html#valueextractordefinition-builtinvalueextractors@NotBlank
must have at least 1 non-whitespace character and must not be null, as noted in the javadoc for the annotation: https://jakarta.ee/specifications/bean-validation/3.0/jakarta-bean-validation-spec-3.0.html#builtinconstraints-notblankMarko suggested implementing one of the following to get around the issue:
While either option works, I suppose the main question is: Why does
@NotBlank
consider null to be invalid? The behavior seems inconsistent to me because@Email
and@Pattern
are also constraints againstCharSequence
, but these two consider null to be valid. If a developer wanted an element to be not-nullable, wouldn't it be more appropriate to use@NotNull
in conjunction with whatever other constraints needed? (e.g.@NotNull @NotEmpty String
)There's probably some historical reason for this behavior, but I'm not sure if it's documented anywhere. Some insight regarding this issue would be very much appreciated, if this behavior can be changed in future specs or if the solution is to simply roll our own solutions.
Thanks!
The text was updated successfully, but these errors were encountered: