JSpecify 1.0.0 发布

JSpecify 是由多个组织和项目组成的集体，旨在为 JVM 语言定义通用的注解类型，以改善静态分析和语言互操作性。JSpecify 1.0.0 是其首次发布，主要关注使用类型注解来指示静态类型的可空性状态。

参与项目与组织

参与 JSpecify 的项目和组织包括：

• OpenJDK
• EISOP
• PMD
• 谷歌（Android、Error Prone、Guava）
• JetBrains（Kotlin、IntelliJ）
• 微软（Azure SDK）
• Sonar
• Spring

兼容性保证

参与 JSpecify 的成员保证其项目在源码级别保持向后兼容性，不会更改注解的名称或位置，确保代码在更新后仍能正常编译。

初始发布重点

JSpecify 1.0.0 主要关注使用类型注解来指示变量、参数和返回值等静态类型的可空性状态。然而，某些概念上不合理的用法（如 class Foo extends @Nullable Bar）仍不被支持。

背景：可空性与空值检查器

Java 生态中的挑战

Java 生态中长期存在关于可空性的讨论，开发者希望通过构建时的静态分析工具减少空指针异常（NPE）。然而，Java 的历史和向后兼容性传统使得在语言中添加可空性支持变得复杂。

历史尝试

JSR 305 是早期的尝试，但最终在 2012 年未能完成标准化。此后，各公司和项目推出了自己的可空性注解，其中 Kotlin 语言在类型系统中内置了可空性支持。

当前现状

在纯 Java 项目中，大多数通过构建时检查器工具处理可空性，JSpecify 试图统一这些方法。1.0.0 版本定义了四个注解：

• @Nullable
• @NonNull
• @NullMarked
• @NullUnmarked

这些注解提供了声明式的可空性支持，适用于 Java 类型。@NullMarked 可用于模块、包或类型声明，表明未注解的类型使用不可为空，而 @Nullable 用于显式标记可空情况。

JSpecify 的应用与未来

项目采用

IntelliJ 已经支持 JSpecify 注解，但泛型支持尚未完全实现。JSpecify 提供了一个参考检查器，主要用于参与项目的内部使用，而非应用开发者。

Spring 框架的参与

Spring 框架项目负责人 Juergen Hoeller 表示，Spring 自 2017 年起采用了非空默认设计，与 Kotlin 集成和 Java 项目结合使用，显著提升了代码的可维护性。Spring 参与了 JSpecify，旨在为注解语义和工具支持提供战略路径。

未来发展

JSpecify 有望取代 JSR 305，成为工具支持和开源框架中常见的注解标准。未来，JSpecify 将继续演进，支持更多需求，如官方元注解支持，以便 Spring 能够使用 JSpecify 元注解而非 JSR 305 元注解。

总结

JSpecify 1.0.0 的发布标志着 JVM 语言中可空性注解标准化的初步实现，旨在通过统一的注解类型改善静态分析和语言互操作性。参与项目的广泛支持和向后兼容性保证使其成为未来 Java 生态中可空性处理的重要工具。