Good news!

Bean Validation is now in proposed final draft and available for download on the JCP website. Bean Validation standardizes the way constraint validations are defined, declared and validated in objects graphs. By using annotations such as @NotNull, @Email etc, you express constraints on your domain model once (following the DRY principle) and let them be validated automatically by different layers of you application. Bean Validation also exposes constraints via a metadata query API which is useful for frameworks interacting beyond Java like javascripts libraries or database schema generators.

Here are the main highlights of this proposed final draft:

• Type-safe constraint validator
• XML configuration and XML mapping support
• Clearer names
• integration into JPA 2 and JSF 2
• More built-in constraints

Type-safe constraint validatorS

Constraints are now validating particular types (like String and Collection) in a type-safe way. You can even have several ConstraintValidator implementations associated to a given constraint. Each ConstraintValidator is dedicated to a specific type.

@Constraint(validatedBy = {
	SizeValidatorForString.class,
        SizeValidatorForCollection.class } ) 
public @interface Size { 
    String message() default "{constraint.size}"; 
    Class<?>[] groups() default {}; 
    int min() default 0;
    int max() default Integer.MAX_VALUE;
}

public class SizeValidatorForString implements<Size, String> {
	public void initialize(Size size) {}
	public boolean isValid(String value, ConstraintValidatorContext context) {}
}


public class SizeValidatorForCollection implements<Size, Collection> {
	public void initialize(Size size) {}
	public boolean isValid(Collection value, ConstraintValidatorContext context) {}
}

The appropriate ConstraintValidator is chosen automatically by the Bean Validation provider. Even better, an IDE or an annotation processor (see another usage here) can warn you if you place a constraint on a property of an incompatible type.

@Size //invalid usage of @Size
Number number;

XML configuration and mappings

Support for XML configuration via META-INF/validation.xml and XML mapping (ie using XML instead of annotations) have been added. Check it out if you are interested and give us feedback. The configuration can also be done entirely programmatically if needed, XML is completely optional.

Clearer names

We took a second look at all the class names and cleaned that up, especially in the bootstrapping API. Names are much more consistent and clear.

Integration with JPA 2 and JSF 2

It's official now, Bean Validation is integrated with JPA 2 and JSF 2. Even better, it requires zero configuration in your application. Pretty neat. Check JSF and JPA's specifications to read more about it.

More built-in constraints

We have added a few new built-in constraints. @Pattern which validates a String against a regular expression. @DecimalMin and @DecimalMax which uses BigDecimal style notation and range to define boundaries. @Min and @Max are still be used for integer boundaries.

@Pattern(regexp="[0-9]*")
String number;

@Max(500000)
BigDecimal salary;

@DecimalMax("27.5")
BigDecimal luggageWeight;

Feedback

Additional minor and not so minor enhancements and bug fixes have been done. See our JIRA changelog for more details.

We listened to your feedbacks since the public draft and are pretty pleased with the current status of the spec. Do more, go read the proposed final draft and give us even more feedbacks (spec, forums).

You can already use Bean Validation by downloading Hibernate Validator 4, we are almost feature complete now!

Many thanks to all the contributions we received inside and outside the JCP. This spec is very solid and will remove one of the remaining painpoints of Java SE and Java EE developments.