Bean Validation 2.0 Early Draft 1 is Out
I’m very happy to announce the first Early Draft Review of JSR 380, Bean Validation 2.0!
This Early Draft comprises all the spec changes done so far and it’s a great opportunity for us to get feedback from the community at large. You can read the spec draft either directly on this website or download it from jcp.org. A GitHub diff showing all the changes to the spec’s AsciiDoc document done so far (sans some typo and style fixes) is available here.
The updated API can be downloaded from from jcp.org or fetched from Maven Central using the coordinates javax.validation:validation-api:2.0.0.Alpha1.
What’s New?
The main theme of Bean Validation 2.0 is support for and taking advantage of Java 8. This concerns new language features such as type use annotations as well as library additions.
An example of the latter is the support for the new Java 8 date and time API (JSR 310).
You can now use @Past and @Future on javax.time types such as Instant, LocalDate etc.:
@Future
private LocalDate deliveryDate;For types that don’t represent a specific instant but rather an interval of time,
you can configure that the current month, year etc. should be considered valid, too,
using the new attribute orPresent():
@Past(orPresent=true)
private final Year inceptionYear = Year.of( 2017 );An example where Bean Validation benefits from new language features in Java 8
is the new mechanism for validating the elements of Collection, Optional and other container types.
By annotating type arguments of generic types you can now put constraints to the container elements
(as opposed to the container itself):
List<@NotNull @Email String> emails;Also cascaded validation (@Valid) gets more powerful with that.
E.g. you can now perform a cascaded validation of map keys and map values (only values were supported before):
Map<@Valid Customer, @Valid Address> primaryAddressByCustomer;Another use case for this is validation of values wrapped in a java.util.Optional:
Optional<@Past LocalDate> getRegistrationDate();We’ve baked in support for type argument constraints on types such as Iterable, Map, Optional and some more,
but this isn’t a fixed list.
You can plug in custom implementations of the ValueExtractor contract
which will allow you to put type argument constraints to other collection types (e.g. Google Guava’s Multimap)
or even collection classes from other JVM languages such as Ceylon.
What else?
Support for JSR 310 and type argument constraints are just two of the new features. Some other changes are:
-
All constraints and a few other Bean Validation annotations are repeatable
-
Method parameter names to be shown in error messages are obtained using reflection (if enabled)
-
ConstraintValidator#initialize()is a default method, simplifying the implementation of constraint validators which don’t need to access the annotation state -
ValidatorFactoryextendsAutoCloseable, allowing to use it intry-with-resourcesblocks
To learn more about the changes we’ve done so far, either check out our progress report from a few weeks ago or the specification document itself.
What’s next?
The next step will be to bring the Bean Validation reference implementation, Hibernate Validator, up to par with the Early Draft 1. Most of the work for this has been done already, so you can expect the first Alpha release of Hibernate Validator 6 later this week. This will allow you to play around with all the new features and explore them in more depth.
This release will add some features on top of what is in spec so far, e.g. support for defining constraints using Lambda expressions. We felt it’d be good to gain some experience with this and some other features by putting an implementation into the hands of users before adding them to the spec. More details on that once the reference implementation is out.
In terms of spec changes, some of the next features we are planning to work on are:
-
Adding some new constraints as per our recent survey, e.g.
@Email,@NotEmpty,@NotBlank -
Ability to validate an object and a list of changes (BVAL-214) which would be useful for validating class-level constraints in UI use cases
-
Separating the message interpolation algorithm from the retrieval of messages from resource bundles (BVAL-217)
What can you do to help?
Glad you asked :)
As in its previous versions, Bean Validation 2.0 is developed fully in the open. So we count on your feedback on the Early Draft as well as any other ideas or suggestions you may have around Bean Validation. One area where we are looking for feedback specifically is the proposal for container value validation. There is a list of open questions towards the end of that section. If you have thoughts on any of those, please let us know.
To get a discussion started, just post 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 them in the issue tracker.
And as Bean Validation is a true open source project, contributing e.g. in form of patches is easy, too. Check out the contribution guide to learn more.
Finally, let me say a big thank you to everyone involved with making the Early Draft happen; your work is much appreciated!
Bean Validation 1.1 is a spec
It's now official, these couple of years of work have made it into an official JCP specification. Bean Validation is also part of Java EE 7 which has been approved too a few of days ago.
We have already discussed the features at great length here but to do a short summary:
- support for method and constructor validation (via CDI, JAX-RS etc)
- integration with CDI (
ValidatorandValidatorFactoryinjectable,ConstraintValidatorinstances being CDI beans and thus accept@Inject, etc) - EL expressions based error messages
- group conversion in object graphs
I would like to thank the expert group and the community at large (without your input there would be no 1.1), Hardy and Gunnar that worked round to clock on the spec, the RI and the TCK and deliver everything on time, Pete for being my springboard when all hell broke lose and the folks at Oracle who worked with us to integrate Bean Validation with the rest of the Java EE ecosystem whether it be spec, implementation or TCK.
Go grab Hibernate Validator, the RI. The team has even spent an extra couple of weeks to deliver a nice documentation. And if you can't sleep, go read the specification itself.
Bean Validation 1.1 CR3 - Final Approval Ballot
Bean Validation, Hibernate Validator (its Reference Implementation) and the Test Compatibility Kit have been handed over to the JCP for what is called the Final Approval Ballot. That's when the expert committee votes for the go / no-go of the specification going final as it is.
We have found a few glitches when working on both the RI and the TCK in the
last month but everything is in order now. The biggest visible change for you
is that we renamed @ValidateExecutable into @ValidateOnExecution and we added a
way to disable method validation entirely via the XML deployment descriptor.
We worked hard to make a stellar TCK. Let's speak numbers: the specification has 549 assertions including 492 testable. We cover 98,8% of them with 1500 tests. Good luck to all future Bean Validation 1.1 implementors :)
Everything is already available for you to use:
Enjoy!
Bean Validation 1.1 CR1 - Proposed Final Draft
Our Proposed Final Draft has been officially handed over to the JCP last night.
After a frantic month of work culminating with two weeks of monomaniac focus, we are finally handing over the Bean Validation 1.1 Proposed Final Draft to the JCP. Of course everything is open source so you can get it too:
- the spec
- the JavaDoc
- and the API JAR: maven coordinates javax.validation:validation-api:1.1.0.CR1
What's new in Bean Validation 1.1?
The specification highlights very well the main features of this version but to summarize them:
- work done entirely in the open
- support for dependency injection and better integration with CDI
- support for method and constructor validation
- support for group conversion when cascading
- support for EL based message interpolation
What's different between Beta 4 and CR 1?
We did a lot of polishing and nailed a lot of remaining corner cases. Here is a few of the tasks we worked on:
- rework of the JavaDoc
- move to
@SupportValidationTargetonConstraintValidatorinstead of the additional@CrossParameterConstrainton the constraint to mark a constraint as cross-parameter - many more examples in the specification
- improve node creation logic when nodes are added programmatically
- improve the creation logic of custom nodes when using the programmatic API of
ConstraintViolationBuilderin aConstraintValidator
And of course many hours rereading the specification to find holes and fix them.
Review
Hibernate Validator 5.0.0.CR1 and the TCK should be here any minute. Help us make this spec as good as possible by reviewing it and opening issues where it itches you.
You can access the specification here. All changes are marked with a different color. Green for additions, yellow for changes. This will help you see what has changed precisely.
Please send us your remarks and comments:
- on our mailing list
- in our issue tracker
- or on the Bean Validation forum
Many many thanks to my partners in crime Hardy and Gunnar that worked around the clock with me to deliver this proposed final draft right on time but with no compromise on quality.
Bean Validation 1.1 Beta 4 - issue smashing edition
Our proposed final draft is due soon but we did one last drop of the specification and the API jar. We worked all over the board (and the clock) but the most notable improvements are:
Improvements on the CDI integration section
We made it much more descriptive of the expected behavior instead of imposing an implementation pattern. We have also added the method and constructor interception priority as defined in the Java EE specification and the interceptor specification in particular.
Thanks Pete for your help.
Remove the link between the Node API and the metadata API
This is something we could not make work, so we fall back into a more redundant but we think cleaner design. We also made the node builder API easier to use despite the increased number of node types.
//Cross-parameter constraint on a method
//mergeAddresses(Map<String,Address> addresses, Map<String,Address> otherAddresses)
//Build a constraint violation on the default path + "otherAddresses["home"]
//ie. the Address bean hosted in the "home" key of the "otherAddresses" map parameter
context.buildConstraintViolationWithTemplate(
"Map entry home present in both and does not match")
.addParameterNode(1)
.addBeanNode()
.inIterable().atKey("home")
.addConstraintViolation();
Clarification around method validation (metadata, cross-parameter, reports)
We now have an explicit cross-parameter concept materialized in the metadata
API. It makes for a more regular and easier to browse API.
ConstraintViolation has also seen some improvements and adaptations to make
it ready for prime - method validation - time.
Mark a method as (non) validated
We slightly improved @ValidateExecutable to be more friendly when
put on a specific method. To force a getter to be validated or to
force a method to not be validated is now more readable.
public class Operations {
@ValidateExecutable
@Status
public String getStatus() { ... }
@ValidateExecutable(ExecutableType.NONE)
public void apply(@Valid Operation operation) { ... }
}
Review
Let us know what you think.
You can access the specification here. All changes are marked with a different color. Green for additions, yellow for changes and struck through red for removals . This will help you see what has changed precisely.
Please send us your remarks and comments:
- on our mailing list
- in our issue tracker
- or on the Bean Validation forum
If you want to go to the next step and contribute, send us an email to the mailing list and read how to contribute.
Latest news
Stay up to date, subscribe to the news feed.