Red Hat

In Relation To Guillaume Smet

In Relation To Guillaume Smet

We just released the Bean Validation 2.0 release train (e.g. the specification, the API and the TCK) for the Final Approval Ballot and, as usual, we release a compatible version of Hibernate Validator shortly after: here comes Hibernate Validator 6.0.0.CR3.

What’s new since CR2

As the final release of Bean Validation is getting closer, we mainly focused on keeping up with the latest spec clarifications and improving a few things here and there.

Here are the highlights of this release:

  • We removed the support for constraints and cascading on container elements of arrays as we decided to not include it in the spec. Basically, it was not possible to be backward compatible with Bean Validation 1.1 and introduce this support, considering how array annotations are handled according to the JLS. As we don’t think there’s much traction for it, we stayed on the safe side for now.

  • It is now possible to use expression language in OSGi environments without having to specify an external class loader: no more headaches trying to get the javax.el based message interpolation working!

  • Speaking of OSGi, Toni Menzel contributed a fix to the Paranamer Karaf feature. Thanks!

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.CR3

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.CR3. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

What’s next?

So, once the Bean Validation 2.0 gets approved, we will release the final of Hibernate Validator 6.0.0.

Until then, we will work on completing the documentation.

Feedback, issues, ideas?

To get in touch, use the usual channels:

We just released a CR2 of the Bean Validation 2.0 release train (e.g. the specification, the API and the TCK) and, as usual, we release a compatible version of Hibernate Validator shortly after: here comes Hibernate Validator 6.0.0.CR2.

What’s new since CR1

As the final release of Bean Validation is getting closer, we mainly focused on keeping up with the latest spec clarifications and on updating the documentation.

Here are the highlights of this small release:

  • The from of @ConvertGroup and <convert-group> is now optional: it defaults to the Default group.

  • Some last minute changes were made in the Bean Validation API on the naming of the value unwrapping related method: we updated Hibernate Validator accordingly.

  • We made a first pass on the documentation: some things are still missing (mostly about the new value extraction feature) but the documentation should not contain outdated information anymore.

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.CR2

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.CR2. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

As we published the Proposed Final Draft, we are in the final stretch for Bean Validation 2.0, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Testing the Reference Implementation is also a good way to help us finalize both the specification and the next major version of Hibernate Validator, now is the time!

The Proposed Final Draft (CR1) of Bean Validation 2.0 has been released earlier this week and it is time to release a version of the Reference Implementation compatible with it: here comes Hibernate Validator 6.0.0.CR1.

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new since Beta2

As the final release of Bean Validation is getting closer, we mainly focused on keeping up with the latest spec clarifications, fixing bugs and improving overall consistency.

We also added/improved a few things:

  • After a community survey, we decided to create specific annotations for @PositiveOrZero, @NegativeOrZero, @PastOrPresent and @FutureOrPresent instead of using annotation attributes.

  • CDI is now enabled for ValueExtractors loaded via the ServiceLoader. We also fixed a class loading issue in that area.

  • The programmatic API for @NotBlank, @NotEmpty and @Email is now using the new Bean Validation constraints instead of the Hibernate Validator specific ones.

  • We added automatic module names for the new Java 9 module system. You can find them in our reference documentation.

Finally, we made quite a lot of improvements to our testing infrastructure but you shouldn’t notice it (except if you come join us!).

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.CR1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.CR1. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

As we published the Proposed Final Draft, we are in the final stretch for Bean Validation 2.0, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Testing the Reference Implementation is also a good way to help us finalize both the specification and the next major version of Hibernate Validator, now is the time!

It has just been a couple of weeks since the 6.0.0.Beta1 release but we needed a new version matching Bean Validation 2.0.0.Beta2.

Hibernate Validator 6 is going to be the reference implementation of Bean Validation 2.0 and, as such, we coordinate releases so you can test the latest additions as soon as possible.

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new since Beta1

Bean Validation 2.0.0.Beta2 support

The main goal of this version is to upgrade to Bean Validation 2.0.0.Beta2.

We fixed a couple of bugs and also introduced a few new features.

Support for non generic types in value extraction

Our value extraction framework (which is the basis of our new container element validation implementation) only supported generic types until now.

