Migrate to JSpecify annotations for nullability constraints

[sbrannen]

Overview

Once JSpecify releases a relatively stable (potentially beta) version, we should migrate to JSpecify annotations for nullability constraints.

The current plan is to meta-annotate annotations in the org.springframework.lang package with JSpecify annotations alongside the JSR-305 annotations. Doing so will allow a transition period away from JSR-305 annotations while JSpecify annotations gain traction in the community and proper support from IDEs and build tools.

Related Issues

• Replace @Nonnull(when = When.MAYBE) by @CheckForNull in @Nullable #27183

[sdeleuze]

An interesting related blog post by Meta.

An important improvement would be IMO to update the Spring Framework build to check null-safety at build-time, not just rely on IntelliJ IDEA warnings, and potentially to publish guidelines for Spring portfolio projects and Spring applications that want to do the same.

[sdeleuze]

In addition to the change of artifact and meta-annotations, the switch to jSpecify is expected to allow Spring to refine the following aspects of null-safety:

• Support null-safety at generics, varargs and array elements levels (to be checked depending on which jSpecify version we leverage).
• Better tooling integration, with a build-time check in Spring Framework Gradle build.
• Prevent the unknown enum constant When.MAYBE compile-time warning when Spring null-safety annotations are used without JSR 305 available in the classpath.

[xenoterracide]

usage of jsr305 jar breaks JPMS. So requires monkey patching to deal with this if -Werror is used. and then makes the build also incompatible with javax annotations-api (v1). Although I'm sure people here are well aware of the issues around the 3? jars... I'd hope.

[sdeleuze]

I have dropped a comment in jakartaee/common-annotations-api#124 (comment) as it seems not realistic to me to just drop a bunch of annotations there, this topic is much more complex than that.

Hey, Spring Framework committer here. I am not sure that would be as simple as adding those 2 additional annotations since:

• Spring use case is leveraging meta annotations
• The scope where null-safety applies needs to be specified, in JSR 305, we use @TypeQualifierDefault
• Annotation attributes like When.MAYBE need to be expressed in another way in order to avoid warnings from javac
• Need to have specifications and tooling support

In a nutshell, going beyond simple @Nonnull and @Nullable annotations is a huge task that is much more involved that it seems, as proven in https://github.com/jspecify/jspecify related work.

@xenoterracide Could you please give a try to JSpecify 0.3.0 on a sample application and see if it fulfils your JPMS needs (mostly to provide a feedback to the JSpecify team)?

Myself I plan to experiment with a Spring Framework branch using JSpecify annotations instead of JSR 305 to provide also feedback to JSpecify as they need that for an upcoming release.

[sdeleuze]

It looks like meta-annotation capabilities have been removed from JSpecify 1.0 so using them to meta annotate Spring annotations will not be possible.

The other issue is that the "annote package to set the default to non-null" works differently in JSpecify than with JSR 305. It is expressed with the @NullMarked annotation which does not allow to differentiate the scope where those defaults are applied (while Spring allow to target APIs and field distinctly). I need to have a deeper look to @NullMarked to understand what would be the best path to move forward.

[xenoterracide]

They have decided that for version 1.0 they aren't covering lazy initialized fields. So for situations like JPA it is not a complete solution. This message is simply an FYI.