First milestone release of Jakarta Validation 4.0
Recently, we published the first milestone release of the upcoming Jakarta Validation 4.0. Jakarta Validation 4.0 will be a part of the Jakarta EE 12 platform, to be released later.
What has been done so far?
The 4.0 update of the specification, compared to 3.1, brings the following changes:
-
Easier Custom Constraint Validator Integration: developers of custom constraints can now declare their
ConstraintValidatorimplementations using the Java Service Loader mechanism. This decouples the constraint definition and the constraint validator implementation details. It especially simplifies the process for external libraries to add support for more types to constraints existing in other libraries, including the default, Jakarta Validation ones. -
Optional
validatedByAttribute: ThevalidatedByattribute on thejakarta.validation.Constraintannotation is now optional. It defaults to an empty array, which cleans up the code when you don’t need to specify validators explicitly, for example, when you define your constraint validators through a service loader mechanism. -
Simplified Attribute Retrieval: We’ve introduced a simpler, more direct way to fetch a single attribute from a
ConstraintDescriptor. This reduces the boilerplate type casts. -
Clarified Number Validation for Strings: Both
@Minand@Maxconstraints were already able to validate the string representation of numbers, as the TCK was testing for it. Hence, from now on, it is explicitly mentioned that these constraints are applicable to Strings. This also better matches the behaviour of their decimal counterparts:@DecimalMinand@DecimalMax -
Formal Deprecation of
ConstraintViolationBuilderMethods: Some methods in theConstraintViolationBuilderthat were previously marked as deprecated only in the Javadoc comments are now formally deprecated. This makes it clearer which methods you should avoid using going forward and sets the stage for future removals.
What won’t be getting in?
We were exploring the possibility of relaxing some of the XML schema validation constraints. But with what is currently available in the XSD specification, there is not much we can change, hence this idea is put on hold.
What is yet to come?
There are still a few things to address and some ongoing discussions about potential improvements. In particular:
-
We are planning to make it clear that after Jakarta Validation 4.0 the legacy approach to cascading validation will be removed.
@Valid // (1) List<MyObject> legacyObjects; List<@Valid MyObject> objects; // (2)
-
The legacy approach to applying cascading validation to list elements.
-
The modern approach to applying cascading validation to list elements. Available since Bean Validation 2.0.
Moving forward (e.g. in Jakarta Validation 5), keeping the "legacy" approach in place would result in an attempt to validate the container itself (i.e. the list in this case) instead of validating the container elements.
We encourage users to finally move away from the legacy approach.
-
-
There is also a discussion on providing access to the initialization context within the constraint validator initialization step. Currently,
ConstraintValidator#initialize(..)method only exposes the constraint annotation to theConstraintValidatorimplementer. However, it may be useful for some constraints to obtain more information at this stage. For example, constraints dealing with temporal types may need to get their hand on theClockProvider, or get access to some of the Jakarta Validation provider-specific details.
Jakarta Validation 3.1 specification
Jakarta Validation 3.1 was released earlier in 2024.
What’s new in Bean Validation 3.1?
The 3.1 update of the specification, compared to 3.0, brings the following changes:
-
The minimum required Java version is set to 17.
-
The rename of the specification from Jakarta Bean Validation to Jakarta Validation.
-
The clarification on the record validation.
Jakarta Validation 3.1 will be a part of the Jakarta EE 11 platform, to be released later.
Give it a try
Don’t wait and try out the new release yourself! Just get the Hibernate Validator implementation, read the Getting started section of its reference guide. You also can read the complete specification as well as the API docs.
Bean Validation 2.0 is a spec!
It is done — after one year of hard work, and a bit more than four years after the previous revision, the final release of Bean Validation 2.0 (JSR 380) is out!
Last week, the JSR passed the Final Approval Ballot by the executive committee of the JCP unanimously with 25 "Yes" votes. After the ballot we’ve released version 2.0.0.Final of the specification, the API as well as the TCK. At the same time, the final version of the reference implementation, Hibernate Validator 6, was released, too.
Within the next few days, the final specification will also be available on the JSR 380 page on jcp.org, after which the work on this JSR is complete and the expert group officially will disband.
What’s new in Bean Validation 2.0?
By now, you’ll probably have heard about all the new features added in Bean Validation 2.0. Just in case you haven’t, here’s a quick summary:
-
Support for validating container elements by annotating type arguments of parameterized types, e.g.
List<@Positive Integer> positiveNumbers; this also includes:-
More flexible cascaded validation of collection types; e.g. values and keys of maps can be validated now:
Map<@Valid CustomerType, @Valid Customer> customersByType -
Support for
java.util.Optional -
Support for the property types declared by JavaFX
-
Support for custom container types by plugging in additional value extractors
-
-
Support for the JSR 310 date/time types for
@Pastand@Future; fine-grained control over the current time and time zone used for validation -
New built-in constraints:
@Email,@NotEmpty,@NotBlank,@Positive,@PositiveOrZero,@Negative,@NegativeOrZero,@PastOrPresentand@FutureOrPresent -
All built-in constraints are marked as repeatable
-
Parameter names are retrieved using reflection
-
ConstraintValidator#initialize()is a default method
Bean Validation 2.0 will also be part of the Java EE 8 platform, to be released later this summer.
To learn more about all the new features in Bean Validation 2.0, check out this presentation which I recently gave at the jdk.io conference.
Thank you!
I’d like to shout out a huge "Thank you" to everyone helping with the work on Bean Validation 2.0:
-
The fantastic JSR 380 expert group (thanks to Christian, Hendrik, Marco, Otavio and everyone else for their great input, proposals and much more) as well as the BV community at large (thanks to Hardy, Matt and everyone else for making themselves heard and providing feedback)
-
The former spec lead Emmanuel for his continued support with everything JCP-related and going through the details of container element validation again and again
-
My dear fellow Guillaume for his tireless work on the TCK, the reference implementation, the website and the spec; merci beaucoup!
-
Marko Bekhta who stepped up to work on the TCK which has been a very much appreciated contribution
-
Everyone participating in our polls and surveys; your replies and comments helped very much to arrive on good decisions on the different options on the table
-
The friendly folks of Oracle’s GlassFish team for all their work on integrating Bean Validation 2.0 into the Java EE 8 reference implementation
It has been a true pleasure and honor for me to make the new spec a reality together with such a fantastic community!
Give it a try
Don’t wait and try out the new release yourself! Just download the reference implementation Hibernate Validator and read the Getting started section of its reference guide. You also can read the complete specification as well as the API docs.
Bean Validation 2.0 CR 3 released and submitted to Final Approval Ballot
It’s my great pleasure to announce the CR 3 release of the Bean Validation 2.0 spec!
This release of the spec and the API as well as accompanying releases of the TCK and the reference implementation (release announcement) have been handed over to the JCP for the Final Approval Ballot last night. It’s this ballot where the Executive Committee of the JCP will cast its final go/no-go vote on the Bean Validation 2.0 JSR.
Since the CR 2 release, only a few things have changed after reviewing the spec changes one more time:
-
Clarifying the semantics of
ConstraintViolation#getLeafBean()in case a container element constraint is violated (BVAL-690) -
Making the order of the
<container-element-type>and<constraint>elements consistent in the schema for XML constraint mapping files (BVAL-693) -
Minor wording and JavaDoc improvements (BVAL-692)
The updated spec document can be found here. To see the changes applied since the CR 2, check out this colored diff. If you’d like to see all the changes since Bean Validation 1.1, take a look at this diff. The updated API is available on Maven Central, using the GAV coordinates are javax.validation:validation-api:2.0.0.CR3.
Some TCK stats
Thanks to Guillaume’s tireless work, the Bean Validation TCK has grown substantially since 1.1. There are now 685 assertions overall, out of which 627 are testable. 99.04% of them are covered by 2133 tests overall. The added tests cover all the new Bean Validation 2.0 features, so we feel very confident that the TCK ensures correctness of implementations passing it.
Also the tooling for producing the TCK has been improved significantly: sentences or phrases of the spec document can be marked as relevant for the TCK with the help of AsciiDoc roles. A special Maven plug-in then is used to generate a report of all those marked assertions, allowing to link them to tests of the TCK and making it easy to identify assertions without corresponding tests yet.
We’ll discuss the entire TCK tool chain in more depth in a separate blog post. If you are interested in the TCK and would like to learn more about its development, the appeals process and other related things, check out the TCK reference guide.
What’s new in Bean Validation 2.0?
The focus of Bean Validation 2.0 is supporting and taking advantage of Java SE 8.
For instance type annotations are used to validate the elements of generic containers: List<@NotNull @Email String> emails.
There are new built-in constraints (@NotBlank, @NotEmpty, @Email, @FutureOrPresent, @PastOrPresent, @Positive, @PositiveOrZero, @Negative and @NegativeOrZero) and all built-in constraints are repeatable annotations now.
Bean Validation 2.0 also supports the new Java 8 date and time types (JSR 310), the property types defined by JavaFX (StringProperty etc.) as well as java.util.Optional.
To learn more about all the new features in Bean Validation 2.0, check out this presentation which I recently gave at the jdk.io conference.
What can you do to help?
With the submission of the specification to the JCP for the Final Approval Ballot, the work on Bean Validation 2.0 is done more or less. If you’d like to help, reviewing the specification changes would be the best thing to do at this point. You also could try out the reference implementation Hibernate Validator in your applications and let us know how it works.
Also tell us about ideas and wishes for a future 2.1 release of the spec. We are eager to learn about your requirements, so we can explore any new features in the reference implementation.
To post your feedback, just add a comment below, send a message to our mailing list or post in the Bean Validation forum. If you find a bug or have a specific feature request, please raise it in the issue tracker.
Everything in Bean Validation is open source, so you also can send in actual patches: be it to the API, the spec document, the TCK or the reference implementation. If you are interested, you can find out all the details to get started in the contribution guide.
Bean Validation 2.0 CR 2 released
I’m very happy to announce the CR 2 release of the Bean Validation 2.0 spec!
The CR 2 is an update to the Proposed Final Draft (CR 1), addressing remarks and comments from reviewing all the changes. The updated spec document can be found here. To see the changes applied since the CR 1, check out this colored diff. If you’d like to see all the changes since Bean Validation 1.1, take a look at this diff. The updated API is available on Maven Central, using the GAV coordinates are javax.validation:validation-api:2.0.0.CR2.
What’s new since CR 1?
Given we are in the CR phase, most of the changes of this release naturally fall into the category of bug fixes, wording clarifications, formatting and other similar improvements. Reviewing the work done so far, and also working on the reference implementation and the TCK, we’ve decided to include two improvements to the API, too:
-
ConstraintDescriptor#validateUnwrappedValue()got renamed intogetValueUnwrapping()(BVAL-674). The original method name sounded like a "command", whereas the new name makes clear it’s a "query" kind of method; also the members of the returned enum have been adapted to be in sync with the correspondingUnwrappingpayload type names. We’ve also added a methodConstraintDescriptor#unwrap(Class), which will let providers expose additional functionality via extension interfaces, e.g. to explore new features which then can be standardized in a future spec revision. -
@ConvertGroup#from()has a default value ofDefault.classnow (BVAL-689). This simplifies group conversions in the common case where the default group is converted into another group.
Another interesting change is BVAL-613:
when using the reference API JAR with the Java 9 module system, it will have the module name "java.validation" (following the recommendation in the spec appendix).
This is done using the Automatic-Module-Name manifest header defined by Java 9.
Other changes include JavaDoc improvements and more clearly separating API types from examples in the spec. The complete list of all issues resolved for the CR 2 release can be found in the BVAL JIRA project. Corresponding releases of our reference implementation Hibernate Validator 6 and the TCK are also done today.
What’s new in Bean Validation 2.0?
The focus of Bean Validation 2.0 is supporting and taking advantage of Java SE 8.
For instance type annotations are used to validate the elements of generic containers: List<@NotNull @Email String> emails.
There are new built-in constraints (@NotBlank, @NotEmpty, @Email, @FutureOrPresent, @PastOrPresent, @Positive, @PositiveOrZero, @Negative and @NegativeOrZero) and all built-in constraints are repeatable annotations now.
Bean Validation 2.0 also supports the new Java 8 date and time types (JSR 310), the property types defined by JavaFX (StringProperty etc.) as well as java.util.Optional.
To learn more about all the new features in Bean Validation 2.0, check out this presentation which I recently gave at the jdk.io conference.
What can you do to help?
We’ll hand over the specification to the JCP for the Final Approval Ballot early next week. For the FAB release, we don’t expect any significant changes over today’s CR 2. If you’d like to help, reviewing the specification changes would be the best thing to do at this point. Also it’d be of great help if you tried out the reference implementation in your applications and let us know how it works. Any feedback is welcomed!
To post your feedback, just add a comment below, send a message to our mailing list or post in the Bean Validation forum. If you find a bug or have a specific feature request, please raise it in the issue tracker.
Everything in Bean Validation is open source, so you also can send in actual patches: be it to the API, the spec document, the TCK or the reference implementation. If you are interested, you can find out all the details to get started in the contribution guide.
Latest news
Stay up to date, subscribe to the news feed.