Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty Optional<@NotBlank String> fails validation #222

Open
krnhotwings opened this issue Jul 18, 2024 · 0 comments
Open

Empty Optional<@NotBlank String> fails validation #222

krnhotwings opened this issue Jul 18, 2024 · 0 comments

Comments

@krnhotwings
Copy link

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:

  1. The Optional value extractor returns null if empty: https://jakarta.ee/specifications/bean-validation/3.0/jakarta-bean-validation-spec-3.0.html#valueextractordefinition-builtinvalueextractors
  2. @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-notblank

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant