The Final Approval Ballot for the Bean Validation 2.0 JSR has started and
runs until July 31st. So if you or your company are on the EC, please cast
your vote :)
Also a big thanks to the person who nominated me as "Outstanding spec lead"
for this year's JCP awards; that's appreciated very much! I see it as a
nomination of our entire group really, it has been a great honour and
pleasure to work together with all of you to make BV 2.0 happen!
After last week's Proposed Final Draft, we are almost there for the
submission to the Final Approval Ballot.
I'd like to do a CR 2 release of the spec tomorrow, which is about
adding some clarifications, polishing comments, formatting and things
like that. You can find the complete list of issues here:
During reviews we've also noticed a small set of things that mandated
fixes to the API. These are:
* BVAL-569  - "Remove TYPE from targets of @ConvertGroup for
consistency with @Valid" - @ConvertGroup was accidentally allowed to
be given on type definitions, too (unlike @Valid which it always must
accompany). This has been corrected by removing TYPE from the set of
supported targets; the change is strictly binary and source
compatible, as a) annotation targets are only checked at compile time
but not runtime and b) the newly introduced target of TYPE_USE also
allows the annotation to be given on type definitions; so it's a mere
* BVAL-689  - "Make @ConvertGroup#from() default to Default.class"
- this simplifies group conversions in the common case where the
default group is converted
* BVAL-674  - "Rename ConstraintDescriptor#validateUnwrappedValue()
into getValueUnwrapping()" - the method name sounded like a "command"
before, 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 Unwrapping payload type names; also
there's a new method ConstraintDescriptor#unwrap(Class), our common
loophole allowing providers to add additional functionality; this
eases exploration of such features and future standardization
Another interesting change is this:
* BVAL-613  - Add an Automatic-Module-Name entry to the JAR
manifest; fixing the module name to "java.validation" as recommended
in the spec appendix when using the reference API JAR as an automatic
module on JPMS
With the CR 2, I consider the spec as feature complete and am only
expecting small changes like typo fixes and the like between CR 2 and
CR 3, the version to be submitted for the Final Approval Ballot. We
got one more week for that, i.e. I'll submit to the FAB on July 11th.
Please use this remaining time for reviewing and pointing out any
remaining glitches (I hope there are none of course :).