Spring Lang注解与JSR305元注解差异探究：以NonNull与Nonnull为例

Great question! Let’s dive into the key differences between Spring’s org.springframework.lang.NonNull and JSR-305’s javax.annotation.Nonnull, and unpack why Spring chose to develop their own annotations instead of leaning on the existing standard.

核心差异 #

1. 归属与维护主体 #

• JSR305是Java EE（现Jakarta EE）的官方规范，由Eclipse Foundation维护，但该规范已经长期处于停滞状态（最后一次更新是2006年），没有后续迭代或适配新Java特性的计划。
• Spring Lang注解是Spring Framework团队完全自主维护的，属于Spring生态体系的一部分，会随着Spring版本迭代持续更新，适配Java新特性（如JPMS模块化、虚拟线程等）。

2. 生态集成能力 #

• Spring的注解提供了JSR305没有的批量生效特性：比如@NonNullApi（标记整个包下的方法返回值默认非空）、@NonNullFields（标记类中所有字段默认非空），能大幅减少重复标记的工作量，完美适配Spring项目的包结构和开发习惯。
• 在Spring生态组件（Spring MVC、Spring Data、Spring Boot等）中，Spring Lang注解的支持更深度：比如Spring MVC会自动校验@NonNull参数的空值，Spring Data在Repository方法中会对@NonNull返回值做空值检查；而JSR305注解在这些场景下的支持需要额外配置，且一致性不如Spring原生注解。

3. 兼容性与依赖轻量化 #

• JSR305的依赖（如com.google.code.findbugs:jsr305）在现代Java环境中可能存在兼容性问题：比如Java 9+的模块系统中，JSR305的jar没有模块化描述符，容易引发模块依赖错误；而Spring Lang注解是Spring Framework核心模块的一部分，无需额外引入第三方依赖，避免了依赖冲突。
• Spring的注解在语义上更贴合Spring的开发语境：比如@NonNull vs JSR305的@Nonnull，命名更直观，且Spring对注解的空值检查逻辑在整个生态内是统一的，不会出现不同工具（如IntelliJ、FindBugs）对JSR305注解解读不一致的情况。

Spring自研的原因 #

1. 摆脱停滞规范的束缚 #

JSR305作为一个停滞了十几年的规范，无法适配Java和Spring生态的发展节奏。Spring需要能快速迭代、适配新特性的注解体系，自研可以完全控制注解的演进方向，不会被外部规范的停滞拖后腿。

2. 满足Spring生态的定制化需求 #

Spring的批量注解、深度组件集成等特性，都是JSR305无法提供的。为了给开发者提供更流畅的开发体验，Spring需要一套能和自身生态无缝融合的注解，而不是在现有规范上做妥协性的扩展。

3. 保证依赖的轻量化与稳定性 #

引入JSR305依赖会增加项目的依赖树复杂度，甚至引发版本冲突（比如不同库依赖不同版本的JSR305）。Spring自研注解可以避免这些问题，同时保证注解的行为在Spring生态内完全一致，减少开发者的调试成本。

4. 语义明确性 #

JSR305的注解在不同工具和框架中存在语义歧义：比如有些工具将@Nonnull视为“编译期提示”，有些则视为“运行期校验”。Spring的注解则明确了自身的语义——既支持IDE的编译期提示，也支持Spring生态内的运行期校验，语义清晰无歧义。

内容的提问来源于stack exchange，提问作者Loop