search

spring-projects / spring-framework

Spring Framework
https://spring.io/projects/spring-framework
Apache License 2.0
56.14k stars 37.95k 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 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

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 6 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 6 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 5 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 5 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 1 month ago

JSpecify 1.0.0 has been released. It does not provide meta annotation / implication capabilities yet so we will probably need to wait for JSpecify 1.1 to be able to leverage it in Spring.