We alleviated this restriction by introducing a new type attribute to the ExtractedValue annotation allowing to define the type of the extracted value even in the absence of a type argument providing the information.

Thus, it is now possible to define value extractors as below:

@UnwrapByDefault
public class OptionalIntValueExtractor implements ValueExtractor<@ExtractedValue(type = Integer.class) OptionalInt> {

    @Override
    public void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
        receiver.value( null, originalValue.isPresent() ? originalValue.getAsInt() : null );
    }
}

And that’s indeed what we do in Hibernate Validator to support OptionalInt, OptionalLong and OptionalDouble.

Addition of container element information via the node builder API

The node builder API allows you to define a property path for a constraint violation using the ConstraintValidatorContext.

It is now possible to define container element information for existing node types supporting them or to define container element nodes:

public static class Validator implements ConstraintValidator<MyConstraint, MyBean> {

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        context.disableDefaultConstraintViolation();

        context.buildConstraintViolationWithTemplate( context.getDefaultConstraintMessageTemplate() )
                .addContainerElementNode( "myNode1", Map.class, 1 )
                        .inIterable()
                        .atKey( "key" )
                .addConstraintViolation();

        context.buildConstraintViolationWithTemplate( context.getDefaultConstraintMessageTemplate() )
                .property( "myNode2" )
                        .inContainer( List.class, 0 )
                        .inIterable()
                        .atKey( "key" )
                .addConstraintViolation();

        return false;
    }
}

CDI improvements

Value extractors defined in the XML configuration are now managed beans.

We also fixed an issue that could occur if you were using a managed ParameterNameProvider.

And a few other things

  • @SafeHtml now supports defining accepted protocols (think allowing the data protocol for images) and has an improved programmatic API.

  • The @Min / @Max, @DecimalMin / @DecimalMax validators were split to have one validator per type and avoid reflection at runtime.

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.Beta2

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Beta2. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 is currently in the Public Review phase, the Public Review Ballot will take place at the beginning of June. The Proposed Final Draft is planned to be released shortly thereafter, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Hibernate Validator 6 is still under active development. We’ll keep you posted with our progress.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. This Beta1 release is coordinated with the 2.0.0.Beta1 release (Public Review Draft) of the Bean Validation specification.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new since Alpha2

Bean Validation 2.0.0.Beta1 support

The main goal of this version is to upgrade to Bean Validation 2.0.0.Beta1.

This was mainly small adjustments to be on par with the latest changes in the specification but we also added a couple of features related to the validation of container elements (think List<@NotBlank String>).

Metadata API support for container element constraints

Until now, the container element constraints were not exposed via the metadata API. You can now obtain them via the API:

// Given a class User with a property declared as Map<@Valid AddressType, @NotNull Address> addresses

PropertyDescriptor propertyDescriptor = validator
        .getConstraintsForClass( User.class )
        .getConstraintsForProperty( "addresses" );

List<ContainerElementTypeDescriptor> containerElementTypeDescriptors =
        propertyDescriptor.getContainerElementTypes();

ContainerElementTypeDescriptor mapKeyDescriptor = containerElementTypeDescriptors.get( 0 );
ContainerElementTypeDescriptor mapValueDescriptor = containerElementTypeDescriptors.get( 1 );

// get the type argument index corresponding to this container element
assert mapKeyDescriptor.getTypeArgumentIndex() == 0;
assert mapValueDescriptor.getTypeArgumentIndex() == 1;

// get the constraint descriptors for this container element
assert mapKeyDescriptor.getConstraintDescriptors().size() == 0;
assert mapValueDescriptor.getConstraintDescriptors().size() == 1;

// indicates if the validation is cascaded
assert mapKeyDescriptor.isCascaded() == true;
assert mapValueDescriptor.isCascaded() == false;

// get the potential nested container elements
assert mapKeyDescriptor.getContainerElementTypes().size() == 0;
assert mapValueDescriptor.getContainerElementTypes().size() == 0;

Support for group conversions in container elements

We added support for cascaded validation of container elements a while ago but we did not support group conversions. They are now supported.

public class User {

    private Map<@Valid AddressType, @Valid @ConvertGroup(from = Default.class, to = BasicChecks.class) Address> addresses;
}

Polished support for the new built-in annotations

