Meta开发了一种名为 Nullsafe 的新静态分析工具，Meta 使用它来检测 Java 代码中的 NullPointerException (NPE) 错误。
Nullsafe 帮助显着减少了 NPE 错误的总数并提高了开发人员的工作效率。这显示了静态分析在大规模解决现实世界问题中的价值。
在 Android 上，NullPointerException (NPE) 错误是Google Play 上应用程序崩溃的最大原因。由于 Java 不提供表达和检查空不变量的工具，开发人员不得不依靠测试和动态分析来提高代码的可靠性。这些技术是必不可少的，但在信号发送时间和覆盖范围方面有其自身的局限性。
2019 年，我们启动了一个名为0NPE的项目，目标是在我们的应用程序中解决这一挑战，并通过静态分析显着提高 Java 代码的空安全性。
在两年的时间里，我们开发了 Nullsafe，这是一种用于检测 Java 中 NPE 错误的静态分析器，将其集成到核心开发人员工作流程中，并进行了大规模代码转换，使数百万行 Java 代码符合 Nullsafe 标准。
以Meta 最大的 Android 应用程序之一Instagram为例，我们观察到在 18 个月的代码转换期间，生产 NPE 崩溃减少了 27%。此外，NPE 不再是导致 alpha 和 beta 通道崩溃的主要原因，这直接反映了开发人员体验和开发速度的改善。
谈到 Java，从JSR-305开始，曾多次尝试添加空性，但没有一次取得广泛成功。目前，有许多很棒的 Java 静态分析工具可以检查 nullness，包括 CheckerFramework、SpotBugs、ErrorProne 和 NullAway 等。特别是，Uber通过使用 NullAway 检查器使他们的 Android 代码库 null-safe走上了同样的道路。但最终，所有检查员都以不同且微妙地不兼容的方式执行无效性分析。缺乏具有精确语义的标准注解限制了整个行业对 Java 静态分析的使用。
这个问题正是JSpecify 工作组旨在解决的问题。JSpecify 始于 2019 年，是代表谷歌、JetBrains、优步、甲骨文等公司的个人之间的合作。自 2019 年底以来，Meta 也已成为 JSpecify 的一部分。
尽管nullness 标准尚未最终确定，但规范本身和工具方面已经取得了很大进展，很快就会有更多令人兴奋的公告发布。参与 JSpecify 也影响了我们在 Meta 对 Java 的 nullness 和我们自己的代码库演变的看法。
详细点击标题
彩蛋：
令人遗憾的是，Java 8 有机会真正解决 null 问题，但只给了我们半废的 `java.util.Optional<T>`。它不是在语言级别实现可选值，它只是扔进 JRE 的另一个类。
下面是完全合规的Java代码，只是其中Optional包装器本身为空：
Optional<String> getMiddleName() { |
恭喜你，现在你有两种空值。