1. 22 3月, 2019 1 次提交
  2. 12 12月, 2018 1 次提交
  3. 22 11月, 2018 1 次提交
  4. 19 11月, 2018 2 次提交
  5. 08 8月, 2018 2 次提交
  6. 20 7月, 2018 1 次提交
  7. 01 7月, 2018 1 次提交
  8. 28 6月, 2018 3 次提交
  9. 09 3月, 2018 1 次提交
  10. 27 2月, 2018 1 次提交
  11. 25 2月, 2018 1 次提交
  12. 22 2月, 2018 1 次提交
  13. 11 2月, 2018 1 次提交
  14. 09 2月, 2018 2 次提交
  15. 06 2月, 2018 1 次提交
  16. 27 9月, 2017 1 次提交
  17. 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
  18. 18 8月, 2017 1 次提交
    • J
      Enforce non-null value from getBean and at injection points · b94302b5
      Juergen Hoeller 提交于
      Bean-derived null values may still get passed into bean properties and injection points but only if those are declared as non-required. Note that getBean will never return null; a manual bean.equals(null) / "null".equals(bean.toString()) check identifies expected null values now.  This will only ever happen with custom FactoryBeans or factory methods returning null - and since all common cases are handled by autowiring or bean property values in bean definitions, there should be no need to ever manually check for such a null value received from getBean.
      
      Issue: SPR-15829
      b94302b5
  19. 17 8月, 2017 1 次提交
  20. 20 7月, 2017 1 次提交
  21. 19 7月, 2017 2 次提交
  22. 30 6月, 2017 1 次提交
  23. 13 6月, 2017 2 次提交
  24. 12 6月, 2017 2 次提交
  25. 07 6月, 2017 1 次提交
    • J
      Consistent use of @Nullable across the codebase (even for internals) · f813712f
      Juergen Hoeller 提交于
      Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments.
      
      Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit.
      
      Issue: SPR-15540
      f813712f
  26. 01 6月, 2017 1 次提交
  27. 31 5月, 2017 1 次提交
  28. 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
  29. 25 1月, 2017 1 次提交
  30. 19 12月, 2016 1 次提交
  31. 24 11月, 2016 1 次提交
  32. 20 7月, 2016 1 次提交