The error messages were missing for the new built-in annotations, we fixed it. Note that several translations need an update so if you speak a language other than English, German, French or Ukrainian, don’t hesitate to step up to the plate and send a pull request.

We also added support for @Positive and @Negative to the JavaMoney types.

And, finally, we added support for these new constraints to the annotation processor.

And a few other things

  • @SafeHtml now supports relative URLs thanks to the new baseURI attribute.

  • We fixed a few things to support the latest JDK 9 early access releases.

The complete list of 23 fixed issues can be found in the release notes.

Getting 6.0.0.Beta1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Beta1. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 is currently in the Public Review phase, the Public Review Ballot will take place at the beginning of June. The Proposed Final Draft is planned to be released shortly thereafter, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Hibernate Validator 6 is still under active development. We’ll keep you posted with our progress.

Simple Query String, what about it?

Posted by    |       |    Tagged as Hibernate Search

In the last Hibernate Search release announcement, you might have noticed something about Simple Query Strings.

The documentation is still a little sparse and we wanted to give this feature some more light and have some feedback before going Final with it.

This feature is part of the already released 5.8.0.Beta1 so you can already play with it (either with the Lucene backend or with the new Elasticsearch backend).

What’s a Simple Query String?

Let’s begin with some history.

Lucene 4.7.0 introduced a new query parser, the SimpleQueryParser, presented as a "parser for human-entered queries". The point of this parser is to be a very simple lenient state machine to parse queries entered by your end users.

The parser is capable to transform keyword "some phrase" -keywordidontwant fuzzy~ prefix* into a Lucene query, giving your users a little more power (phrase queries, fuzzy queries, boolean operators…​). The lenient part is important as it will try to build the best possible query without throwing a parse exception, even if the query is not what we would consider syntactically correct.

Another nice feature is that it allows to search on multiple fields. You basically end up establishing the following contract with Lucene:

  • users will enter a search query (more or less syntactically correct)

  • it will search on the fields you have specified (and you can also specify a specific boost for each field)

  • you can enable each of the features that you want to expose to the users (i.e. you can enable the phrase queries but not the boolean operators)

  • building the query won’t throw an exception

So, what is a Simple Query String for us? Just a string following the SimpleQueryParser syntax or, in user terms, what the user entered in the search box.

Let’s take an example

In the following, we will base our discussion on the following Book entity:

@Entity
@Indexed
public class Book {

    // [...]

    @Field
    private String title;

    @Field
    private String summary;

    @Field
    private String author;

    // [...]
}

Our goal is to be able to search war peace on the title field with a boost of 5 and on the summary field with a boost of 2 and have only the results containing both words. A Book containing war in title and peace in summary should be considered a valid result.

Until now, to fulfill these requirements with Hibernate Search, you had the following possibilities:

Use the DSL
  • Manually split the search query into keywords

  • Manually build a (rather complicated) query using the keyword() entry point of the DSL (keyword() only supports OR so you would have to build several different keyword() queries for each keyword and for each field)

  • Downsides:

    • it is not possible to allow the users to optionally enter phrase queries, fuzzy queries…​ without implementing a parser (or having checkbox options to enable them)

    • it might lead to a lot of boilerplate code if you want to search in more than 2 fields

Use the Lucene MultiFieldQueryParser
  • Quite efficient

  • Downsides:

    • Not lenient: can throw a ParseException

    • You expose the full power of the Lucene default QueryParser which might not be what you want

    • You can define the default fields but the user can search on other fields with the field:keyword syntax: it might not be what you want

How would we do it with the new simpleQueryString() DSL entry point?

It is as simple as:

String simpleQueryString = "war peace"; // what the end user is looking for

QueryBuilder qb = fullTextSession.getSearchFactory()
            .buildQueryBuilder()
            .forEntity( Book.class)
            .get(); // instantiate the QueryBuilder providing the DSL

Query query = qb.simpleQueryString()
            .onField( "title" ).boostedTo( 5.0f )
            .andField( "summary" ).boostedTo( 2.0f )
            .withAndAsDefaultOperator() // we want AND to be the default operator
            .matching( simpleQueryString )
            .createQuery();
List<Book> results = fullTextSession.createFullTextQuery( query, Book.class ).getResultList();

