本文旨在解决Java Bean Validation中@NotNULL与@AssertTrue同时使用时，@AssertTrue方法在关联字段为null时可能抛出异常的问题。我们将探讨此问题的根源，并提供一种简洁高效的解决方案，即在@AssertTrue方法内部进行空值检查，从而避免复杂的验证组配置，确保数据校验的健壮性与空值安全性。
1. Bean Validation中@NotNull与@AssertTrue的协同挑战
在Java Bean Validation（JSR 380）中，我们经常使用注解来定义数据模型的约束。@NotNull用于确保字段值非空，而@AssertTrue则用于方法级别，定义更复杂的业务逻辑校验。一个常见的场景是，一个字段既需要非空，又需要满足特定的业务规则：
@Data public class Dto { @NotNull(message = "anInt 不能为空") private Integer anInt; @AssertTrue(message = "anInt 必须是 123 或 999") public boolean isIntCustomValid() { // 尝试访问 anInt 字段 return anInt == 123 || anInt == 999; } }
当使用@Valid注解触发校验时，例如在一个spring mvc控制器中：
@RestController public class MyController { @PostMapping("/validate") public String validateDto(@Valid @RequestBody Dto dto) { return "Validation successful!"; } }
此时，如果客户端提交的json数据中anInt字段为null，我们期望@NotNull能够捕获到这个错误。然而，在某些情况下，@AssertTrue注解的isIntCustomValid()方法可能会在anInt为null时被执行，导致NullPointerException，或者更具体地，由于hibernate Validator尝试访问一个空值而抛出HV000090: Unable to access错误。
这通常是因为Bean Validation的默认校验流程不保证字段级别的@NotNull约束总是在方法级别的@AssertTrue之前执行，特别是在@AssertTrue方法内部直接引用了可能为空的字段时。当@AssertTrue方法被调用时，它会尝试解引用anInt，如果anInt为null，就会导致运行时错误。
立即学习“Java免费学习笔记（深入）”；
2. 解决方案：构建空值安全的@AssertTrue断言
解决此问题的最直接和优雅的方法是，在@AssertTrue注解的方法内部添加对关联字段的空值检查。这样，即使anInt为null，方法也能安全地执行，并将空值情况的处理权交回给@NotNull约束。
import java.util.Objects; // 导入 Objects 类 @Data public class Dto { @NotNull(message = "anInt 不能为空") private Integer anInt; @AssertTrue(message = "anInt 必须是 123 或 999") public boolean isIntCustomValid() { // 在访问 anInt 之前，首先检查其是否为 null if (Objects.nonNull(anInt)) { // 如果 anInt 不为空，则执行业务逻辑校验 return anInt == 123 || anInt == 999; } // 如果 anInt 为空，则此 @AssertTrue 约束视为通过。 // 空值校验的责任将完全由 @NotNull 承担。 return true; } }
工作原理分析：
- 当anInt为null时，Objects.nonNull(anInt)返回false，isIntCustomValid()方法直接返回true。这意味着对于@AssertTrue而言，当anInt为null时，这个特定的业务规则被认为是满足的。
- 此时，@NotNull约束会正常发挥作用，捕获到anInt为null的错误，并生成相应的校验消息。
- 当anInt不为null时，Objects.nonNull(anInt)返回true，isIntCustomValid()方法会执行其核心业务逻辑（anInt == 123 || anInt == 999），确保只有满足条件的anInt值才能通过校验。
这种方法避免了NullPointerException或HV000090错误，并且清晰地分离了@NotNull和@AssertTrue的职责：@NotNull负责判断是否为空，而@AssertTrue负责在非空情况下判断业务逻辑。
3. GroupSequence与空值安全断言的对比
在Bean Validation中，@GroupSequence和@Groups提供了一种更严格的验证组排序机制，可以确保某些验证组（例如包含@NotNull的组）在其他组（例如包含@AssertTrue的组）之前执行。例如：
// 定义空接口作为验证组 public interface FirstValidationGroup {} public interface SecondValidationGroup {} @Data @GroupSequence({FirstValidationGroup.class, SecondValidationGroup.class, Dto.class}) public class Dto { @NotNull(message = "anInt 不能为空", groups = FirstValidationGroup.class) private Integer anInt; @AssertTrue(message = "anInt 必须是 123 或 999", groups = SecondValidationGroup.class) public boolean isIntCustomValid() { // 注意：这里不再需要 Objects.nonNull 检查，因为我们依赖组顺序 return anInt == 123 || anInt == 999; } }
并在控制器中指定验证组：
@PostMapping("/validate") public String validateDto(@Validated({FirstValidationGroup.class, SecondValidationGroup.class}) @RequestBody Dto dto) { return "Validation successful!"; }
这种方法确实能够保证@NotNull先于@AssertTrue执行，如果@NotNull失败，则后续的@AssertTrue不会被执行。然而，它引入了额外的复杂性：
- 需要创建空的标记接口：每当需要明确的验证顺序时，都可能需要定义新的接口。
- 增加代码量和概念负担：管理多个验证组和它们的顺序会使代码更难理解和维护。
- 适用场景有限：@GroupSequence主要用于需要严格分阶段验证的复杂场景，例如表单提交的不同步骤。
相比之下，在@AssertTrue内部进行空值检查的方案更为简洁，对于单个字段的空值与业务逻辑组合校验的场景，它提供了更低的实现成本和更高的可读性。它将空值安全逻辑内聚在约束方法内部，避免了全局验证顺序的复杂配置。
4. 注意事项与最佳实践
-
选择合适的方案：
- 对于字段级别的@NotNull与方法级别的@AssertTrue结合校验，且@AssertTrue方法依赖该字段的场景，推荐使用空值安全断言方案（即在@AssertTrue方法内添加Objects.nonNull()检查）。这种方案简单、直观，且易于维护。
- 只有当你的业务逻辑确实需要严格的验证阶段划分（例如，第一步验证基本数据格式，第二步验证业务规则），并且这些阶段之间存在依赖关系时，才考虑使用@GroupSequence。
-
清晰的错误消息：确保@NotNull和@AssertTrue都提供了清晰、用户友好的错误消息，以便在校验失败时能准确地告知问题所在。
-
理解校验生命周期：虽然我们通过空值检查解决了特定问题，但深入理解Bean Validation的校验生命周期和不同类型约束的执行时机，有助于更好地设计和调试复杂的校验逻辑。
总结
在Java Bean Validation中，当@NotNull与@AssertTrue同时应用于一个DTO，并且@AssertTrue方法依赖于被@NotNull约束的字段时，为了避免运行时错误，最优雅的解决方案是在@AssertTrue方法内部增加空值检查。通过Objects.nonNull()判断，我们可以确保方法在安全的环境下执行业务逻辑，同时将字段的空值校验职责明确地留给@NotNull。这种方法比使用@GroupSequence更为简洁，更适用于此类特定场景，提升了代码的健壮性和可维护性。
