One of the nice things about IntelliJ is that you don't need to use their annotations. You can write your own, or you can use those of whatever other tool you like. You're not even limited to a single type. If you're using two libraries that use different @NotNull annotations, you can tell IntelliJ to use both of them. To do this, go to "Configure Inspections", click on the "Constant Conditions & Exceptions" inspection, and hit the "Configure inspections" button. I use the Nullness Checker wherever I can, so I set up IntelliJ to use those annotations, but you can make it work with whatever other tool you want. (I have no opinion on the other tools because I've been using IntelliJ's inspections for years, and I love them.)

我非常喜欢检查器框架，它是类型注释(JSR-308)的实现，用于实现像null检查器这样的缺陷检查器。我并没有尝试其他任何方法进行比较，但我对这个实现感到满意。

我没有加入提供该软件的组织，但我是它的粉丝。

我喜欢这个系统的四个方面:

It has a defect checkers for nullness (@Nullable), but also has ones for immutability and interning (and others). I use the first one (nullness) and I'm trying to get into using the second one (immutability/IGJ). I'm trying out the third one, but I'm not certain about using it long term yet. I'm not convinced of the general usefulness of the other checkers yet, but its nice to know that the framework itself is a system for implementing a variety of additional annotations and checkers. The default setting for nullness checking works well: Non-null except locals (NNEL). Basically this means that by default the checker treats everyhing (instance variables, method parameters, generic types, etc) except local variables as if they have a @NonNull type by default. Per the documentation: The NNEL default leads to the smallest number of explicit annotations in your code. You can set a different default for a class or for a method if NNEL doesn't work for you. This framework allows you to use with without creating a dependency on the framework by enclosing your annotations in a comment: e.g. /*@Nullable*/. This is nice because you can annotate and check a library or shared code, but still be able to use that library/shared coded in another project that doesn't use the framework. This is a nice feature. I've grown accustom to using it, even though I tend to enable the Checker Framework on all my projects now. The framework has a way to annotate APIs you use that aren't already annotated for nullness by using stub files.

如果有人只是在寻找IntelliJ类:您可以从maven存储库中使用

<dependency>
    <groupId>org.jetbrains</groupId>
    <artifactId>annotations</artifactId>
    <version>15.0</version>
</dependency> 

对于Android项目，您应该使用Android .support.annotation. nonnull和Android .support.annotation. nullable。这些和其他有用的特定于android的注释在支持库中可用。

从http://tools.android.com/tech-docs/support-annotations:

支持库本身也使用这些注释 注解，所以作为支持库的用户，Android Studio将 检查您的代码并基于这些标记潜在的问题 注释。

如果您正在使用Spring 5。2.执行以下命令:你应该使用Spring注释(org.springframework.lang)，因为它们通过@NonNullFields和@NonNullApi注解为你提供了默认的包范围的null检查。当你使用@NonNullFields/@NonNullApi时，你甚至不会与来自其他依赖的其他NotNull/NonNull注释发生冲突。注释必须用在一个名为package-info.java的文件中，该文件位于包的根目录下:

@NonNullFields
@NonNullApi
package org.company.test;

要排除null检查中的某些字段、参数或返回值，只需显式地使用@Nullable注释。而不是使用@NonNullFields/@NonNullApi，你也可以在任何地方设置@NonNull，但可能更好的是在默认情况下使用@NonNullFields/@NonNullApi激活null检查，并且只使用@Nullable执行特定的异常。

IDE (Intellij)将突出显示违反null条件的代码。如果设置正确，每个开发人员都可以假设字段、参数和返回值必须不是空，除非有@Nullable注释。要了解更多信息，请查看这篇文章。

根据Java 7的特性列表，JSR-308类型注释被推迟到Java 8。甚至没有提到JSR-305注释。

在最新的JSR-308草案的附录中有一些关于JSR-305状态的信息。这包括观察到JSR-305注释似乎被抛弃了。JSR-305页面还将其显示为“inactive”。

同时，实用的答案是使用最广泛使用的工具所支持的注释类型……如果情况发生变化，也要做好改变的准备。

事实上，JSR-308没有定义任何注释类型/类，而且看起来他们认为这超出了范围。(考虑到JSR-305的存在，他们是正确的)。

然而，如果JSR-308真的想要加入Java 8，那么如果人们对JSR-305重新产生兴趣，我也不会感到惊讶。AFAIK, JSR-305团队还没有正式放弃他们的工作。他们已经沉默了2年多了。

有趣的是，Bill Pugh (JSR-305的技术主管)是FindBugs背后的人之一。