Important precision: the default operator used if you don’t define the operator explicitly is OR. In the general case, it might not be what you’re looking for, thus the call to withAndAsDefaultOperator() in the example above.

If you also want to search on the author field, just add another andField() clause and you’re done.

The thing I particularly like about it is the fact that you’re able to define a simple contract with your Lucene index and that the users have some flexibility to define more advanced queries inside the contract you defined:

  • -war peace: documents contain peace but not war

  • war | peace: documents contain war or peace (you can omit the | operator if it is defined as the default)

  • war + pea*: documents contain war and at least a word starting with pea (you can omit the + operator if it is defined as the default)

  • "war and peace": documents contain the phrase war and peace

  • pease~: documents contain pease with a fuzzy search so documents containing peace will be returned too

  • war + (peace | harmony): documents contain war and either peace or harmony

  • and any combinations of the above…​

  • or none: simple searches are obviously also supported!

What do you think about it?

Still there? We have a few questions for you.

First, after a lot of discussions, we have chosen to name the DSL entry point simpleQueryString(). It has the advantage to be consistent with Elasticsearch. If you can think of a better (and maybe more explicit) name, it’s not too late to join the party! Once we go final, we will stick to this name foreeeever.

Your feedback is very welcome in the comments below or on the hibernate-dev mailing list.

Secondly, for now, we haven’t exposed the ability to disable particular features. By default, the following features are all enabled:

  • boolean operators (+, - and |)

  • precedence operators (parenthesis)

  • phrase search ("some phrase")

  • prefix operator (prefix*)

  • fuzzy operator (fuzzy~)

  • slop for phrase search ("some phrase"~2)

Think it might be useful to be able to disable features? Feel free to open an issue on our JIRA or even better propose a pull request! You can find the original patch here: https://github.com/hibernate/hibernate-search/pull/1318, it might help you to start.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. This Alpha2 release is coordinated with the 2.0.0.Alpha2 release of the Bean Validation specification.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

If you missed the Alpha1 release, consulting its announcement might be beneficial to you before continuing your reading.

What’s new since Alpha1

Improved container element validation support

Container element validation support is the big new feature of Bean Validation 2.0 and it got some more love during this cycle.

Programmatic API and XML support

To obtain the equivalent of:

public class FishTank {

    private Optional<@Valid FishTankModel> model;

    private Map<@Size(min = 3, max = 10) String, @Min(1) Integer> fishCountByType;
}

it is now possible to declare container element type constraints and cascaded validation either via an XML mapping configuration (which is part of the Bean Validation 2.0 specification):

[...]
    <bean class="com.acme.FishTank" ignore-annotations="false">
        <field name="model">
            <containerElementType>
                <valid />
            </containerElementType>
        </field>
        <field name="fishCountByType">
            <containerElementType typeArgumentIndex="0">
                <constraint annotation="javax.validation.constraints.Size">
                    <element name="min">
                        <value>3</value>
                    </element>
                    <element name="max">
                        <value>10</value>
                    </element>
                </constraint>
            </containerElementType>
            <containerElementType typeArgumentIndex="1">
                <constraint annotation="javax.validation.constraints.Min">
                    <element name="value">
                        <value>1</value>
                    </element>
                </constraint>
            </containerElementType>
        </field>
    </bean>
[...]

or via the (implementation specific) programmatic API:

ConstraintMapping newMapping = config.createConstraintMapping();
newMapping
    .type( FishTank.class )
        .property( "model", FIELD )
            .containerElementType()
                .valid()
        .property( "fishCountByType", FIELD )
            .containerElementType( 0 )
                .constraint( new SizeDef().min( 3 ).max( 10 ) )
            .containerElementType( 1 )
                .constraint( new MinDef().value( 1 ) );

Other improvements

We also made a couple of more minor improvements:

  • the TYPE_ARGUMENT node type has been renamed to CONTAINER_ELEMENT (type argument don’t make sense for annotated array elements)

  • we allow per context custom value extractors

  • we allow value extractors to be contributed using the service loader mechanism

  • we allow to specify value extractors using XML configuration

  • we explore the parent classes and interfaces to search the ValueExtractor definition

Support for the new constraints added to Bean Validation 2.0

