http://beanvalidation.org/Jakarta Bean Validation2023-11-03T14:56:33+00:00http://beanvalidation.org/news/2018/02/26/bean-validation-2-0-whats-in-it/Bean Validation 2.0 - What’s in it?2023-11-03T14:56:33+00:002018-02-26T00:00:00+00:00Gunnar Morling
While a couple of months have passed since Bean Validation 2.0 got released, the info about what’s new in the spec may still not yet have reached everyone.
Here are two presentations which I wanted to share in order to help with that.
The first one is the slide set of the talk on Bean Validation 2.0 and JSR 380 which I did at JavaOne 2017:
You can also download a PDF with these slides from Speaker Deck here.
While the JavaOne session was not recorded, my quickie session on the same topic at Devoxx 2017 luckily was.
In just 14:17 min you’ll get an...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>While a couple of months have passed since <a href="http://beanvalidation.org/news/2017/08/07/bean-validation-2-0-is-a-spec/">Bean Validation 2.0 got released</a>, the info about what’s new in the spec may still not yet have reached everyone.
Here are two presentations which I wanted to share in order to help with that.</p>
</div>
<div class="paragraph">
<p>The first one is the slide set of the talk on Bean Validation 2.0 and JSR 380 which I did at <a href="https://events.rainfocus.com/catalog/oracle/oow17/catalogjavaone17?search=%22keeping%20your%20data%20sane%20with%20bean%20validation%202.0%22&showEnrolled=false">JavaOne 2017</a>:</p>
</div>
<br />
<div style="text-align-center">
<script async="" class="speakerdeck-embed" data-id="e3ad48be0eee487a8f1e1eac4d55ca18" data-ratio="1.37081659973226" src="//speakerdeck.com/assets/embed.js" />
</div>
<br />
<div class="paragraph">
<p>You can also download a PDF with these slides from Speaker Deck <a href="https://speakerdeck.com/gunnarmorling/keeping-your-data-sane-with-bean-validation-2-dot-3">here</a>.</p>
</div>
<div class="paragraph">
<p>While the JavaOne session was not recorded, my <a href="https://cfp.devoxx.be/2017/talk/TKL-4941/Bean_Validation_2.0_-_you%E2%80%99ve_put_your_annotations_everywhere!">quickie session</a> on the same topic at Devoxx 2017 luckily was.
In just 14:17 min you’ll get an overview on the new spec revision.
It’s lots of contents for the short amount of time, but you can pause and rewind as often as you like ;)</p>
</div>
<br />
<div class="responsive-video">
<iframe width="1600" height="900" src="https://www.youtube.com/embed/GdKuxmtA65I?rel=0" frameborder="0" allowfullscreen="" />
</div>
<br />
</div>
</div>
<div class="sect1">
<h2 id="feedback"><a class="anchor" href="#feedback" />Feedback</h2>
<div class="sectionbody">
<div class="paragraph">
<p>You got feedback on these presentations or just have a general question around Bean Validation?
Then let us know by adding a comment below or sending a message to the <a href="mailto:bean-validation-dev@eclipse.org">Bean Validation mailing list</a>.</p>
</div>
<div class="paragraph">
<p>While at the moment no work on the spec itself is going on, we’re eager to explore new features in the <a href="http://hibernate.org/validator/">reference implementation</a>.
So if there’s something which you think should be added in a future spec revision,
it’s the perfect time to get in touch so we can begin to experiment with these things.</p>
</div>
<div class="paragraph">
<p>Your feature requests (and pull requests) will be highly welcomed!</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/10/19/new-website/Bean Validation has a new website!2023-11-03T14:56:33+00:002017-10-19T00:00:00+00:00Guillaume Smet
Bean Validation just got a new website and we hope you will like it!
New layout
We developed a more modern layout based on Semantic UI.
It should be easier to the eye and more readable too.
The logo, contributed by Hendrik Ebbers for Bean Validation 2.0, is now in good place.
New organization
In the old website, the information about a given version of the spec was spread over multiple pages. It was hard for the user to get an overview of a given version and it was also hard for us to work on new versions of the spec.
We changed the website organization to...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>Bean Validation just got a new website and we hope you will like it!</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="new-layout"><a class="anchor" href="#new-layout" />New layout</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We developed a more modern layout based on <a href="https://semantic-ui.com/">Semantic UI</a>.</p>
</div>
<div class="paragraph">
<p>It should be easier to the eye and more readable too.</p>
</div>
<div class="paragraph">
<p>The logo, contributed by Hendrik Ebbers for Bean Validation 2.0, is now in good place.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="new-organization"><a class="anchor" href="#new-organization" />New organization</h2>
<div class="sectionbody">
<div class="paragraph">
<p>In the old website, the information about a given version of the spec was spread over multiple pages. It was hard for the user to get an overview of a given version and it was also hard for us to work on new versions of the spec.</p>
</div>
<div class="paragraph">
<p>We changed the website organization to centralize all the information of a spec release on one page.</p>
</div>
<div class="paragraph">
<p>See for instance:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a href="http://beanvalidation.org/2.0/">The Bean Validation 2.0 landing page</a></p>
</li>
<li>
<p><a href="http://beanvalidation.org/1.1/">The Bean Validation 1.1 landing page</a></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The main changes, the TCK and the certified implementations are all accessible from these landing pages.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="a-bright-future"><a class="anchor" href="#a-bright-future" />A bright future</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The last version of the spec has a prominent link in the menu and you can find the old versions of the spec in the archives.</p>
</div>
<div class="paragraph">
<p>Presenting a new version of the spec should be easier than ever. That was our ultimate goal.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="feedback"><a class="anchor" href="#feedback" />Feedback</h2>
<div class="sectionbody">
<div class="paragraph">
<p>As usual, if you have some feedback or if you find an issue in the new website, either add a comment just below or post something on the <a href="mailto:bean-validation-dev@eclipse.org">Bean Validation mailing list</a>.</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/08/07/bean-validation-2-0-is-a-spec/Bean Validation 2.0 is a spec!2023-11-03T14:56:33+00:002017-08-07T00:00:00+00:00Gunnar Morling
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,...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>It is done — after <a href="http://beanvalidation.org/news/2016/07/15/bean-validation-2-0-is-coming/">one year</a> of hard work, and a bit more than <a href="http://beanvalidation.org/news/2013/05/02/bean-validation-1-1-is-a-spec/">four years</a> after the previous revision,
the final release of Bean Validation 2.0 (<a href="https://www.jcp.org/en/jsr/detail?id=380">JSR 380</a>) is out!</p>
</div>
<div class="paragraph">
<p>Last week, the JSR <a href="https://jcp.org/en/jsr/results?id=6033">passed the Final Approval Ballot</a> 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 <a href="http://in.relation.to/2017/08/07/and-here-comes-hibernate-validator-60/">final version</a> of the reference implementation, Hibernate Validator 6, was released, too.</p>
</div>
<div class="paragraph">
<p>Within the next few days, the final specification will also be available on the <a href="https://jcp.org/en/jsr/detail?id=380">JSR 380 page</a> on jcp.org, after which the work on this JSR is complete and the expert group officially will disband.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new-in-bean-validation-2-0"><a class="anchor" href="#whats-new-in-bean-validation-2-0" />What’s new in Bean Validation 2.0?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Support for validating container elements by annotating type arguments of parameterized types, e.g. <code>List<@Positive Integer> positiveNumbers</code>; this also includes:</p>
<div class="ulist">
<ul>
<li>
<p>More flexible cascaded validation of collection types; e.g. values <em>and</em> keys of maps can be validated now: <code>Map<@Valid CustomerType, @Valid Customer> customersByType</code></p>
</li>
<li>
<p>Support for <code>java.util.Optional</code></p>
</li>
<li>
<p>Support for the property types declared by JavaFX</p>
</li>
<li>
<p>Support for custom container types by plugging in additional value extractors</p>
</li>
</ul>
</div>
</li>
<li>
<p>Support for the JSR 310 date/time types for <code>@Past</code> and <code>@Future</code>;
fine-grained control over the current time and time zone used for validation</p>
</li>
<li>
<p>New built-in constraints: <code>@Email</code>, <code>@NotEmpty</code>, <code>@NotBlank</code>, <code>@Positive</code>, <code>@PositiveOrZero</code>, <code>@Negative</code>, <code>@NegativeOrZero</code>, <code>@PastOrPresent</code> and <code>@FutureOrPresent</code></p>
</li>
<li>
<p>All built-in constraints are marked as repeatable</p>
</li>
<li>
<p>Parameter names are retrieved using reflection</p>
</li>
<li>
<p><code>ConstraintValidator#initialize()</code> is a default method</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Bean Validation 2.0 will also be part of the <a href="https://www.jcp.org/en/jsr/detail?id=366">Java EE 8 platform</a>, to be released later this summer.</p>
</div>
<div class="paragraph">
<p>To learn more about all the new features in Bean Validation 2.0,
check out <a href="https://speakerdeck.com/gunnarmorling/keeping-your-data-sane-with-bean-validation-2-dot-0-jdk-dot-io">this presentation</a> which I recently gave at the jdk.io conference.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="thank-you"><a class="anchor" href="#thank-you" />Thank you!</h2>
<div class="sectionbody">
<div class="paragraph">
<p>I’d like to shout out a huge "Thank you" to everyone helping with the work on Bean Validation 2.0:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>The fantastic <strong>JSR 380 expert group</strong> (thanks to Christian, Hendrik, Marco, Otavio and everyone else for their great input, proposals and much more) as well as the <strong>BV community at large</strong> (thanks to Hardy, Matt and everyone else for making themselves heard and providing feedback)</p>
</li>
<li>
<p>The former spec lead <strong>Emmanuel</strong> for his continued support with everything JCP-related and going through the details of container element validation again and again</p>
</li>
<li>
<p>My dear fellow <strong>Guillaume</strong> for his tireless work on the TCK, the reference implementation, the website and the spec; merci beaucoup!</p>
</li>
<li>
<p><strong>Marko Bekhta</strong> who stepped up to work on the TCK which has been a very much appreciated contribution</p>
</li>
<li>
<p><strong>Everyone participating</strong> in our polls and surveys; your replies and comments helped very much to arrive on good decisions on the different options on the table</p>
</li>
<li>
<p>The friendly folks of Oracle’s <strong>GlassFish team</strong> for all their work on integrating Bean Validation 2.0 into the Java EE 8 reference implementation</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>It has been a true pleasure and honor for me to make the new spec a reality together with such a fantastic community!</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="give-it-a-try"><a class="anchor" href="#give-it-a-try" />Give it a try</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Don’t wait and try out the new release yourself!
Just <a href="http://hibernate.org/validator/downloads/">download</a> the reference implementation Hibernate Validator and read the <a href="http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#validator-gettingstarted">Getting started</a> section of its reference guide.
You also can read the <a href="http://beanvalidation.org/2.0/spec/">complete specification</a> as well as the <a href="http://docs.jboss.org/hibernate/beanvalidation/spec/2.0/api/">API docs</a>.</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/07/12/bean-validation-2-0-cr3-submitted-to-final-approval-ballot/Bean Validation 2.0 CR 3 released and submitted to Final Approval Ballot2023-11-03T14:56:33+00:002017-07-12T00:00:00+00:00Gunnar Morling
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...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>It’s my great pleasure to announce the CR 3 release of the Bean Validation 2.0 spec!</p>
</div>
<div class="paragraph">
<p>This release of the spec and the API as well as accompanying releases of the TCK and the reference implementation (<a href="http://in.relation.to/2017/07/11/hibernate-validator-600-cr3-out/">release announcement</a>) 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.</p>
</div>
<div class="paragraph">
<p>Since the CR 2 release, only a few things have changed after reviewing the spec changes one more time:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Clarifying the semantics of <code>ConstraintViolation#getLeafBean()</code> in case a container element constraint is violated (<a href="https://hibernate.atlassian.net/browse/BVAL-690">BVAL-690</a>)</p>
</li>
<li>
<p>Making the order of the <code><container-element-type></code> and <code><constraint></code> elements consistent in the schema for XML constraint mapping files (<a href="https://hibernate.atlassian.net/browse/BVAL-693">BVAL-693</a>)</p>
</li>
<li>
<p>Minor wording and JavaDoc improvements (<a href="https://hibernate.atlassian.net/browse/BVAL-692">BVAL-692</a>)</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The updated spec document can be found <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr3/">here</a>.
To see the changes applied since the CR 2, check out this <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr3/diff/diff-to-2.0-cr2/">colored diff</a>. If you’d like to see all the changes since Bean Validation 1.1, take a look at <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr3/diff/diff-to-1.1/">this diff</a>.
The updated API is available on Maven Central, using the GAV coordinates are <em>javax.validation:validation-api:2.0.0.CR3</em>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="some-tck-stats"><a class="anchor" href="#some-tck-stats" />Some TCK stats</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Thanks to Guillaume’s tireless work, the Bean Validation TCK has grown substantially since 1.1.
There are now <strong>685</strong> assertions overall, out of which <strong>627</strong> are testable. <strong>99.04%</strong> of them are covered by <strong>2133</strong> 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.</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>
<div class="paragraph">
<p>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 <a href="http://docs.jboss.org/hibernate/beanvalidation/tck/2.0/reference/html_single/">TCK reference guide</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new-in-bean-validation-2-0"><a class="anchor" href="#whats-new-in-bean-validation-2-0" />What’s new in Bean Validation 2.0?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The focus of Bean Validation 2.0 is supporting and taking advantage of Java SE 8.</p>
</div>
<div class="paragraph">
<p>For instance type annotations are used to validate the elements of generic containers: <code>List<@NotNull @Email String> emails</code>.
There are new built-in constraints (<code>@NotBlank</code>, <code>@NotEmpty</code>, <code>@Email</code>, <code>@FutureOrPresent</code>, <code>@PastOrPresent</code>, <code>@Positive</code>, <code>@PositiveOrZero</code>, <code>@Negative</code> and <code>@NegativeOrZero</code>) 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 (<code>StringProperty</code> etc.) as well as <code>java.util.Optional</code>.</p>
</div>
<div class="paragraph">
<p>To learn more about all the new features in Bean Validation 2.0,
check out <a href="https://speakerdeck.com/gunnarmorling/keeping-your-data-sane-with-bean-validation-2-dot-0-jdk-dot-io">this presentation</a> which I recently gave at the jdk.io conference.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-can-you-do-to-help"><a class="anchor" href="#what-can-you-do-to-help" />What can you do to help?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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 <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr3/diff/diff-to-1.1/">specification changes</a> 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.</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>
<div class="paragraph">
<p>To post your feedback, just add a comment below, send a message to our <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/">mailing list</a> or post in the <a href="https://discourse.hibernate.org/c/bean-validation">Bean Validation forum</a>.
If you find a bug or have a specific feature request, please raise it in the <a href="https://hibernate.atlassian.net/projects/BVAL/summary">issue tracker</a>.</p>
</div>
<div class="paragraph">
<p>Everything in Bean Validation is open source, so you also can send in actual patches: be it to the <a href="https://github.com/beanvalidation/beanvalidation-api">API</a>, the <a href="https://github.com/beanvalidation/beanvalidation-spec">spec document</a>, the <a href="https://github.com/beanvalidation/beanvalidation-tck">TCK</a> or the <a href="https://github.com/hibernate/hibernate-validator">reference implementation</a>.
If you are interested, you can find out all the details to get started in the <a href="http://beanvalidation.org/contribute">contribution guide</a>.</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/07/05/bean-validation-2-0-cr2-is-out/Bean Validation 2.0 CR 2 released2023-11-03T14:56:33+00:002017-07-05T00:00:00+00:00Gunnar Morling
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...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>I’m very happy to announce the CR 2 release of the Bean Validation 2.0 spec!</p>
</div>
<div class="paragraph">
<p>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 <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr2/">here</a>.
To see the changes applied since the CR 1, check out this <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr2/diff/diff-to-2.0-cr1/">colored diff</a>. If you’d like to see all the changes since Bean Validation 1.1, take a look at <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr2/diff/diff-to-1.1/">this diff</a>.
The updated API is available on Maven Central, using the GAV coordinates are <em>javax.validation:validation-api:2.0.0.CR2</em>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new-since-cr-1"><a class="anchor" href="#whats-new-since-cr-1" />What’s new since CR 1?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>ConstraintDescriptor#validateUnwrappedValue()</code> got renamed into <code>getValueUnwrapping()</code> (<a href="https://hibernate.atlassian.net/browse/BVAL-674">BVAL-674</a>).
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 corresponding <code>Unwrapping</code> payload type names.
We’ve also added a method <code>ConstraintDescriptor#unwrap(Class)</code>, 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.</p>
</li>
<li>
<p><code>@ConvertGroup#from()</code> has a default value of <code>Default.class</code> now (<a href="https://hibernate.atlassian.net/browse/BVAL-689">BVAL-689</a>).
This simplifies group conversions in the common case where the default group is converted into another group.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Another interesting change is <a href="https://hibernate.atlassian.net/browse/BVAL-613">BVAL-613</a>:
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 <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr2/#appendix-module-name">spec appendix</a>).
This is done using the <code>Automatic-Module-Name</code> manifest header defined by Java 9.</p>
</div>
<div class="paragraph">
<p>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 <a href="https://hibernate.atlassian.net/issues/?jql=project%20%3D%20BVAL%20AND%20fixVersion%20%3D%202.0.0.CR2">BVAL JIRA project</a>.
Corresponding releases of our reference implementation Hibernate Validator 6 and the TCK are also done today.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new-in-bean-validation-2-0"><a class="anchor" href="#whats-new-in-bean-validation-2-0" />What’s new in Bean Validation 2.0?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The focus of Bean Validation 2.0 is supporting and taking advantage of Java SE 8.</p>
</div>
<div class="paragraph">
<p>For instance type annotations are used to validate the elements of generic containers: <code>List<@NotNull @Email String> emails</code>.
There are new built-in constraints (<code>@NotBlank</code>, <code>@NotEmpty</code>, <code>@Email</code>, <code>@FutureOrPresent</code>, <code>@PastOrPresent</code>, <code>@Positive</code>, <code>@PositiveOrZero</code>, <code>@Negative</code> and <code>@NegativeOrZero</code>) 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 (<code>StringProperty</code> etc.) as well as <code>java.util.Optional</code>.</p>
</div>
<div class="paragraph">
<p>To learn more about all the new features in Bean Validation 2.0,
check out <a href="https://speakerdeck.com/gunnarmorling/keeping-your-data-sane-with-bean-validation-2-dot-0-jdk-dot-io">this presentation</a> which I recently gave at the jdk.io conference.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-can-you-do-to-help"><a class="anchor" href="#what-can-you-do-to-help" />What can you do to help?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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 <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr2/diff/diff-to-1.1/">specification changes</a> 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!</p>
</div>
<div class="paragraph">
<p>To post your feedback, just add a comment below, send a message to our <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/">mailing list</a> or post in the <a href="https://discourse.hibernate.org/c/bean-validation">Bean Validation forum</a>.
If you find a bug or have a specific feature request, please raise it in the <a href="https://hibernate.atlassian.net/projects/BVAL/summary">issue tracker</a>.</p>
</div>
<div class="paragraph">
<p>Everything in Bean Validation is open source, so you also can send in actual patches: be it to the <a href="https://github.com/beanvalidation/beanvalidation-api">API</a>, the <a href="https://github.com/beanvalidation/beanvalidation-spec">spec document</a>, the <a href="https://github.com/beanvalidation/beanvalidation-tck">TCK</a> or the <a href="https://github.com/hibernate/hibernate-validator">reference implementation</a>.
If you are interested, you can find out all the details to get started in the <a href="http://beanvalidation.org/contribute">contribution guide</a>.</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/06/26/bean-validation-2-0-proposed-final-draft-released/Proposed Final Draft of Bean Validation 2.0 released2023-11-03T14:56:33+00:002017-06-26T00:00:00+00:00Gunnar Morling
I’m very happy to announce that Bean Validation 2.0 has published its Proposed Final Draft (CR 1)!
You can find the PFD right here on beanvalidation.org as well as on JSR 380’s pages on jcp.org.
We’ve also prepared a colored diff with all the changes since Bean Validation 1.1.
The updated API is available on Maven Central, using the GAV coordinates are javax.validation:validation-api:2.0.0.CR1.
Alternatively, it’s part of the ZIP that can be downloaded from from jcp.org.
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...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>I’m very happy to announce that Bean Validation 2.0 has published its Proposed Final Draft (CR 1)!</p>
</div>
<div class="paragraph">
<p>You can find the PFD right here on <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr1/">beanvalidation.org</a> as well as on JSR 380’s pages on <a href="https://jcp.org/aboutJava/communityprocess/pfd/jsr380/index.html">jcp.org</a>.
We’ve also prepared a <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-1.1/">colored diff</a> with all the changes since Bean Validation 1.1.
The updated API is available on Maven Central, using the GAV coordinates are <em>javax.validation:validation-api:2.0.0.CR1</em>.
Alternatively, it’s part of the ZIP that can be downloaded from <a href="https://jcp.org/aboutJava/communityprocess/pr/jsr380/index.html">from jcp.org</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new-in-bean-validation-2-0"><a class="anchor" href="#whats-new-in-bean-validation-2-0" />What’s new in Bean Validation 2.0?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The focus of Bean Validation 2.0 is supporting and taking advantage of Java SE 8.</p>
</div>
<div class="paragraph">
<p>For instance type annotations are used to validate the elements of generic containers: <code>List<@NotNull @Email String> emails</code>.
There are new built-in constraints (e.g. <code>@NotBlank</code>, <code>@NotEmpty</code>, <code>@Email</code>, <code>@Positive</code> and <code>@Negative</code>) 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 (<code>StringProperty</code> etc.) as well as <code>java.util.Optional</code>.</p>
</div>
<div class="paragraph">
<p>To learn more about all the new features in Bean Validation 2.0,
check out <a href="https://speakerdeck.com/gunnarmorling/keeping-your-data-sane-with-bean-validation-2-dot-0-jdk-dot-io">this presentation</a> which I recently gave at the jdk.io conference.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new-since-the-public-review-draft"><a class="anchor" href="#whats-new-since-the-public-review-draft" />What’s new since the Public Review Draft?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Since the <a href="http://beanvalidation.org/news/2017/05/24/bean-validation-2-0-public-review-update/">Public Review Draft</a> (Beta 2) we’ve primarily focused on improving the new Bean Validation 2.0 features,
e.g. by clarifying ambiguities in the spec, fixing bugs in the API, adding more examples etc.</p>
</div>
<div class="paragraph">
<p>In terms of API changes, we’ve followed up on our <a href="http://beanvalidation.org/news/2017/05/12/feedback-on-positive-and-negative-constraints/">community survey</a> on the new built-in constraints <code>@Positive</code> and <code>@Negative</code>
and removed the <code>strict()</code> attribute in favor of separate annotations: <code>@PositiveOrZero</code> and <code>@NegativeOrZero</code>.
As suggested by the community feedback, we’ve found that those separate annotations improve readability of code using the constraints.
In order to stay consistent, we’ve also removed <code>orPresent()</code> from <code>@Past</code> and <code>@Future</code> in favor of <code>@PastOrPresent</code> and <code>@FutureOrPresent</code>.
We think the same argument of readability applies; if you have any thoughts on these changes, please let us know.</p>
</div>
<div class="paragraph">
<p>Another API change (<a href="https://hibernate.atlassian.net/browse/BVAL-655">BVAL-655</a>) relates to how container element constraints are exposed in the constraint metadata API.
In case an overriding method of a sub-type specializes the return type of the overridden method (co-variant return type)
it’s now possible to obtain the constraint metadata for the return type of the super-type method as well as of the sub-type method.
Refer to <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr1/#constraintmetadata-containerdescriptor">the spec</a> for the complete metadata API definition and an extensive example of its usage.</p>
</div>
<div class="paragraph">
<p>The complete list of all 38 issues resolved for the CR 1 release can be found in the <a href="https://hibernate.atlassian.net/issues/?jql=project%20%3D%20BVAL%20AND%20fixVersion%20%3D%202.0.0.CR1">BVAL JIRA project</a>.
Corresponding releases of our reference implementation Hibernate Validator 6 and the TCK can be expected within the next few days.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-can-you-do-to-help"><a class="anchor" href="#what-can-you-do-to-help" />What can you do to help?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The Proposed Final Draft is pretty much what the expert group thinks should make up Bean Validation 2.0, i.e. it should be considered feature-complete.
Any further changes will essentially be bug fixes, further clarifications in the wording, formatting and other polishing.
If you’d like to help, reviewing the <a href="http://beanvalidation.org/2.0/spec/2.0.0.cr1/diff/diff-to-1.1/">specification changes</a> 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!</p>
</div>
<div class="paragraph">
<p>To post your feedback, just add a comment below, send a message to our <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/">mailing list</a> or post in the <a href="https://discourse.hibernate.org/c/bean-validation">Bean Validation forum</a>.
If you find a bug or have a specific feature request, please raise it in the <a href="https://hibernate.atlassian.net/projects/BVAL/summary">issue tracker</a>.</p>
</div>
<div class="paragraph">
<p>Everything in Bean Validation is open source, so you also can send in actual patches: be it to the <a href="https://github.com/beanvalidation/beanvalidation-api">API</a>, the <a href="https://github.com/beanvalidation/beanvalidation-spec">spec document</a>, the <a href="https://github.com/beanvalidation/beanvalidation-tck">TCK</a> or the <a href="https://github.com/hibernate/hibernate-validator">reference implementation</a>.
If you are interested, you can find out all the details to get started in the <a href="http://beanvalidation.org/contribute">contribution guide</a>.</p>
</div>
<div class="paragraph">
<p>Finally, let me say a huge "Thank You" to all the fine folks who helped to deliver this Proposed Final Draft:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Matt Benson, Emmanuel Bernard, Yoann Rodiere, Marco Molteni, Otávio Gonçalves de Santana, Michael Nascimento and everyone else who sent in comments and review remarks on the spec</p>
</li>
<li>
<p>Guillaume Smet who worked tirelessly to keep up the TCK and the reference implementation with the latest changes</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Your efforts are greatly appreciated!</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/05/24/bean-validation-2-0-public-review-update/Update to the Bean Validation 2.0 Public Review Draft2023-11-03T14:56:33+00:002017-05-24T00:00:00+00:00Gunnar Morling
While the Bean Validation 2.0 spec (JSR 380) has been put up for Public Review last month,
we’ve continued to address some more outstanding issues, added some clarifications etc.
Of course we wanted to get out these improvements as quickly as possible,
so we’ve published an update to the Public Review draft
(the JCP rules explicitly foresee the possibility of updates during the Public Review phase).
The updated draft can be found here on beanvalidation.org or you can download it from jcp.org.
As always the updated API is deployed to Maven Central, using the GAV coordinates are javax.validation:validation-api:2.0.0.Beta2.
Alternatively, it’s part of the ZIP that can be...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>While the Bean Validation 2.0 spec (<a href="https://www.jcp.org/en/jsr/detail?id=380">JSR 380</a>) has been <a href="http://beanvalidation.org/news/2017/04/26/bean-validation-2-0-up-for-public-review/">put up for Public Review</a> last month,
we’ve continued to address some more outstanding issues, added some clarifications etc.</p>
</div>
<div class="paragraph">
<p>Of course we wanted to get out these improvements as quickly as possible,
so we’ve published an update to the Public Review draft
(the JCP rules <a href="https://jcp.org/en/procedures/jcp2#3.4.4">explicitly foresee</a> the possibility of updates during the Public Review phase).
The updated draft can be found <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta2/">here on beanvalidation.org</a> or you can download it <a href="https://jcp.org/aboutJava/communityprocess/pr/jsr380/index.html">from jcp.org</a>.</p>
</div>
<div class="paragraph">
<p>As always the updated API is deployed to Maven Central, using the GAV coordinates are <em>javax.validation:validation-api:2.0.0.Beta2</em>.
Alternatively, it’s part of the ZIP that can be downloaded from <a href="https://jcp.org/aboutJava/communityprocess/pr/jsr380/index.html">from jcp.org</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-has-changed-since-the-original-public-review-draft"><a class="anchor" href="#what-has-changed-since-the-original-public-review-draft" />What has changed since the original Public Review Draft?</h2>
<div class="sectionbody">
<div class="paragraph">
<p><a href="http://beanvalidation.org/2.0/spec/2.0.0.beta2/#valueextractordefinition">Value extractors</a> got more flexible and can extract values from non-generic wrapper types now.</p>
</div>
<div class="paragraph">
<p>This allows to put all the constraints for numeric types (e.g. <code>@Min</code>, <code>@Max</code>, <code>@DecimalMin</code>, <code>@DecimalMax</code> etc.) to the optional numeric wrapper types in Java 8: <code>OptionalInt</code>, <code>OptionalLong</code> and <code>OptionalDouble</code> (<a href="https://hibernate.atlassian.net/browse/BVAL-579">BVAL-579</a>).
Also other JVM languages with their own numeric types benefit from that, as one can define value extractors for such types and apply all existing numeric constraints to them.
The key to this is the <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta2/#valueextractordefinition-extractedvalue">new attribute</a> <code>@ExtractedValue#type()</code> which allows to specify the type of the wrapped element for extractors of non-generic types.</p>
</div>
<div class="paragraph">
<p>Another improvement related to constraints on the elements of (generic) containers is the possibility to build property paths leading to a container element using the node builder API exposed via <code>ConstraintValidatorContext</code> (<a href="https://hibernate.atlassian.net/browse/BVAL-592">BVAL-592</a>).
For instance this will let you declare the container type and type argument index of a container element from within a custom class-level constraint validator.</p>
</div>
<div class="paragraph">
<p>The following validator for the <code>ValidUser</code> constraint will ensure that an entry for the <code>WORK</code> key is in the addresses map if the user’s type is <code>EMPLOYEE</code>.
If not, it will create a property path pointing to the map’s value, with the container type (<code>Map.class</code>) and type argument index (1, representing the <code>V</code> type parameter, as it’s about the map value):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@ValidUser</span>
<span style="color:#088;font-weight:bold">public</span> <span style="color:#339;font-weight:bold">class</span> <span style="color:#B06;font-weight:bold">User</span> {
<span style="color:#088;font-weight:bold">private</span> UserType type;
<span style="color:#088;font-weight:bold">private</span> <span style="color:#0a8;font-weight:bold">Map</span><AddressType, Address> addressesByType;
<span style="color:#777">// getters, setters etc. ...</span>
}</code></pre>
</div>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@Constraint</span>(validatedBy=UserValidator.class)
<span style="color:#088;font-weight:bold">public</span> <span style="color:#007">@interface</span> ValidUser {
<span style="color:#777">// constraint attributes ...</span>
}</code></pre>
</div>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#088;font-weight:bold">public</span> <span style="color:#339;font-weight:bold">class</span> <span style="color:#B06;font-weight:bold">UserValidator</span> <span style="color:#088;font-weight:bold">implements</span> ConstraintValidator<ValidUser, User> {
<span style="color:#007">@Override</span>
<span style="color:#088;font-weight:bold">public</span> <span style="color:#339;font-weight:bold">boolean</span> isValid(User user, ConstraintValidatorContext context) {
context.disableDefaultConstraintViolation();
<span style="color:#080;font-weight:bold">if</span> ( user.getType() == UserType.EMPLOYEE &&
user.getAddressesByType().get( AddressType.WORK ) == <span style="color:#069">null</span> ) {
context.buildConstraintViolationWithTemplate( <span style="background-color:hsla(0,100%,50%,0.05)"><span style="color:#710">"</span><span style="color:#D20">Work address needed for employee</span><span style="color:#710">"</span></span> )
.addContainerElementNode( <span style="background-color:hsla(0,100%,50%,0.05)"><span style="color:#710">"</span><span style="color:#D20">addressesByType</span><span style="color:#710">"</span></span>, <span style="color:#0a8;font-weight:bold">Map</span>.class, <span style="color:#00D">1</span> )
.inIterable()
.atKey( AddressType.WORK )
.addConstraintViolation();
<span style="color:#080;font-weight:bold">return</span> <span style="color:#069">false</span>;
}
<span style="color:#080;font-weight:bold">return</span> <span style="color:#069">true</span>;
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>One further improvement to mention is that the specification now recommends the module name "java.validation" (<a href="https://hibernate.atlassian.net/browse/BVAL-517">BVAL-517</a>),
should Bean Validation providers wish to distribute the API as a module for the Java Platform Module System (JPMS) as currently developed under <a href="https://www.jcp.org/en/jsr/detail?id=376">JSR 376</a>.
This could be used within a <em>module-info.java</em> descriptor or via the manifest entry "Automatic-Module-Name" when preparing the module to be used as an automatic module.</p>
</div>
<div class="paragraph">
<p>Note that this is a non-binding recommendation as of Bean Validation 2.0.
A mandatory module name (which could be "java.validation" or something else) — and potentially other requirements relating to the module system — will be mandated in a future revision of the spec,
once the module module system has been finalized and best practices around modules have emerged.</p>
</div>
<div class="paragraph">
<p>The complete list of all issues can be found in the <a href="https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10090&version=28800">release notes</a>.
There are also HTML diffs which highlight what has changed since the <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-2.0-beta1/">original Public Review Draft</a> (2.0.0.Beta1)
and since <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta2/diff/diff-to-1.1/">Bean Validation 1.1</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="new-releases-of-reference-implementation-and-tck"><a class="anchor" href="#new-releases-of-reference-implementation-and-tck" />New releases of reference implementation and TCK</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Together with the specification we’ve also released a corresponding version of the reference implementation Hibernate Validator 6.
Refer to the <a href="http://in.relation.to/2017/05/24/hibernate-validator-600-beta2-out/">announcement blog post</a> for more details.
This release lets you try out all the new features added in Bean Validation 2.0.</p>
</div>
<div class="paragraph">
<p>Also the TCK (test compatibility kit) has been updated and released.
You can learn more in the <a href="http://docs.jboss.org/hibernate/beanvalidation/tck/2.0/reference/html_single/">TCK documentation</a> and the <a href="https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10100&version=29100">release notes</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-can-you-do-to-help"><a class="anchor" href="#what-can-you-do-to-help" />What can you do to help?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The Public Review phase still runs for a few more days, followed by the Public Review Ballot (the voting by the JCP executive committee) until June 12th.
So it’s the perfect time for reviewing the <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-1.1/">spec changes</a>, we are very curious about your feedback.
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 appreciated!</p>
</div>
<div class="paragraph">
<p>To post your feedback, just add a comment below, send a message to our <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/">mailing list</a> or post in the <a href="https://discourse.hibernate.org/c/bean-validation">Bean Validation forum</a>.
If you find a bug or have a specific feature request, please raise it in the <a href="https://hibernate.atlassian.net/projects/BVAL/summary">issue tracker</a>.</p>
</div>
<div class="paragraph">
<p>Everything in Bean Validation is open source, so you also can send in actual patches: to the API, the spec document or the TCK.
If you are interested, you can find out all the details to get started in the <a href="http://beanvalidation.org/contribute">contribution guide</a>.</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/05/12/feedback-on-positive-and-negative-constraints/Survey - Behavior of @Positive and @Negative constraints2023-11-03T14:56:33+00:002017-05-12T00:00:00+00:00Gunnar Morling
Based on our previous survey we’ve recently added the new constraints @Positive and @Negative to the Bean Validation spec.
Now we’ve had an interesting discussion on some details of those constraints,
e.g. should 0 (zero) be considered as a valid value by default?
I.e. what’s the more common use case, to consider 0 as valid or not?
So we thought let’s make another survey to gauge the community feedback on those issues.
You’d help us very much by answering the two questions below, you won’t need more than a minute.
If you have any other thoughts you’d like to share, either add an answer to the...
<div class="paragraph">
<p>Based on our <a href="http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/">previous survey</a> we’ve recently added the new constraints <code>@Positive</code> and <code>@Negative</code> to the Bean Validation spec.
Now we’ve had an <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/2017-May/001309.html">interesting discussion</a> on some details of those constraints,
e.g. should 0 (zero) be considered as a valid value by default?
I.e. what’s the more common use case, to consider 0 as valid or not?</p>
</div>
<div class="paragraph">
<p>So we thought let’s make another survey to gauge the community feedback on those issues.
You’d help us very much by answering the two questions below, you won’t need more than a minute.</p>
</div>
<div class="paragraph">
<p>If you have any other thoughts you’d like to share, either add an answer to the free-text question or post a comment below.
The survey will be open until the end of next week.</p>
</div>
<div class="paragraph">
<p>Thanks a lot for your help!</p>
</div>
<div style="text-align: center">
<iframe src="https://docs.google.com/forms/d/e/1FAIpQLScJR1k6NdMjjV3xj8dPA4AMIqP5LZBdq_FKmqmKWLU_KX2few/viewform?embedded=true" width="760" height="600" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>
</div>
http://beanvalidation.org/news/2017/04/26/bean-validation-2-0-up-for-public-review/Bean Validation 2.0 is up for Public Review2023-11-03T14:56:33+00:002017-04-26T00:00:00+00:00Gunnar Morling
It’s with great pleasure that I’m announcing that Bean Validation 2.0 (JSR 380) is entering the Public Review phase!
You can read the Public Review Draft right here on this website or download it from jcp.org.
We are also publishing HTML diffs, making it very easy for you to track the changes since Bean Validation 1.1 and since the previous 2.0 release (Alpha2).
The updated API is deployed to Maven Central, its coordinates are javax.validation:validation-api:2.0.0.Beta1.
Alternatively, it’s part of the ZIP that can be downloaded from from jcp.org.
A huge thank you goes to everyone in the expert group and in the wider community who...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>It’s with great pleasure that I’m announcing that Bean Validation 2.0 (<a href="https://www.jcp.org/en/jsr/detail?id=380">JSR 380</a>) is entering the Public Review phase!</p>
</div>
<div class="paragraph">
<p>You can read the Public Review Draft right here <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/">on this website</a> or download it <a href="https://jcp.org/aboutJava/communityprocess/pr/jsr380/index.html">from jcp.org</a>.
We are also publishing HTML diffs, making it very easy for you to track the changes <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-1.1/">since Bean Validation 1.1</a> and <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-2.0-alpha2/">since the previous 2.0 release</a> (Alpha2).</p>
</div>
<div class="paragraph">
<p>The updated API is deployed to Maven Central, its coordinates are <em>javax.validation:validation-api:2.0.0.Beta1</em>.
Alternatively, it’s part of the ZIP that can be downloaded from <a href="https://jcp.org/aboutJava/communityprocess/pr/jsr380/index.html">from jcp.org</a>.</p>
</div>
<div class="paragraph">
<p>A huge thank you goes to everyone in the expert group and in the wider community who helped to make this release happen!
Whether it’s discussions on the mailing list, reviewing pull requests, sending in your own patches or lobbying for the new spec revision - it’s your contributions that make the difference.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new"><a class="anchor" href="#whats-new" />What’s New?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Since the Alpha2 release, we’ve mainly focused on consolidating the container element validation feature (think <code>List<@Email String> emails</code>);
the previous appendix describing this feature has been removed and its contents have been merged into the actual specification chapters.</p>
</div>
<div class="paragraph">
<p>The related chapters and sections in the spec are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>4. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#valueextractordefinition">Value extractor definition</a></p>
</li>
<li>
<p>5.5. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#constraintdeclarationvalidationprocess-containerelementconstraints">Container element constraints</a></p>
</li>
<li>
<p>5.7.5. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#constraintdeclarationvalidationprocess-validationroutine-valueextractorresolution">Value extractor resolution</a></p>
</li>
<li>
<p>6.2. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#validationapi-constraintviolation">ConstraintViolation</a> (changes around property paths in <code>ConstraintViolation</code> objects)</p>
</li>
<li>
<p>7.11. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#constraintmetadata-containerdescriptor">ContainerDescriptor and ContainerElementTypeDescriptor</a> (metadata API extensions)</p>
</li>
<li>
<p>9.1.1. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#xml-mapping-constraintdeclarationinxml">Constraint declaration in XML</a></p>
</li>
<li>
<p>10.5. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#exception-valueextractordefinition">ValueExtractorDefinitionException</a></p>
</li>
<li>
<p>10.6. <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/#exception-valueextractordeclaration">ValueExtractorDeclarationException</a></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Note that we have decided to remove the support for container element validation of arrays which had been part of the previous proposal.</p>
</div>
<div class="paragraph">
<p><a href="http://lists.jboss.org/pipermail/beanvalidation-dev/2017-April/001273.html">As we found out</a>, there’s an ambiguity when type annotations are used on an element like a field of a Java bean:
in this case it isn’t clear whether the annotation applies to the declaration itself (i.e. the array) or the component type of the array (i.e. the array elements).
We felt that it is better to play it safe and let Bean Validation implementations experiment with this first and bring back array support later on.
The names and semantics used in the spec and API should be generic enough so that they should suit for the array case, too, should we decide to add it down the road.</p>
</div>
<div class="paragraph">
<p>Together with the Java EE expert group we’ve also worked on a clarification regarding the location of the Bean Validation deployment descriptor.
The Bean Validation spec only ever meant to support <em>META-INF/validation.xml</em> for this, but the Java EE spec unfortunately mentioned <em>WEB-INF/validation.xml</em> for web modules.
While this has never been supported by the Bean Validation reference implementation and most application servers,
a community member thankfully brought the inconsistency between the specs to our attention recently.
The issue has been fixed by having the Java EE spec refer to Bean Validation for the descriptor location, which clearly says that it always is <em>META-INF/validation.xml</em>.
Servers which happen to support the alternative location, should phase out support for this, e.g. by raising a warning when detecting its usage and recommending to use the standardized location.</p>
</div>
<div class="paragraph">
<p>The complete list of changes in the Beta1 release can be found in the <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-2.0-alpha2/#changelog">change log</a>.</p>
</div>
<div class="paragraph">
<p>To learn more about all the new features we’ve added to Bean Validation 2 so far, check out the <a href="http://beanvalidation.org/news/2017/01/19/bean-validation-2-0-progress-report/">previous posts</a> <a href="http://beanvalidation.org/news/2017/02/14/bean-validation-2-0-early-draft-released/">in this blog</a>,
the <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha1/#_what_s_new_in_2_0">What’s new</a> section in the spec draft or simply the <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-1.1/">full HTML diff</a> with all the changes.</p>
</div>
<div class="paragraph">
<p>Another helpful resource may be <a href="https://speakerdeck.com/gunnarmorling/bean-validation-2-dot-0-support-fur-java-8-und-mehr">the slides</a> of a (German) presentation on Bean Validation 2.0 I recently did at JavaLand.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-next"><a class="anchor" href="#whats-next" />What’s next?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Currently we’re focusing on updating the reference implementation to the latest spec changes.
You can expect a new release of <a href="http://hibernate.org/validator/">Hibernate Validator 6</a> some time next week.
This will let you experiment with all the new features and explore them in more depth.</p>
</div>
<div class="paragraph">
<p>We are also planning to pick up some remaining loose ends around container element validation and - if we get to it -
the separation of the message interpolation algorithm from the retrieval of messages from resource bundles (<a href="https://hibernate.atlassian.net/projects/BVAL/issues/BVAL-217">BVAL-217</a>).</p>
</div>
<div class="paragraph">
<p>There is a <a href="https://hibernate.atlassian.net/issues/?jql=statusCategory%20%3D%20new%20AND%20project%20%3D%2010090%20AND%20fixVersion%20%3D%2028800%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC">couple of issues</a> assigned to the Beta2 release already.
If you think something else should really be in there, please let us know as soon as possible!</p>
</div>
<div class="paragraph">
<p>Apart from work on the spec itself and the reference implementation there is also the TCK
(the test suite all implementations need to run in order to ensure their compatibility).
There are quite a few tests to add for the recently added features.
We already got many within the Hibernate Validator’s test suite, so we can simply move over those.
But there also some new tests to be written.</p>
</div>
<div class="paragraph">
<p>The Public Review runs until May 27th, followed by Public Review Ballot (the voting by the JCP executive committee) until June 12th.
If all goes well, we’ll release the Proposed Final Draft soon after that, followed by the submission to the Final Approval Ballot in July, aligning with the overall schedule for <a href="https://www.jcp.org/en/jsr/detail?id=366">Java EE 8</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-can-you-do-to-help"><a class="anchor" href="#what-can-you-do-to-help" />What can you do to help?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Reviewing the spec changes (all or part of them) would be super-awesome!
There is a very handy <a href="http://beanvalidation.org/2.0/spec/2.0.0.beta1/diff/diff-to-1.1/">HTML diff</a> (did I mention it before?) which makes it easy to spot all the changes since Bean Validation 1.1.</p>
</div>
<div class="paragraph">
<p>Another thing you can do is to try out the reference implementation in your applications (ideally the new version to be released next week).
Do the new features work as intended? Is anything missing, not behaving as described in the spec or generally just not working as you think it should?
Then please tell us.
The more feedback we get, the better.</p>
</div>
<div class="paragraph">
<p>To post your feedback, just add a comment below, send a message to our <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/">mailing list</a> or post in the <a href="https://discourse.hibernate.org/c/bean-validation">Bean Validation forum</a>.
If you find a bug or have a specific feature request, please raise it in the <a href="https://hibernate.atlassian.net/projects/BVAL/summary">issue tracker</a>.</p>
</div>
<div class="paragraph">
<p>Everything in Bean Validation is open source, so you also can send in actual patches: to the API, the spec document or the TCK.
If you are interested, you can find out all the details to get started in the <a href="http://beanvalidation.org/contribute">contribution guide</a>.</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/03/31/bean-validation-2-0-alpha2-is-out/Bean Validation 2.0 Alpha2 is out2023-11-03T14:56:33+00:002017-03-31T00:00:00+00:00Gunnar Morling
I’m happy to announce the release of the Alpha2 release of the Bean Validation 2 API and specification.
This release contains several improvements and clarifications around the validation of container elements (think List<@Email String>):
Custom value extractors can now be passed in when bootstrapping a validator factory or validator (via API or XML)
Value extractors are detected via the Java service loader mechanism
(e.g. allowing libraries to ship their own extractors for custom collection types)
Property paths for constraint violations on container elements will now contain a node of the new type CONTAINER_ELEMENT
Container element constraints can be specified in XML mapping descriptors
There are also some...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>I’m happy to announce the release of the Alpha2 release of the Bean Validation 2 API and specification.</p>
</div>
<div class="paragraph">
<p>This release contains several improvements and clarifications around the <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha2/#appendix-value-extraction">validation of container elements</a> (think <code>List<@Email String></code>):</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Custom value extractors can now be passed in when bootstrapping a validator factory or validator (via API or XML)</p>
</li>
<li>
<p>Value extractors are detected via the Java service loader mechanism
(e.g. allowing libraries to ship their own extractors for custom collection types)</p>
</li>
<li>
<p>Property paths for constraint violations on container elements will now contain a node of the new type <code>CONTAINER_ELEMENT</code></p>
</li>
<li>
<p>Container element constraints can be specified in XML mapping descriptors</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>There are also some new constraints, as per the community feedback on the <a href="http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/">survey we did last year</a>:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>@NotEmpty</code>, <code>@NotBlank</code></p>
</li>
<li>
<p><code>@Email</code></p>
</li>
<li>
<p><code>@Positive</code>, <code>@Negative</code></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The first three have been part of the reference implementation for a long time
and have been promoted to the spec due to their frequent usage.
The latter two are new constraints which address the very common use case of
mandating that a numeric value should be positive or negative.
It’s configurable via the <code>strict()</code> attribute whether 0 should be considered as valid or not.</p>
</div>
<div class="paragraph">
<p>You can find the complete list of addressed issues <a href="https://hibernate.atlassian.net/issues/?jql=project%20%3D%20BVAL%20AND%20fixVersion%20%3D%202.0.0.Alpha2">in JIRA</a>.
The spec text of the Alpha2 release is published <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha2/">here</a>.
The GAV coordinates of the API JAR are <a href="http://search.maven.org/#artifactdetails%7Cjavax.validation%7Cvalidation-api%7C2.0.0.Alpha2%7Cjar">javax.validation:validation-api:2.0.0.Alpha2</a>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="tck-update"><a class="anchor" href="#tck-update" />TCK update</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Together with the spec we also released a new version of the Bean Validation TCK for testing the new features.
Its coordinates are <code>org.hibernate.beanvalidation.tck:beanvalidation-tck-tests:2.0.0.Alpha3</code> (it should be synced to Maven Central soon).</p>
</div>
<div class="paragraph">
<p>If you are wondering why the TCK is at Alpha3 already, that’s because of a glitch with the Alpha2 release which wouldn’t allow to run the TCK in a container.
Hence we released the Alpha3 version right after that.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="trying-it-out-yourself"><a class="anchor" href="#trying-it-out-yourself" />Trying it out yourself</h2>
<div class="sectionbody">
<div class="paragraph">
<p>In order to try out the latest Bean Validation features, grab this week’s release of
the reference implementation, Hibernate Validator 6 Alpha2.</p>
</div>
<div class="paragraph">
<p>It supports the Alpha2 version of the spec and some things more.
Refer to the <a href="http://in.relation.to/2017/03/30/hibernate-validator-600-alpha2-out/">announcement post</a> for all the details.
Please give it a try and let us know about your thoughts on these changes as well as any other things related to Bean Validation.</p>
</div>
<div class="paragraph">
<p>We are now working towards the Public Draft of the spec (to be expected in April).
The Public Draft will mostly polish the work done so far.
Most prominently, the container element validation feature,
which currently is <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha2/#appendix-value-extraction">an appendix</a> to the spec,
will be incorporated in the actual specification sections.</p>
</div>
<div class="paragraph">
<p>We’ve also planned to address some other feature requests, like <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha2/#appendix-value-extraction">splitting up</a> the notion of message interpolation and retrieving message bundles.
If there are other things you’d like to see addressed in Bean Validation 2.0,
please <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/">get in touch</a> quickly, the clock is ticking :)</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/02/16/first-alpha-of-bean-validation-2-0-reference-implementation/First Alpha of Bean Validation 2.0 Reference Implementation Available2023-11-03T14:56:33+00:002017-02-16T00:00:00+00:00Gunnar Morling
A few days after the release of the Bean Validation 2.0 Early Draft 1
there is now also a first version of the reference implementation available.
If you are using Apache Maven, add the following dependency to your pom.xml to give it a test ride:
<dependency>
<groupId>org.hibernate.validator</groupId>
<artifactId>hibernate-validator</artifactId>
<version>6.0.0.Alpha1</version>
</dependency>
The 6.0.0.Alpha1 release provides all the functionality of the Early Draft 1.
In addition there is support for
nested type argument constraints, e.g. Map<String, Size(min=1) List<@NotNull Item>> itemsByCategory;
this addresses open question #1 from the proposal for the validation of container elements
definition of constraints using Lambda expressions and method...
<div class="paragraph">
<p>A few days after the release of the <a href="http://beanvalidation.org/news/2017/02/14/bean-validation-2-0-early-draft-released/">Bean Validation 2.0 Early Draft 1</a>
there is now also a <a href="http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/">first version of the reference implementation</a> available.</p>
</div>
<div class="paragraph">
<p>If you are using Apache Maven, add the following dependency to your <em>pom.xml</em> to give it a test ride:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><dependency>
<groupId>org.hibernate.validator</groupId>
<artifactId>hibernate-validator</artifactId>
<version><span style="color:#60E">6.0</span><span style="color:#60E">.0</span>.Alpha1</version>
</dependency></code></pre>
</div>
</div>
<div class="paragraph">
<p>The 6.0.0.Alpha1 release provides all the functionality of the <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha1/">Early Draft 1</a>.
In addition there is support for</p>
</div>
<div class="ulist">
<ul>
<li>
<p>nested type argument constraints, e.g. <code>Map<String, Size(min=1) List<@NotNull Item>> itemsByCategory</code>;
this addresses <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha1/#_open_questions">open question #1</a> from the proposal for the validation of container elements</p>
</li>
<li>
<p>definition of constraints using Lambda expressions and method references</p>
</li>
<li>
<p>validation of <code>java.time.Duration</code> via two new constraints, <code>@DurationMin</code> and <code>@DurationMax</code></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>If you think those things should be added to the spec, please let us know.
Your feedback on these features as well as all the other Early Draft 1 additions will be much appreciated!</p>
</div>
<div class="paragraph">
<p>Check out the original <a href="http://in.relation.to/2017/02/16/hibernate-validator-600-alpha1-out/">Hibernate Validator release announcement</a> for all the details.</p>
</div>
http://beanvalidation.org/news/2017/02/14/bean-validation-2-0-early-draft-released/Bean Validation 2.0 Early Draft 1 is Out2023-11-03T14:56:33+00:002017-02-14T00:00:00+00:00Gunnar Morling
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...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>I’m very happy to announce the first Early Draft Review of <a href="https://www.jcp.org/en/jsr/detail?id=380">JSR 380</a>, Bean Validation 2.0!</p>
</div>
<div class="paragraph">
<p>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 <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha1/">on this website</a> or download it <a href="https://jcp.org/aboutJava/communityprocess/edr/jsr380/index.html">from jcp.org</a>.
A GitHub diff showing all the changes to the spec’s AsciiDoc document done so far (sans some typo and style fixes) is available <a href="https://github.com/beanvalidation/beanvalidation-spec/compare/2a9d0ce21856386a8bf9a1d9e963ebffc049604a…9bfd5a34ca6c10d2a8a7b512b174aae7362259f0">here</a>.</p>
</div>
<div class="paragraph">
<p>The updated API can be downloaded from <a href="https://jcp.org/aboutJava/communityprocess/edr/jsr380/index.html">from jcp.org</a> or fetched from Maven Central using the coordinates <em>javax.validation:validation-api:2.0.0.Alpha1</em>.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-new"><a class="anchor" href="#whats-new" />What’s New?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>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.</p>
</div>
<div class="paragraph">
<p>An example of the latter is the support for the new Java 8 date and time API (JSR 310).
You can now use <code>@Past</code> and <code>@Future</code> on <code>javax.time</code> types such as <code>Instant</code>, <code>LocalDate</code> etc.:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@Future</span>
<span style="color:#088;font-weight:bold">private</span> LocalDate deliveryDate;</code></pre>
</div>
</div>
<div class="paragraph">
<p>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 <code>orPresent()</code>:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@Past</span>(orPresent=<span style="color:#069">true</span>)
<span style="color:#088;font-weight:bold">private</span> <span style="color:#088;font-weight:bold">final</span> Year inceptionYear = Year.of( <span style="color:#00D">2017</span> );</code></pre>
</div>
</div>
<div class="paragraph">
<p>An example where Bean Validation benefits from new language features in Java 8
is the new mechanism for validating the elements of <code>Collection</code>, <code>Optional</code> 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):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#0a8;font-weight:bold">List</span><<span style="color:#007">@NotNull</span> <span style="color:#007">@Email</span> <span style="color:#0a8;font-weight:bold">String</span>> emails;</code></pre>
</div>
</div>
<div class="paragraph">
<p>Also cascaded validation (<code>@Valid</code>) gets more powerful with that.
E.g. you can now perform a cascaded validation of map keys <em>and</em> map values (only values were supported before):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#0a8;font-weight:bold">Map</span><<span style="color:#007">@Valid</span> Customer, <span style="color:#007">@Valid</span> Address> primaryAddressByCustomer;</code></pre>
</div>
</div>
<div class="paragraph">
<p>Another use case for this is validation of values wrapped in a <code>java.util.Optional</code>:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java">Optional<<span style="color:#007">@Past</span> LocalDate> getRegistrationDate();</code></pre>
</div>
</div>
<div class="paragraph">
<p>We’ve baked in support for type argument constraints on types such as <code>Iterable</code>, <code>Map</code>, <code>Optional</code> and some more,
but this isn’t a fixed list.
You can plug in custom implementations of the <code>ValueExtractor</code> contract
which will allow you to put type argument constraints to other collection types (e.g. Google Guava’s <code>Multimap</code>)
or even collection classes from other JVM languages such as Ceylon.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-else"><a class="anchor" href="#what-else" />What else?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Support for JSR 310 and type argument constraints are just two of the new features.
Some other changes are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>All constraints and a few other Bean Validation annotations are repeatable</p>
</li>
<li>
<p>Method parameter names to be shown in error messages are obtained using reflection (if enabled)</p>
</li>
<li>
<p><code>ConstraintValidator#initialize()</code> is a default method,
simplifying the implementation of constraint validators which don’t need to access the annotation state</p>
</li>
<li>
<p><code>ValidatorFactory</code> extends <code>AutoCloseable</code>, allowing to use it in <code>try-with-resources</code> blocks</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>To learn more about the changes we’ve done so far, either check out our <a href="http://beanvalidation.org/news/2017/01/19/bean-validation-2-0-progress-report/">progress report</a> from a few weeks ago
or the <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha1/#_what_s_new_in_2_0">specification document</a> itself.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="whats-next"><a class="anchor" href="#whats-next" />What’s next?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The next step will be to bring the Bean Validation reference implementation, <a href="http://hibernate.org/validator/">Hibernate Validator</a>, 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.</p>
</div>
<div class="paragraph">
<p>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.</p>
</div>
<div class="paragraph">
<p>In terms of spec changes, some of the next features we are planning to work on are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Adding some new constraints as per our <a href="http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/">recent survey</a>, e.g. <code>@Email</code>, <code>@NotEmpty</code>, <code>@NotBlank</code></p>
</li>
<li>
<p>Ability to validate an object and a list of changes (<a href="https://hibernate.atlassian.net/projects/BVAL/issues/BVAL-214">BVAL-214</a>) which would be useful for validating class-level constraints in UI use cases</p>
</li>
<li>
<p>Separating the message interpolation algorithm from the retrieval of messages from resource bundles (<a href="https://hibernate.atlassian.net/projects/BVAL/issues/BVAL-217">BVAL-217</a>)</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect1">
<h2 id="what-can-you-do-to-help"><a class="anchor" href="#what-can-you-do-to-help" />What can you do to help?</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Glad you asked :)</p>
</div>
<div class="paragraph">
<p>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 <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha1/#appendix-value-extraction">container value validation</a>.
There is a <a href="http://beanvalidation.org/2.0/spec/2.0.0.alpha1/#_open_questions">list of open questions</a> towards the end of that section.
If you have thoughts on any of those, please let us know.</p>
</div>
<div class="paragraph">
<p>To get a discussion started, just post a comment below, send a message to our <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/">mailing list</a> or post in the <a href="https://discourse.hibernate.org/c/bean-validation">Bean Validation forum</a>.
If you find a bug or have a specific feature request, please raise them in the <a href="https://hibernate.atlassian.net/projects/BVAL/summary">issue tracker</a>.</p>
</div>
<div class="paragraph">
<p>And as Bean Validation is a true open source project, contributing e.g. in form of patches is easy, too.
Check out the <a href="http://beanvalidation.org/contribute">contribution guide</a> to learn more.</p>
</div>
<div class="paragraph">
<p>Finally, let me say a big thank you to everyone involved with making the Early Draft happen; your work is much appreciated!</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2017/02/07/apache-bval-is-compatible-with-bean-validation-1-1/Apache BVal certified as Bean Validation 1.1 implementation2023-11-03T14:56:33+00:002017-02-07T00:00:00+00:00Gunnar Morling
While the work on Bean Validation 2.0 is well underway,
I’ve some good news to share on Bean Validation 1.1 today:
Apache BVal has been certified as a compliant implementation of the Bean Validation 1.1 spec!
Thanks to the great work of the friendly folks working on Apache BVal and TomEE, it has passed the TCK quite a while ago, so this announcement is long overdue.
The tested version is Apache BVal 1.1.2,
using the Bean Validation API signatures from org.apache.tomee:javaee-api:7.0-1 and
version 1.1.4.Final of the Bean Validation TCK.
The list of certified implementations has been updated accordingly.
Congrats to the BVal team!...
<div class="paragraph">
<p>While the work on Bean Validation 2.0 is <a href="http://beanvalidation.org/news/2017/01/19/bean-validation-2-0-progress-report/">well underway</a>,
I’ve some good news to share on Bean Validation 1.1 today:
<a href="http://bval.apache.org/">Apache BVal</a> has been certified as a compliant implementation of the <a href="http://beanvalidation.org/1.1/">Bean Validation 1.1</a> spec!</p>
</div>
<div class="paragraph">
<p>Thanks to the great work of the friendly folks working on Apache BVal and TomEE, it has passed the TCK quite a while ago, so this announcement is long overdue.
The tested version is <a href="http://bval.apache.org/downloads.html#apache-bval-112-released-nov-3-2016">Apache BVal 1.1.2</a>,
using the Bean Validation API signatures from <a href="http://mvnrepository.com/artifact/org.apache.tomee/javaee-api/7.0-1">org.apache.tomee:javaee-api:7.0-1</a> and
version 1.1.4.Final of the <a href="http://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_single/">Bean Validation TCK</a>.</p>
</div>
<div class="paragraph">
<p>The list of <a href="http://beanvalidation.org/certified/">certified implementations</a> has been updated accordingly.</p>
</div>
<div class="paragraph">
<p>Congrats to the BVal team!</p>
</div>
http://beanvalidation.org/news/2017/01/19/bean-validation-2-0-progress-report/Bean Validation 2.0 Progress Report2023-11-03T14:56:33+00:002017-01-19T00:00:00+00:00Gunnar Morling
It has been a few months since we’ve kicked off the work on Bean Validation 2.0 (JSR 380).
We have made some good progress, so I’d like to give you a quick update on what has been achieved so far and what the next steps will be.
This is planned to be the first post of a regular blog series with JSR 380 status updates.
Expert group formation
It all started with the review ballot of the JCP executive committee on the new JSR.
The ballot was approved with a huge majority, allowing the JSR to proceed and create its expert group.
In a short time,...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>It has been a few months since we’ve kicked off the work on Bean Validation 2.0 (<a href="https://www.jcp.org/en/jsr/detail?id=380">JSR 380</a>).
We have made some good progress, so I’d like to give you a quick update on what has been achieved so far and what the next steps will be.
This is planned to be the first post of a regular blog series with JSR 380 status updates.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="expert-group-formation"><a class="anchor" href="#expert-group-formation" />Expert group formation</h2>
<div class="sectionbody">
<div class="paragraph">
<p>It all started with the review ballot of the JCP executive committee on the new JSR.
The ballot was approved with a <a href="https://www.jcp.org/en/jsr/results?id=5871">huge majority</a>, allowing the JSR to proceed and create its expert group.</p>
</div>
<div class="paragraph">
<p>In a short time, <a href="https://www.jcp.org/en/jsr/detail?id=380">individuals and representatives</a> from multiple companies joined the EG, providing input and experiences from different angles and perspectives.
This also gives us very good connections to the EGs of other specs such as JAX-RS or java.time (JSR 310) which will be beneficial for creating new (or improving existing) integrations with those.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="first-changes"><a class="anchor" href="#first-changes" />First changes</h2>
<div class="sectionbody">
<div class="paragraph">
<p>With the first EG members on board, we didn’t lose time and began with the work on the new spec revision.
One of the initial actions was to convert the spec document from DocBook into the fabulous <a href="http://asciidoc.org/">AsciiDoc</a> format.
Using AsciiDoc comes with many advantages which make working on the spec a much more enjoyable experience:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>It can be written using any text editor</p>
</li>
<li>
<p>Changes are easier to track, e.g. when reviewing pull requests on GitHub</p>
</li>
<li>
<p>We can include actual source files from the API instead of copying them</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>While that’s primarily a technicality interesting to those working on the spec, it also is beneficial for Bean Validation users,
as you for instance can easily track all the changes done so far by examining a <a href="https://github.com/beanvalidation/beanvalidation-spec/compare/2a9d0ce21856386a8bf9a1d9e963ebffc049604a…spec-full">simple diff</a> on GitHub.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="support-for-new-date-and-time-api"><a class="anchor" href="#support-for-new-date-and-time-api" />Support for new date and time API</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The primary theme in Bean Validation is the embrace of Java 8.
Java 8 comes with a variety of improvements to the language (e.g. Lambda expressions and default methods)
but also many useful additions to the class library.</p>
</div>
<div class="paragraph">
<p>One prominent example of the latter is the new date and time API (<a href="https://www.jcp.org/en/jsr/detail?id=310">JSR 310</a>).
Types such as <code>Instant</code>, <code>LocalDate</code> or <code>ZonedDateTime</code> are now supported by the <code>@Past</code> and <code>@Future</code> constraints (<a href="https://hibernate.atlassian.net/browse/BVAL-496">BVAL-496</a>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@Future</span>
<span style="color:#088;font-weight:bold">private</span> LocalDate deliveryDate;</code></pre>
</div>
</div>
<div class="paragraph">
<p><code>@Past</code> and <code>@Future</code> now also have a new attribute <code>orPresent()</code>:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@Past</span>(orPresent=<span style="color:#069">true</span>)
<span style="color:#088;font-weight:bold">private</span> <span style="color:#088;font-weight:bold">final</span> Year inceptionYear = Year.of( <span style="color:#00D">2017</span> );</code></pre>
</div>
</div>
<div class="paragraph">
<p>That’s useful for types such as <code>Year</code> or <code>LocalDate</code> which don’t represent a specific instant but rather an interval of time
and you want to consider the entire current year, day etc. as valid.</p>
</div>
<div class="paragraph">
<p>Another improvement related to the validation of dates and times is the new <code>ClockProvider</code> extension point.
It allows you to specify what is "now" when validating <code>@Past</code> and <code>@Future</code>.
That comes in handy for instance if you want to work with the time and time zone of the currently logged in user in a multi-user, multi-timezone application.</p>
</div>
<div class="paragraph">
<p>But it’s also useful for (re-)running batch jobs with a different logical date than the current one or for testing with a fixed point in time considered as "now":</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#0a8;font-weight:bold">Validator</span> validator = Validation.byDefaultProvider()
.configure()
.clockProvider( () -> Clock.fixed(
Instant.parse(<span style="background-color:hsla(0,100%,50%,0.05)"><span style="color:#710">"</span><span style="color:#D20">2017-01-19T11:00:00.00Z</span><span style="color:#710">"</span></span> ), ZoneId.systemDefault() )
)
.buildValidatorFactory()
.getValidator();</code></pre>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="validation-of-collection-optional-and-other-containers"><a class="anchor" href="#validation-of-collection-optional-and-other-containers" />Validation of <code>Collection</code>, <code>Optional</code> and other containers</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Looking at language changes in Java 8, the newly allowed locations for annotations (<a href="https://docs.oracle.com/javase/tutorial/java/annotations/type_annotations.html">type annotations</a>) prove themselves a very useful feature for Bean Validation.
By putting constraints to type arguments of parameterized types, it finally gets possible to apply constraints to the elements of collections in a concise and intuitive way (<a href="https://hibernate.atlassian.net/browse/BVAL-508">BVAL-508</a>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#0a8;font-weight:bold">List</span><<span style="color:#007">@NotNull</span> <span style="color:#007">@Email</span> <span style="color:#0a8;font-weight:bold">String</span>> emails;</code></pre>
</div>
</div>
<div class="paragraph">
<p>Putting the constraints to the <code>String</code> type argument makes it apparent that they should not be applied to the list object itself, but rather to each contained element.</p>
</div>
<div class="paragraph">
<p>Similarly, it’s possible to apply constraints to the elements of an array:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#0a8;font-weight:bold">String</span> <span style="color:#007">@NotNull</span> <span style="color:#007">@Email</span><span style="color:#339;font-weight:bold">[]</span> emails;</code></pre>
</div>
</div>
<div class="paragraph">
<p>Also cascaded validation gets more flexible with that.
It’s now possible to mandate that the keys <em>and</em> values of maps should be validated
(so far, only values were validated) by using <code>@Valid</code> like this:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#0a8;font-weight:bold">Map</span><<span style="color:#007">@Valid</span> Customer, <span style="color:#007">@Valid</span> Address> primaryAddressByCustomer;</code></pre>
</div>
</div>
<div class="paragraph">
<p>But it doesn’t end there.
The spec also defines support for <code>java.util.Optional</code>:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java">Optional<<span style="color:#007">@Past</span> LocalDate> getRegistrationDate();</code></pre>
</div>
</div>
<div class="paragraph">
<p>As well as for the hierarchy of property types in JavaFX:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java">Property<<span style="color:#007">@Min</span>(<span style="color:#00D">1</span>) <span style="color:#0a8;font-weight:bold">Integer</span>> revenue;</code></pre>
</div>
</div>
<div class="paragraph">
<p>Acknowledging that JavaFX provides dedicated non-generic sub-types of <code>Property</code> for specific data types (e.g. <code>StringProperty</code> or <code>IntegerProperty</code>),
it is also supported to put constraints on the element itself in this case:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@Min</span>(<span style="color:#00D">1</span>)
IntegerProperty revenue;</code></pre>
</div>
</div>
<div class="paragraph">
<p>This becomes possible by defining means of "automatic value unwrapping" for specific types such as the JavaFX ones.
Check out the <a href="http://beanvalidation.org/latest-draft/spec/#appendix-valueextraction-wrappedelements">latest spec draft</a> to learn more about how this is handled.</p>
</div>
<div class="paragraph">
<p>While the spec mandates support for type argument constraints on types such as <code>Iterable</code>, <code>Map</code>, <code>Optional</code> and some more,
this can be easily extended via the <code>ValueExtractor</code> contract.
This interface is used when the Bean Validation engine needs to obtain the elements of a constrained container.</p>
</div>
<div class="paragraph">
<p>Custom extractor implementations can be plugged in when bootstrapping a validator,
allowing to use type argument constraints with custom collection types such as the ones defined by <a href="https://github.com/google/guava/wiki/NewCollectionTypesExplained">Google’s Guava library</a> (e.g. <code>Multimap</code> or <code>Table</code>):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java">ListMultimap<<span style="color:#007">@Valid</span> Customer, <span style="color:#007">@Email</span> <span style="color:#0a8;font-weight:bold">String</span>> emailsByCustomer;</code></pre>
</div>
</div>
<div class="paragraph">
<p>We are considering to detect custom extractors using the <a href="http://docs.oracle.com/javase/8/docs/api/index.html?java/util/ServiceLoader.html">service loader mechanism</a>,
allowing providers of container types to bundle corresponding extractors with their library and making them automatically available to you.</p>
</div>
<div class="paragraph">
<p>Validation of container elements is by far the most complex feature and we’d like to gather some more feedback on it before committing to it.
Hence its current proposal is added as <a href="http://beanvalidation.org/latest-draft/spec/#appendix-value-extraction">an appendix</a> to the spec draft.
We are eager to learn about your thoughts and feedback in general, but it’s especially important for this issue due to its complexity.</p>
</div>
<div class="paragraph">
<p>We’ve compiled a list of <a href="http://beanvalidation.org/latest-draft/spec/#_open_questions">open questions</a> around this proposal.
If you have thoughts on any of those, please make sure to let us know, e.g. by commenting below.
The snapshot builds of the reference implementation (Maven GAV <code>org.hibernate:hibernate-validator:6.0.0-SNAPSHOT</code>) already implement the current proposal, so you can get it from the <a href="https://repository.jboss.org/nexus/content/repositories/public/">JBoss Maven repo</a> in order to play with that feature.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="other-improvements"><a class="anchor" href="#other-improvements" />Other improvements</h2>
<div class="sectionbody">
<div class="paragraph">
<p>While support for JSR 310 and validation of container elements have been the largest features we’ve been working on so far,
there are some more smaller, yet very useful improvements.</p>
</div>
<div class="paragraph">
<p>E.g. all the built-in constraints are <a href="http://docs.oracle.com/javase/tutorial/java/annotations/repeating.htmlhttps://hibernate.atlassian.net/browse/BVAL-497">repeatable annotations</a> now, allowing to define them several times without requiring the explicit <code>@List</code> annotation ([BVAL-497]):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#007">@ZipCode</span>(countryCode = <span style="background-color:hsla(0,100%,50%,0.05)"><span style="color:#710">"</span><span style="color:#D20">fr</span><span style="color:#710">"</span></span>, groups = Default.class, message = <span style="background-color:hsla(0,100%,50%,0.05)"><span style="color:#710">"</span><span style="color:#D20">zip code is not valid</span><span style="color:#710">"</span></span>)
<span style="color:#007">@ZipCode</span>(
countryCode = <span style="background-color:hsla(0,100%,50%,0.05)"><span style="color:#710">"</span><span style="color:#D20">fr</span><span style="color:#710">"</span></span>,
groups = SuperUser.class,
message = <span style="background-color:hsla(0,100%,50%,0.05)"><span style="color:#710">"</span><span style="color:#D20">zip code invalid. Requires overriding before saving.</span><span style="color:#710">"</span></span>
)
<span style="color:#088;font-weight:bold">private</span> <span style="color:#0a8;font-weight:bold">String</span> zipCode;</code></pre>
</div>
</div>
<div class="paragraph">
<p><code>ConstraintValidator#initialize()</code> has an empty default implementation now (<a href="https://hibernate.atlassian.net/browse/BVAL-555">BVAL-555</a>),
simplifying the implementation of constraint validators that don’t need to access any constraint attributes.
You can simply omit the <code>initialize()</code> method:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#088;font-weight:bold">public</span> <span style="color:#339;font-weight:bold">class</span> <span style="color:#B06;font-weight:bold">AssertTrueValidator</span> <span style="color:#088;font-weight:bold">implements</span> ConstraintValidator<AssertTrue, <span style="color:#0a8;font-weight:bold">Boolean</span>> {
<span style="color:#007">@Override</span>
<span style="color:#088;font-weight:bold">public</span> <span style="color:#339;font-weight:bold">boolean</span> isValid(<span style="color:#0a8;font-weight:bold">Boolean</span> bool, ConstraintValidatorContext constraintValidatorContext) {
<span style="color:#080;font-weight:bold">return</span> bool == <span style="color:#069">null</span> || bool;
}
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Another nice improvement is the usage of actual parameter names when reporting constraint violations for constraints on method or constructor parameters (<a href="https://hibernate.atlassian.net/browse/BVAL-498">BVAL-498</a>).
Provided you have enabled reflective parameter name access during compilation (using <code>-parameters</code> javac option),
<code>Path.Node#getName()</code> will return the actual parameter name instead of "arg0", "arg1" for parameter nodes.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="next-steps"><a class="anchor" href="#next-steps" />Next steps</h2>
<div class="sectionbody">
<div class="paragraph">
<p>With all these things in place, we feel it is the right time to put out an Alpha1 release of Bean Validation 2.0 and will post it for Early Draft Review to the JCP within the next days.
This should get the discussed changes into the hands of more people out there and will let us improve and hone the features added so far.</p>
</div>
<div class="paragraph">
<p>In parallel we’ll continue with some other features from the backlog.
Issues high on our priority list are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Adding some new constraints as per our <a href="http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/">recent survey</a>, e.g. <code>@NotEmpty</code>, <code>@NotBlank</code></p>
</li>
<li>
<p>Separating the notions of message resolver and message interpolator (<a href="https://hibernate.atlassian.net/browse/BVAL-217">BVAL-217</a>)</p>
</li>
<li>
<p>Ability to validate an object and a list of changes (<a href="https://hibernate.atlassian.net/browse/BVAL-214">BVAL-214</a>)</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>We also contemplate the idea of using Java 8 Lambda expressions and method references for defining constraints without an explicit <code>ConstraintValidator</code> implementation class.
This is already supported in the reference implementation:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java">ConstraintMapping mapping = ...
mapping.constraintDefinition( Directory.class ) <span style="color:#777">// @Directory is a constraint annotation</span>
.validateType( <span style="color:#0a8;font-weight:bold">File</span>.class ).with( <span style="color:#0a8;font-weight:bold">File</span>::exists );</code></pre>
</div>
</div>
<div class="paragraph">
<p>We haven’t decided yet whether to put this into the spec or not.
So we recommend you give it a try in the reference implementation and let us know about your thoughts.
The feedback when <a href="https://twitter.com/gunnarmorling/status/819631488358563840">sharing the idea</a> on Twitter was <a href="https://twitter.com/dblevins/status/819633752888475648">very encouraging</a>.</p>
</div>
<div class="paragraph">
<p>We are also <a href="https://java.net/projects/jax-rs-spec/lists/users/archive/2017-01/message/4">working</a> with the expert group for JAX-RS 2.1 (<a href="https://www.jcp.org/en/jsr/detail?id=370">JSR 370</a>) to further improve integration of the two specs, e.g. in the <a href="https://java.net/jira/browse/JAX_RS_SPEC-539">field of I18N</a>.</p>
</div>
<div class="paragraph">
<p>This list of issues is not cast in stone, so if there is anything close to your heart, please speak up and let us know about your ideas.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="outreach"><a class="anchor" href="#outreach" />Outreach</h2>
<div class="sectionbody">
<div class="paragraph">
<p>To get more closely in touch with the Bean Validation users out there, we’ve also submitted talks on Bean Validation 2.0 to several conferences.
I will be presenting on it at <a href="https://www.javaland.eu/konferenz/konferenzplaner/konferenzplaner_details.php?id=522447&locS=0&vid=529258">JavaLand 2017</a> and have plans for some JUGs.
You also can expect a new edition of the <a href="http://asylum.libsyn.com/">Asylum Podcast</a> discussing Bean Validation 2.0 and working on a JSR in general in the next weeks.
And you can find an <a href="https://www.heise.de/developer/artikel/Bean-Validation-ist-sehr-nuetzlich-fuer-Microservice-Architekturen-3321829.html">interview with me</a> on Bean Validation 2.0 on heise Developer (in German).</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="raise-your-feedback"><a class="anchor" href="#raise-your-feedback" />Raise your feedback</h2>
<div class="sectionbody">
<div class="paragraph">
<p>Bean Validation is a true community effort, so we are eager to learn about your suggestions and proposals.
Don’t be shy, get a discussion started by dropping a comment below, posting to the <a href="https://discourse.hibernate.org/c/bean-validation">feedback forum</a> or sending a message to the <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">Bean Validation mailing list</a>.</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2016/11/23/survey-constraints-and-parameterized-type/Survey - Where do you use constraints on parameterized type?2023-11-03T14:56:33+00:002016-11-23T00:00:00+00:00Emmanuel Bernard
For Bean Validation 2, we are working on the support for Collection<@Email String>, Optional<@Min(3) Integer> etc.
This has been a very common request and with Java 8 type use support, we can how achieve this.
However, we need your feedback on how you would use such feature.
Some context
We have support not only for collections, Optional, Java FX properties but also for what we call custom parameterized containers.
We are wondering a few things about custom parameterized containers, namely how common they are.
This will affect the trade-offs we want to make on the design of that feature.
What is a container?
A container is a type...
<div id="preamble">
<div class="sectionbody">
<div class="paragraph">
<p>For Bean Validation 2, we are working on the support for <code>Collection<@Email String></code>, <code>Optional<@Min(3) Integer></code> etc.
This has been a very common request and with Java 8 type use support, we can how achieve this.
However, we need your feedback on how you would use such feature.</p>
</div>
</div>
</div>
<div class="sect1">
<h2 id="some-context"><a class="anchor" href="#some-context" />Some context</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We have support not only for collections, <code>Optional</code>, Java FX properties but also for what we call custom parameterized containers.
We are wondering a few things about custom parameterized containers, namely how common they are.
This will affect the trade-offs we want to make on the design of that feature.</p>
</div>
<div class="sect2">
<h3 id="what-is-a-container"><a class="anchor" href="#what-is-a-container" />What is a <em>container</em>?</h3>
<div class="paragraph">
<p>A container is a type that wraps and exposes one or several values.
The values is what you want to apply your constraints on.
And the container is parameterized because at use site, you can declare what type it actually contains.
For a <code>Set<@Email String></code>, we want to make sure every string in the set is an email.</p>
</div>
<div class="paragraph">
<p>Another less obvious example is a tuple class.</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="CodeRay highlight"><code data-lang="java"><span style="color:#088;font-weight:bold">public</span> <span style="color:#339;font-weight:bold">class</span> <span style="color:#B06;font-weight:bold">Pair</span><V1,V2> {
V1 getV1() { ... }
V2 getV2(); { ... }
}
<span style="color:#088;font-weight:bold">public</span> <span style="color:#339;font-weight:bold">class</span> <span style="color:#B06;font-weight:bold">Address</span> {
<span style="color:#777">// street1 is mandatory, street2 is optional</span>
<span style="color:#777">// represented via a Pair object</span>
Pair<<span style="color:#007">@NotNull</span> <span style="color:#007">@Size</span>(max=<span style="color:#00D">250</span>) <span style="color:#0a8;font-weight:bold">String</span>, <span style="color:#007">@Size</span>(max=<span style="color:#00D">250</span>) <span style="color:#0a8;font-weight:bold">String</span>> streetFields;
}</code></pre>
</div>
</div>
<div class="paragraph">
<p>Other examples are:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>a tree structure containing specific object types</p>
</li>
<li>
<p>Guava’s Multimap (or any multimap for that matter)</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="questions"><a class="anchor" href="#questions" />Questions</h2>
<div class="sectionbody">
<div class="paragraph">
<p>We are wondering which type of parameterized containers you have in your code base
and how likely you are going to apply constrains on their contained value.
The form is a list of short questions that will help us get a better picture.</p>
</div>
<div class="paragraph">
<p>Here is the <a href="https://docs.google.com/forms/d/e/1FAIpQLSc-s7fSYXiPSuZ0NaT0_-0jBx9TaxrZ-QiLRg_eVRxgrISjrw/viewform">link to the form in a separate page</a>
or use it directly embedded below.</p>
</div>
<iframe src="https://docs.google.com/forms/d/e/1FAIpQLSc-s7fSYXiPSuZ0NaT0_-0jBx9TaxrZ-QiLRg_eVRxgrISjrw/viewform?embedded=true" width="760" height="2800" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>
<div class="paragraph">
<p>Many thanks!</p>
</div>
</div>
</div>
http://beanvalidation.org/news/2016/09/15/which-constraints-to-add/Feedback needed - Which constraints should be added?2023-11-03T14:56:33+00:002016-09-15T00:00:00+00:00Gunnar Morling
The work on Bean Validation 2.0 is in full swing and there is an issue where we could benefit from your help.
Recently we have been discussing whether any new constraints should be added to the specification or not.
Traditionally, Bean Validation stayed on the conservative side of things in this regard.
It defined only some generically applicable and widely useful constraints in the specification itself, e.g. @NotNull, @Size or @Pattern.
Now Marco Molteni did a very interesting analysis on the constraints which are actually used in real world projects by running an analysis of open source projects hosted on GitHub.
Only a specific type...
<p>The work on Bean Validation 2.0 is in full swing and there is an issue where we could benefit from your help.</p>
<p>Recently we have been discussing whether any new constraints <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/2016-August/001000.html">should be added</a> to the specification or not.
Traditionally, Bean Validation stayed on the conservative side of things in this regard.
It defined only some generically applicable and widely useful constraints in the specification itself, e.g. <code>@NotNull</code>, <code>@Size</code> or <code>@Pattern</code>.</p>
<p>Now Marco Molteni did a very interesting analysis on the constraints which are actually used in real world projects by <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/2016-August/001000.html">running an analysis</a> of open source projects hosted on GitHub.
Only a specific type of project is hosted there usually (mostly libraries, as opposed to actual end user facing applications),
so the numbers should be taken with a grain of salt. But nevertheless they are very interesting.</p>
<p>Marco's analysis shows that besides the BV-defined constraints <code>@NotEmpty</code> and <code>@NotBlank</code> - both defined by the reference implementation Hibernate validator - are very frequently used and thus are potential candidates for inclusion into Bean Validation 2.0.
The former asserts that the annotated string, collection, map or array is neither null nor empty, the latter validates that the annotated string is neither null nor empty, stripping leading/trailing whitespace.</p>
<p>Another candidate may be <code>@Email</code>; but validation of e-mail addresses is a surprisingly complex business, with different people having different ideas and expectations of how a valid (or invalid) e-mail address should look like (take a look at the <a href="https://en.wikipedia.org/wiki/Email_address#Examples">examples on Wikipedia</a> to get an idea).
Hence I feel this is not something we should aim for in the specification.</p>
<p>To add some further data points, we created the following survey on constraints to be added potentially.
Getting back many answers to this poll will help us to form a better understanding of what you, the users out there, really need.
If you would like to see support for other constraints not mentioned in the survey, you can add them via the free-text field in the last question.
These may be custom constraints defined by a Bean Validation provider, a third-party library or in your own projects which you see yourself using very frequently.</p>
<p>Taking the survey will take you only a minute, so give it a go. Thanks a lot for your help!</p>
<iframe src="https://docs.google.com/forms/d/e/1FAIpQLScR9o9p2GlrmhrtSinp2D9PY8gN4C-AOA-bjm8bwXkX_4H1Sw/viewform?embedded=true" width="760" height="500" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>
http://beanvalidation.org/news/2016/07/15/bean-validation-2-0-is-coming/Bean Validation 2.0 - A new JSR is born!2023-11-03T14:56:33+00:002016-07-15T00:00:00+00:00Gunnar Morling
Today I've got some great news to share with you: a new revision of the Bean Validation spec is about to be kicked off!
Over the last weeks, we've been busy with preparing a proposal for this JSR and I've submitted it to the JCP (Java Community Process) last week.
You can find the proposal for "JSR 380: Bean Validation 2.0" on jcp.org.
In the following, let's take a look at what we think should be part of Bean Validation 2.0 and what we've planned as the next steps.
Looking back...
Bean Validation 1.0 and 1.1 (JSRs 303/349) saw a huge adoption by the Java...
<p>Today I've got some great news to share with you: a new revision of the Bean Validation spec is about to be kicked off!</p>
<p>Over the last weeks, we've been busy with preparing a proposal for this JSR and I've submitted it to the JCP (Java Community Process) last week.
You can find the proposal for "JSR 380: Bean Validation 2.0" on <a href="https://jcp.org/en/jsr/detail?id=380">jcp.org</a>.</p>
<p>In the following, let's take a look at what we think should be part of Bean Validation 2.0 and what we've planned as the next steps.</p>
<h2>Looking back...</h2>
<p>Bean Validation 1.0 and 1.1 (JSRs 303/349) saw a huge adoption by the Java community and are integrated with a wide range of technologies, be it other Java standards (e.g. CDI, JPA, JAX-RS)
or 3rd party libraries and frameworks such as Spring, Vaadin and many, many more.</p>
<p>The main contribution of Bean Validation 1.1 - the declarative validation of method-level constraints - has been integrated into techs such as CDI and Spring,
making it a breeze to write expressive API contracts with constraints which are automatically validated upon execution.</p>
<p>Bean Validation 1.1 has been finalized <a href="http://beanvalidation.org/news/2013/05/02/bean-validation-1-1-is-a-spec/">three years ago</a> and Java continued to evolve since then.
Java 8 - released in 2014 - brings many very interesting language features to the table, but also adds a new time and date API and much more.</p>
<h2>...and forward</h2>
<p>So it's about time that Bean Validation supports new JDK types such as <code>LocalTime</code> or <code>Optional</code>, but also takes advantage of new (language) features such as type annotations, repeatable annotations, reflective parameter name retrieval, lambda expressions etc.</p>
<p>To give just one example, let's consider the requirement of applying constraints to the elements of a specific collection.
This has been a <a href="https://hibernate.atlassian.net/browse/BVAL-202">long-standing feature request</a>, but we could never find a way to solve it generically in an acceptable manner.</p>
<p>Java 8 finally provides the perfect tool to solve this issue: <a href="https://docs.oracle.com/javase/tutorial/java/annotations/type_annotations.html">type annotations</a>.
Annotating type parameters of collections is a very intuitive way to apply constraints to collection elements (and not the entire collection itself):</p>
<pre><code>List<@Email String> emails;
</code></pre>
<p>Java 8 provides the required APIs to retrieve the constraint annotation from the type parameter and apply the validation accordingly.</p>
<p>But it doesn't stop there.
Repeatable annotation types will make it less verbose to specify several constraints of the same type one and the same element.
Reflective parameter name retrieval will provide better validation messages out of the box when validating constraints on method parameters.
Lambda expressions might be a useful vehicle to express small ad-hoc validation routines.</p>
<h2>What else?</h2>
<p>While we envision supporting and leveraging Java 8 as the "main theme" of Bean Validation 2.0, we hope to address some other issues, too.
E.g. there may be support for more customized payloads of constraint violations.
Also a builder API for constraint violation exceptions might be useful.
As would an API for validating an object graph assuming a list of changes to be applied.
Check out the <a href="https://jcp.org/en/jsr/detail?id=380">JSR 380 proposal</a> for some more ideas we have.</p>
<p>While the baseline for Bean Validation 2.0 will be Java 8, we'll also be tracking the ongoing work for Java 9 and work towards making Bean Validation ready for Java 9 and its module system as far as possible.</p>
<p>As the time-line of Bean Validation 2.0 is quite compact, we are very eager to hear from you, the community of users, and learn what would be the things most useful to you.
For sure we won't be able to address all potential ideas out there. So if there are features close to your heart which you'd really love to see in the spec, be sure to speak up and let us know.</p>
<h2>What's next?</h2>
<p>As per <a href="https://jcp.org/en/procedures/jcp2#3.3">the rules</a> of the Java Community Process, the Bean Validation 2.0 JSR is currently up for review by the JCP executive committee.
After that, there will be an approval ballot and we will hopefully be ready to go and kick off the work on actual spec changes, prototyping new features in the reference implementation and so on.</p>
<p>So if you ever wanted to contribute to a Java Specification Request - be it just by voting for issues, opening new feature requests or actually working on the specification, its reference implementation and the test compatability kit (TCK) - then this is the perfect time.
If you are a member of the JCP, you also can <a href="https://jcp.org/en/jsr/egnom?id=380">join the expert group</a>, we'd be very happy to have you aboard.</p>
<p>Whether EG member or not, in order to get the discussion on this JSR proposal started, just drop a comment below, post to the <a href="https://discourse.hibernate.org/c/bean-validation">feedback forum</a>, shoot a message to the <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">Bean Validation mailing list</a> or
comment on specific issues in <a href="https://hibernate.atlassian.net/projects/BVAL/summary">the tracker</a>.</p>
<p>We are looking forward to hearing from you and get Bean Validation 2.0 rolling!</p>
http://beanvalidation.org/news/2015/06/18/bean-validation-tck-1-1-4-released/Bean Validation TCK 1.1.4.Final released2023-11-03T14:56:33+00:002015-06-18T00:00:00+00:00Gunnar Morling
Exactly one year after the last maintenance release we've published version 1.1.4.Final of the Bean Validation TCK today.
It contains exactly one issue, BVTCK-68,
which is about the removal of two tests from the TCK which could not be tested in a portable manner across containers.
Check out the issue itself for the complete story.
As always, the new TCK version is available for download as TAR.GZ and ZIP on SourceForge.
Alternatively you can obtain the test suite via Maven, Gradle etc. using the coordinates org.hibernate.beanvalidation.tck:beanvalidation-tck-tests:1.1.4.Final.
More information about the Bean Validation TCK can be found here and the TCK reference guide.
In case you have any...
<p>Exactly one year after the last maintenance release we've published version 1.1.4.Final of the Bean Validation TCK today.
It contains exactly one issue, <a href="https://hibernate.atlassian.net/browse/BVTCK-68">BVTCK-68</a>,
which is about the removal of two tests from the TCK which could not be tested in a portable manner across containers.
Check out the issue itself for the complete story.</p>
<p>As always, the new TCK version is available for download as TAR.GZ and ZIP on <a href="http://sourceforge.net/projects/hibernate/files/beanvalidation-tck/1.1.4.Final/">SourceForge</a>.
Alternatively you can obtain the test suite via Maven, Gradle etc. using the coordinates <em>org.hibernate.beanvalidation.tck:beanvalidation-tck-tests:1.1.4.Final</em>.</p>
<p>More information about the Bean Validation TCK can be found <a href="http://beanvalidation.org/1.1/tck/">here</a> and the <a href="https://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_single/">TCK reference guide</a>.
In case you have any questions or ideas around the Bean Validation specification in general or the TCK
in particular, don't hesitate to contact us through <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">our mailing list</a>.</p>
http://beanvalidation.org/news/2014/06/18/bean-validation-tcks-now-with-support-for-java-se-8/Bean Validation TCKs now with signature files for Java SE 82023-11-03T14:56:33+00:002014-06-18T00:00:00+00:00Gunnar Morling
Good news for those of you who want to certify the compatibility of a Bean Validation
implementation (and its API JAR) against Java SE 8.
We have released updates to the Bean Validation TCK 1.0 and 1.1;
The versions are 1.0.7.GA and 1.1.3.Final, respectively.
Both TCK releases come now with a version of the API signature file which works with Java SE 8.
This signature file can be used to assert API compatibility with JSR 303/349 via
the SigTest tool.
SigTest 3.0 needs to be used from now on. Note that the actual tests of the TCKs remain unchanged.
You can get distribution bundles with the new signature...
<p>Good news for those of you who want to certify the compatibility of a Bean Validation
implementation (and its API JAR) against Java SE 8.</p>
<p>We have released updates to the Bean Validation TCK 1.0 and 1.1;
The versions are 1.0.7.GA and 1.1.3.Final, respectively.
Both TCK releases come now with a version of the API signature file which works with Java SE 8.
This signature file can be used to assert API compatibility with JSR 303/349 via
the <a href="https://wiki.openjdk.java.net/display/CodeTools/SigTest">SigTest</a> tool.
SigTest 3.0 needs to be used from now on. Note that the actual tests of the TCKs remain unchanged.</p>
<p>You can get distribution bundles with the new signature file from SourceForge
(<a href="http://sourceforge.net/projects/hibernate/files/beanvalidation-tck/1.0.7.GA/">1.0</a>,
<a href="http://sourceforge.net/projects/hibernate/files/beanvalidation-tck/1.1.3.Final/">1.1</a>).</p>
<p>More information about the Bean Validation TCK can be found <a href="http://beanvalidation.org/1.1/tck/">here</a>.
Refer to the TCK reference guide (<a href="https://docs.jboss.org/hibernate/beanvalidation/tck/1.0/reference/html_single/#sigtest">1.0</a>, <a href="https://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_single/#sigtest">1.1</a>)
if you would like to learn more about the process of asserting API compatibility.</p>
<p>Don't hesitate to <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">contact us</a>
in case you have any questions around the Bean Validation specification in general or the TCK
in particular.</p>
http://beanvalidation.org/news/2014/05/28/training-materials/Training materials on Bean Validation 1.12023-11-03T14:56:33+00:002014-05-28T00:00:00+00:00Emmanuel Bernard
I have two good Bean Validation related content for you today.
Training slides (in French)
Laurent Guerin wrote a comprehensive training on Bean Validation (1.0 and 1.1) for French students.
The slides are available under a Creative Commons license.
I did review them and they are very good.
The bad news is that they are in French.
The good news is that they are in French!
Video training (in English)
Antonio Goncalves, my esteemed co-host of Les Cast Codeurs has published
a 2 and a half hour video training on Bean Validation.
It is hosted on Pluralsight where packages start at $29 / month but you can get the first...
<p>I have two good Bean Validation related content for you today.</p>
<h2>Training slides (in French)</h2>
<p>Laurent Guerin wrote a comprehensive training on Bean Validation (1.0 and 1.1) for French students.
The <a href="http://fr.slideshare.net/lguerin/cours-javabean-validationv11">slides are available</a> under a Creative Commons license.
I did review them and they are very good.</p>
<p>The bad news is that they are in French.
The good news is that they are in French!</p>
<h2>Video training (in English)</h2>
<p>Antonio Goncalves, my esteemed co-host of <a href="http://lescastcodeurs.com">Les Cast Codeurs</a> has published
a <a href="http://pluralsight.com/training/Courses/Description/bean-validation">2 and a half hour video training</a> on Bean Validation.
It is hosted on Pluralsight where packages start at $29 / month but you can get the first 10 days free.</p>
<p>The good news is that Antonio has a Dr Love / French accent combo voice.
The bad news? I'll let you find out ;)</p>
<p>Let me know if you have found good materials on Bean Validation.
We might start a dedicated page on the website.</p>
http://beanvalidation.org/news/2013/06/04/xml-namespace-and-jcp/XML namespace and JCP2023-11-03T14:56:33+00:002013-06-04T00:00:00+00:00Emmanuel Bernard
Antonio Goncalves, fellow JCP member and friend has asked
me
why Bean Validation XML's namespace has not moved from its original location to
the jcp.org location like other Java EE 7 specifications.
I don't remember being aware that such a move was orchestrated so there are two
possible reasons:
I was never been made aware of the move,
I was aware of it but considered that it was low priority compared to the other
issues we were working on.
Provided we had to work hard till the last minute, and that the community never
was keen on the XML support we put in Bean Validation, #2 is not impossible but
I...
<p>Antonio Goncalves, fellow JCP member and friend <a href="http://antoniogoncalves.org/2013/06/04/java-ee-7-deployment-descriptors/">has asked
me</a>
why Bean Validation XML's namespace has not moved from its original location to
the jcp.org location like other Java EE 7 specifications.</p>
<p>I don't remember being aware that such a move was orchestrated so there are two
possible reasons:</p>
<ol>
<li>I was never been made aware of the move,</li>
<li>I was aware of it but considered that it was low priority compared to the <a href="https://hibernate.atlassian.net/issues/?jql=project%20%3D%20BVAL%20AND%20fixVersion%20in%20(%221.1.0.Alpha1%20(early%20draft%201)%22%2C%20%221.1.0.Beta1%20(public%20draft%201)%22%2C%20%221.1.0.Beta2%22%2C%20%221.1.0.Beta3%22%2C%20%221.1.0.Beta4%22%2C%20%221.1.0.CR1%22%2C%20%221.1.0.CR2%22%2C%20%221.1.0.CR3%22%2C%20%221.1.0.Final%22)%20AND%20status%20in%20(Resolved%2C%20Closed)">other
issues</a> we were working on.</li>
</ol>
<p>Provided we had to work hard till the last minute, and that the community never
was keen on the XML support we put in Bean Validation, #2 is not impossible but
I suspect it's #1 or I would have opened an issue to track the task.</p>
<p>Anyways, that's not a problem. Anyone can open an issue (I've just <a href="https://hibernate.atlassian.net/browse/BVAL-455">created
one</a> for this task), write a
couple of pull requests to fix the spec, TCK and RI as explained in <a href="http://beanvalidation.org/contribute/">our
contribute section</a>. Scratch your own itch: so who's jumping? :)</p>
<p>We will have to wait for the next version of the spec to avoid breaking older
applications but if it's committed, it won't be forgotten.</p>
<p>PS: no, I'm not bitter, but since I haven't blogged in a while that was a good
occasion to remind everyone of the power of contributions ;)</p>
http://beanvalidation.org/news/2013/05/02/bean-validation-1-1-is-a-spec/Bean Validation 1.1 is a spec2023-11-03T14:56:33+00:002013-05-02T00:00:00+00:00Emmanuel Bernard
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 (Validator and ValidatorFactory injectable,
ConstraintValidator instances 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...
<p>It's now official, these couple of years of work have made it into <a href="http://jcp.org/en/jsr/results?id=5488">an
official JCP specification</a>.
Bean Validation is also part of Java EE 7 which has
<a href="https://blogs.oracle.com/theaquarium/entry/java_ee_7_platform_completes">been approved too</a>
a few of days ago.</p>
<p>We have already discussed the features at great length here but to do a short
summary:</p>
<ul>
<li>support for method and constructor validation (via CDI, JAX-RS etc)</li>
<li>integration with CDI (<code>Validator</code> and <code>ValidatorFactory</code> injectable,
<code>ConstraintValidator</code> instances being CDI beans and thus accept <code>@Inject</code>,
etc)</li>
<li>EL expressions based error messages</li>
<li>group conversion in object graphs</li>
</ul>
<p>I would like to thank the <strong>expert group</strong> and the <strong>community</strong> at large (without your
input there would be no 1.1), <strong>Hardy</strong> and <strong>Gunnar</strong> that worked round to clock on the
spec, the RI and the TCK and deliver everything on time, <strong>Pete</strong> for being my
springboard when all hell broke lose and the <strong>folks at Oracle</strong> who worked with us
to integrate Bean Validation with the rest of the Java EE ecosystem whether it
be spec, implementation or TCK.</p>
<p>Go grab <a href="http://validator.hibernate.org">Hibernate Validator</a>, 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 <a href="http://beanvalidation.org/1.1/">specification itself</a>.</p>
http://beanvalidation.org/news/2013/03/21/bean-validation-1-1-final-approval-ballot/Bean Validation 1.1 CR3 - Final Approval Ballot2023-11-03T14:56:33+00:002013-03-21T00:00:00+00:00Emmanuel Bernard
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...
<p>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.</p>
<p>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 <code>@ValidateExecutable</code> into <code>@ValidateOnExecution</code> and we added a
way to disable method validation entirely via the XML deployment descriptor.</p>
<p>We worked hard to make a stellar TCK. Let's speak numbers: the specification
has <strong>549 assertions</strong> including <strong>492 testable</strong>. We cover <strong>98,8%</strong> of them
with <strong>1500 tests</strong>. Good luck to all future Bean Validation 1.1 implementors
:)</p>
<p>Everything is already available for you to use:</p>
<ul>
<li><a href="http://beanvalidation.org/1.1/spec/1.1.0.cr3/">the specification</a></li>
<li><a href="http://www.hibernate.org/subprojects/validator/download">Hibernate Validator (the
RI)</a></li>
<li><a href="http://www.hibernate.org/subprojects/validator/download">the TCK</a></li>
</ul>
<p>Enjoy!</p>
http://beanvalidation.org/news/2013/02/20/bean-validation-1-1-proposed-final-draft/Bean Validation 1.1 CR1 - Proposed Final Draft2023-11-03T14:56:33+00:002013-02-20T00:00:00+00:00Emmanuel Bernard
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...
<p>Our Proposed Final Draft has been officially handed over to the JCP last night.</p>
<p>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:</p>
<ul>
<li><a href="http://beanvalidation.org/1.1/spec/1.1.0.cr1/?utm_source=blog&utm_medium=web&utm_content=spec&utm_campaign=1_1_cr1">the spec</a></li>
<li><a href="http://docs.jboss.org/hibernate/beanvalidation/spec/1.1/api/">the JavaDoc</a></li>
<li>and the API JAR: maven coordinates <a href="https://repository.jboss.org/nexus/content/groups/public-jboss/javax/validation/validation-api/1.1.0.CR1/">javax.validation:validation-api:1.1.0.CR1</a></li>
</ul>
<h2>What's new in Bean Validation 1.1?</h2>
<p>The specification
<a href="http://beanvalidation.org/1.1/spec/1.1.0.cr1/#whatsnew">highlights very well</a>
the main features of this version but to summarize them:</p>
<ul>
<li>work done entirely in the open</li>
<li>support for dependency injection and better integration with CDI</li>
<li>support for method and constructor validation</li>
<li>support for group conversion when cascading</li>
<li>support for EL based message interpolation</li>
</ul>
<h2>What's different between Beta 4 and CR 1?</h2>
<p>We did a lot of polishing and nailed a lot of remaining corner cases. Here is a
few of the tasks we worked on:</p>
<ul>
<li>rework of the JavaDoc</li>
<li>move to <code>@SupportValidationTarget</code> on <code>ConstraintValidator</code> instead of the
additional <code>@CrossParameterConstraint</code> on the constraint to mark a constraint
as cross-parameter</li>
<li>many more examples in the specification</li>
<li>improve node creation logic when nodes are added programmatically</li>
<li>improve the creation logic of custom nodes when using the programmatic API of
<code>ConstraintViolationBuilder</code> in a <code>ConstraintValidator</code></li>
</ul>
<p>And of course many hours rereading the specification to find holes and fix them.</p>
<h2>Review</h2>
<p>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.</p>
<p>You can <a href="http://beanvalidation.org/1.1/spec/1.1.0.cr1/?utm_source=blog&utm_medium=web&utm_content=spec&utm_campaign=1_1_cr1">access the specification here</a>.
All changes are marked with a different
color. <span style="background-color:#DDFFDD;">Green for additions</span>,
<span style="background-color:#FFFFDD;">yellow for changes</span>.
This will help you see what has changed precisely.</p>
<p>Please send us your remarks and comments:</p>
<ul>
<li>on our <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">mailing list</a></li>
<li>in our <a href="http://beanvalidation.org/issues">issue tracker</a></li>
<li>or on the Bean Validation <a href="https://discourse.hibernate.org/c/bean-validation">forum</a></li>
</ul>
<p>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.</p>
http://beanvalidation.org/news/2013/02/15/bean-validation-1-1-beta4/Bean Validation 1.1 Beta 4 - issue smashing edition2023-11-03T14:56:33+00:002013-02-15T00:00:00+00:00Emmanuel Bernard
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...
<p>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:</p>
<h2>Improvements on the CDI integration section</h2>
<p>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.</p>
<p>Thanks Pete for your help.</p>
<h2>Remove the link between the Node API and the metadata API</h2>
<p>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.</p>
<pre><code>//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();
</code></pre>
<h2>Clarification around method validation (metadata, cross-parameter, reports)</h2>
<p>We now have an explicit cross-parameter concept materialized in the metadata
API. It makes for a more regular and easier to browse API.
<code>ConstraintViolation</code> has also seen some improvements and adaptations to make
it ready for prime - method validation - time.</p>
<h2>Mark a method as (non) validated</h2>
<p>We slightly improved <code>@ValidateExecutable</code> 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.</p>
<pre><code>public class Operations {
@ValidateExecutable
@Status
public String getStatus() { ... }
@ValidateExecutable(ExecutableType.NONE)
public void apply(@Valid Operation operation) { ... }
}
</code></pre>
<h2>Review</h2>
<p>Let us know what you think.</p>
<p>You can <a href="http://beanvalidation.org/1.1/spec/1.1.0.beta4/?utm_source=blog&utm_medium=web&utm_content=spec&utm_campaign=1_1_beta4">access the specification here</a>.
All changes are marked with a different
color. <span style="background-color:#DDFFDD;">Green for additions</span>,
<span style="background-color:#FFFFDD;">yellow for changes</span> and
<span style="text-decoration: line-through;background-color: #FFDDDD;">struck through red for removals</span>
. This will help you see what has changed precisely.</p>
<p>Please send us your remarks and comments:</p>
<ul>
<li>on our <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">mailing list</a></li>
<li>in our <a href="http://beanvalidation.org/issues">issue tracker</a></li>
<li>or on the Bean Validation <a href="https://discourse.hibernate.org/c/bean-validation">forum</a></li>
</ul>
<p>If you want to go to the next step and contribute, send us an email to
the mailing list and read <a href="http://beanvalidation.org/contribute/">how to contribute</a>.</p>
http://beanvalidation.org/news/2013/02/05/javaspotlight-podcast-on-bean-validation-1-1/Java Spotlight Podcast on Bean Validation 1.12023-11-03T14:56:33+00:002013-02-05T00:00:00+00:00Emmanuel Bernard
Roger Brinkle from Java Spotlight Podcast
has interviewed me on the status of Bean Validation 1.1. It's 20 mins long so you
won't suffer too much :)
The podcast is available here.
Unfortunately the audio of the interview is not great, so if you find it hard
to follow, I have put an alternative recording with better quality of the
interview itself. Get the mp3....
<p>Roger Brinkle from <a href="https://blogs.oracle.com/javaspotlight/">Java Spotlight Podcast</a>
has interviewed me on the status of Bean Validation 1.1. It's 20 mins long so you
won't suffer too much :)</p>
<p>The podcast is available <a href="http://goo.gl/UphGL">here</a>.
Unfortunately the audio of the interview is not great, so if you find it hard
to follow, I have put an alternative recording with better quality of the
interview itself. <a href="http://beanvalidation.org/downloads/javaspotlight-119-interview.mp3">Get the mp3</a>.</p>
http://beanvalidation.org/news/2013/02/01/bean-validation-1-1-beta3-last-line/Bean Validation 1.1 Beta 3 - the last line2023-11-03T14:56:33+00:002013-02-01T00:00:00+00:00Emmanuel Bernard
With two months since the last release and more than 38 (non trivial)
issues behind us, we felt that it was a good time to release a new version.
We are less than 20 days from the proposed final draft so feedback time and
polishing are going into overdrive.
Expect a reference implementation and a much improved TCK aligned with this
version in the next few days.
What's new
There are too many improvements so let's pick three.
Enable / disable method validation
We worked a lot on method validation and in particular how you can control
whether or not a method or constructor is being validated. You can use
@ValidateExecutable...
<p>With two months since the last release and more than 38 (non trivial)
issues behind us, we felt that it was a good time to release a new version.
We are less than 20 days from the proposed final draft so feedback time and
polishing are going into overdrive.</p>
<p>Expect a reference implementation and a much improved TCK aligned with this
version in the next few days.</p>
<h2>What's new</h2>
<p>There are too many improvements so let's pick three.</p>
<h3>Enable / disable method validation</h3>
<p>We worked a lot on method validation and in particular how you can control
whether or not a method or constructor is being validated. You can use
<code>@ValidateExecutable</code> and the XML <code>validated-executables</code> element in
<code>validation.xml</code> to do that.</p>
<h3>Message interpolation with UEL</h3>
<p>We have also greatly enhanced message interpolation. You can now use the unified
expression language inside your messages. This elegantly solves a lot of feature
requests we had in this area like:</p>
<ul>
<li>the ability to put the validated value in the message</li>
<li>the ability to format numbers, dates etc according to the locale</li>
</ul>
<p>Here is an example from <code>@DecimalMin</code>. It uses the min boundary <code>value</code>, the
<code>inclusive</code> parameter in an EL and use a formaatter to display the erroneous
value:</p>
<pre><code>${formatter.format("%1$2f", validatedValue} is incorrect ; must be greater than ${inclusive == true ? 'or equal to ' : ''}{value}
</code></pre>
<p>Which will be interpolated into</p>
<pre><code>324.32 is incorrect ; must be greater than or equal to 500
</code></pre>
<h3>Generic and cross-parameter constraints</h3>
<p>Finally we have introduce the ability to make constraints both generic and
cross-parameter aware. This is useful for constraints like <code>@ScriptAssert</code> that
are very flexible.</p>
<h2>Review</h2>
<p>Please, please, please go and review the specification and tell us if something
needs to be fixed.</p>
<p>You can <a href="http://beanvalidation.org/1.1/spec/1.1.0.beta3/?utm_source=blog&utm_medium=web&utm_content=spec&utm_campaign=1_1_beta3">access the specification here</a>.
All changes are marked with a different
color. <span style="background-color:#DDFFDD;">Green for additions</span>,
<span style="background-color:#FFFFDD;">yellow for changes</span> and
<span style="text-decoration: line-through;background-color: #FFDDDD;">struck through red for removals</span>
. This will help you see what has changed precisely.</p>
<p>Please send us your remarks and comments:</p>
<ul>
<li>on our <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">mailing list</a></li>
<li>in our <a href="http://beanvalidation.org/issues">issue tracker</a></li>
<li>or on the Bean Validation <a href="https://discourse.hibernate.org/c/bean-validation">forum</a></li>
</ul>
<p>If you want to go to the next step and contribute, send us an email to
the mailing list and read <a href="http://beanvalidation.org/contribute/">how to contribute</a>.</p>
http://beanvalidation.org/news/2012/12/18/bean-validation-in-the-press/Bean Validation in the press2023-11-03T14:56:33+00:002012-12-18T00:00:00+00:00Gunnar Morling
The German journal Javamagazin recently
published an article about the works on Bean Validation 1.1. The article
is full of praise for the new version in general and our open,
community-centered way of creating the spec in particular.
The publisher and authors generously provided us with a PDF of the article
which you can download here.
Alternatively you can also read the article
online....
<p>The German journal <a href="http://www.javamagazin.de/">Javamagazin</a> recently
published an article about the works on Bean Validation 1.1. The article
is full of praise for the new version in general and our open,
community-centered way of creating the spec in particular.</p>
<p>The publisher and authors generously provided us with a PDF of the article
which you can download <a href="http://beanvalidation.org/downloads/javamagazin_2012_10_Einer_fuer_alle_alle_fuer_einen_Bean_Validation_1_1.pdf">here</a>.
Alternatively you can also read the article
<a href="http://it-republik.de/jaxenter/artikel/Einer-fuer-alle-%96-alle-fuer-einen-Bean-Validation-1.1-5372.html">online</a>.</p>
http://beanvalidation.org/news/2012/12/11/should-getters-be-considered-methods/Should getters be validated when they are called?2023-11-03T14:56:33+00:002012-12-11T00:00:00+00:00Emmanuel Bernard
The expert group is agonizing on a specific issue. We need your
feedback. Should getters be considered regular methods and thus be validated
when called?
The problem
Existing applications put Bean Validation constraints on properties
(ie getters). If we enable validations when getters are called, some
applications might fail and Bean Validation would not be backward
compatible. Besides, it is unlikely that you want to validate genuine getters
when they are called. These are state, not operations for the most part.
First off what does it mean to be a getter. A method is a getter if:
its name starts with is, has no parameter and its return type is...
<p>The expert group is agonizing on a specific issue. We need your
feedback. Should getters be considered <em>regular</em> methods and thus be validated
when called?</p>
<h2>The problem</h2>
<p>Existing applications put Bean Validation constraints on properties
(ie getters). If we enable validations when getters are called, some
applications might fail and Bean Validation would not be backward
compatible. Besides, it is unlikely that you want to validate genuine getters
when they are called. These are state, not operations for the most part.</p>
<p>First off what does it mean to be a getter. A method is a getter if:</p>
<ul>
<li>its name starts with <code>is</code>, has no parameter and its return type is <code>Boolean</code></li>
<li>or its name starts with <code>get</code> and has not parameter</li>
</ul>
<p>If in your service (say a CDI bean), you have an action method with
no parameter and starting with <code>get</code>, and if you have added constraints
to validate the return value upon method call, we cannot differentiate
this action method from a genuine getter.</p>
<p>We have several solutions to work around the problem and we would like
to know which one you prefer.</p>
<h2>Solutions</h2>
<p>We can use a few levers to work around the issue:</p>
<ul>
<li>ask you to enable method validation explicitly</li>
<li>offer a coarse or fine grained solution to change the default behavior</li>
</ul>
<h3>Solution 1: enable method validation out of the box</h3>
<p>If method validation is enabled out of the box then the sensible default is
to exclude getters from method validation.</p>
<p>This approach is friendly out of the box and will work as expected most of
the time (except for action methods with no parameter, starting with <code>get</code>
and with constraints on the return value).</p>
<p>The downside of this approach is that in this very specific case where
an action method is also a getter, method validation would be disabled
out of the box and a manual intervention would be necessary.</p>
<p>You can change the default approach in two ways:</p>
<h4>Solution 1.a: global flag</h4>
<p>Use a global flag to disable method validation entirely or ask for getters
to be validated upon call. You would use <code>validation.xml</code> for that:</p>
<pre><code><method-validation mode="INCLUDE_GETTERS"/>
</code></pre>
<p>There is no way to change the behavior for a specific (set of) class.</p>
<h4>Solution 1.b: fine grained flag</h4>
<p>An alternative solution is to change method validation behavior in a
much more fine-grained approach:</p>
<ul>
<li>set the default approach globally
in <code>validation.xml</code></li>
<li>set or override the setting for a given package (including sub-packages?)
via <code>@ValidateOnCall</code> as a package annotation (or <code>validation.xml</code>)</li>
<li>set or override the setting for a given class
via <code>@ValidateOnCall</code> as a type annotation (or <code>validation.xml</code>)</li>
<li>set or override the setting for a given method
via <code>@ValidateOnCall</code> as a method annotation (or <code>validation.xml</code>)</li>
</ul>
<p>A <code>@ValidateOnCall</code> annotation can be overridden in <code>validation.xml</code> like we do for
constraints declarations.</p>
<pre><code>public class AwesomeService {
// not a getter - validated by default
@NotNull Currency provideMainCurrency(@ISO @NotNull String country) { ... }
// not a getter - validated by default
@NotNull Currency getAlternativeCurrencies(@ISO @NotNull String country) { ... }
// getter - must use @ValidateOnCall to activate
@ValidateOnCall(mode=INCLUDE_GETTERS)
@NotNull getAllCurrencies() { ... }
}
</code></pre>
<p>Note that, we could put <code>@ValidateOnCall(mode=INCLUDE_GETTERS)</code> on the package
of service classes</p>
<pre><code>@ValidateOnCall(mode=INCLUDE_GETTERS)
package com.acme.gladiator.action;
</code></pre>
<p>In this case, <code>getAllCurrencies()</code> does not need to be annotated with <code>@ValidateOnCall</code>.</p>
<h3>Solution 2: disable method validation out of the box</h3>
<p>In this situation, a user wanting to enable method validation needs to both:</p>
<ul>
<li>add the constraints on methods</li>
<li>add the flag to enable method validation</li>
</ul>
<p>The method validation flag would both allow it to be enabled and decide if getters
should be considered.</p>
<p>This approach is the least surprise approach as nothing is happening that you
have not explicitly asked for. The drawback is that it requires a manual intervention to enable
method validation in a given archive which is not groovy.</p>
<h4>Solution 2.a: global flag</h4>
<p>For all archives using method validation, a <code>META-INF/validation.xml</code> file must
be added. The file would contain the explicit setting:</p>
<pre><code><method-validation mode="INCLUDE_GETTER"/>
</code></pre>
<p>There is no way to change the behavior for a specific (set of) classes.</p>
<h4>Solution 2.b: fine grained flag</h4>
<p>As described in the previous section, we could enable method validation at
the package, class and method level using either a <code>@ValidateOnCall</code> annotation
or via the <code>validation.xml</code>. In this approach, <code>validation.xml</code> is not mandatory
to enable method validation provided that you use <code>@ValidateOnCall</code> in your code.</p>
<h2>So what's your favorite?</h2>
<p>My personal favorite is to enable non-getter method validation out of the
box and offer fine-grained options to override the behavior. That's solution
1.b. My reasoning is the following:</p>
<ul>
<li>I want ease of use and method validation enabled by default</li>
<li>actions methods named like a getter, with no parameter and constraints
on its return value will be rare - return value constraint are less common
than parameter methods</li>
</ul>
<p>Some in the expert group do prefer solution 2.a or 2.b.</p>
<p>What's your take? And why do you prefer this approach?</p>
http://beanvalidation.org/news/2012/11/29/public-review-ballot/Public review ballot favorable to Bean Validation 1.12023-11-03T14:56:33+00:002012-11-29T00:00:00+00:00Emmanuel Bernard
The Java expert comity has just approved
the public review version of Bean Validation 1.1.
What does that mean for the spec? We keep going and carry on our work
to finalize the specification.
Onwards....
<p>The Java expert comity has <a href="http://jcp.org/en/jsr/results?id=5386">just approved</a>
the public review version of Bean Validation 1.1.</p>
<p>What does that mean for the spec? We keep going and carry on our work
to finalize the specification.</p>
<p>Onwards.</p>
http://beanvalidation.org/news/2012/11/27/1-1-beta2-is-out/Bean Validation 1.1 Beta 2 is out2023-11-03T14:56:33+00:002012-11-27T00:00:00+00:00Emmanuel Bernard
With Hibernate Validation, the reference implementation catching
up with the public review draft, we found a couple of minor glitches
to actually implement the specification. We did a minor release
to fix those glitches.
Check out the specification and make sure to
use 1.1.0.Beta2 if you plan on implementing the specification early....
<p>With Hibernate Validation, the reference implementation catching
up with the public review draft, we found a couple of minor glitches
to actually implement the specification. We did a minor release
to fix those glitches.</p>
<p>Check out the <a href="http://beanvalidation.org/1.1/spec/1.1.0.beta2">specification</a> and make sure to
use 1.1.0.Beta2 if you plan on implementing the specification early.</p>
http://beanvalidation.org/news/2012/10/22/release-1-1-public-review/Public Review Draft for Bean Validation 1.12023-11-03T14:56:33+00:002012-10-22T00:00:00+00:00Emmanuel Bernard
Last Friday I have handed over the Public Review Draft to the JCP.
Beyond the new features and polishing of existing ones (see below),
the Public Review Draft marks the point where:
the community at large is invited to comment on the specification before the last
leg of work towards the final release starts
the JCP executive commitee votes on the current work at the end of the review
period
We have been doing our work in the open but if you have not yet paid much attention
now is the time to fix that :)
You can access the draft on this website.
All changes are marked with a...
<p>Last Friday I have handed over the Public Review Draft to the JCP.</p>
<p>Beyond the new features and polishing of existing ones (see below),
the Public Review Draft marks the point where:</p>
<ul>
<li>the community at large is invited to comment on the specification before the last
leg of work towards the final release starts</li>
<li>the JCP executive commitee votes on the current work at the end of the review
period</li>
</ul>
<p>We have been doing our work in the open but if you have not yet paid much attention
now is the time to fix that :)</p>
<p>You can <a href="http://beanvalidation.org/1.1/spec/1.1.0.beta1/?utm_source=blog&utm_medium=web&utm_content=spec&utm_campaign=1_1_pr1">access the draft on this website</a>.
All changes are marked with a different
color. <span style="background-color:#DDFFDD;">Green for additions</span>,
<span style="background-color:#FFFFDD;">yellow for changes</span> and
<span style="text-decoration: line-through;background-color: #FFDDDD;">struck through red for removals</span>
. This will help you see what has changed precisely.</p>
<p>Please send us your remarks and comments:</p>
<ul>
<li>on our <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">mailing list</a></li>
<li>in our <a href="http://beanvalidation.org/issues">issue tracker</a></li>
<li>or on the Bean Validation <a href="https://discourse.hibernate.org/c/bean-validation">forum</a></li>
</ul>
<p>If you want to go to the next step and contribute, send us an email to
the mailing list and read <a href="http://beanvalidation.org/contribute/">how to contribute</a>.</p>
<h2>What's new in this draft</h2>
<p>A lot of work has been done to polish or rework the features introduced
in the first draft. We have also added a few additional improvements:</p>
<ul>
<li>improved integration with CDI: dependency injection, component
lifecycle management and interception for method validation</li>
<li>add rules describing method validation in particular how an interception
technology ought to integrate: this will offer better portability</li>
<li>add support for cross parameter validators on method validation</li>
<li>add metadata APIs to identify constrained methods</li>
<li>add support for group conversion (i.e., change the targeted group when
cascading validation)</li>
<li>clarify that composed constraints should fail fast when <code>@RepostAsSingleViolation</code>
is present</li>
<li>support <code>CharSequence</code> (used to be <code>String</code>) for built-in constraints</li>
</ul>
<h2>Contributions</h2>
<p>As usual, many thanks to the community for its feedback, the expert group for its
work. Special thanks to Gunnar and Hardy who worked round the clock this past two
weeks to integrate all planned improvements in the specification document.</p>
http://beanvalidation.org/news/2012/09/12/fine-control-over-method-validation/Fine control over method validation in Bean Validation... or not!2023-11-03T14:56:33+00:002012-09-12T00:00:00+00:00Emmanuel Bernard
I need your feedback on whether or not you need fine controls on method
validation.
Some context
Bean Validation 1.1 introduces the idea of method validation. When
the method is called, parameters and return value can be validated.
The constraints are of course defined as Bean Validation constraint
annotations.
I am working on the chapter describing how interceptor technologies like
CDI, EJB, Spring, Guice, AspectJ should integrate it.
We have decided to convert most of the
recommendations into mandatory rules. In particular, methods annotated
with constraints should be validated by the integration technology
by default.
Early in the design we have introduced an annotation @MethodValidated
that lets you control a few things:
which group should...
<p>I need your feedback on whether or not you need fine controls on method
validation.</p>
<h2>Some context</h2>
<p>Bean Validation 1.1 introduces the idea of method validation. When
the method is called, parameters and return value can be validated.
The constraints are of course defined as Bean Validation constraint
annotations.</p>
<p>I am working on the chapter describing how interceptor technologies like
CDI, EJB, Spring, Guice, AspectJ should integrate it.</p>
<p>We have decided to convert most of the
recommendations into mandatory rules. In particular, methods annotated
with constraints should be validated by the integration technology
by default.</p>
<p>Early in the design we have introduced an annotation <code>@MethodValidated</code>
that lets you control a few things:</p>
<ul>
<li>which group should be used for validation (defaulting to <code>Default</code>)</li>
<li>what part should be validated: parameters, return value, both or none</li>
</ul>
<p>This annotation made sense when validation was not on by default but I am
now questioning its usefulness.</p>
<p><strong>I have a bunch of questions for you</strong>. I tried to keep them short and to
the point so feel free to answer them one by one. They also go from easy
to more convoluted. Are you up for the challenge?</p>
<p>Note that I have added a bonus question in the end.</p>
<h2>What's your use case for disabling method validation?</h2>
<p>Why would you want to disable method validation on a given method or a
given class?</p>
<pre><code>public class UserService {
@MethodValidated(validationMode=NONE)
public void createUser(
@NotEmpty @Email String email,
@Valid Address address ) {
...
}
}
</code></pre>
<p>If you have a use case, would it be fulfilled with the <code>@MethodValidated</code>
annotation as described?</p>
<h2>What's your use case for changing the default group?</h2>
<p><code>@MethodValidated(groups=Heavy.class)</code> let's you change validation from
the <code>Default</code> group to the group of your choice - in this case <code>Heavy</code>.</p>
<p>Provided that we will offer support for group translation when cascading
<a href="http://beanvalidation.org/proposals/BVAL-208/">http://beanvalidation.org/proposals/BVAL-208/</a></p>
<pre><code>public class UserService {
public void createUser(
@NotEmpty @Email String email,
@Valid @ConvertGroup(from=Default.class, to=BasicPostal.class)
Address address ) {
...
}
}
</code></pre>
<p>do we really need the ability do decide which group to use to validate a
given method? What would be the use case?</p>
<p>To me it seems that it could makes sense to validate one group over
another based on:</p>
<ul>
<li>some environmental consideration
say a newbie user has more constraints on how it enters data
than an advanced user hence different groups</li>
<li>the caller
say a branch of the code wants to apply different rules than
an other</li>
</ul>
<p>In both case, it does not make sense to define the group via an
annotation on the method to be validated.
This would need to be a rather container specific behavior to let people
inject the right group for the right context.</p>
<h2>When would you want to only validate parameters or return values?</h2>
<p><code>@MethodValidated.validationMode</code> let's you validate both method
parameters as well as return value, or either one of them or none at all.</p>
<pre><code>@MethodValidated(validationMode=PARAMETERS)
public class UserService {
@Valid
public User createUser(
@NotEmpty @Email String email,
@Valid Address address ) {
...
}
}
</code></pre>
<p>Do you have a use case in mind for such need?</p>
<h2>What inheritance rules make sense for <code>@MethodValidated</code>?</h2>
<p>Assuming we have <code>@MethodValidated</code>, we need to define the overriding
rules.</p>
<p>We could decide that <code>@MethodValided</code> must be placed on the method to be
validated (no overriding rule), or we could try and add some or all of
the following rules:</p>
<ol>
<li><code>@MethodValidated</code> definitions on a method overrides the ones on a class</li>
<li><code>@MethodValidated</code> definition on a subclass overrides the ones on superclasses</li>
</ol>
<p>Here is an example</p>
<pre><code>//example of rule 1
@MethodValidated(validationMode=PARAMETERS)
public class UserService {
@MethodValidated(validationMode=BOTH)
@Valid
public User createUser(
@NotEmpty @Email String email,
@Valid Address address ) {
...
}
}
</code></pre>
<p>Interfaces make things harder as there would be no magic rule to decide
which definition has precedence over another in case of conflict.</p>
<p>We could consider that methods of a class implementing an interface
inherit the interface hosted <code>@MethodValidated</code> definition (unless overridden).
And in case two interfaces define the same method, overriding the
<code>@MethodValidated</code> definition would be mandatory.</p>
<p>I can live with rule 1, I can support rule 2. but I feel that the rules
related to interfaces make things quite complex and not especially
readable. Plus I don't see why you would want to add <code>@MethodValidated</code>
on an interface. Not surprising as I don't see why one would do it on a
class method anyways ;)</p>
<p>What do you make of that?</p>
<h2>You are a convinced @MethodValidated fan? What about the name?</h2>
<p>We have never found a good name for this annotation anyways. If you
like and want this annotation, how should it be named?</p>
<p>Yep that's the bonus question, sorry.</p>
<h2>Conclusion</h2>
<p>I realize that it must look like I am having a <code>@MethodValidated</code>
mid-life crisis but better now than later :D</p>
http://beanvalidation.org/news/2012/08/31/big-push-on-bean-validation/Big push on Bean Validation 1.12023-11-03T14:56:33+00:002012-08-31T00:00:00+00:00Emmanuel Bernard
Like most of you, the Bean Validation specification is coming back from holiday
fresh and motivated.
Java EE 7 is coming soon and to avoid missing the train, it is time to reap the fruits of all the discussions
we have had over the last few months. I expect September and October to be focused
on:
integrating the various proposals in the speficication and flesh out
the remaining problems
taking decisions to unstuck discussions
iterating over the features proposed in the early draft
(we have had good feedback from the JAX-RS expert group to refine
method validation)
The rest of the time will be focused on writing the reference implementation
and the...
<p>Like most of you, the Bean Validation specification is coming back from holiday
fresh and motivated.</p>
<p>Java EE 7 is coming soon and to avoid missing the train, it is time to reap the fruits of all the discussions
we have had over the last few months. I expect September and October to be focused
on:</p>
<ul>
<li>integrating the various proposals in the speficication and flesh out
the remaining problems</li>
<li>taking decisions to unstuck discussions</li>
<li>iterating over the features proposed in the early draft
(we have had good feedback from the JAX-RS expert group to refine
method validation)</li>
</ul>
<p>The rest of the time will be focused on writing the reference implementation
and the TCK and refine the various new features.
We will also work with other expert groups to clarify the integration (CDI,
JAX-RS, Java EE...).</p>
<p>Our priority list is <a href="http://beanvalidation.org/roadmap/#priorities">published</a> in the open. We will probably adjust it
a bit but the main lines are now fixed. If you feel that something important is missing,
come and help us identify it and build it.</p>
<p>And remember, if you come later and complain about Bean Validation, we will ask you:
<a href="http://beanvalidation.org/contribute/">where</a> <a href="https://github.com/beanvalidation/beanvalidation-spec">were</a>
<a href="https://github.com/hibernate/hibernate-validator">you</a>? ;)</p>
http://beanvalidation.org/news/2012/08/29/methodvalidation-inheritance/Method validation and inheritance - feedback needed!2023-11-03T14:56:33+00:002012-08-29T00:00:00+00:00Gunnar Morling
Now that everybody is returning from their summer holidays, also the Bean Validation team
is getting back to their desks in order to work with full steam towards revision 1.1.
As you know, the largest new feature will be
method validation, that is the validation
of method parameters and return values using constraint annotations. Bean Validation 1.1
early draft 1 lays the
ground for this, and right now we're tackling some
advanced questions still open in that area
(btw. if you haven't yet tried out the
reference implementation
of ED1, this is the perfect time to do so and give us your feedback).
The problem
One question the EG currently is discussing
is...
<p>Now that everybody is returning from their summer holidays, also the Bean Validation team
is getting back to their desks in order to work with full steam towards revision 1.1.</p>
<p>As you know, the largest new feature will be
<a href="http://beanvalidation.org/1.1/spec/#d0e2147">method validation</a>, that is the validation
of method parameters and return values using constraint annotations. Bean Validation 1.1
<a href="http://beanvalidation.org/news/2012/03/13/release-1-1-edr1/">early draft 1</a> lays the
ground for this, and right now we're tackling some
<a href="https://hibernate.atlassian.net/browse/BVAL-272">advanced questions</a> still open in that area
(btw. if you haven't yet tried out the
<a href="http://in.relation.to/Bloggers/FirstAlphaReleaseOfHibernateValidator5">reference implementation</a>
of ED1, this is the perfect time to do so and give us your feedback).</p>
<h2>The problem</h2>
<p>One question the EG currently is <a href="http://lists.jboss.org/pipermail/beanvalidation-dev/2012-August/000504.html">discussing</a>
is whether and, if so, how a refinement of method constraints should be allowed in
sub-types. That is, if a class implements a method of an interface or overrides a method
from a super class, should the sub-type be allowed to place any additional constraints?</p>
<p>The current draft defines the following rules for such cases (see the
<a href="http://beanvalidation.org/1.1/spec/#d0e2429">draft document</a> for all the gory details):</p>
<ul>
<li>No parameter constraints may be specified in addition to those constraints defined on
the method in the interface or super class.</li>
<li>Return value constraints may be added in sub-types.</li>
</ul>
<h2>The rationale</h2>
<p>The rationale behind this is the principle of
<a href="http://en.wikipedia.org/wiki/Liskov_substitution_principle">behavioral sub-typing</a>, which
demands that wherever a given type <code>T</code> is used, it should be possible to replace <code>T</code> with
a sub-type <code>S</code> of <code>T</code>. This means that a sub-type must not strengthen a method's
preconditions (by adding parameter constraints), as this might cause client code working
correctly against <code>T</code> to fail when working against <code>S</code>. A sub-type may also not weaken a
method's postconditions. However, a sub-type may strengthen the method's postconditions
(by adding return value constraints), as client code working against <code>T</code> still will work
against <code>S</code>.</p>
<h2>Can you show me some code, please?</h2>
<p>To give you an example, the following shows a constraint declaration considered illegal as
of the current draft, as parameter constraints are added to the <code>placeOrder()</code> method in a
sub-class of <code>OrderService</code>:</p>
<pre><code>public class OrderService {
void placeOrder(@NotNull String customerCode, @NotNull Item item, int quantity) { ... }
}
public class SimpleOrderService extends OrderService {
@Override
public void placeOrder(
@Size(min=3, max=20) String customerCode,
Item item,
@Min(1) int quantity) { ... }
}
</code></pre>
<h2>Alternatives</h2>
<p>While this approach works, follows principles of clean OO design and also
<a href="http://research.microsoft.com/en-us/projects/contracts/">is employed</a> by other
<em>Programming by Contract</em> solutions, some voices in the EG expressed doubts whether the
handling of parameter constraints isn't too restrictive and thus may limit innovation in
that area. In particular with respect to legacy code, the question was raised whether it
shouldn't be allowed to add parameter constraints in sub-types.</p>
<p>One example may be a legacy interface, which <em>technically</em> has no constraints (that is, no
parameter constraints are placed on its methods), but comes with a verbal description of
preconditions in its documentation. In this case an implementor of that interface might
wish to implement this contract by placing corresponding constraint annotations on the
implementation.</p>
<p>An open question in this situation is what should the behavior be if the
interface is being constrained afterwards?</p>
<h2>Give use your feedback!</h2>
<p>So what do you think, should such a refinement of parameter constraints be allowed or not?
Possible alternatives:</p>
<ul>
<li>allow such a refinement by default</li>
<li>have some sort of switch controlling the behavior (either standardized or provider-specific)</li>
</ul>
<p>As there are pro's and con's of either approach, we'd very interested in user feedback on this.</p>
<p>Let us know what you think by posting a comment directly to this blog, shooting a message
to the <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">mailing list</a> or
participating in this <a href="http://www.doodle.com/qp78u6mqzetuas7p">Doodle vote</a>. Which use cases
you have encountered come to mind where the possibility to refine parameter constraints
may help you?</p>
http://beanvalidation.org/news/2012/06/28/hibernate-validator-5-alpha/Hibernate Validator 5 alpha for Bean Validation 1.1 is out2023-11-03T14:56:33+00:002012-06-28T00:00:00+00:00Emmanuel Bernard
Hibernate Validator, the reference implementation for Bean Validation has just been released
in version 5 alpha. This version implements the new features described in
Bean Validation 1.1 first draft.
Integrators, spec leads and users should all go and try this release to see if some
adjustments are needed. On the menu: method validation, dependency
injection and more.
Read more about it in Hardy's blog post....
<p>Hibernate Validator, the reference implementation for Bean Validation has just been <a href="http://in.relation.to/Bloggers/FirstAlphaReleaseOfHibernateValidator5">released
in version 5 alpha</a>. This version implements the new features described in
Bean Validation 1.1 first draft.</p>
<p>Integrators, spec leads and users should all go and try this release to see if some
adjustments are needed. On the menu: method validation, dependency
injection and more.</p>
<p>Read more about it in <a href="http://in.relation.to/Bloggers/FirstAlphaReleaseOfHibernateValidator5">Hardy's blog post</a>.</p>
http://beanvalidation.org/news/2012/06/06/continuous-publication-specification-snapshot/Continuous publication of the specification snapshot2023-11-03T14:56:33+00:002012-06-06T00:00:00+00:00Emmanuel Bernard
The latest snapshot of the specification is now always published on the site
as soon as we push change to the Git repository.
The expert group has been using it for a while, we simply forgot to announce it publicly....
<p>The latest snapshot of the specification is now always published <a href="http://beanvalidation.org/latest-draft/">on the site</a>
as soon as we push change to the Git repository.
The expert group has been using it for a while, we simply forgot to announce it publicly.</p>
http://beanvalidation.org/news/2012/03/28/jcp-release-1-1-edr1/Bean Validation 1.1 officially reaches the JCP2023-11-03T14:56:33+00:002012-03-28T00:00:00+00:00Emmanuel Bernard
Bean Validation 1.1 early draft 1 officially reaches the JCP and is available
on their website. You already knew about it from the release
and artifacts announcements.
That's still a significant milestone that has to be reached by the JCP rules.
A specification needs to produce a certain amount of output which is regulated
by the JCP itself. If you are curious, I encourage you to read the process document.
Note that JSR-349 (Bean Validation 1.1) does run under the previous version of
this process but in practice we obey the rules of the current version
(especially in openness)....
<p>Bean Validation 1.1 early draft 1 officially reaches the JCP and is available
<a href="http://jcp.org/aboutJava/communityprocess/edr/jsr349/index.html">on their website</a>. You already knew about it from the <a href="http://beanvalidation.org/news/2012/03/13/release-1-1-edr1/?utm_source=blog&utm_medium=web&utm_content=blogedr1&utm_campaign=1_1_edr1">release</a>
and <a href="http://beanvalidation.org/news/2012/03/16/artifacts-1-1-edr1/?utm_source=blog&utm_medium=web&utm_content=blogedr1&utm_campaign=1_1_edr1">artifacts</a> announcements.</p>
<p>That's still a significant milestone that has to be reached by the JCP rules.
A specification needs to produce a certain amount of output which is regulated
by the JCP itself. If you are curious, I encourage you to read the <a href="http://jcp.org/en/procedures/jcp2">process document</a>.</p>
<p>Note that JSR-349 (Bean Validation 1.1) does run under the previous version of
this process but in practice we obey the rules of the current version
(especially in openness).</p>
http://beanvalidation.org/news/2012/03/16/artifacts-1-1-edr1/Code artifacts published for Bean Validation 1.1 early draft 12023-11-03T14:56:33+00:002012-03-16T00:00:00+00:00Emmanuel Bernard
Following the release of the first early draft for Bean Validation 1.1,
we have published the code artifacts:
the code source
the jar
the JavaDoc
All are available on JBoss's Maven repository. Alternatively, you can
reference them in your Maven POM
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.1.0.Alpha1</version>
</dependency>
Enjoy....
<p>Following the release of the <a href="http://beanvalidation.org/news/2012/03/13/release-1-1-edr1/?utm_source=blog&utm_medium=web&utm_content=blogedr1&utm_campaign=1_1_edr1">first early draft</a> for Bean Validation 1.1,
we have published the code artifacts:</p>
<ul>
<li>the code source</li>
<li>the jar</li>
<li>the JavaDoc</li>
</ul>
<p>All are available on <a href="https://repository.jboss.org/nexus/content/groups/public/javax/validation/validation-api/1.1.0.Alpha1/">JBoss's Maven repository</a>. Alternatively, you can
reference them in your Maven POM</p>
<pre><code><dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.1.0.Alpha1</version>
</dependency>
</code></pre>
<p>Enjoy.</p>
http://beanvalidation.org/news/2012/03/13/release-1-1-edr1/Bean Validation 1.1 early draft 1 is out - time for feedback2023-11-03T14:56:33+00:002012-03-13T00:00:00+00:00Emmanuel Bernard
After a long time in the shadows of open work... Ahem, take two. After a long time at work,
I am very pleased to announce Bean Validation 1.1 early draft 1.
This is our first big milestone since the release of 1.0.
The draft is making its way through the official channels of the JCP but
we also wanted to release it in full openned. For people in a hurry,
the spec draft is here.
What's new
We worked on three major areas:
openess
method level validation
dependency injection
Openess
The specification, the reference implementation, the TCK, this website... everything is open sourced.
All work done on Bean Validation 1.1 is done in...
<p>After a long time in the shadows of open work... Ahem, take two. After a long time at work,
I am very pleased to announce Bean Validation 1.1 early draft 1.
This is our first big milestone since the release of 1.0.</p>
<p>The draft is making its way through the official channels of the JCP but
we also wanted to release it in full openned. For people in a hurry,
<a href="http://beanvalidation.org/1.1/spec/1.0.0.alpha1/?utm_source=blog&utm_medium=web&utm_content=spec&utm_campaign=1_1_edr1">the spec draft is here</a>.</p>
<h2>What's new</h2>
<p>We worked on three major areas:</p>
<ul>
<li>openess</li>
<li>method level validation</li>
<li>dependency injection</li>
</ul>
<h3>Openess</h3>
<p>The specification, the reference implementation, the TCK, this website... everything is open sourced.
All work done on Bean Validation 1.1 is done in the open either on the mailing list, the issue tracker
or via GitHub pull requests. Check out more in the <a href="http://beanvalidation.org/contribute">how to contribute section</a>.</p>
<h3>Method-level validation</h3>
<p>You can now put constraints declarations on parameters and return values of methods and constructors.</p>
<pre><code>@MethodValidated
public class OrderService {
public OrderService(@NotNull CreditCardProcessor creditCardProcessor) {
//...
}
public void placeOrder(
@NotNull @Size(min=3, max=20) String customerCode,
@NotNull @Valid Item item,
@Min(1) int quantity) {
//...
}
}
</code></pre>
<p>Interception frameworks like CDI will check these constraints upon method calls thanks to the
<code>@MethodValidated</code> annotation. Read more in the spec.</p>
<h3>Dependency injection</h3>
<p>Bean Validation uses a few components <code>MessageInterpolator</code>, <code>TraversableResolver</code>, <code>ConstraintValidatorFactory</code>
and most importantly <code>ConstraintValidator</code>. We have standardized how these objects are managed by a container
and how these objects can benefit from container services.</p>
<p>That means that your constraint validator implementation will be able to get resources injected automatically.</p>
<p>While we go into details on how it will fit in CDI and Java EE, we have worked hard to make it container
agnostic. If you write or use other containers (Guice, Spring Framework, Avalon :) ), check out
if it fits properly.</p>
<h2>Contributions</h2>
<p>We have had tremendous help from the Bean Validation community at large but I would
like to give a massive thank you to <a href="http://musingsofaprogrammingaddict.blogspot.com/">Gunnar Morling</a> who stepped
up and lead the work on method-level validation. This is by far the biggest new
feature of Bean Validation 1.1.</p>
<h2>How to read the spec and provide feedback</h2>
<p>The draft has been published <a href="http://beanvalidation.org/1.1/spec/1.0.0.alpha1/?utm_source=blog&utm_medium=web&utm_content=spec&utm_campaign=1_1_edr1">here</a> and all changes are marked with a different
color. <span style="background-color:#DDFFDD;">Green for additions</span>,
<span style="background-color:#FFFFDD;">yellow for changes</span> and
<span style="text-decoration: line-through;background-color: #FFDDDD;">struck through red for removals</span>
. This will help you see what has changed precisely.</p>
<p>Have feedback? Please talk to us either:</p>
<ul>
<li>on our <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">mailing list</a></li>
<li>in our <a href="http://beanvalidation.org/issues">issue tracker</a></li>
<li>or on the Bean Validation <a href="https://discourse.hibernate.org/c/bean-validation">forum</a></li>
</ul>
<p>If you want to go to the next step and contribute, send us an email to the mailing list and read
<a href="http://beanvalidation.org/contribute">how to contribute</a>.</p>
http://beanvalidation.org/news/2012/02/01/method-level-proposal/Proposal for method validation added2023-11-03T14:56:33+00:002012-02-01T00:00:00+00:00Gunnar Morling
The first draft of the proposal for method-level validation is online. The proposal covers the declaration of parameter as well as
return values constraints, extensions to the Validator API, related additions to the meta-data API etc.
So check out the proposal document and let us know what you think, e.g. by sending your questions or remarks to the
beanvalidation-dev mailing list....
<p>The first draft of the proposal for method-level validation is online. The proposal covers the declaration of parameter as well as
return values constraints, extensions to the <code>Validator</code> API, related additions to the meta-data API etc.</p>
<p>So check out the <a href="http://beanvalidation.org/proposals/BVAL-241">proposal document</a> and let us know what you think, e.g. by sending your questions or remarks to the
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">beanvalidation-dev</a> mailing list.</p>
http://beanvalidation.org/news/2011/10/21/dependency-injection-proposal/Adding proposal section and first proposal2023-11-03T14:56:33+00:002011-10-21T00:00:00+00:00Emmanuel Bernard
We have introduced a new section of the website called proposals.
This will include wiki-style, work in progress proposals for various features being worked on.
Check out the first proposal page describing ideas and open questions on how to propose
dependency injection in ConstraintValidator instances....
<p>We have introduced a new section of the website called <a href="http://beanvalidation.org/proposals">proposals</a>.
This will include wiki-style, work in progress proposals for various features being worked on.</p>
<p>Check out the first proposal page describing ideas and open questions on how to propose
<a href="http://beanvalidation.org/proposals/BVAL-238">dependency injection in <code>ConstraintValidator</code> instances</a>.</p>
http://beanvalidation.org/news/2011/09/16/method-level-validation/Work on method level validation2023-11-03T14:56:33+00:002011-09-16T00:00:00+00:00Emmanuel Bernard
The expert groups has begun its work on method-level validation. A feature that was drafted in the
latest spec (appendix) but that we could nto finish in time.
You will be able to define constraints on parameters and your favorite interception technology
(CDI, @Inject, AspectJ, Spring etc) will call Bean Validation.
The final approach is not fixed yet but it will look like this.
public class BidManager {
public void placeBid(@Min(0) BigDecimal upTo) { ... }
}
Want to know more? Join the expert group mailing list. Learn how....
<p>The expert groups has begun its work on method-level validation. A feature that was drafted in the
latest spec (appendix) but that we could nto finish in time.</p>
<p>You will be able to define constraints on parameters and your favorite interception technology
(CDI, @Inject, AspectJ, Spring etc) will call Bean Validation.</p>
<p>The final approach is not fixed yet but it will look like this.</p>
<pre>public class BidManager {
public void placeBid(@Min(0) BigDecimal upTo) { ... }
}</pre>
<p>Want to know more? Join the expert group mailing list. <a href="http://beanvalidation.org/contribute">Learn how</a>.</p>
http://beanvalidation.org/news/2011/09/01/spec-repository-out/The specification repository is released2023-11-03T14:56:33+00:002011-09-01T00:00:00+00:00Emmanuel Bernard
The last piece of the puzzle is now in the open. I have just released the specification repository on GitHub.
The list of repositories for the spec are
Specification repository
Reference implementation repository
API repository
TCK repository
This website source
Want to contribute? Learn how....
<p>The last piece of the puzzle is now in the open. I have just released the specification repository on GitHub.</p>
<p>The list of repositories for the spec are</p>
<ul>
<li><a href="https://github.com/beanvalidation/beanvalidation-spec">Specification repository</a></li>
<li><a href="https://github.com/hibernate/hibernate-validator">Reference implementation repository</a></li>
<li><a href="https://github.com/beanvalidation/beanvalidation-api">API repository</a></li>
<li><a href="https://github.com/beanvalidation/beanvalidation-tck">TCK repository</a></li>
<li><a href="https://github.com/beanvalidation/beanvalidation.org">This website source</a></li>
</ul>
<p>Want to contribute? <a href="http://beanvalidation.org/contribute">Learn how</a>.</p>
http://beanvalidation.org/news/2011/07/23/voted-yes/Bean Validation has been voted yes!2023-11-03T14:56:33+00:002011-07-23T00:00:00+00:00Emmanuel Bernard
The expert committee has voted yes on JSR-349. That means
the work for Bean Validation 1.1 can start. Read some more on Emmanuel's blog.
The next few days will be dedicated getting an expert group up and running....
<p>The expert committee has <a href="http://jcp.org/en/jsr/results?id=5227">voted yes</a> on JSR-349. That means
the work for Bean Validation 1.1 can start. Read some more on <a href="http://in.relation.to/Bloggers/BeanValidation11HasStartedJoinUs">Emmanuel's blog</a>.</p>
<p>The next few days will be dedicated getting an expert group up and running.</p>
http://beanvalidation.org/news/2011/07/22/review-ballot/Bean Validation in review ballot2023-11-03T14:56:33+00:002011-07-22T00:00:00+00:00Emmanuel Bernard
The specification has been proposed to the JCP expert committee and is in review ballot. Stay tuned for the real work to begin....
<p>The specification has been proposed to the JCP expert committee and is in review ballot. Stay tuned for the real work to begin.</p>
http://beanvalidation.org/news/2011/07/21/Site-is-live/The website is live!2023-11-03T14:56:33+00:002011-07-21T00:00:00+00:00Emmanuel Bernard
The website is live!...
<p>The website is live!</p>