Skip to content

S
spring-framework

爱吃血肠 / spring-framework

通知 1
Star 0
Fork 0
S
spring-framework

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 22 3月, 2019 1 次提交
  3. 09 1月, 2019 1 次提交
  5. 25 7月, 2018 1 次提交
  7. 02 7月, 2018 1 次提交
  9. 11 1月, 2018 1 次提交
  11. 24 10月, 2017 1 次提交
  13. 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
  15. 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
  17. 07 7月, 2016 1 次提交
  19. 05 7月, 2016 1 次提交
  21. 20 5月, 2015 1 次提交
  23. 08 12月, 2014 1 次提交
  25. 26 11月, 2013 1 次提交
    • P
      Fix remaining compiler warnings · 59002f24
      由 Phillip Webb 提交于 
      Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.

Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.

Issue: SPR-11064
      59002f24
  27. 10 10月, 2013 1 次提交
  29. 18 1月, 2013 1 次提交
  31. 29 12月, 2012 2 次提交
  33. 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
  35. 01 12月, 2011 1 次提交
  37. 10 10月, 2011 1 次提交
    • C
      Distinguish between different bridge method types · 980c15d5
      由 Chris Beams 提交于 
      Add BridgeMethodResolver#isJava6VisibilityBridgeMethodPair to
distinguish between (a) bridge methods introduced in Java 6 to
compensate for inheriting public methods from non-public superclasses
and (b) bridge methods that have existed since Java 5 to accommodate
return type covariance and generic parameters.

In the former case, annotations should be looked up from the original
bridged method (SPR-7900).  In the latter, the annotation should be
looked up against the bridge method itself (SPR-8660).

As noted in the Javadoc for the new method, see
http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html
for a useful description of the various types of bridge methods, as
well as http://bugs.sun.com/view_bug.do?bug_id=6342411, the bug fixed in
Java 6 resulting in the introduction of 'visibility bridge methods'.

Issue: SPR-8660, SPR-7900
      980c15d5
  39. 26 11月, 2009 1 次提交
  41. 16 2月, 2009 1 次提交
  43. 27 11月, 2008 1 次提交
  45. 22 10月, 2008 1 次提交