search

spring-projects / spring-framework

Spring Framework
https://spring.io/projects/spring-framework
Apache License 2.0
56.68k stars 38.15k forks source link

Migrate to JSpecify annotations for nullability constraints #28797

Open sbrannen opened 2 years ago

sbrannen commented 2 years ago

Overview

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

The previous plan was to meta-annotate annotations in the org.springframework.lang package with JSpecify annotations alongside the JSR-305 annotations, but JSpecify won't provide such meta annotations for various reasons. So the new plan is to leverage directly JSpecify annotations and deprecate Spring Framework null-safety annotations.

Related Issues

sdeleuze commented 1 year ago

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 commented 1 year ago

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:

xenoterracide commented 9 months ago

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 commented 9 months ago

I have dropped a comment in https://github.com/jakartaee/common-annotations-api/issues/124#issuecomment-1943490978 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 commented 7 months ago

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 commented 7 months ago

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.

sdeleuze commented 4 months ago

JSpecify 1.0.0 has been released. It does not provide meta annotation / implication capabilities.

sdeleuze commented 1 month ago

After evaluating various options, we have decided to tentatively migrate Spring Framework 7 to JSpecify annotations and deprecate Spring null-safety annotations.

Even more important than the annotations themselves, the specifications as well as the resolution of the split package issue caused by the JSR 305 annotations impacting JPMS, the ongoing work in the ecosystem for JSpecify support in tooling or Kotlin and the capability of specifying generic type, array and varargs element null-safety have been strong reasons for this choice.

This will also enable consistency with other libraries not based on Spring that we maintain (if the project leads agree to do such move as well) like Reactor or Micrometer, and hopefully other ones we don't, helping the wider JVM ecosystem to gradually check more and more for null-safety at build-time rather seeing NullPointerException thrown on production.

hantsy commented 1 month ago

It seems JDK plans Nonnull/Nullable support in the future. https://bugs.openjdk.org/browse/JDK-8303099

sdeleuze commented 1 month ago

Indeed, and we are tracking this JDK effort, which will have a different timeline and some specific goals (JVM optimization angle, backward compatibility), closely.

We expect null-safety information provided by JSpecify annotation to be useful to build a bridge between JDKs not supporting null-safety and those which will.

The Spring team also intends to provide feedback to the Java Platform team on the related JEP.

xenoterracide commented 1 month ago

Hopefully we see a more bulk option/default soon TM. I might comment that I'd like to know if it will be able to do inference which is something that no other solution has been able to do and is probably not completely possible outside of java itself.