Red Hat

In Relation To Guillaume Smet

In Relation To Guillaume Smet

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.

Hibernate Validator 5.4.0.CR1

Posted by    |       |    Tagged as Hibernate Validator Releases

I am proud to announce the release of Hibernate Validator 5.4.0.CR1. This is a candidate release, please take the time to test it and report any issues you might find so that we can build the best possible 5.4.0.Final.

What’s new

5.4.0.CR1 is a small release built on the shoulders of our previous beta. It contains a couple of nice improvements and bugfixes:

  • We improved the javax.money support with a new annotation @Currency

  • Marko Bekhta finished his work on the annotation processor: we are now on a par with the Hibernate Validator engine features

  • We also fixed a possible overflow issue in java.time validation reported by Stanislav Bashkyrtsev

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

Playing with @Currency

In Beta1, we introduced the ability to validate your Order bean containing a MonetaryAmount property with the @DecimalMin annotation. Starting from CR1, you can also use the @Currency annotation to specify the currencies allowed:

public class Order {

    @NotBlank
    private String name;

    @DecimalMin(value = "0", inclusive = false)
    @Currency("EUR")
    private MonetaryAmount amount;

    public JavaxMoneyOrder(String name, MonetaryAmount amount) {
        this.name = name;
        this.amount = amount;
    }
}

JDK 9 support

As usual, we are working on validating the releases of Hibernate Validator with the latest JDK 9 early access builds.

5.4.0.CR1 is supported on the JDK 9+148 build. However, a blocking issue in JDK 9 prevents it to run on +151. It should be fixed in the next JDK 9 release.

Getting 5.4.0.CR1

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

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?

The obvious next step is the 5.4.0.Final release.

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.

Today, we announce the release of two Hibernate Validator versions: the first beta of the 5.4 branch and a maintenance release for our current stable, 5.3.

5.4.0.Beta1

5.4.0.Beta1 contains a lot of good things coming from the Hibernate Validator community:

  • lots of improvements to the annotation processor thanks to Marko Bekhta. For the last 2 months, Marko did a tremendous work getting the annotation processor up to speed: it will now report many more issues you might have with your annotations. We are especially interested in feedback on this feature so that we are sure we don’t report issues for configurations that should just work. So, if you have some time, give it a try on your project and, if you see something fishy, report it to us.

  • another contribution came in the form of the JavaMoney (JSR 354) support, contributed by Lukas Niemeier and Willi Schönborn from Zalando.

  • we now provide a WildFly patch based on WildFly’s patching infrastructure to allow testing a new version of HV on WildFly.

  • a couple of other improvements such as cleanups backported from our 6.0 work, a Ukrainian translation, constraint annotations for the various Polish identification numbers, improvements to the @Email constraint…​

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

More in depth with JavaMoney

The JavaMoney API is now an optional dependency of Hibernate Validator. So adding the following dependencies will make HV capable of validating JavaMoney types:

<dependency>
    <groupId>javax.money</groupId>
    <artifactId>money-api</artifactId>
    <version>1.0.1</version>
</dependency>
<dependency>
    <groupId>org.javamoney</groupId>
    <artifactId>moneta</artifactId>
    <version>1.1</version>
</dependency>

You’ll then be able to validate your Order bean containing a MonetaryAmount property with the @DecimalMin annotation:

public class Order {

    @NotBlank
    private String name;

    @DecimalMin(value = "0", inclusive = false)
    private MonetaryAmount amount;

    public JavaxMoneyOrder(String name, MonetaryAmount amount) {
        this.name = name;
        this.amount = amount;
    }
}

Applying a WildFly patch

The WildFly application server in its latest stable version (10.1.0.Final) embeds Hibernate Validator 5.2.4.Final but you might want to give our new features a try.

WildFly 8 introduced a patching infrastructure that allows you to apply patches to WildFly with a lot of nice features: you can list the applied patches, rollback a specific patch…​

Starting with HV 5.4, we leverage this infrastructure to provide you with the capability to upgrade the core Hibernate Validator modules with an updated version. As the patch overrides the core modules, the new features of 5.4.0.Beta1 are available to all the WildFly components using HV (e.g. Jax-RS for instance).

The patch file can be downloaded from Maven Central or from our distribution.

You can apply the HV 5.4.0.Beta1 update on top of WildFly 10.1.0.Final with the following command:

$JBOSS_HOME/bin/jboss-cli.sh patch apply hibernate-validator-modules-5.4.0.Beta1-wildfly-10.1.0.Final-patch.zip

