1. 22 3月, 2019 1 次提交
  2. 15 9月, 2017 1 次提交
    • S
      Revisit nullability annotations · 1bc93e3d
      Sebastien Deleuze 提交于
      This commit introduces the following changes.
      
      1) It adds a new Spring @NonNull annotation which allows to apply
      @NonNullApi semantic on a specific element, like @Nullable does.
      Combined with @Nullable, it allows partial null-safety support when
      package granularity is too broad.
      
      2) @Nullable and @NonNull can apply to ElementType.TYPE_USE in order
      to be used on generic type arguments (SPR-15942).
      
      3) Annotations does not apply to ElementType.TYPE_PARAMETER anymore
      since it is not supported yet (applicability for such use case is
      controversial and need to be discussed).
      
      4) @NonNullApi does not apply to ElementType.FIELD anymore since in a
      lot of use cases (private, protected) it is not part for the public API
      + its usage should remain opt-in. A dedicated @NonNullFields annotation
      has been added in order to set fields default to non-nullable.
      
      5) Updated Javadoc and reference documentation.
      
      Issue: SPR-15756
      1bc93e3d
  3. 27 5月, 2017 1 次提交
    • S
      Introduce null-safety of Spring Framework API · 87598f48
      Sebastien Deleuze 提交于
      This commit introduces 2 new @Nullable and @NonNullApi
      annotations that leverage JSR 305 (dormant but available via
      Findbugs jsr305 dependency and already used by libraries
      like OkHttp) meta-annotations to specify explicitly
      null-safety of Spring Framework parameters and return values.
      
      In order to avoid adding too much annotations, the
      default is set at package level with @NonNullApi and
      @Nullable annotations are added when needed at parameter or
      return value level. These annotations are intended to be used
      on Spring Framework itself but also by other Spring projects.
      
      @Nullable annotations have been introduced based on Javadoc
      and search of patterns like "return null;". It is expected that
      nullability of Spring Framework API will be polished with
      complementary commits.
      
      In practice, this will make the whole Spring Framework API
      null-safe for Kotlin projects (when KT-10942 will be fixed)
      since Kotlin will be able to leverage these annotations to
      know if a parameter or a return value is nullable or not. But
      this is also useful for Java developers as well since IntelliJ
      IDEA, for example, also understands these annotations to
      generate warnings when unsafe nullable usages are detected.
      
      Issue: SPR-15540
      87598f48
  4. 21 10月, 2014 1 次提交
  5. 29 12月, 2012 1 次提交
  6. 31 1月, 2012 1 次提交
    • C
      Rename modules {org.springframework.*=>spring-*} · 02a4473c
      Chris Beams 提交于
      This renaming more intuitively expresses the relationship between
      subprojects and the JAR artifacts they produce.
      
      Tracking history across these renames is possible, but it requires
      use of the --follow flag to `git log`, for example
      
          $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java
      
      will show history up until the renaming event, where
      
          $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java
      
      will show history for all changes to the file, before and after the
      renaming.
      
      See http://chrisbeams.com/git-diff-across-renamed-directories
      02a4473c
  7. 01 6月, 2009 1 次提交