In Relation To

Today, we released new maintenance releases for our Hibernate Validator 6.2 and 7.0 branches.

Both versions improve testing of Java records and make sure the annotation processor is working correctly with records.

We also released a new candidate release (CR2) of Hibernate Validator 8.0, which targets Jakarta EE 10.

I am glad to announce the release of Hibernate Validator 8.0.0.CR1, which is the final step before our Final release (except if important issues are reported, of course).

Hibernate Validator 8 is the Hibernate Validator version targeting Jakarta EE 10 and it is the reference implementation of Jakarta Bean Validation.

We released maintenance releases for our Hibernate Validator 6.2 and 7.0 branches.

Both versions bring back support for validating java.sql.Date which was broken when we refactored the time constraints.

7.0.3.Final also fixes an oversight in the annotation processor made when we migrated to the jakarta.* packages. Until this fix, the annotation processor for 7.0 was ignored, even if you properly used the jakarta.validation constraints.

We also released Hibernate Validator 8.0.0.Alpha1, which specifically targets the upcoming Jakarta EE 10.

Today, we released maintenance releases for our Hibernate Validator 6.2 and 7.0 branches.

As of now, you are all aware of the Log4j 2 security issue called Log4Shell announced on Friday. The good news is that Hibernate Validator does NOT use Log4j 2 but uses JBoss Logging as its logging framework.

Why release these versions then? Log4j 2 is only a test dependency of Hibernate Validator (being a test dependency, Log4j 2 doesn’t come in your apps through Hibernate Validator so you don’t have to worry about this issue from the Hibernate Validator perspective), but we already got hit in the past by security scanners being not as fine grained as we would have liked so we preferred to release new versions proactively so that we are sure Hibernate Validator does not get wrongly reported as unsafe.

As of now, you are probably aware of the Jakarta EE 9 effort that aims to provide new foundations for EE innovation.

Jakarta EE 9 is an iterative release on top of EE 8 with the main purpose of renaming all the javax. packages to the jakarta. packages.

For a while, we will provide equivalent Hibernate Validator versions for both EE 8 and EE 9: Hibernate Validator 6.x will keep the javax. packages while Hibernate Validator 7.x moved to the jakarta. packages.

We just released Hibernate Validator 6.1.7.Final which contains some minor fixes.

This is a recommended upgrade for everyone using Hibernate Validator and it is a drop-in replacement for 6.1.6.Final.

We also released 6.0.22.Final.

As of now, you are probably aware of the Jakarta EE 9 effort that aims to provide new foundations for EE innovation.

Jakarta EE 9 is an iterative release on top of EE 8 with the main purpose of renaming all the javax. packages to the jakarta. packages.

For a while, we will provide equivalent Hibernate Validator versions for both EE 8 and EE 9: Hibernate Validator 6.x will keep the javax. packages while Hibernate Validator 7.x moved to the jakarta. packages.

We just released Hibernate Validator 6.1.6.Final which contains a few fixes and the new @Normalized constraint.

This is a recommended upgrade for everyone using Hibernate Validator and it is a drop-in replacement for 6.1.5.Final.

We also released 6.0.21.Final.

We just released Hibernate Validator 6.1.5.Final which contains a fix for CVE-2020-10693 and a few other minor fixes.

This is a recommended upgrade for everyone using Hibernate Validator and it is a drop-in replacement for 6.1.4.Final.

We also released 6.0.20.Final that includes the fix for CVE-2020-10693.

We just released Hibernate Validator 6.1.3.Final which contains some fixes for our translations and a performance improvement for validation of executables (i.e. methods and constructors).

This is a recommended upgrade for everyone using Hibernate Validator and it is a drop-in replacement for 6.1.2.Final.

We also released 6.0.19.Final.