In the Alpha2 release of Bean Validation 2.0, we introduced the following new constraints:

  • @NotBlank: check that a char sequence is not blank (i.e. not null, and length of trimmed char sequence > 0)

  • @NotEmpty: check that an element (char sequence, collection, array) is not null and not empty

  • @Email: check that a char sequence is a valid email

  • @Positive: check that a number is positive

  • @Negative: check that a number is negative

We added support for these new constraints to Hibernate Validator.

Performance improvements

We started to run a few benchmarks on Hibernate Validator 6 and we fixed a few performance regressions.

6.0.0.Alpha2 is now significantly faster than 5.4, mostly thanks to the new ValueExtractor design.

Getting 6.0.0.Alpha2

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Alpha2. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are still under active development. We will release new alphas on a regular basis.

Hibernate Validator 5.4.1.Final

Posted by    |       |    Tagged as Hibernate Validator Releases

A bugfix release

Hibernate Validator 5.4.1.Final is a bugfix release, mostly for corner cases. 5.4.1.Final is a recommended upgrade for everyone.

Here are the most prominent bugfixes of this release:

  • HV-1088 - Fix a concurrency issue in validator initialization that you probably wouldn’t encounter in a normal usage - you’re supposed to use a shared ConstraintValidatorFactory which mitigates the issue

  • HV-1280 - Fix a class loading conflict with Xerces in modular environements (e.g. WildFly)

  • HV-1252 - Fix an issue with the annotation processor and JavaMoney support. Thanks go to Guillaume Husta for this one.

  • HV-1253 - A few TYPE_USE mentions had been mistakenly introduced in 5.4 when backporting from 6 (5.4 still supports Java 6)

We also integrated a new translation, Persian, thanks to Shahram Goodarzi.

And finally, we upgraded our build instructions for the latest JDK 9 early access build.

As usual, you can find the complete list of all addressed issues in the change log.

Getting 5.4.1.Final

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.4.1.Final.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are under active development. We will release a new alpha in the next few days.

As far as Bean Validation 2.0 is concerned, there are very interesting discussions going on about value extraction which is THE big BV 2.0 feature. Come and join us on Bean Validation website to define the future of Bean Validation.

It is not every day that we announce the first release of a new major version of Hibernate Validator. And today is one of those days: the first alpha of Hibernate Validator 6 has just been released.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. That’s why we coordinated the releases of the first alphas of these two projects.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new

New group id

First, starting from 6, the new home of Hibernate Validator is org.hibernate.validator (it used to be org.hibernate).

For instance, the Maven coordinates of this version are:

<dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>6.0.0.Alpha1</version>
</dependency>

We published relocation artifacts to make the transition more smooth. Examine the output of your build, if you see messages like "[WARNING] The artifact org.hibernate:hibernate-validator:jar:6.0.0.Alpha1 has been relocated to org.hibernate.validator:hibernate-validator:jar:6.0.0.Alpha1", you are still using the old GAV coordinates and should upgrade to the new ones.

Also make sure to not depend on 5.x and 6.x at the same time (as the group ids are different, the dependency resolution algorithm of your build tool fails to detect that these are two versions of the same logical artifact).

Java 8 goodness

As we now target Java 8 and above, we benefit from the language improvements:

  • all Bean Validation and Hibernate Validator constraints can be used in type use context (e.g. List<@NotBlank String>);

  • all the annotations that could be repeated with a List container are now marked @Repeatable.

Implementation of the new features of the spec

Earlier this week, Gunnar presented on the Bean Validation website the new features introduced in Early Draft 1 of Bean Validation 2.0. They are implemented in Hibernate Validator 6.0.0.Alpha1 so you can already play with them and give us your feedback.

Nested type use constraints and nested cascaded validation

There are some things where Hibernate Validator goes beyond the Early Draft 1 of the spec.

Typically, with Hibernate Validator, type use constraints may be used even on nested types. And so may cascaded validation.

public class Order {

        private Map<@NotNull @Valid Product, @Size(min = 1) List<@NotNull @Valid OrderLine>> lines;

}

In the above example, Hibernate Validator is going to:

  • validate the @NotNull constraint on Product;

  • cascade the validation to Products;

  • validate that for a Product, the list of OrderLines contains at least one element;

  • validate that the lists do not contain any null element;

  • cascade the validation to OrderLines.

