Jakarta Validation

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 and the XML validated-executables element in validation.xml to do that.

Message interpolation with UEL

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:

• the ability to put the validated value in the message
• the ability to format numbers, dates etc according to the locale

Here is an example from @DecimalMin. It uses the min boundary value, the inclusive parameter in an EL and use a formaatter to display the erroneous value:

${formatter.format("%1$2f", validatedValue} is incorrect ; must be greater than ${inclusive == true ? 'or equal to ' : ''}{value}

Which will be interpolated into

324.32 is incorrect ; must be greater than or equal to 500

Generic and cross-parameter constraints

Finally we have introduce the ability to make constraints both generic and cross-parameter aware. This is useful for constraints like @ScriptAssert that are very flexible.

Review

Please, please, please go and review the specification and tell us if something needs to be fixed.

You can access the specification here. All changes are marked with a different color. Green for additions, yellow for changes and struck through red for removals . This will help you see what has changed precisely.

Please send us your remarks and comments:

• on our mailing list
• in our issue tracker
• or on the Bean Validation forum

If you want to go to the next step and contribute, send us an email to the mailing list and read how to contribute.

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.

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 different color. Green for additions, yellow for changes and struck through red for removals . This will help you see what has changed precisely.

Please send us your remarks and comments:

• on our mailing list
• in our issue tracker
• or on the Bean Validation forum

If you want to go to the next step and contribute, send us an email to the mailing list and read how to contribute.

What's new in this draft

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:

• improved integration with CDI: dependency injection, component lifecycle management and interception for method validation
• add rules describing method validation in particular how an interception technology ought to integrate: this will offer better portability
• add support for cross parameter validators on method validation
• add metadata APIs to identify constrained methods
• add support for group conversion (i.e., change the targeted group when cascading validation)
• clarify that composed constraints should fail fast when @RepostAsSingleViolation is present
• support CharSequence (used to be String) for built-in constraints

Contributions

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.

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).

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.