Java - 在不允许使用@NotNull或@Nullable注释时在编译时检测NPE的最佳方法

我曾经使用过大量的注释来使IDE帮助我在编译时发现潜力。但是，我的新团队不允许使用任何注释，并且不允许使用自定义注释。结果，我比以前更有可能编写由此引起的错误。@NotNull/@NullableNPE@NotNull/@NullableNPE

我尝试了几种解决方案：

1. 在 java 8 中使用。但是，这并不适用于每种情况。通常不建议将其用作字段或参数的类型。同样令人沮丧的是，实例本身可能是 .此外，在调用时很难在 lambda 表达式中操作控制流（在 Java 9 中更容易）。使用太多的s会使代码有点冗长。（更新：不幸的是，可选<T>现在也被禁止使用）Optional<T>Optional<T>Optional<T>nullifPresent(obj->...)Optional<T>
2. 使 IDE 将每个未注释的实例视为 。这个解决方案确实可以帮助我找出一些潜在的错误，但是，IDE会建议我检查几乎所有的方法调用，这真的很烦人，因为许多方法都是故意设计的不返回 。@Nullablenull
3. 检查每个方法调用。这是一个可行的解决方案，但它具有严重的影响，即通过方法调用将无处不在的可能性传递到任何地方。在这种情况下，方法的每个参数都可能是 ，并且当检查参数是否为空时，该方法通常会返回连续参数。最后，每种方法都被“感染”，有可能接收参数并返回 。nullnullnullnullnull
4. 调用以防止上述问题。它稍微减轻了到处检查的痛苦。但是，它不保证调用方不会在不允许的情况下将 a 传递给案例。一旦通过，抛出的运行时就更有可能破坏您的应用程序。Objects.requireNonNull()nullnullnullnullNPE
5. 切换到 kotlin。当然，这是不允许的：）

关于在编译时检测 NPE（并保存我的工作）还有其他建议吗？我认为这个问题的解决方案可以广泛使用，不仅可以帮助我自己，因为并非所有团队都允许使用@NotNull/@Nullable注释和可选<T>s。