因此，今天是我的生日，这与这篇博客文章没有任何关系，但绝对值得知道！对我来说，这一天似乎是一个宣布Hibernate Validator 5.3的第二个维护版本的好机会。
为什么这么快？
如果您使用默认的ResourceBundleMessageInterpolator作为消息插值器，并且您的类路径中有javax.el API但没有实现（这会在运行时导致错误），5.3.1.Final将抛出一个讨厌的javax.el.ELException: Provider com.sun.el.ExpressionFactoryImpl not found异常。这个异常打破了我们向您，我们亲爱的用户，承诺抛出一个带有清晰错误消息的javax.validation.ValidationException的承诺。
背后的故事是这样的，在5.3.1.Final中，我们更改了使用ResourceBundleMessageInterpolator时初始化javax.el.ExpressionFactory的方式。这个类是用于使用表达式语言插值约束违反消息的默认消息插值器。在此更改之前，ExpressionFactory是在每次插值时在运行时初始化的，这并不是什么好事，您可以想象。
从5.3.1.Final开始，我们在初始化ResourceBundleMessageInterpolator时一次性初始化ExpressionFactory。因此，即使没有消息被插值，如果您使用默认的消息插值器，现在您需要在类路径中提供javax.el API和javax.el实现。在此更改之前，只需要在启动时提供API。
在正常使用Hibernate Validator的情况下，您不应该注意到这种差异，因为您有很大几率需要插值一个消息：好消息是，如果您的类路径不正确，您现在会在启动时而不是在运行时遇到错误。
因此，最终，这个版本完全是关于修复这个问题。
我们还回滚了一些与Java 9构建无关的改进。
您可以在变更日志中找到所有已解决的问题的完整列表。
获取发布版本
接下来是什么？
我们将准备 5.4 版本，该版本支持由 Zalando 的 Lukas Niemeier 和 Willi Schönborn 贡献的 javax.money 验证，以及 Marko Bekhta 所做的许多对注解处理器的改进。
我们正在积极开发 Bean Validation 2.0 和 Hibernate Validator 6，重点关注支持 Java 8 的新功能（以及更多！）。人多力量大，欢迎加入我们：提出想法，对其他人的提议发表评论，现在是定义 Bean Validation 未来的时候了。您可以在 Bean Validation 网站 上找到所有必要的信息。