And if you want to go back to the original version, you can easily revert the update:

$JBOSS_HOME/bin/jboss-cli.sh patch rollback --reset-configuration=true

Getting 5.4.0.Beta1

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

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

5.3.4.Final

Our fourth maintenance release of Hibernate Validator 5.3 comes with a few important bugfixes:

  • HV-1165 - this is a regression introduced in 5.3.0.CR1 when we fixed the type arguments support for Maps: we broke the support for Sets. The issue is now fixed and we added a comprehensive suite of regression tests for all the existing cases.

  • HV-1176 - validation of type arguments constraints on Optional parameters or return value of a method could be ignored if there were no other constraints applied on the method

  • HV-1164 - a bugfix related to dynamic constraint payloads contributed by Sebastian Bayerl

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

Getting 5.3.4.Final

Hibernate Validator 5.3.4.Final is a drop-in replacement of Hibernate Validator 5.3.3.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.3.4.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 following channels:

What’s next?

We are going to prepare the first Candidate Release of the 5.4 branch in which we will integrate your feedback.

We are also actively working on Bean Validation 2.0 and Hibernate Validator 6 with a strong focus on supporting the new features of Java 8 (and much more!). The more the merrier, so feel free to join us: drop ideas, comment on others' proposals, now is the time to define the future of Bean Validation. You can find all the necessary information on the Bean Validation website.

Hibernate Validator 5.3.3.Final is out

Posted by    |       |    Tagged as Hibernate Validator Releases

A bugfix version for modular environments

Disclaimer: if you are not using a modular environment such as WildFly or OSGi, this release will probably be of little interest to you. But you can read this post anyway!

We are in the process of upgrading the Hibernate Validator version shipped with the WildFly application server. This 5.3.3.Final release is here to fix a bug exposed in the very flexible modular environment of WildFly.

If you have followed what we did for the 5.3.1.Final and the 5.3.2.Final releases, you know that we changed the way the javax.el.ExpressionFactory was managed. For the better.

But by doing so, we exposed a very well hidden bug in some specific WildFly environments. After some very fun class loading debugging, we ended up with a solution that fixes the issue at hand and also improves the user experience in OSGi environments.

You can find the complete list of all addressed issues (well, of the addressed issue) in the change log.

Getting the release

Hibernate Validator 5.3.3.Final is a drop-in replacement of Hibernate Validator 5.3.2.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.3.3.Final.

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

To get in touch, use the following channels:

What’s next?

We are going to prepare a 5.4 release with support for javax.money validation contributed by Lukas Niemeier and Willi Schönborn from Zalando and a lot of improvements to the annotation processor thanks to the great work of Marko Bekhta.

We are actively working on Bean Validation 2.0 and Hibernate Validator 6 with a strong focus on supporting the new features of Java 8 (and much more!). The more the merrier, so feel free to join us: drop ideas, comment on others' proposals, now is the time to define the future of Bean Validation. You can find all the necessary information on the Bean Validation website.

Hibernate Validator 5.3.2.Final is out

Posted by    |       |    Tagged as Hibernate Validator Releases

So, today is my birthday which is in no way related to this blog post but is definitely worth knowing! This special day for me seems to be a good occasion to announce the second maintenance release of Hibernate Validator 5.3.

Why so soon?

If you are using the default ResourceBundleMessageInterpolator as your message interpolator and you have the javax.el API in your classpath but not the implementation (which would break at runtime anyway), 5.3.1.Final would throw a nasty javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not found. This exception breaks the promise we made to you, our beloved users, to throw a nice javax.validation.ValidationException with a clear error message.

The story behind it is that, in 5.3.1.Final, we changed the way the javax.el.ExpressionFactory is initialized when using ResourceBundleMessageInterpolator. This latter class is the default message interpolator used to interpolate the constraint violations messages using the Expression Language. Prior to this change, the ExpressionFactory was initialized at runtime for each interpolation which was not a good thing, as you can imagine.

Starting with 5.3.1.Final, we initialize once and for all the ExpressionFactory when initializing the ResourceBundleMessageInterpolator. Thus, even if no messages are interpolated, if you use the default message interpolator, you now need the javax.el API and the javax.el implementation in your classpath. Before this change, only the API was required at bootstrap.

You shouldn’t notice this difference in a normal Hibernate Validator usage as there is a good chance you would need to interpolate a message: the good news is that you now have an error at bootstrap instead of at runtime if your classpath is not correct.

