Jakarta Bean Validation

Bean Validation, Hibernate Validator (its Reference Implementation) and the Test Compatibility Kit have been handed over to the JCP for what is called the Final Approval Ballot. That's when the expert committee votes for the go / no-go of the specification going final as it is.

We have found a few glitches when working on both the RI and the TCK in the last month but everything is in order now. The biggest visible change for you is that we renamed @ValidateExecutable into @ValidateOnExecution and we added a way to disable method validation entirely via the XML deployment descriptor.

We worked hard to make a stellar TCK. Let's speak numbers: the specification has 549 assertions including 492 testable. We cover 98,8% of them with 1500 tests. Good luck to all future Bean Validation 1.1 implementors :)

Everything is already available for you to use:

• the specification
• Hibernate Validator (the RI)
• the TCK

Enjoy!

Our Proposed Final Draft has been officially handed over to the JCP last night.

After a frantic month of work culminating with two weeks of monomaniac focus, we are finally handing over the Bean Validation 1.1 Proposed Final Draft to the JCP. Of course everything is open source so you can get it too:

• the spec
• the JavaDoc
• and the API JAR: maven coordinates javax.validation:validation-api:1.1.0.CR1

What's new in Bean Validation 1.1?

The specification highlights very well the main features of this version but to summarize them:

• work done entirely in the open
• support for dependency injection and better integration with CDI
• support for method and constructor validation
• support for group conversion when cascading
• support for EL based message interpolation

What's different between Beta 4 and CR 1?

We did a lot of polishing and nailed a lot of remaining corner cases. Here is a few of the tasks we worked on:

• rework of the JavaDoc
• move to @SupportValidationTarget on ConstraintValidator instead of the additional @CrossParameterConstraint on the constraint to mark a constraint as cross-parameter
• many more examples in the specification
• improve node creation logic when nodes are added programmatically
• improve the creation logic of custom nodes when using the programmatic API of ConstraintViolationBuilder in a ConstraintValidator

And of course many hours rereading the specification to find holes and fix them.

Review

Hibernate Validator 5.0.0.CR1 and the TCK should be here any minute. Help us make this spec as good as possible by reviewing it and opening issues where it itches you.

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

Please send us your remarks and comments:

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

Many many thanks to my partners in crime Hardy and Gunnar that worked around the clock with me to deliver this proposed final draft right on time but with no compromise on quality.

Our proposed final draft is due soon but we did one last drop of the specification and the API jar. We worked all over the board (and the clock) but the most notable improvements are:

Improvements on the CDI integration section

We made it much more descriptive of the expected behavior instead of imposing an implementation pattern. We have also added the method and constructor interception priority as defined in the Java EE specification and the interceptor specification in particular.

Thanks Pete for your help.

Remove the link between the Node API and the metadata API

This is something we could not make work, so we fall back into a more redundant but we think cleaner design. We also made the node builder API easier to use despite the increased number of node types.

//Cross-parameter constraint on a method
//mergeAddresses(Map<String,Address> addresses, Map<String,Address> otherAddresses)
//Build a constraint violation on the default path + "otherAddresses["home"]
//ie. the Address bean hosted in the "home" key of the "otherAddresses" map parameter
context.buildConstraintViolationWithTemplate(
        "Map entry home present in both and does not match")
                .addParameterNode(1)
                .addBeanNode()
                    .inIterable().atKey("home")
                .addConstraintViolation();

Clarification around method validation (metadata, cross-parameter, reports)

We now have an explicit cross-parameter concept materialized in the metadata API. It makes for a more regular and easier to browse API. ConstraintViolation has also seen some improvements and adaptations to make it ready for prime - method validation - time.

Mark a method as (non) validated

We slightly improved @ValidateExecutable to be more friendly when put on a specific method. To force a getter to be validated or to force a method to not be validated is now more readable.

public class Operations {
    @ValidateExecutable
    @Status
    public String getStatus() { ... }

    @ValidateExecutable(ExecutableType.NONE)
    public void apply(@Valid Operation operation) { ... }
}

Review

Let us know what you think.

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

Please send us your remarks and comments:

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

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

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.