As mentioned above, the nested part is new in Hibernate Validator and is not part of the spec yet. If you think it should go in, raise your hand and participate to the discussions. Expect some interesting discussions soon on what the nodes of the property path should look like in the case of nested types validation.

Lambda based constraint definition

We started to explore how lambdas could be integrated into Hibernate Validator and the first outcome of it is lambda based constraint definition. Using the programmatic API, you can define a constraint without writing a ConstraintValidator:

HibernateValidatorConfiguration configuration = Validation
    .byProvider( HibernateValidator.class )
    .configure();

ConstraintMapping constraintMapping = configuration.createConstraintMapping();

constraintMapping
    .constraintDefinition( ValidPassengerCount.class )
        .validateType( Bus.class )
            .with( b -> b.getSeatCount() >= b.getPassengers().size() );

Note that the programmatic API is not part of the specification so, for now, this part is specific to our implementation.

Validation of Duration

In Hibernate Validator 6, we are able to validate a lot more java.time classes and Marko recently introduced support for Duration.

Here is an example of what you can do with it:

public class TrainingSession {
    [...]

    @DurationMin(hours = 1, minutes = 30)
    @DurationMax(days = 1, inclusive = false)
    private Duration duration;

    [...]
}

Again, let us know if you think this feature should go into the spec.

Getting 6.0.0.Alpha1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Alpha1. As mentioned earlier, the group id has been changed to org.hibernate.validator.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are still under active development. We will release new alphas on a regular basis.

Hibernate Validator 5.4.0.Final

Posted by    |       |    Tagged as Hibernate Validator Releases

It’s with great pleasure that I announce the final release of Hibernate Validator 5.4.0.

What’s new since 5.4.0.CR1

For those of you following closely this blog, not much to say since 5.4.0.CR1. We fixed a few bugs and polished a few things.

We shod in a small new feature: you can now require a @ScriptAssert constraint violation to be reported on a specific property. In the following example, the constraint violation will be reported on the endDate property rather than at the class level:

@ScriptAssert(lang = "javascript", script = "_this.endDate.after(_this.startDate)", reportOn="endDate")
public class CalendarEvent {

    private Date startDate;
    private Date endDate;

    //...
}

You can find the complete list of all addressed issues in the change log.

New documentation layout

We converted the Hibernate Validator documentation to AsciiDoctor a loooong time ago but we were still using a Docbook output to be able to generate the PDF documentation. AsciiDoctor now has a (still in alpha but already pretty mature) PDF plugin and we decided to take the final step and get rid of our Docbook output.

So our reference documentation now uses a nice AsciiDoctor output and so does our PDF documentation.

We hope you’ll like it. We do!

5.4.0 Retrospective

You might not follow our blog on a regular basis so here is a retrospective of all the good things included in 5.4.0.Final.

JavaMoney support

Hibernate Validator now includes JavaMoney (JSR 354) support. You can use @DecimalMin and @DecimalMax constraints on your MonetaryAmount fields and we also introduced a new @Currency annotation allowing you to constrain the currency used in your MonetaryAmounts.

See our previous blog posts for more information:

This feature was initially contributed by Lukas Niemeier and Willi Schönborn from Zalando. Thanks again.

Annotation processor improvements

A special thank you goes to Marko Bekhta for his work on the annotation processor. Marko invested a lot of time to get the annotation processor on par with the latest Hibernate Validator features. Go validate your constraint definitions at compile time!

WildFly patch

Using WildFly and wanting to use the good things of this new version? We now provide a WildFly patch you can apply on top of your WildFly installation to use 5.4.0.Final.

You can find more information in the 5.4.0.Beta1 release announcement.

And a whole lot of other good things

  • Improvements to the @Email constraint

  • New constraints specific to Polish identification numbers

  • A Ukrainian translation

Getting 5.4.0.Final

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.4.0.Final.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are under active development. The first alpha will be out in the next few days.

As far as Bean Validation 2.0 is concerned, there are very interesting discussions going on about value extraction which is THE big BV 2.0 feature. Come and join us on Bean Validation website to define the future of Bean Validation.

back to top