So, at the end of the day, this release is all about fixing this issue.

We also backported a few totally unrelated Java 9 build improvements.

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

Getting the release

Hibernate Validator 5.3.2.Final is a drop-in replacement of Hibernate Validator 5.3.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.3.2.Final.

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

To get in touch, use the following channels:

What’s next?

We are going to prepare a 5.4 release with support for javax.money validation contributed by Lukas Niemeier and Willi Schönborn from Zalando and a lot of improvements to the annotation processor thanks to the great work of Marko Bekhta.

We are actively working on Bean Validation 2.0 and Hibernate Validator 6 with a strong focus on supporting Java 8 new features (and much more!). The more the merrier, so feel free to join us: drop ideas, comment on others' proposals, now is the time to define the future of Bean Validation. You can find all the necessary information on the Bean Validation website.

Hibernate Validator 5.3.1.Final is out

Posted by    |       |    Tagged as Hibernate Validator Releases

I am pleased to announce the first maintenance release of Hibernate Validator 5.3.

Bug fixes

Here are the main issues we fixed in this release:

  • HV-1131 - An implementation of javax.el mistakenly became a hard dependency in 5.3 even if you were using a message interpolator not requiring it.

  • HV-1032 - Under specific inheritance scheme involving generics, you could encounter an infinite loop. This issue was already present in 5.2 and is now fixed.

  • HV-1140 - Mert Çalişkan fixed a long standing bug with our decapitalization method not being correct with specific locales (and especially the Turkish one).

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

JDK 9 support

We upgraded our JDK 9 support to the latest release and integrated it to our automated CI testing. 5.3.1.Final is the first release benefiting from this new process.

Note that we still have some progress to do on the JDK 9 front:

  • our OSGi tests are not running on JDK 9 as we are waiting for Pax and Karaf to release JDK 9 ready versions

  • we can’t build the full distribution with JDK 9 yet (see our build instructions for JDK 9)

But we are definitely on the right track!

Getting the release

Hibernate Validator 5.3.1.Final is a drop-in replacement of Hibernate Validator 5.3.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.3.1.Final.

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

To get in touch, use the following channels:

What’s next?

We are going to prepare a 5.4 release with support for javax.money validation contributed by Lukas Niemeier and Willi Schönborn from Zalando and a lot of improvements to the annotation processor thanks to the great work of Marko Bekhta.

We are actively working on Bean Validation 2.0 and Hibernate Validator 6 with a strong focus on supporting Java 8 new features (and much more!). The more the merrier, so feel free to join us: drop ideas, comment on others' proposals, now is the time to define the future of Bean Validation. You can find all the necessary information on the Bean Validation website.

Hibernate Validator 5.3.0.Final is out

Posted by    |       |    Tagged as Hibernate Validator Releases

There has been a lot of release activity on the Hibernate front lately and it is my pleasure to announce that Hibernate Validator just joined the party with the release of Hibernate Validator 5.3.0.Final.

What’s new since 5.3.0.CR1

5.3.0.CR1 was a candidate release so we did not change much!

Marco Davi reported on Stackoverflow that the property path generated for type arguments constraints could be improved so we fixed it. You should now be able to exploit type arguments constraints violations more easily.

Ahmed Al Hafoudh contributed a translation for Slovak for our default messages.

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

Hey! I missed the previous announcements!

If you missed what we already announced for 5.3.0, the most important changes are:

  • Dynamic payloads for constraints

  • A new programmatic API for constraint definition and declaration

Please consult the announcements for more information:

Getting the release

Hibernate Validator 5.3.0.Final should be a drop-in replacement in most cases. Please consult our migration guide before upgrading your application to 5.3.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.3.0.Final.

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

To get in touch, use the following channels:

What’s next?

We are going to prepare a 5.4 release with support for javax.money validation contributed by Lukas Niemeier and Willi Schönborn from Zalando and a lot of improvements to the annotation processor thanks to the great work of Marko Bekhta.

We are actively working on Bean Validation 2.0 and Hibernate Validator 6 with a strong focus on supporting Java 8 new features (and much more!). The more the merrier, so feel free to join us: drop ideas, comment on others' proposals, now is the time to define the future of Bean Validation. You can find all the necessary information on the Bean Validation website.

Hibernate Validator 5.3.0.CR1 is out

Posted by    |       |    Tagged as Hibernate Validator Releases

