Jakarta Bean Validation

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.

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 the open either on the mailing list, the issue tracker or via GitHub pull requests. Check out more in the how to contribute section.

Method-level validation

You can now put constraints declarations on parameters and return values of methods and constructors.

@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) {

        //...
    }
}

Interception frameworks like CDI will check these constraints upon method calls thanks to the @MethodValidated annotation. Read more in the spec.

Dependency injection

Bean Validation uses a few components MessageInterpolator, TraversableResolver, ConstraintValidatorFactory and most importantly ConstraintValidator. We have standardized how these objects are managed by a container and how these objects can benefit from container services.

That means that your constraint validator implementation will be able to get resources injected automatically.

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.

Contributions

We have had tremendous help from the Bean Validation community at large but I would like to give a massive thank you to Gunnar Morling who stepped up and lead the work on method-level validation. This is by far the biggest new feature of Bean Validation 1.1.

How to read the spec and provide feedback

The draft has been published here and 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.

Have feedback? Please talk to us either:

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