Tags
Authors
We just published Hibernate Validator 9.0.0.CR1, the first candidate release of the new 9.0 series of Hibernate Validator.
This series targets Jakarta EE 11. It is the implementation of the Jakarta Validation 3.1.
Since the previously released 9.0.0.Beta3, we spent some time on various build improvements, tidied up a few things and addressed various reports from the community and our testing.
With this release, we no longer publish relocation POMs for the old org.hibernate group id.
There also are some dependency updates and bug fixes.
Hibernate Validator 8.0.2.Final maintenance release is out.
This release contains some documentation and constraint violation message translation updates as well as a few bug fixes.
A few weeks ago, the GitHub Security Lab reported to the Hibernate team a vulnerability in GitHub Actions workflows used in some Hibernate projects, which could have (indirectly) impacted released artifacts.
Fortunately, that vulnerability wasn’t exploited and all Hibernate releases are perfectly safe.
However, considering the impact an exploit could have had, we thought it would be best to provide some transparency on what happened and how we made sure that Hibernate releases — past, present and future — are safe.
We just published Hibernate Validator 9.0.0.Beta3, the next beta release of the new 9.0 series of Hibernate Validator.
This series targets Jakarta EE 11. It is the implementation of the Jakarta Validation 3.1. Compared to the previous release in this series, this version removes a few more constraints, configuration properties and APIs, which have been deprecated for several major versions. We have also identified some possible areas to improve while testing the previous version in the downstream projects. Also, there are some bug fixes.
We just published Hibernate Validator 9.0.0.Beta2, the first release of the new 9.0 series of Hibernate Validator.
This series targets Jakarta EE 11. It is the implementation of the Jakarta Validation 3.1. It also introduces new constraints, removes the integration of the Security Manager, provides the BOM for simpler dependency management, includes dependency updates, and makes other improvements and bug fixes.
[ ... ]
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.
Hibernate projects are not affected by the vulnerabilities behind CVE-2021-45046 and CVE-2021-44228: none of the Hibernate projects has a runtime dependency on Log4j core.
We use JBoss Logging, which provides a minimal API bridging to your logger backend of choice and does not come with fancy features relying on JNDI lookups.
We do use Log4j during development of the Hibernate libraries as it’s a dependency of our testsuites; therefore we’ve still upgraded all branches.
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.