We are making good progress working on Bean Validation 2.0 and we decided to move the target version for BV 2.0 to Hibernate Validator 6 (see more at the end of this post!).

We did not want to leave 5.3 half backed so we are preparing a 5.3 release with bugfixes, additional translations…​ and a few new features. This Candidate Release 1 is the first step towards this process. Expect a quick 5.3.0.Final release after that so please test this version as thoroughly as possible and report any bugs you may find in it!

Programmatic API for constraint definition and declaration

The experimental notion of ConstraintDefinitionContributor has been removed in favor of a new fluid API, more consistent with what already existed in Validator.

If you want to define a new ValidPassengerCount constraint annotation which relies on a ValidPassengerCountValidator validator, you can use the API as follows:

ConstraintMapping constraintMapping = configuration.createConstraintMapping();

constraintMapping
    .constraintDefinition( ValidPassengerCount.class )
        .validatedBy( ValidPassengerCountValidator.class );

It can also be used to replace the implementation of the validator used for a given annotation constraint. Say you need to support International Domain Names (IDN) in your URL validation, the default URLValidator won’t work for you as it uses java.net.URL which does not support IDN. We provide an alternative RegexpURLValidator and you might want to use it in this case:

ConstraintMapping constraintMapping = configuration.createConstraintMapping();

constraintMapping
    .constraintDefinition( URL.class )
        .includeExistingValidators( false )
        .validatedBy( RegexpURLValidator.class );

Constraint mapping contributor*s*

Thanks to the new hibernate.validator.constraint_mapping_contributors property, you can now declare several constraint mapping contributors separated by a comma, whereas you were limited to only one before.

Note that in 5.3, the existing hibernate.validator.constraint_mapping_contributor property is still supported but has been deprecated.

The deprecated hibernate.validator.constraint_mapping_contributor property will be removed as of Hibernate Validator 6.

Email validation

We changed the way email validation is done. It is now both more correct and stricter. We know of a few people running random tests on the constraints and they might have to update their tests: the domain of the email now needs to be a valid domain with each label (part between 2 dots) being at most 63 characters long. So you can’t just generate a 80 characters long domain with random characters, you need to be a bit more careful.

Translations

We added a few new translations of messages of the constraints we provide:

  • an Arabic translation thanks to Kathryn Killebrew

  • a Russian translation thanks to Andrey Derevyanko

Several other translations were updated.

What else is there?

Other changes of this release are an upgrade of all our Maven dependencies and a few fixes and polishing here and there.

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

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

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

To get in touch, use the following channels:

Next stop?

We are actively working on Bean Validation 2.0 and Hibernate Validator 6 with a strong focus on supporting Java 8 new features (and much more!). The more the merrier, so feel free to join us: drop ideas, comment on others' proposals, now is the time to define the future of Bean Validation. You can find all the necessary information on the Bean Validation website.

We are making good progress on our next major release which focuses on Elasticsearch integration but we don’t forget our beloved users of Hibernate Search 5.5.x and here is a new stable release to prove it!

This bugfix release is entirely based on user feedback so keep it coming!

Hibernate Search version 5.5.4.Final is available now and fixes the following issues:

  • HSEARCH-2301 - CriteriaObjectInitializer is suboptimal when we query only one subtype of a hierarchy

  • HSEARCH-2286 - DistanceSortField should support reverse sorting

  • HSEARCH-2306 - Upgrade 5.5.x to Hibernate ORM 5.0.9

  • HSEARCH-2307 - Documentation shouldn’t suggest need for @Indexed of embedded association fields

Small focus on HSEARCH-2301 as it might significantly improve your performances if you index complex hierarchy of objects. Prior to this fix, when querying the database to hydrate the objects, Hibernate Search was using the root type of the hierarchy potentially leading to queries with a lot of joins. Hibernate now builds the most efficient query possible depending on the effective results.

You can see two instances of this issue on Stack Overflow here and here.

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.5.4.Final</version>
</dependency>
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>5.0.9.Final</version>
</dependency>
<dependency>
   <groupId>org.apache.lucene</groupId>
   <artifactId>lucene-core</artifactId>
   <version>5.3.1</version>
</dependency>

How to get this release

Everything you need is available on Hibernate Search’s web site. Download the full distribution from here, or get it from Maven Central using the above coordinates, and don’t hesitate to reach us in our forums or mailing lists.

We also monitor closely the hibernate-search tag on Stack Overflow.

back to top