java - 这是从 JSR305 使用 javax.annotation 的正确方法吗？

Question

我最近将 JSR305 的 RI 添加到我的项目中，并一直在我的界面中添加注释，如下所示:

public interface AccountService
{
    @Nullable AccountResult consolidate( @Nonnull Date from, @Nonnull Date to )
}

本着 JSR 的精神(如此处所述)，您认为我在接口(interface)中使用注释是在滥用注释吗？我想指出返回值可以为空，但我认为@Nullable 更适用于“合并”方法。我不会将它们添加到实现中，因为在我编码时，接口(interface)代码是我的指路明灯。

Answer 1

您可以将@NonNull String 视为String 的严格子类。毕竟，任何非空字符串都是绝对是一个“instanceof”@Nullable String，但任何 instanceof @Nullable String 都可能不是@NonNull String 的实例(例如，如果它是 null，它就不会是 null)。

这样看，@Nullable 和 @NonNull 是类型信息，因此是完美的合理的接口(interface)。您是在向实现者表明他们可能会返回 null，并且他们不必担心输入空值，并且您向调用者表明他们不能传入 null，并且他们应该期待 null。

当然，虽然这一切都非常合理，但 vanilla javac v1.6 当然不会强制执行任何这些规定了它为实际类型强制类型安全的方式。但是一个人可以梦想，或者一个人可以使用像 pmd 或 findbugs 这样的东西来完成验证这些注释的工作。

不过，@NonNull 和 @Nullable 注释对于一个完整的空类型系统来说是不够的。我真的不知道为什么 JSR305 没有解决这个问题，但还有第三种类型:@MaybeNull。它会出现在泛型参数中；在其他任何地方，它的含义都与 @Nullable 相同。

public static <T> void addIfNotNull(List<@MaybeNull T> list, @Nullable T item) {
  if ( item != null ) list.add(item);
}

如果第一个T上的注解有@Nullable，那么就不能传入非空列表，这将导致一个相当无用的 API。另一方面，如果是@NonNull，则不能通过一个可为 null 的列表。实际上，无论您在其中移动什么，它都会

1. 永远不会导致 NullPointerException，并且
2. 绝不违反注释。

所以，你需要一种方式来表达:我不关心这个特定的 T 是否为 Nullable；我会在读取它时进行空检查，并且我会永远不要写空值，所以没关系。

@MaybeNull 和@Nullable 之间的区别类似于?在泛型中扩展 Number 和 Number。在泛型之外，它们的意思是一样的，但在泛型中有区别。

所以，不要对很快的严格类型检查抱有希望。

@Inherited 仅适用于类，但可以想象类似的东西用于带注释的返回类型和带注释的参数。